Understanding the Penetration Test Report
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
Welcome to module to setting the foundation for success
less than one Understanding the penetration test report
are. Learning objectives are to understand the components of the penetration test report, as well as hacking the penetration test report for relevant information.
You'll see books guides, all kinds of things describing what makes a good pen test report.
At the very core we have, we have three different sections. One is an executive summary.
So high level summary for executives describing what you found. So the totality of what you found, how severe it is as well as, you know, can I fix this? And if I'm an executive, I want to know, you know, what did you find? How bad is it and how do I fix it?
And in a very non technical way. So as as best as you can describe what you found in a without using any kind of technical jargon. Um just a general description goes a very long way as well as including things like graphs and charts that that really helps um
display exactly what you found and how severe it might be.
Methodologies are important information gathering at the end of O S T P. You don't want to realize that you didn't scan for every port and you didn't discover every service
are scanning and enumeration portion of our pen test is very, very, very critical
and it's important to include what you found in your penetration test report. You know, maybe port 22 is open and they didn't want port 22 to be open. Um so that's important to tell your customer attack path
as far as what vulnerability exploited. You know, this is a very important information of course you're basically going through your attack path
of how you exploit the vulnerability and got a shell um on on a vulnerable machine. So if you can describe what that vulnerability is, if there's a CBE attached to that, that's great. You may find exploit code and something like exploit dB google is your best friend here. Um as well as maybe you file you found something a vulnerability in a custom piece of software
in offensive security uh in their sample report. They have both they have both a C V E and something found in a custom piece of application. So there's a specific Cbe of course you can use that information from from your google searches and then for custom applications you may want to use something like a C. W E,
which is more of a broad category. So a CV might be
um a sequel injection and a wordpress plug in. Whereas um a C W E is just generally what a sequel injection is.
So you want to explain what the vulnerability is as well as how to fix it. If there's a C. D. E, you can be confident that the vendor has issued a patch or guidance on how to fix that.
C W s are great too because they you know, it's a sequel injection but they'll provide some on the sea on the miter website for CWS. They'll provide some general guidance on how to fix sequel injections.
I know this meme is used a lot but I don't think you have too many screenshots. That's not to say you should include all of them in your OS CPI report. The worst thing again is that is to have your O. S. E. P lab end and you can no longer take screenshots and then you realize that you didn't take enough.
So when I include screenshots, screenshots in my report, I will typically have a caption below and explain why I'm including that screenshot to show why it's relevant and why I'm including it in my pen test report.
There was an appendix back in the 2013 version of the P W K report on the off off sec website. Um I'm glad they took that out because it didn't really follow a logical flow. Now it really does. You know, you have your executive summary and then it kind of goes through each host and explains
what vulnerability was found, how severe it is and then your path of exploitation
and it lays that out for each different host rather than having different sections broken out for these are all my recommendations. These are all my attack paths. I don't think that was very clear. So I'm glad that the new version uh kind of breaks things out by by specific host
couple bonuses here.
If you already exploited those 10 different hosts in in the P. W. K. Lab, you've already had the experience of writing this and you know, you can take those the good and the bad that you found writing though that report
uh in the OS CPI report when you write it. So you already have some background of, you know, what worked for you and what didn't, if you finish up the osc p early? If you're one of the lucky for you to do that, um make sure you go through your attacks steps and and clearly document that in your report. So
my third oh SCP attempt, I had plenty of time. So while I was writing my report, I was going through my tax steps within the lab environment. That was very helpful. Um Also if you go to the offensive security forums, they already have a write up for two of their machines, Alpha and Beta.
I would look through those and see how they're written because of course the people scoring your exam
are the people that wrote those up so see how they themselves wrote up their pen test reports, so to speak.
Don't reinvent the wheel. You already have an exam, a sample report available to you on the offensive security website. I've seen other people come out with their own custom reports and things of that nature. I've used the Offensive security report not only for the O. S. C. P.
But for some other L. Learned tests and I found to be very useful. Um and I was successful in those exams. So
I really do like the offensive security report on their website.
Also if there's already a CV out there, google is your best friend. As I've said before, you know, research that C. V. E. Try to find um you know, fixes for clear explanations of what it is and if it's a custom piece of application again,
you can go back to CWS. Capek is kind of like more broad categories like CWS,
but they have great descriptions of vulnerabilities, you know, cross site scripting whatever it might be. Um and general fixes on on how to fix those types of vulnerabilities, severity is also a big one. If I could go back and change the severity in my report, I would because now that I'm, you know, in this, in this realm, I I didn't think, I don't think I escort my severity correctly and I think that's very important, especially for customers, customers are gonna want to know
if it is a is a critical vulnerability. They need to fix it immediately rather than maybe it's a low and then they have more time to fix that and they can focus on more of the severe vulnerabilities. So a lot of Cbs already have a severity assigned to them. But if not, if, if it's more of a general or custom piece of software,
you can use CVS s to score that and we'll show that in the demo.
If you didn't get the local or proof file, I've seen people go back and forth on this. Should I include information, my report? I don't think it hurts to include this information. You know, if you don't include it, you're definitely not going to get extra points. If you do include it, maybe, you know, maybe they will give you extra points. But
if I was a customer, I'd want to see that, you know, I'm paying for equality pen test.
Um, and even if, you know, even though the pen tester wasn't able to exploit something, maybe there's something that's concerning that I should know about. I I still want that included in the report.
So don't forget these things. The local improve files must show the I. P. Address. So you want to do I. P. Configure I. P. A. R. I. F. Config depending on what type of machine you have. You know you want to make sure you have both of those in your screenshots. Don't forget that because you know you'll lose points. Um
You want to submit your proof files in the control panel. You wanna make sure you do that accurately. You want to make sure that your accurately submitting the correct
hash for the correct machine and the correct file.
Follow the submission instructions very carefully. If you mix up hashes or you don't do something correctly, you could lose all your points for that machine even though you you got root on it.
So once you submit your lab report you can't go back and submit it again. I tried this, I wrote the report, realized I should have included more and then resubmitted it and they said no we're only taking your first report
so you can get
all the proofs you can you know hack every single machine
but you could fail because you wrote a bad report. So the report is equally as important as compromising as many machines as you can. So you know, pay attention to writing your lab report for the exam.
So here's the quiz question. What screenshots must you uh must report include original code and then modified code. Local. Improved files with hash and I. P. Address or obtaining a shell in the box.
So the correct answer is local and proof files with hash and I. P. Address.
In summary, we learned how to understand the components of the penetration test report, as well as how to hack the penetration test report itself
for relevant information on what we need to include when we write our report for the escape.
Penetration Test Report Demo
Note Taking and Mind Mapping
Finding Resources to Prepare for the Offensive Penetration Testing
Setting up the Kali Linux VM
Overview of Tools in Kali Linux