← All talks

Writing Powerful Pentest Reports

BSides SATX · 202228:09142 viewsPublished 2023-03Watch on YouTube ↗
Speakers
Tags
About this talk
Penetration testing reports are critical deliverables often overlooked in favor of vulnerability identification. This talk covers strategies for writing effective reports tailored to diverse audiences—from CISOs to developers—and explores common mistakes including scope errors, grammatical issues, credential leaks, and missing methodology. It outlines essential report components, proof-of-concept structure, and practical techniques like peer review and color-coding standards.
Show original YouTube description
Writing Powerful Pentest Reports 2022-06-18, 15:00–15:25, Track 2 (Moody Rm 101) A penetration testing engagement involves many things, ranging from the initial recon phase to submitting the final deliverable at the end of it all, what is called the penetration testing report. Often, the quality of this final deliverable gets ignored because of the heavy focus on identifying vulnerabilities. This talk will include the strategies that can be followed to write effective and powerful reports, do's and don'ts to be followed when crafting one penetration testing report. A penetration testing report is a very important document that is read by people like the CISO, developer, manager and contains confidential information like critical vulnerabilities, test URLs etc. Some common mistakes while creating this penetration testing report are incorrect scope details, grammatical errors, not providing the methodology followed, leaking sensitive data like passwords etc. This talk will include the following: 1. Why Penetration Testing Reports are important 2. Things to be included in the penetration testing report 3. Strategy to be followed for creating an effective Proof-of-Concept 4. How to avoid the common mistakes Abhinav Khanna Abhinav Khanna is an Information Security Professional, currently working as an Application Security Engineer at NotSoSecure | part of Claranet Cyber Security. He is an active bug bounty hunter & is a member of Synack Red Team as well. Apart from security, he likes playing Table Tennis.
Show transcript [en]

so hi everyone I hope you are doing so today I'll be talking about this very interesting topic that is called as uh writing powerful vintage reports so let's just quickly jump into it all right so before actually starting with these slides I would uh quickly like to introduce myself my name is and I'm currently working as an application security engineer also secure uh apart from that I'm also actively involved in bug bounties as well and I remember oxygen protein now let's just jump to the main question that is uh what is a pen test report can be considered uh as a final deliverable of the entire engagement which includes uh all the vulnerabilities found on the aggregate

School while the main purpose of the pen test report is to you know craft uh reportings are such a way that the vulnerabilities identified it is shown it's not only limited to that uh we need to take care of a lot of other things like the summaries or the graphs or you know methodology things like that because we have a vast audience that we need to take care of so this report actually involves a lot of other things as well so let's try to understand why let's let's see who is going to read our report uh it can see soon's project managers the dev team application owners audit team co-workers clients internal security team or interns now if we talk

about csos uh they are the people who are not going to dig deep into the report but might be interested into the tables or the uh the scan one graph the scan to graph or maybe they want to see the number of high vulnerabilities or critical vulnerabilities so we need to take care that what the CSO wants to see if the report is there project managers so project managers might actually have to go through the entire report uh but they might not be technically enough to understand what is there in the report so while we are crafting the report we need to take care that uh we are writing in such a way that these guys can also understand what

they put the drifting so the main target audience is the dev team uh because at the end of the day they are going to look at the report the vulnerabilities and the recommendations that they are going to work on it so they obviously we have to write in such a way like those guys uh are understanding so I was at the auditing so third party uh third party audit teams are equally important because uh I recently went to a situation where um just a minute where uh the third party audit team asked us that why this vulnerability is marked as fixed while it is open on the uh scan one URL so some Miss happening

happened in the entire report and that is how we got to know that third party teams are on so uh interested in our reports so we need to take care of that as well then uh comes the co-workers so your co-workers might be interested to uh you know what vulnerability have you found out how you found out how you're creating the reports so so the people who are working with your equally important when you're creating the reboots because they can be used as a future reference then comes the client's internal security team and uh those guys might also also be interested in your report uh to understand what you will identified because we are the ones who

might replicate that timing then comes the interns so in turns uh might not be knowing what exactly a report is or how to exploit a vulnerability but uh they might use your remote as a reference to understand how to create a report to see how a scenario can be exploited and again to use as a template or of user reference so these are some people not the potential target audience that we need to take care of while we are crafting variable now let's move on okay so let's see what good report writing can lead to the first is client appreciation well a well-beared report can really be uh good for your confidence and your organization's

confidence because believe me client optimization in any form be it vulnerability identification report writing is always a great booster to your motivation and uh makes you perform even well so that is the utmost uh priority getting the client's appreciation client retention still um the reason I mentioned is this because uh we retained a client because of the kind of report we were sharing them the structure available there were other uh consultancies that were working on that same project but we were able to retain it why because our reporting was good it was better than others effective communication see the main point of the report is that you are trying to convey the story of how you found the vulnerability or all

extractor vulnerability and if you are not communicating it effectively then there's no amount of writing the report so that again is an important point to consider while you are creating the report communication deposit just like I mentioned before your report can be used as a reference can be used as a template for future reference suppose you've created a very good exercise reporter very good SQL injections and that time used in the future so that is again the plus point for you okay new clients again this I have mentioned this because uh a few years back we were working on a POC to get a client on board and we missed out on a few findings but still we were able to pack

that project because our reporting was better than the other teams so here we were able to pack a project because of our reporting skills and not on the mobile variability identification again a person job opportunities so again the reason for mentioning business because recently one of my friends got a job opportunity from one of their clients because of her reporting skills she was a good pen tester but an even good uh report like that and that is how she landed the job in a better place so that is also a point to consider so while we have seen a few points that can be good for uh for a good report writing let's see what are not so good

report right the writing can lead you to report real time your client come might come back to you and say that a uh we want you to edit this or we want you to modify this to delete this this is time consuming and this may not leave a good impression of you and your organization uh if the client comes back to you again and again second loss of Revenue the client might continue to uh you know might not continue with their organization if the report does not meet the standards so at one place we saw that we are including the revenue by getting new clients on board and buying it in the client there are organizations who are going to lose

the track as well and which would effectively lead to loss of Revenue so that's a big one to consider escalation vulnerability or any other thing but if the escalation comes for your report writing uh believe we are going in the wrong direction because vulnerability identifications and intimidation can still be a technical thing but the report writing is not so technical and chances of escalations for this is low but if you're getting the explanation for report writing believe me are heading to the wrong direction lack of trust your client or your colleagues might stop reaching out to you for any suggestions suggestions for report writing and that is again a very critical uh point to consider for our own personal

group because it is going to lead you to demotivation safe mode all these points are interconnected sent out uh report rewriting and lack of trust all these points are integrated too it is going to lead you to demotivate demotivation if you are you know facing all this and because of this uh there is going to be miscommunication the the entire point of the report writing is that you are conveying your story to the reader properly and if you're not doing that then there is a huge miscommunication happening and no point of writing credible so whether there are the good points or the bad points they are they all are interrelated to each other and you need to work on them

call it so let's move on now let's look at some of the things that can be included in the report let's start with a short description about the application while this is optional I would generally recommend to add this in your report because it is going to leave a good impression uh about you and your organization that you guys have put in the effort to understand the application and what the application really does along with it you can mention the working date in case it was provided again it's optional the reason I have mentioned here is because um instead of digging deep into the emails to find on the walk through date you can add this little thing in the

report itself because we are already creating such a detailed document a one-liner is not going to create a much message than production values so if you're working on speaking violating committee that environment do mention the production environment details as well URLs given for testing again you at environmental staging environment whatever it is do make sure that you are in your report and the reason the reason mentioned is that I based a similar uh I based incident in my career where uh the vulnerability was fixed on the rescanning URL but was open on the URL given for scan one because there is an URL and the first scan URL were both different So to avoid that confusion mention the

URL that is given to you each time for the testing deliverable I guess that's it given I'm not going to go deep into it uh every time you're releasing a report to the client you need to write the version that's version to a V1 or V2 whatever way your company promotes printational consultancy again that's a given and I'm not going to watch into it test credentials so uh if you're using a mobile number or a email or username you can and you should mention it in the report but you should not include the password the reason um so for example if an intern is going through a report and since the username and password you might want to access

the application using those credentials and might hamper the application so to avoid that situation do not include the password the next three things I guess are given in your you guys must be following it already uh the company's logo the client slogan your methodology all right let's move if you are working on an Android application do try to mention the hash of the application be it Android arrivals the reason um because the application versions keep getting updated on the Play Store and App Store to keep the exact version uh locked you can take a hash using no obser and the hash is going to include mt5 details as such one details sa250 16. basically it is a very good way to

present the exact position that you're working on so if you're working on mobile apps this can definitely be considered but if you want to keep it simple you can just go to the apps to our Play store and just highlight the version that you're working on it now let's have a look at what csos are interested in or the board of directive people are interested in the graphs scan welcome for example if you're working on the application for the first time this is what a graph we're going to look like for example there are four vulnerabilities reported in five or five in medium um seven seven lower one Indian but this is what a graph is going to

look like this is interested in Adobe these are the four vulnerabilities and he might or might not go through these uh POC of these five units this comparison now this becomes a very crucial figure when it comes to these counts because this P the C show that the board are detectors are going to look at what work has been done by waiting in fixing these findings uh for example here two findings of which two are not fixed uh in medium as well so he might want to see what is the count that is what what are the findings that are still open uh what are the findings that are closed or things that need to be accepted by his team as a

risk so all these things these graphs are going to be very helpful for scissors okay yep so before we move ahead uh just a point that uh we should consider report writing as part of our job and not an extra loan because it is a part of the engagement we need to write the report we should not consider it extra volume the reason I am mentioning this is because I have seen people who consider this an extra load uh ideally they should not so uh if you're talking to someone about pen testing do mention that uh all these steps Recon Gathering exploitation post exploitation remote writing is equally important and equal emphasis is should be given to it as

well okay now let's look at the roadmap to create your profile concept and it would involve six to seven steps uh starting from the vulnerability name and then severity affected you are in parameters description of the impact steps to reproduce the vulnerabilities then comes the remediation and the final will be references now let's look at each point uh one by one let's start with the vulnerability name color coding I guess that's given everywhere I you you are using some certain colors for uh for writing the vulnerabilities in your report but what needs to be taken care of is stack for project a if you are using three or four colors for high and medium low keep the same for Project B

as well use the same colors same color coding for all the projects keep it your account do not do not change if you are doing so okay now when it comes to description impact keep in mind that you do not copy paste the description and impacts from resources like portrayal equinitics next partner and things like that who was the reason is that because for example you copy it from somewhere some of the blocks and there is something wrong written so that wrong thing is going to be there in your report as well and the client might come back to you and say that if this these things are copy pasted what work have you done in

the report to avoid that situation try to understand the vulnerability boost and write your own uh description and impact afterwards try to craft your own description here use simpler words instead of technical jackets so because we need to take care of the non non-technical audience as well we need to use simpler words so that the report is understood by them as well do not create dual empty descriptions and impact we are trying to tell a story of how we exploited our vulnerability how we found our vulnerability and if we are writing in too long the the person who is reading is is going to get bored and might not be interested in reading the report so we need to take

care that things are not too lengthy in our report okay let's move ahead and understand the steps to reproduce the vulnerabilities now as I previously mentioned uh nor do not keep it too technical because there are going to be non-technical people involved in the report reading process and you need to take care of them as well so let's keep it as simple as possible highlight the effective parameter in the description where we are going to see it further we need to keep in mind that we are highlighting exact parameters uh to minimize the developers effort to find out the vulnerable parameter so that is our job to highlight the effective part so that they don't have to search for

that uh vulnerable parameter do not misspell words I've given you an example as well that if you want to write custom but you wrote costumes itself these are two similar words but they both have very different meaning and I'll show you why and uh why and how I I am going to use it the next is mention the exact parameter that is affected if it's first name with n capital in the request write it that way do not use your own words or do not use all small kids or all of cookies try to uh try to write the exact word that is there in the request itself it's jQuery with Q capital and not all

small case or large kids so take care of that as well do not write unnecessary steps if they're not required if a vulnerability for vulnerability of low or informational severity can be explained in a single step or two steps there's no need to write four or five steps to it you are unnecessarily killing your time and you are going to kill the redage time as well by doing so let's understand all these points so just like I mentioned previously uh highlight the effective parameter we have highlighted the search for parameter View which is going to make the developers work easier that okay this is the parameter that is going to work and the parameter is search for the real

Capital we need to take care of it it's not simply search for all small small kids so this is something that you need to take care of okay so we need to take care of spellings as well for example this is a vulnerability called a proper error family so one of my teammates actually wanted to write that the application does not handle the error properly try to use custom error page but what he wrote try to use costume error page well it's actually it's it's funny but when it comes from client that you have written this it it actually leaves you an embarrassing situation so understand the meaning of the words and if you're not sure you can always Google it

so try to take care of the words that you are entering in your report here as well so you can see that this jQuery with Q capital and jQuery UI is a different thing so try to mention both separately they are not one angularjs angularjs is JS Capital not all small cases are uppercases these little little things these things show the client or the person needing it that you are trying to create a near duplicate report the last Point what we said that do not write unnecessary steps this is a vulnerability called missing HTTP headers and it we can write it as a d notice that the HTTP security head is around implemented that's it it can work

in a single step now this is a completely wrong way to report the same vulnerability open the application go to sign up page reload the page go to send the request to repeater notice that it is another these threads are unnecessary and not not required you can simply do it in a single step now let's move ahead and discuss what needs to be there in the remediation the first part is again what I mentioned in description about that do not copy paste your medication from anywhere if you're copying uh the remediation from online resources the the dev team might come back to you and say that hey we have implemented these fixes but the vulnerability is still open

how is it possible to avoid a situation try to write your own recommendation and try to be precise about it I mean try to find the exact recommendation of the vulnerability if you are not able to write the exact remediation try to give the journal recommendation and do mention to the depth that these are the general recommendations not days and ones to avoid the confusion or conflict also remember that a recommendation that worked for you in a project a would not work employment B I mean it can work but not not sure I mean not delegate so you need to take care of these things remediation description impact should not be copied from anywhere they

should come in your own language because this is what the client is going to think then uh that it actually understands the vulnerability they actually understand the impact and that is why they are able to write it in their own language now when it comes to references we can use references from ovas we can use references from CW meanings or we can use some from any traffic resources things like Volkswagen and netspark we can use them here the reason that I mentioned previously that we should avoid a ports fingers definitions in our description as well because we would be giving the references here and again if the team if the reading team is going to

go through the references when they might come back again and say you have copy pasted from Portugal from OS what work have you done or what effort have you put it so you need to take care of it references that should not be included is irrelevant links or any YouTube link or competition companies so when it comes to YouTube links uh some companies might be having a policy where YouTube is not accessible in that situation these links become completely irrelevant to avoid that situation do not include videos links in the first place okay now let's try to see uh let's try to see a few tips that can be used to improve the report writing the first is uh peer

review so whenever you have written a report ask a colleague to uh read the report by doing so they might be able to help you or guide you that this thing can be improved or you can write this here basically they they are giving you feedback on the report and believe me it's a very good way to improve your report writing I used to do it during my initial days and uh it's it's a really good technique to follow read out loud I still do it today in fact reading out loud makes you understand that the report is good or not if you're reading it to yourself and you're able to understand your confidence enough

that the other person would also understand but if you're not confident that you are not able to understand how can the other person would understand so this should be a definitely go to step when you are writing read reports by others just like I mentioned previously reading reports by others can be used as a template or understand scenarios it can also be used uh as as a reference to how can you improve your own writing or where is it that you need to improve on or you can see that you're actually working uh better than the other person so this is again a good method to follow use of grammar check to the sentence to

this while you should not rely on them but once in a while it is okay to go to these Checkers and see that the sentence formation your sentences are accurate uh this can be really helpful to you know reduce the amount of time that you are spending on when you put effective training this is a very important point for organizations uh so organizations are going to give you subscription for platforms like pinterested Academy or hack the box or prediction lab things like that where you can improve your Apple skills but I've never seen a company giving training for report writing and this needs to be taken care of because companies need to realize that report

writing is a part of the pen testing engagement and it is an important part especially for the people who are entering into the corporate world or entering into the security team training should be provided to them definitely provided to them because uh if training is not there then they are going to have a hard time understanding the entire process adequate time for report this is also a very important time uh if adequate time is not given to you for reports mistakes are going to happen you have given you have been given four to five days for uh identifying vulnerabilities but you have only been given half a day to type the report believe me it is not going to work you

are going to make a lot of mistakes in the report a good report writing is easily going to take two to three days adequate time timing should be given to you and your organization needs to realize it that you have given sufficient time for pen testing you need to give sufficient time to report writing as well by giving you only half a year one a day it's not going to improve your report writing at all so for the last two points are definitely for the companies and the others can be used by individuals uh At Last I would say that right like it's a job do not think that this is a burden that has been put on you it is a part of

your daily job and you need to be good at it if not good you need to be decent enough to craft a report yep so that was it uh any questions that you guys have I'll be stopping my screen sharing for a while but if any questions that you guys have I'll be happy to take