Lecturer: Throughout the course,
we learned a number of methods to discover bugs
and vulnerabilities in different types of software
and infrastructure.
Usually, at the end of the pentest,
you will need to inform the client
with all of the vulnerabilities that you found
or with all of the findings,
this is done using a pentest report.
So basically what we mean by a pentest report,
it's just a document that includes everything
that you found through your engagement
so that the client or the admin
can go ahead and fix all of the vulnerabilities
and the weaknesses that you found.
These reports are also read by executives a lot of the time,
therefore you would need to account for that,
so a good report should be easy enough,
but it's also easy to understand.
Now, if you're working as a pentester,
then the company that you're working for
will probably have their own template
and their own standards that you have to follow
when writing a report.
And in many cases,
you won't even be doing that,
you'll simply be forwarding your findings to another member
in your own team,
and they will be fill in the blanks properly in the report.
Therefore you probably will not need to write one
from scratch,
and in many cases, you won't even write the actual report
that the client sees.
With that being said, I still wanna show you
how this is done just to give you an idea
of what a pentest report looks like.
Now first of all, before I show you the sample that I have,
I'm gonna include this repository
which basically contains a large number of pentest reports.
So you could actually look through these for inspiration
and just to see the different styles
that different companies follow
when making a pentest report.
So you can click on any of these and you'll find the report,
and you can actually go through it
to learn how this specific company write their reports,
and maybe you find something that you like
that you would start including in your own reports.
So I'm gonna include this in the resources of the lecture
so you could come back to it for inspiration.
But what I really wanna do
is walk you through a sample report
that we use here in ZSecurity
just to give you an idea of the main sections
that most reports have.
I will also include this in the resources,
so feel free to modify it and use it,
or take some elements of it if you want to.
So you'll notice from the repository in here,
each company has its own style of writing reports,
but in general, there is always a few main sections
that you will find in every report.
So starting with the first page right here,
we have the covering page.
So again, you can sell this as you want,
you'll usually have the company logo,
you have the title,
and then you'll have the date of the report and the version,
this is very important.
And then, we have the company, our company information,
so this report written by us,
this is our company information.
And then you have in the for field,
you have the company that you're writing this report for.
So you'd have the company name,
you'll have a specific ID for this company.
This is the ID that you identify this company
within your own records.
Again, this is probably not something
you'll be doing yourself,
you'll be given this ID by your own company.
And then we have contact information for both companies.
So you can see in this company, we have pentester 1
and pentester 2 with their email addresses,
this could be obviously a bigger list
with all of the team that is doing the pentest,
and similar to the company
that you're doing the pentest for,
again, you have their names,
their position in the company and their contact information.
Now, again, keep in mind,
you don't always have to style the first page like this,
but more or less, usually in the first page,
you'll have the title, the date, the version,
and the contact information,
this is how we do it,
but again, you can do it the way you want
and you can draw inspiration
from the resource that I'm gonna include here.
Next, we usually have the table of contents.
Again, as you can see,
simple stuff, usually we'll have in any kind of document.
This will help you navigate throughout this whole document.
And like I said, in here,
we can see the main sections of any pentest report.
So it's very important to have an executive summary,
this is a summary of the whole engagement
that is designed for less technical people.
So it's supposed to give them an idea of your findings
without diving too deep in the technical details.
Then we have an engagement summary
where we detail the scope,
so this is what you tested,
which parts of their system that you tested,
the risk ratings that you used
and an overview of everything that you found.
So again, so far we're not diving deep
or simply, this is just a summary of the whole engagement.
You'll get a better idea of all of this
as I go through the report.
And then in the technical details section,
this is where you dive really deep
in everything that you found.
So we basically have a section for every finding.
So as you can see, this is just a sample,
so I only made three findings,
we have an SQL injection, a Cross-Site Request Forgery,
a CSRF and an information disclosure.
So as you can see in the first section,
we basically just have the summary of everything
that we found,
whereas in the technical details,
we're basically breaking down every single finding,
and we're gonna talk about how we found it in details,
how to replicate it,
you're going to include screenshots if you can
so that the technical team can understand
exactly the severity of this vulnerability
and how to fix it.
You'll notice other companies will include appendix
at the end,
they will include recommendations where they will tell you
exactly how to fix vulnerabilities.
Like I said, it really depends on the company,
every single company have their own style,
and every single company have their own format.
So what I'm showing you right here
is just a sample of how we do it,
you can draw inspiration from the resources,
and in many cases,
you'll just have to follow the template
that your company has because they don't want you to do it
your own way.
So let's go to the next page,
and you'll see in this page,
we have the legal information.
And that's why I actually said,
you'll probably not do this yourself,
you'll never need to do this yourself
because you'll have parts of the report like this
you'll never have to modify,
and they'll actually be written by the legal team
in your company.
So they'll account for anything that could go out of control
to make sure that you will not be sued
if anything goes wrong,
it'll contain stuff like disclaimers, GDPR, privacy,
legal stuff, and all of that stuff
that we don't really know very well as pentesters
and legal people usually write.
And then we have the change log of the document.
So every time a change is made to the document,
you can see, we have the date,
we have the version and we have a comment,
why did we do this change?
Or what's so significant about this change?
So this was the initial report when we made it
on January 1st,
and then on the 10th of January,
we made the second version
where we are done with the Recon Stage.
Again, this is just samples,
but just to give you an idea that keeping a change log
of all of the changes that this document goes through
is very, very important.
Not all of the companies do it,
but again, that's just our own choice
to add it in our report.
I keep saying this just to give you an idea
that there is no set rules
to making these kinds of documents.
You can add or remove anything you want,
but the main parts would be the legal part,
the executive summary, and then the technical part,
these would be the main parts of the report.
So now we have the executive summary,
and you could read through this.
This is not supposed to be long,
so in my opinion,
it needs to be a page, maximum two pages
if you really have to.
And it basically just says,
we were instructed to test X system,
it'll explain how this document is organized,
where the first section is less detailed,
just to give you an idea of the risk,
and then the second one is detailed for the technical people
to understand these risks and fix them.
And then we're given the risk rating,
so we're assuming this is at high risk
based on the vulnerabilities we found,
it will detail the methodology that we followed.
And then, we have some charts in here.
Remember, this part has been read by the executives,
these are people that are not very technical
most of the time, and they also don't have a lot of time.
So we're including graphs in here
to show them the amount of vulnerabilities we found.
So we can see, we have five vulnerabilities that are high,
we have 10 that are medium and eight are low.
So this will give them a really good understanding
of the threats that they face.
And then we're gonna go into the summary.
Again, this will still be read by the less technical people.
So first of all, we're detailing the scope
to make sure that we tell them what we tested,
even though they already told us what to test,
just so that in case, in the future,
if something was discovered outside of our scope
and they come back to us,
we can say, well, this was outside of the scope,
we did not test this.
Next, we're including the risk ratings.
So you'll have this in every document
you want me to modify it,
we're basically just saying how we would classify
a certain vulnerability as low, medium, high, or critical.
And we're saying, in our opinion,
how you should handle the low, medium, high,
and critical vulnerabilities.
You can see for the critical,
we're saying you need to fix immediately,
whereas for the low, you need to fix
in the next update cycle.
Again, this is just our own opinion.
Next, we have the findings overview.
So we're still in section one,
this is still for the executives,
we don't need to dive too deep.
So we're just given the vulnerability ID.
And you can see, for the first vulnerability, it's critical,
it's an SQL injection.
And in many cases, in many reports,
they'll actually stop at saying, it's just an SQL injection.
We like to actually show the impact in this section,
because like I said, these guys are not technical,
so if they read SQL injection,
they might not know what an SQL injection is,
what they care about is the impact of this vulnerability.
Again, they don't have a lot of time,
so you need to be straight to the point,
so what we're doing is we're saying it's an SQL injection
that could lead to an authorized database access.
So now they know with this vulnerability,
a hacker can access their database,
this is probably pretty bad.
Another vulnerability that we found is medium,
and the CSRF again, many reports will stop here,
doesn't really explain anything to non-technical people.
So we're saying clients can be forced to submit certain
non-critical requests, that's why it's a medium,
it's not non-critical requests,
but they can be forced to submit stuff.
And then we have one low vulnerability
where the PHP version is disclosed,
so this is not really very critical
because it's not an actual vulnerability
that can be exploited to gain access or expose user data,
but this information could be useful for hackers
to chain with other attacks
or discover vulnerabilities for this specific PHP version,
and that's why it's allowed,
that's why it doesn't need to be taken care of
very urgently like the critical ones
as we mentioned above in here.
And feel free to read the text in here,
you'll see a lot of it is basically just to clear our bugs
and make sure that they understand everything
that is in the report.
And that would be the end of the summary,
and now we're into the technical details.
So in this section, we're basically having, like I said,
a subsection for every single finding that we have,
and we're diving really deep into the details
of this finding.
So you can see this is the SQL injection
that we mentioned earlier in the summary,
but this time we're actually giving them the URL
that is vulnerable,
we're giving them the vulnerable parameter,
we're giving them references to understand
what SQL injection is in case they don't understand it,
we're giving them the exact request
and the exact response that we got,
which made us determine that this particular page
is vulnerable to an SQL injection.
Then we're giving them the impact here in details,
not just saying that they can access the database,
so we're saying they can access the database,
they can retrieve data,
we got access to the user's table,
so you're gonna dive in details
and you should even include screenshots in here
if you think there'll be useful.
In the mitigation section,
we're just giving them a quick recommendation,
like I said, some companies give detailed recommendations,
this really depends on the engagement as well.
So in this example, we're basically just saying,
use prepared statements with parameterized queries,
and we're giving them a reference to learn how to do that
or to understand how it works.
And that's pretty much it.
So you're gonna repeat that for every single
vulnerability you found,
I'm leaving the rest empty as this is just a sample,
but you get the idea.
So you're gonna have a subsection for every finding
that you have, explain everything in details
so the understand the vulnerability
and then they can go ahead and fix it.
At the end, many companies would have an appendix
and they might have a bigger recommendation section,
like I said, this is our style of writing reports,
but each company has their own style.
If you like this, maybe spend some time
going through the sample reports
that we have in this repository.
Obviously I'll include both links for my sample
and for the other samples in the resources
so you can go through them yourself
and get an idea of what pentest reports look like.
But like I said, in many cases,
you'll simply be filling a sample
similar to what we have in here,
so you'll never be asked to come up with one from scratch.