Report Writing in Penetration Testing: Pwn that reader!

hello everyone today we are going to talk about that part of penetration testing which is as important as any of its other parts for example be it reconnaissance or exploitation reporting is important but this is something that is really less talked about so in this session we are going to talk about report writing in penetration testing a report is a critical document especially in penetration testing it deals with security critical observations for that matter take any cyber security engagement be it security audits be it source code reviews be it compromise assist assessment engagement the final deliverable will always be a report now summaries of these observations can also be communicated verbally but then complete and final report is always a

written document now we know this from our experience as well have we ever uh see the situation where our pentest observations were recorded and we have audio stored of it no right the final deliverable will always be a written document and that is exactly why that when we are working in a dynamic field like penetration testing it is important that attention the relevant attention is given to one of the most important phases of penetration testing that is report right so now that the stage has been set let's get going so first things first who am i my name is ashwini varadkar and i am working as a lead quality assurance analyst fondly the storyteller at not to secure

and if i have to summarize my journey i started my career as a technical writer and cyber security analyst moving ahead to becoming a pen tester a senior security analyst and then working as a lead qa in cyber security so since i started my career as a tech writer and i was always passionate about writing my interest and my passion was also there towards reports it was natural because i used to love writing so during report debriefs or while writing pentest reports if the client did not understand any finding or be it for any other team member if the client came back and they needed an explanation i used to be curious as to why

did the client not understand what did we miss or if we have not written it correctly did we understand the finding so this curiosity led me to explore report writing more identify common mistakes come out with ways in which how report writing could be improved and as a part of my journey i paid special attention to different kinds of reports in pen test by various consultants i have an experience of reviewing reports from various consultants different years of experiences different projects different templates so in this session i am going to utilize my experience and try to and try to put forward whatever i gathered during these years of experience in cyber security so let's get going

now since we are talking about reporting in penetration testing the first thing that we should understand is what is penetration testing or the objective now when i say penetration testing a lot of people think about vulnerabilities criticality is shell access fine fair enough penetration testing is a exhilarating domain but is that the objective like discovering vulnerabilities taking pocs images and then what storing them in a folder no right do we send across a folder to client no so the actual objective is to identify vulnerabilities report confirmed and validated vulnerabilities if remediation is part of the scope write about remedial measures and then send across this report now based on the remedial measures provided the client will start

fixing those vulnerabilities to achieve security so the ultimate goal of penetration testing is security now if we map penetration testing the goal of penetration testing to security we automatically understand that okay vulnerabilities are important but if we cannot communicate and if we are not on one page with a client in terms of vulnerabilities and remedial measures then there might be a gap in understanding so the objective of penetration testing is security now just before the session i did a small survey because i wanted to understand what our fellow pen testers what fellow pentesters have to say about some questions for example i just asked them what is the ultimate goal of pen test you can see the result here 66 percent

were correct in guessing security obviously the options are a bit tricky but if we have to remember security is a main objective so then automatically communication skills also comes into the picture also steps of ethical hacking now when as newcomers we started studying about security this was the cycle that we were told about we were explained about or hacking methodology ethical hacking cycle so if we see reporting is a very important part in this entire process now if you are a freelancer or if you are doing independent pen tests sometimes it's only from recon to this and there is reports are important but when you are in an organization reporting is a bit different there are report reviews then are report

debriefs so there is a process and there is no running away so this is where reporting stands in penetration testing in and penetration testing engagement and that is why we need to understand the objective first and then go towards how we can improve our writing now if you see this question do you think reporting in your organization is given the attention that it deserves now 55 percent of people have said no so this is quite alarming now when i say attention meaning in terms of training in terms of review in terms of a person who is accountable if there is any doubts related to report writing or sentence formation etc so this is something really alarming

now problem areas because we are adamant in our likes and more so in our dislikes see when we the first thing towards resolution of a problem is that we need to acknowledge that a problem exists now there is no problem per se but then report writing is really a highly despised task if you ask pen testers what is that they don't like in this pen test methodology they'll say reporting because it's like it involves a lot of time and you have to write and there is nothing cool or dynamic about it so the problem statements which i found are additional tasks a lot of pen testers consider report writing as an additional task the fact is penetration report writing

is as important as any other phase like i said reconnaissance exploitation any phase it is a part of pentest and when we look at reporting when we considered it as an important part we automatically feel like investing time in it if you think of it as an additional task you might not want to invest time or you'll be reluctant when any trainings are provided when any feedback is given next accelerating domain now this is important and i wanted to share as a newcomer when we hear about cyber security that we want to make a career in cyber security we immediately think of hacking then there are cyber crimes cyber cells etc all cool stuff but we don't think about communication

skills at this stage fair enough as a senior if i have to switch from some domain to cyber security again i will think about various certifications and how i can move laterally and change my domain right i will think about again communication skills there fair enough but what happens is when they enter into this field and they realize that almost 40 to 50 percent of their time is going to be invested into reporting into amendments as per the changes that are suggested in report debriefs communication skills speaking and writing more so they find it really different that okay oh god there's a lot of reporting can we simply not automate the entire reporting but we don't want to learn

they're reluctant there's some kind of a reluctancy towards trying to invest time in report writing so then is communication skills more important than the skills that are required for ethical hacker no but then balance is the key both are equally important now if we go back to this cycle there's one more important thing that from recon to here the skill set that is required is different and if you see reporting and debriefs the skill set that is required here is different this is communication skills and these are our technical skill sets which are required for assessments so this is the thing what i mean by skill sets that two different skill sets are required when we say we are a pen

tester or a consultant it is a it is a job that we are also focusing on communication skills because like we saw the final two stages are of communication skills so these are three problem statements that we need to address and as and when we also start preaching about communication skills about the importance of reporting at initial stages or when somebody is trying to enter into this field they'll be prepared that this is something that they need to learn and gradually we'll see a day that reporting will be like everybody will be good in reports and in speaking because they already have been preparing themselves gaining technical knowledge and also working on communication skills now the need for good report writing

so if you are really good in identifying vulnerabilities and you have found critical vulnerabilities there are chaining of attacks and everything but if you cannot transfer this knowledge correctly to the reader your knowledge will be limited to you so this is completely your loss because you have studied something but you're not able to put put forth your story to the reader so because of this your knowledge your hard work is restricted to you second point is good impression now suppose you are reading a report that has a lot of spelling mistakes incoherent sentence is like sentences from which any meaning cannot be derived by seeing such reports you will doubt the credibility of that report even

though it is technically accurate you will still doubt for that matter imagine you're getting an email from a legitimate source and there are a lot of spelling mistakes uh inconsistencies with regards to cases the first thing that you will think is is that a phishing email you will right so this is a thing a bad report will affect your image your impression as well so when you are investing time in reporting it is also for your own self for knowledge transfer and also that your report is considered and it is a dc and it is really recently received by the reader now again this is yet another alarming thing do you personally like reporting people don't like reporting again i

think if we go back to the problem statements that they think it is an additional task but it's very much a part of pentest and i'm sure gradually there will be a change tech writing versus content writing this is one beautiful thing that i learned from a mentor difference between tech writing and content writing now when it's penetration testing it comes under tech writing okay now this is some comparison that i did on three factors only the first factor is style okay so the style for technical writing will be formal on technical topics content writing informal on non-tech topics right the vocabulary here is professional and for technical audience your general evocative technical writing is to inform

instruct content writing inform entertain right so if you see technical writing sounds like something very strict official and content writing free flowing poetic kind of but if you go by this definition and if you write technical writing as per these points you will fail you cannot just spit facts at readers they need to be told a story so for a good technical writing these two points in red from content writing needs to be embedded technical writing can be emotional technical writing is technical storytelling you can entertain people via your technical write-ups so this is very important that technical writing is really not that strict as it sounds and once you understand this that it's all about technical storytelling keeping

things simple you will enjoy technical writing or pentest report writing now that we understand that penetration testing can be free flowing too just we need to keep some simple things in mind like not to use jargons or internet words keep it simple decent and then you get your technical writer now let's dissect a penetration testing report now i have divided the report into two parts of course there are other parts in a report like executive summary there might be appendices so the two key parts that i have identified are the proof of concept and risk rating now the proof of concept is a key part because this is where you talk about vulnerabilities the readers will refer

to this if they have to reproduce the attack correct and this is one part which cannot be automated so the real writing the real storytelling happens at this section and the other important key part is the risk rating you organize your findings as per risk rating now be it qualitative risk assignment or numerical scores based on cbss or any other method that you use so risk rating will allow you to arrange your findings and the proof of concept is the evidence that a vulnerability existed when you tested that particular asset and it's a proof evidence so these are the two key parts and the other parts like description mitigation now why mitigation is not in key part

because sometimes for pen test engagements mitigation might not be compulsory it depends upon the scope and what was agreed upon mitigation at a high level can be reused even description now when i say description it is description of a vulnerability mostly we write a generic description like suppose sql injection then we talk about sql injection we talk about in lack of input validation in the description itself impact that it may it will have so if you have already written a description of sql injection for any client you may reuse that part mitigation also at a high level can be reused then depending upon the client and the circumstances you can make some changes but other than that

a lot of content can be reused or you can automate it right so the actual writing or the challenges faced by pen testers if we see is in the proof of concept section so we are going to talk about how proof of concept can be framed how we can frame sentences uh by using various ways and this will also help you with the description as well but since description is a generic part and not very challenging we will focus on proof of concept for this session now if you see here the question was do you write a lot of reports so yes but there are some places where the reports are completely automated

okay now for this session i have created a formula report writing will be storytelling plus immediate takeaways now storytelling and immediate takeaways are basically two sections in this ppt in this session so when i say storytelling it is going to be all about writing and writing takes time you will start writing you will gather feedback you will work upon all the changes that are suggested to you and gradually you will improve your storytelling or writing but immediate takeaways these are some basic points which you can immediately start implementing in your technical write-ups now decent writing and store or storytelling and these basic pointers together will definitely ensure that 60 to 70 percent of your work is done

now remaining 40 to 30 percent work will be done by reviewers when you get a different perspective or input on your reports you automatically get good quality points and your work is done like 80 to 90 percent work is done there because someone is reviewing it and when we spend a lot of time in our reports there'll be a point that we cannot find any mistakes in it fair enough fresh the power of fresh perspective is really great the storytelling and immediate takeaways and reviewing a very important part of report writing process will ensure that you have a good quality report with you so like i said storytelling will take time so first let's understand the immediate takeaways

now you can also have a checklist in place you can note down the points like okay as in when you check one one points i mean once you write your report you can check then if these basic pointers were ensured in the report now the first point is getting the names right now just like how our names are official and defined the name of a software tool attack parameters our organization name client organization name these are all official and defined and in no way should we change those now the best way to understand the official names for the tools or attacks or parameters is to check official websites whatever is written then written there you can use it in your reports for

example jquery not jquery with small queue click jacking like this is wrong now csrf token if in request the developers have written csrf token like this please do not change it to csrf token small t or csrf space token now if you observe that later looks like an english word like we are talking about csrf token in the request that's it but not the csrf token the tokens theme so this is important even attacks like poodle it's an abbreviation so you need to write it like that these small important things if you take care initially during reviews a lot of time will be saved another important point is images or screenshots images or screenshots are used as

evidence in reports they support your proof of concept and helps client reproduce the issue now images are really important one because just imagine if there's a report uh having only descriptive lines and no image it will be very difficult for you also to paste your output to show the client of the exact scene that happened when you executed a command so description and images together enables readers to understand better what had happened and the folders that you visited and how the output or the error looked also there is one more thing that images are important it is important for a consultant or a tester as well sometimes suppose there are two three pen testers testing one asset

and suppose a tool is giving you a different output or an ip is unavailable to you so when you attach a screenshot it gives readers the idea that okay really at that point of time this tool did not work as expected with you or an ip was not really available so it's a proof for yourself as well and when any issue is found for the clients as well now the basic checks related to images that you should take care alignment consistency is the key if you have aligned your image towards the left ensure all your images are aligned towards the left or center whatever consistency is the key here clarity the image should be clear

now it may so happen that the font size on the terminal might be really small so when you take the entire page the image will automatically become smaller and it may be unreadable so clarity is important even the terminals of some tools or some operating systems are like transparent so the back end folders are visible so ensure that you have a correct setting and relevant highlights some tool outputs give a lot of uh out some tools give a lot of output you know like there'll be a huge page so if the page is important you can paste it but ensure that you are highlighting relevant points so that the reader is automatically directed towards those highlights and they don't have to

search okay what is to be seen here if you say some old version has been detected so where is it because there's a lot of write up a lot of content numbers versions license information there could be anything so highlights are important apart from that highlights are important masking is important now if your poc is about hashes or passwords even though you are sharing it with your client there are many stakeholders in the client organization as well so in order to keep that privacy mask those hashes or passwords because we don't want anybody to understand the pattern of it we can have in internal malicious actors right so it's best that you mask hashes so

that nobody is make able to make sense out of it another reason masking is important is like suppose you're capturing your entire desktop screen and by mistake there's a folder about some other client so you don't want to give that information or if there is any personal information or bookmarks and you don't want to reveal that so ensure that correct things are masked before you are submitting your report again these are basic things that you can if you have a checklist i think it will it will be easier you can take that okay alignment has been reviewed for self review you can make a checklist of these immediate takeaway points now highlights and emphasis okay so in cyber security we come across

various terms which mean differently in english language and in cyber security engagements for example when we say a cookie was not secure okay now if you are talking to a fellow pen tester he will immediately understand that you are talking about insecure cookie transmissions but if you have written it just like this a reader will think that you're talking about a cookie which is not secured that is it is not protected that's it but if you add a single quote over here for secure if you add a single quote you're automatically stressing that this is not ordinary secure term we are trying to say something else we are talking about the attribute secure so this message automatically

gets delivered if you hide if you use highlights and emphasis in a proper way another example i can think of is a tool called eyewitness so if you say using eyewitness you did xyz so if there are no highlight of some kind or if you don't add this term tool so eyewitnesses also means human beings human being eyewitness as a proof of concept so highlights and emphasis is important now you can use bold italics single double quotes again consistency is the key here if you have started with bold use that throughout single quotes then single quotes avoid using underlines because underlines will give it a flavor of a link or even color codes like sometimes

you're using red green people the readers might not know of the color codes so avoid colors and you can stick to these options and again you can make a habit like if you are writing a report anytime it will be bold only always so that there is no confusion and you will automatically get that hang of consistency as well so this is why highlights and emphasis are important even for that matter codes scripts if you are appending code or code snippets in your report you may want to use a different form so that the reader understands immediately okay this looks like a request captured in any tool maybe so you get that effect that okay this is

something different this is a script so use these things even for payload you can use a different font suppose if there's a url and in the url there's a affected parameter and you have appended your payload so try to give a different format to the payloads that just by looking at it you know this is not something regular not a part of the url so these are things that you can you should definitely implement in your reports

case consistency another basic simple thing that you can immediately start taking care of the title subtitles or figure captions must have case consistency now either all the titles are like this like the first letter is capital or the first letter is capital and the first letter of second word is not so this consistency is also important be it titles subtitles or figure captions the same rules apply now imagine if you don't take care of this and if you get a feedback that please ensure consistency this is going to be extremely time consuming later on so you might have to note this initially again like i said make your own checklist and just decide that this is what you are

going to stick to no matter what report you write so these are some of the immediate takeaways that you can immediately start implementing apart from this there are some points like not using ampersand for formal writings it's not wrong nobody even highlight that but we can avoid ampersand using etc a lot you can end it like this like x y and z such as x y and z so when we say such as x y and z we are automatically implying that there could be more such as this this and this so you can you should avoid etcetera if possible so these are some simple things that you can avoid in your writing okay coming to storytelling

this is where we are going to talk about writing and in pentes reports proof of concept section is the section where storytelling happens and this is one part which cannot be automated this will be different as per different situations different clients you can automate the description of vulnerabilities or remedial measures but storytelling you have to do it there is like no running away from it now as a part of that survey there was one question which section in the report do you find challenging so if you see poc a lot of people had troubles with poc description impact there were a lot of more responses all geared towards poc so yes of course poc because

vulnerabilities can get complicated and explaining this to readers can be challenging okay so before anything we need to understand the concept of proof of concept now this line is important penetration testing is a proof of concept based approach of finding vulnerabilities so it's a proof of concept based approach not exploitation based exploitation does not happen always for some reason we are required to do non-intrusive testing right sometimes due to time constraints we cannot exploit a vulnerability fully so pen testing is a proof of concept based approach okay so what is a proof of concept so proof of concept is basically where our focus is towards determining whether an idea or a concept can be turned into reality it might not be

complete but can this be developed modified further into a wholesome attack correct so this is proof of concept now the main purpose of poc is to demonstrate the vulnerability and to verify a certain concept or theory that can be achieved in development now proof of concept means different and different domains okay like software testing poc versus prototypes there is a different argument right there in cyber security like i said whether an idea can be converted to reality this is the key point here now i did not think of this really deeply when i started but i was just going through some exploit codes and i wanted to determine scores okay so i saw that some public exploits were

rated as high okay so the description associated with high was that the exploit code is functional it works in all the situations publicly available and plus there are automated tools available for it or the code is written in such a way that it can be automated so it was most harmful then i saw if high exploit code is functional in every situations then what is functional exploit code so the functional exploit was described in just one line that functional exploit code works in most of the situations that's it so basically this was high but high always worked could be automated functional worked in most of the situations not always okay then there was something called as the

exploit code was just proof of concept based so meaning it was not 100 and a lot of modifications were to be required from the testers or consultants end so when i read about the difference between these three terms that is when i realized okay so proof of concept is uh in itself a different concept and yes this is what it means so when i was exploring about exploit quotes i came to know the deep meaning of proof of concept again it reminds me that now since proof of concept is not might not really be wholesome a lot of low and informational vulnerabilities should be reported because we are talking about development here like today we are not

able to exploit but tomorrow this idea can be exploited so anything you feel can become a big issue tomorrow should be reported so that is what a proof of concept is now the target audience this will determine an important part of writing so when you say client it's never one entity when it's spent as profession but an entire organization involving various stakeholders some of the various stakeholders are as below senior management technical and non-technical now since this is a senior management and since we are talking about security of our own organization security posture i think everybody will be interested so when we say security senior management it's it can be technical and non-technical so that is your first

audience there then we have developers because if a web application has been developed by a developer it is them who should know about the flaws and the remedy is going to be implemented by the developers so yes the developers must understand the vulnerability and also the remedial measures and clarity so that they can make those changes in their product or their application then we have our fellow pen testers now suppose for some reason you cannot continue your pen test or you might not be able to give report debriefs or anything so your fellow pen testers will take that ahead or if you have been working in teams then your pen testers may continue your project like for

example you wrote the report but someone else is going to present so your fellow pen testers will refer your report okay so this is one audience who should understand whatever you have written now pen testers could be in our organization and in target organization as well so this is the third audience that is going to read your pen test report and of course auditors who refer pentest reports as a part of audit like if there is annual audit biannual sorry or annual pen tests by annually pen tests and if there is a criteria for some certification then they will want to see of course they are not going to refer it in deep but they will go through it so this is

your fourth audience who's going to refer to your pen test reports report now if you observe they are technical people except for the non-tech senior management everybody is technical but their level of technical competency is different so your your challenge is to effectively educate all these stakeholders at their level and you are going to be delivering only one report so you need to be damn sure that your report is written in such a way that all these readers so that all these readers are going to make sense out of it okay so a single document that is of beneficial to these people are technical but they have different technical competency now what is it that what is

the common element that will allow you to write a report which is understood by all these stakeholders so that is simplicity a simple writing cuts thick skulls so when you write in the most basic way that is easier for you as a writer and everybody can make sense out of it so simple writing it is when it's pen testing you have to ensure that you are basic and there are no shortcuts and you just write all the steps now using plain english now i didn't know about this concept before but recently i came across this plain english now plain english is a language which is which uh which asks the writers to use only as

many words as necessary so we achieve plain english by using everyday words it is the simplest form of writing the idea is to allow readers to only focus on the message instead of being distracted by jargons any complicated phrases or any complication for example if you want to write some word and you are writing a formal document and then you check for synonyms then you're complicating it plain english is all about keeping things really simple now i would really suggest that you all read more about plain english there are also campaigns where in which people are trying to uh rewrite official high of highly official documents beat government and all in simple language so that a layman can

understand so this is the whole objective of plain english plus plain english makes good business sense and you might want to read and this will help you greatly when writing pentest reports because we do have findings which are really complicated and if you stick to plain english because pen test reports a formal report so we end up thinking that okay do we want to use some high five words no plain english is all about using simple languages everyday words and it is used in business documents as well so this is something that you should definitely explore more now sentence construction we all talk talk about uh different ways like read so that your writing improves speak so that your writing

improves but to improve writing you write and you get it reviewed so that you get feedback and you again write and this is the only way how you can improve your writing so now if you're talking about people writing or storytelling sentence construction is important so one of the most important part in sentence construction that greatly helps me is mind maps now when i say mind maps i'm not talking about any tool on the system like using your mouse dragging from here to there of course when the complication is high and if your mind maps is going to be really really big then you cannot do it offline then you need tools but then you know pen and paper the

power of pen and paper doodles is really underrated so what i feel is no matter what the attack is if i have a white board or a notepad in front of me before starting to frame poc poc statements or sentences what i do is i just start doodling okay now i've got idor what was the action okay password could be changed what was since it's idol what was the exposed parameter or the insecure object id parameter okay was authentication required you write your yes no now if you also got something related to privileges like if you could escalate privileges then talk about the user with the user that you used to sign into an account to sign into the application so

you write your user a with low privileges then idea of user a was changed to to that of b and we had high privileges so you know make these star marks and make doodles now if you see this might this is not an order it's okay if you have not followed a particular stepwise order but once you have this in front of you you can refer to it and then decide okay the first step should be user a with low privileges so you can say that the tester signed into the application with the role of user a which had low privileges so this is how you can frame sentences this you can also do in the report

report itself like before starting the poc section just make bullet points this was the issue this is important to this finding like idol so first is what is that direct object note that url affected parameter what could be done so mind maps and doodlings rough work greatly helps in sentence construction this is really important so what happens is when you have this in place you can simply slowly frame sentences around it your job becomes a lot easier rather than you know just seeing the screenshots and if everything is in your mind it's difficult okay what had happened so first you can have a rough work and then make it fair another important point is dictionary

now if you're using ms word or any other tool any other software so like for example in word xyz was able to do something so was able to automatically get a red line below it so that will be replaced by good correct in order to gets replaced by two so there are these things use the power of computers you can have various tools for uh spell checks dictionary keep it on and just see the suggestions now when and if you're using plain english you're already writing in a most basic language and with this suggestions you'll get a good decent sentence right there so use dictionaries and everything that is easily available then we have tenses

now the tense for any verb is its setting in that time okay now first you need to decide whether your proof of concept is going to be in past tense present tense or future tense then you stick to that decision ensure consistency and only change if there is a need for that tone to change mixed tenses are allowed but depends upon the situation now if you see this sentence it was discovered that the application used an outdated version of xyz which is vulnerable so it was discovered which is vulnerable to cve whatever okay now here if you say which was vulnerable no that vulnerability is like kind of forever there was a version of xyz software and it is well

vulnerable to this cve a cv id has been assigned and this is going to be forever so when the reader reads for him it will be like when the testing was done in the past it was discovered that an application used an outdated version of xyz which is vulnerable because when he is reading it even that time this fact will hold true so this is the thing about tenses nothing complicated first you decide majorly it's past or present only and mixed tenses are allowed and how you decide upon mixed tenses is with this is that thing true today then that will be in present tense think from a reader's perspective then this is reading out loud

like when you frame sentences carefully craft your sentences and then when you read out louds loudly what happens is as for the punctuation you will pause and you will speak so when you're speaking when you're reading out loud any glitch that your eye could not catch your toning or your pauses will immediately highlight you if there is any change or if there is any disconnect you will find that out by reading your sentences loudly okay that glitch you will immediately catch that so once you have doodled start to frame sentences if you are using word or any tools whatever you'll get suggestions use that simply don't waste don't invest time in you know specifically finding flaws

whatever is highlighted it's fine you can make that change at that point of time tenses decide i think if you are in an organization then this must have already been decided like your proof of concepts are from in the past tense but if it's your choice then again make a checklist for yourself that all your pocs going ahead are going to be like this so then this gets sorted and read out loud whatever you write so that anything that your eye could not capture is sound will now rule of thumb so think of any finding how do you make mind maps you need to determine what is important to a particular vulnerability like we saw i dot insecure direct object

so what is that object first thing should be i dot object okay then you can write about that affected parameter then another thing important about idol would be if you could get privilege escalation right about that because this is after all you're talking about broken access control here so you jot down points which are important to a particular vulnerability if it were csrf then victim authentication would have been important this again depends upon the user accounts that you are provided for the test the user that you used as a victim and as an attacker you need to determine all that roughly then a context in short now for findings like idol and csrf if there are six to

seven steps involved like we said we have to stick to simplicity no shortcuts and if you are using plain english then there could be even more steps since we are explaining everything so the reader should not wait till your eighth or ninth step to understand what happened so you can provide a context in short that the application was available to idol and this allowed the tester to escalate privileges and get account takeover as the final output so give a context in short so that the reader readers know in advance what is to be expected user accounts and privileges provided this is important uh if authentication is important uh to exploit any vulnerability so you need to talk about

that about the user accounts and privileges provided and especially for findings like idol csrf privileges are important like the user that you used or the user account you used to sign into the application and then you initiated the attack so talk about that then there is modification the modification that you did um suppose id was set to one and you changed it to two talk about this modification what was changed from what to then what was brute force used like automatically it was changing and then you got so many responses and in one response you identified that okay this was an admin account or something so you talk about that then again final outcome what could be achieved if account

takeover then you better show them that you could sign in show them that interface so the this is the thumb rule before writing determine these things what is important to a particular vulnerability provide a context in short and then steps depending upon these questions these pointers now suppose we are taking the example of idol now what is important to this finding this is important to create mind maps like what could happen like what could happen uh you could change a user's password you could gain admins account so you need to determine that note it somewhere then what was the affected parameter and user privileges so these are basically these questions okay so for idol you answer

those questions and make a rough note of it or mind maps of it now suppose this is the situation any user could change the password of other user affected parameter was id so how would you write the proof of concept for this finding this issue the mind maps would look something like this the main action password change possible this was the object authentication was required user a with low privileges this was a modification done id was changed id of a was changed to that of b and we had high privileges so instead of a password of b was changed when the request was submitted due to this the tester could get the access of b users account

so these are just this is just rough work and then you frame sentences around it okay so this is your context that was identified that web application was vulnerable to idol the affected parameter was id and by changing it any application user could change password of other user this is the basic context so in case a reader or some senior management doesn't want to read the steps he'll be satisfied with this paragraph that okay this was the vulnerability and this happened then you can further demonstrate the vulnerability for anybody like developers your fellow pen testers any technical person from the client organization who wants to understand the vulnerability in depth this is step one tester signed in as

user a a low privileged user and clicked on changed password to change this user's password now a low privileged user is important because in this case we did get uh access of a high privileged user and if you were provided a low privileged user before testing then you need to mention about it normally people just directly start that the tester clicked on change change password to change users password okay but this is really important that during testing what was the role that you assumed correct so first step should be about that the tester signed in as user a a low privileged user then you talk about interception of that request tester intercepted this change password request

in a proxy or any yeah proxy tool and observe that there was an id parameter in the request so here you talk about the main part of idol vulnerability the insecure object and it was in the request of change password action then the tester changed a user's id parameter to that of b user a high privileged user provided for testing purpose okay and the request was submitted or forwarded step four should be it was observed that the request was accepted by the server and the password of user b instead of a was changed in this way tester who signed it as a user got account access of buser via an insecure direct object reference that is

in the password change request so if you see this is how this is the most simplest and the basic way in which in four steps we completed idols poc so the moral of the story is you need to stick to basics and if anybody reads it they will understand this finding and stick to the thumb rule talk about what is important like object in eye law the object is important so where did you find that so mention all that then again a user's id parameter was changed to that of b user a high privileged user provided for testing purpose so that the readers understand that okay two user accounts are provided so these are some

important things that you can simply put of course these steps are to be supported with images so that the user along with description and with images they will understand it better there are images will come here after every step now don't combine two three steps don't miss out on pocs now sometimes what happen is people will directly start with step three that tester changed a user's id parameter to that of b not wrong but then if you go step wise it's easier for anybody to understand a technical person will understand from step three as well but the main point like we saw was simplicity so you break it up at the lowest level possible and if

needed if needed if you think and if your reviewer suggests that step one and step two can be combined then do that but the first time go as go to the lowest level as possible so that at least the reviewer also understands then maybe you all can decide about combining sentences and everything now for idol kind of vulnerabilities avoid merging everything in one step do not directly give the image of the final step or the second step for example you have four steps and you are just showing the final step try to give pocs or screenshots at every step remember simplicity is the key again now if we have to talk about csrf so remember that thumb rule what is

important to this finding make mind maps victim user and the attacker user now if you have been given two users which was the victim user and the attacker user the attacker user here will be the tester okay now if if authentication was uh authentication is a must for csrs so you did sign in using some user account correct and if you're using that user account to target another user that was provided so you are the attacker so the first important point is that you signed in for the application using user a who's attacker for this demonstration then you talk about the html poc or the script because csrf is one attack where social engineering will be required if

you want to compromise the victim user because there has to be some way that you send a malicious url or a malicious payload to the victim and they have to click on that link for some action or an unintended activity to happen correct so talk about the html poc show them the raw html poc show them that okay xyz was set to true and you changed it to false show them that tell the readers that when any user clicks on this html page their account will be changed whatever was set to true will be to false so this is important that you describe the html poc or any of the script that you are using for csrf

exploitation there has to be a line about that then you talk about the modification that happen password change then password change and final outcome like account takeover or whatever that you could achieve so now if i have i had to do csrf mind maps so your csrf then first thing that comes to our mind token absent was that no token or there was a token but it was invalidated so these are the two questions you can just make a rough note about your roughly then what happened like password change user you signed in as and the privileges if user accounts were provided what were the what were their privileges was there any kind of privilege escalation if yes

then this point is important then you talk about modification and how you did it html or any script you can further go down that html setting of um xyz was true changed to false who was a victim user and what were his privileges and social engineering aspects if you are normally people don't write about social engineering as a part of csrf poc because then it will become longer like we directly show the html page with the submit button and action happens but if you want to write you can go ahead like the link was sent via an email to any employee like if fixed user accounts are not provided and if you have to target

any employees then maybe you can talk about this and then the final outcome so again this is these are not the perfect steps these are just mind maps like token absent invalidated depending upon the reality you keep this notepad or this page in front of you and start framing sentences so like we said context is important tester identified that the web application was vulnerable to csrf the issue allowed an application user to change contact preference of another user this was the context in short the senior management would like to know then you demonstrate the vulnerability in detail tester signed it as user a the attacker in this case the contact preference page of user a

can be seen in figure below sms is their preferred contact okay so here since we are talking about contact preferences it could be sms it could be emails anything and this particular user user a had sms as their preferred contact then tester as user a that is attacker created an html page which when accessed by any application user will cause their contact preferences to be modified note that the victim user must be authenticated to the affected application so you can add this important note as a part of step so html poc or the appendix so if your html poc is a very small code or you can take a code snippet which is important one and paste it or if your

code is really big move it to the appendix and then redirect user to that appendix so once you paste the code snippet here you can give a note or write such a paragraph that notice in the html code that the value of input type sms is true this means that when the victim clicks on this html page the contact preference will be updated to sms okay like any victim who clicks now tester signs in as user b who has email as his preferred contact now when b accesses the above html page created by malicious actor a and submits it the contact preference of b gets updated and sms is selected as a prefer contact for b

okay so this is how you can simply explain everything keeping simplicity in mind and considering that considering the target audience which is varied for pentest reports this is something really important like you talk about html code and the value that is already there and if sms is set to true you can change it to false or whatever you can add a new type also maybe your if there are advanced attacks so this is something you need to think about and write so that the readers understand everything correctly and in detail step four could be you can talk about anything you are sure of like token invalidation or token missing depending upon the true situation now

here we just updated the contact suppose change password was also happening if the token was not invalidated then you can talk about that as well or like i said proof of concept might not be 100 a perfect exploit code so as a step for talk about possibilities that this is this could also happen or anything that you feel can happen by using automated tools or just by a little tweaking here and there so this was csrf csrf is also one vulnerability which is really difficult as a pen testers for us also to understand at the initial levels so we should understand that if we found it difficult to understand csrf correctly it will be difficult for the

readers as well so keeping this in mind you need to be as simple as possible and when you're writing simply it's also a test of your uh knowledge that if you have understood a concept clearly you will write you will be able to write it in the most simplest way now moving towards common mistakes first is assumptions and technical understanding for example user enumeration now sometimes what happens is there is just this much the application responded with a verbose error message and they mentioned the message here when an invalid email address was provided in the username field and the screenshot just that's it and this is username minimization so don't assume that the reader will

understand what the real issue was now in such case you could have also provided a poc for valid email address like when there are invalid entries submitted the server responds like this and when they are valid the server responds in a different way so by these differing responses is what we realized that we could determine valid and invalid usernames of an application so don't assume that the reader will understand just because you understood so this is one point where people skip steps and this is like not simple so you can elaborate so that if the reviewer suggests that you can merge like i said then go for merging but from your part as a first writer go as deep as possible

lack of completeness again going against simplicity lack of a screen shot suppose you have directly talked about step number three from i don't suppose and that's the only screenshot in between and there are no screenshots so you know images enhance the reader's understanding and if there are if your steps of or if the images are abruptly ending see even without descriptive lines the poc the images in itself should be somewhere enough to foreign for anybody who's going to reproduce the issue for them it's easier it should be easy for them so a missing screenshot is definitely not a good sign ensure you are giving screenshots for all the steps because even without sentences the screenshots in itself should be

sufficient to some extent then we have half knowledge if we are talking about extreme options and missing headers but we are not talking about click checking and your remediation talks about click jacking okay so the finding is missing security headers and your remediation is reused and it has mentions of click checking and you're just half talking about extreme options being misconfigured so you ensure that you are checking everything and if you're talking about something that can also lead to another vulnerability then ensure you have mentions of those because these are some things that some other tester might mention in their reports so then what happens is you are like it seems that you have not done the

testing completely there's something missing it's immediately highlighted so read the descriptions whatever is coming automatically ensure that if there are mentions you have a note around it suppose extreme options were not was not correctly configured and it was not vulnerable to click checking also so in such situations add a note that though this was there this was tested but it was not vulnerable to click checking so something of this sort make your vulnerability wholesome and ensure that there are checks related to other vulnerabilities which can arise from the base vulnerability awkward transitions if there are chaining of attacks and if you have ended something like using username enumeration you got valid usernames and now you're moving towards

brute force because there is also weak password policy so there are chances that using the valid email address you can easily crack maybe a user's password and get through so when you are transitioning from user name enumeration to insufficient anti-automation or lack of rate limiting or brute force or even mentioning about weak password policies so there should be a systematic flow in this again you can use mind maps that first this happened and then you realized that there was a weak password policy so you should be checking about this as well so ensure that the transitions are smooth and again you don't miss out on anything because then it can get complicated for the readers

wrong choice of words now sometimes discovery is fine like username discovery no so then username elimination because you could enumerate the list of those directories or usernames and some things you discover so choice of words is also important when you say a particular issue was exploited then ensure that it was actually exploited and not just simply confirmed confirmed and exploited again that's a different topic so choice of words is also important what you are saying and if you recollect the basic points the immediate takeaways that we talked about now those should not be a part of common mistakes come on so getting a tool name wrong everything this happens but these are some really important

mistakes which we have highlighted and now that you know of the immediate takeaways ensure that those mistakes are not repeated by you in your pen test report

now reviews reviewing is a very important part of reporting reporting process now when you invest a lot of time in your report sometimes you may not find mistakes in it but when a person freshly sees it the power of peer review is tremendous so when someone freshly sees it he will immediately catch errors be technical be it language-wise so reviews are really important and reviews take time there should be someone who is dedicated to this work that they are reviewing your reports this will help you this will give you really good insights so ensure you get your report reviewed before you send it to the client keep a checklist from all the points that we have gathered make a checklist

and if you are doing a self review then ensure that there is a there is a huge gap of time between when you complete the report and when you are reviewing it so that you also review it with a fresh mind so this is important reviewing is important training uh report writing is an essential element of practice for all professions anybody who wants to improve their level of skills must seek specialist training in these areas in addition to obvious advances within the profession communication skills are important and if you feel you want to do upgrade yourself if you feel now that you have the required technical skill sets and you are doing good then you may want to move towards

improving your communication skills and if you think you need guidance then definitely take trainings because like we said in all professions communication skills and the core skill sets balance is the key and both are important so think about getting trained and this was one question would you rather so yes people prefer pen testers with pen testing skills and communication skills even if a tester is extremely good even if they hire them they will have to train that person so yes all this matters and the conclusion if you have to summarize everything reporting is a part of pentest an important part of pentest technical writing is simple and evocative it is emotional proof of concept section is the heart of

a pentest report where which cannot be automated and this is where your real storytelling skills come into the picture use creativity like mind maps doodling and frame sentences easily around it and reviewing is important because it will give you more ideas and proper inputs so yes this was all from my end about reporting in penetration testing thank you so much for joining in thank you