Writing Powerful Pentest Reports

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 wh