Hey everybody.
Welcome to the first video of the module.
We're going to be going over a basic template that you could use freely for looking at a penetration
testing report.
Now the important part to keep in mind here is that reports are not set in stone as in your your organization
whether you're a contractor or an internal red team might have your own report style.
And if that's the case make sure that you get a copy of the template and a copy of a previous report
so you can understand what it should look like versus what the template shows and make sure that your
reports are in turn what they expect.
If you're starting up on a red team and you really don't have one.
The good thing is is you can always grab a template.
There's quite a few companies sans offensive security they all have a really nice template design to
kind of show what they do and you can always take that tweak it if you need to.
Or even just make your own from scratch based on what you want to do it but the important part here
is that when a company such as a contractor pay or a company pays a contractor or even an internal red
team when you're on salary what they're paying you for is your expertise.
And the report at the end of your assessment.
Now this is more true with contractors because the report is really the only thing you're giving to
the customer at that point.
And what they're paying for is the report.
So it needs to make.
You need to make sure the audience is correct you're here.
Your report is pointing to the correct audience need to make sure that you have everything in the report
that you need.
But it's not so big of a report that everybody gets lost.
You don't need to send them a 60 page report unless there's an absolute reason for that.
And it's a gigantic engagement need to be able to atone for different audiences analyze risk.
You need to basically put everything on that engagement in the paper in the paper in multiple different
ways.
Now what we're going to do here is take a look at an example template that is commonly used but I've
tweaked a little bit so we can see here at the starting on page one we've got our company logo.
What type of report it is and then whether it's an internal report you just put internal here or remove
this entirely and just keep the date dates also good importance here is to know when the report was
generated then following this we have our table of contents.
Again you can see the logo at the top with another line just kind of give it a header and we a table
of contents we've got an executive summary which will go over in a second which also contains the summary
results and then attack details which goes over the actual attack.
Then we have the conclusion which contains the remediation and the risk.
Now if we take a look at executive summary this is where the executive level hint hint the name is going
to take a look at the report and depending on which depending on which executive actually looks at this
they might have zero expertise in I.T. maybe they're the financial officer the CEO and they might not
be the technical officer or they might it might even be the CTO but doesn't actually have a detailed
technical background but more from a management perspective.
So you want to keep the technical jargon in general or abbreviations to almost nothing.
You don't want to use any it can try to avoid as much technical words or phrases or sentences as you
possibly can.
It must be easily digestible from any leadership position regardless of technical expertise and you
want a short description of what the tack was the scope was what was found and the final outcome along
with some basic risk that you've decided all within you know a page and a half or so you mind executive
not gonna sit here and read you know 10 15 pages with screenshots and everything else just for the executive
summary.
So it needs to be short sweet into the point and hit the wrong button and then following this we have
this summary of results.
This is still relatively high level you're not going into what commands you did for example but this
is where you can you can throw some technical jargon in there.
This is going to be mainly for the individual that's going to be the true recipient of the port.
So executives might be the actual asking party but the real recipient of this report is going to be
the one that actually needs to fix the stuff that you found.
So this can have a little bit more technical jargon in it such as you know DNS zone transfers or whatever
you might want to say whether it was tunneling involved privilege escalation across this this type of
movement which exploits you use that type of thing you can keep it at that relatively high level and
you kind of want to give a full scope down from top to bottom of what you did without going into necessarily
the full command in a bunch of screenshots.
Again this is just text just like executive summary above it the summary result of results is just text
no screenshots no nothing.
Next we have attack details.
Now this section here can change depending on how your organization builds the report.
So if we look at the table of contents here we can see we have a reconnaissance section host a host
B with information on how the thing was attacked how host B was attacked or what it was compromised.
Was there lateral movement.
So I'm leaving this one up to you guys to actually fill this part in.
It's entirely however you want to do it.
So you can see down here where we have our top level and then we have recommendations as you can see
right here top level recommendations you can do the same thing with attack details and reconnaissance.
So we could go in here and put you know underneath here start putting recon.
Right.
So that's just one example of how you can format.
The formatting is just it's Zong as it's nice and easy to read it doesn't you don't need to worry too
much
but it's it's an entire.
It's how you want to go about it what's important here is this is where the real details come in what
commands you ran where the screenshots showing the compromise making sure you provide all the steps
and details required for somebody on the technical team other recipient of the technical team to be
able to reproduce the results that you found.
So this is where you dump all your detail and this is where 90 percent of the time is going to be spent
in the report.
Do your report might be 60 70 pages long but the executive summary will be one summary of findings might
be one and a half two and then the rest of it is pretty much the attack details and that's completely
fine.
But keep in mind that you want to keep summary and executive executive summary and summary of findings
near the top.
Keep the main chunk in the middle and then your risk factors and stuff with a little bit more technical
details at the bottom.
Just remember that everything from here executive summary is the very first thing that they want to
see when they're done they throw the report away essentially objectives not to sit here and read through
this 60 pages again and then this guy is going to probably redo this just to get a higher level overview
maybe it's the manager of the team that's got to be fixing it and then everybody else is probably gonna
end up reading this so following that we have under conclusion we have recommendations.
So this is where you need to be careful.
In most cases the red team or the consultant is not going to be the expert in the particular service
or system that you are that was attacked such as you know Apache and there are experts on the teams
associated to running those services inside the organization that need to be able to make the fixes.
But if you tell them what the issue is and what the recommended fixed is the standard recommended fix
such as upgrade the service change the config option you know something like that whatever the issue
might be give them the recommendation and then let them figure it out past that point.
Now if you're a contractor This is very important.
You don't want to and probably can't get stuck in trying to go back and forth with them about exactly
how to implement the fix and what the most ideal way is because you don't know their environment you're
not sitting there with them re learning the entire environment from top to bottom just to be able to
do this.
So keep that in mind.
But when you're on an internal team things get a little bit more of a gray area you understand after
awhile what your environment looks like and when things kind of make sense.
So your recommendations might be different than a contractors based on your internal knowledge but when
it comes to internal red teams and red teams you need to be able to be okay with somebody coming to
you and saying Hey this didn't work.
It's not looking like this is the right recommendation can you work with us to try to figure out what
else what else we need to do.
And if that's the case I would definitely spend the time and do it.
Let your manager know that you need to spend a little bit more time on the remediation side of things
and they can decide whether the time is well spent or not.
But let the manager make the choice in most cases if they're just asking for you know a half hour to
an hour of your time to sort out one particular issue that they were having problems with.
Normally it's not a big deal but always defer to the manager just in case because you do not want to
get your name put on to a list that is going through an entire project that might take six months to
complete and they want you in every meeting that's two or three times a week that can eat up a shit
ton of your time and you don't.
Not everybody has the time for that.
So always double check with your manager and make sure that you what what your requirements are for
actually making it through the remediation section and final up the report.
You're going to go over and talk about the risk now as just as an example if you're able to gain domain
administrator from the outside not from the outside Internet from public internet.
That is a high level of risk.
So if you're just able to find maybe a default creds on one web service but you couldn't get a shell
and then you may be found FCP had no password or had anonymous open and you were able to upload something
but you couldn't do anything with it.
That would be considered low.
So keep in mind that from a contractors perspective they're just going to see OK what access do I have
up to a certain point of access.
When does it become low for medium to high and most contracting agencies have their own rubric and metrics
around what they consider low medium and high internally.
This finding might not be as relevant as it would be from the outside.
So for example you might be able to escalate privileges or maybe there's a there's an internal API call
that you can make that allows you to execute commands but it's you can't execute it from the outside
it's only internal on the local machine when you already have command line access from an external from
an auditor's point of view.
They're going to label that as high it's remote code execution but from an internal user's perspective
or an internal red team you might have the back knowledge on that particular service or be able to get
that back knowledge that they contract you could not.
And understand that this is why this is not as big of a deal as we originally thought it might be.
However keep in mind you should feel free and be willing to push back if you find something that's not
good.
So let's say you found a new Web service that they put out and you have remote code execution on it
through whatever whatever means you want and they say it's not that big of a deal because it's inside
the network.
You have the OK to push back depending on what your manager says the pushback on it.
You want to make sure things are fixed because if somebody gains access to another machine in the network
and then all of a sudden they can pop this one because it's running as root that is a problem and it
can even take it a step further is OK.
Yeah.
They say OK you exploited the machine.
Now you have you have initial access but that user that was running that is a very privileged user.
It's not worth us fixing that access if the user can't do anything.
Again you need to take that a step further it's a go to that user log in is that user and see if you
break out if you can break out.
Now you have more pushback to be like hey they can do this and then they can do this to break out of
it.
Then you have your pushback.
And that can that normally forces somebody who's hand over to be able to go fix something because in
larger organizations and enterprises it's much more difficult to get somebody to fix something when
they're already hard pressed and not doing it and spending the time to do it.
So make sure you appropriate risk correctly and if you're new to red teaming take take your findings
provide their initial risk in the reasons of why in this part of the report and then before you send
out the report talk to another team member that might be a little bit more senior to identify whether
this is truly at the risk level that you have decided to for it to be at then you want to give an overall
risk assessment based on the scope of testing that you did and have some reasoning behind that as well.
So this is how I would format a report and how I do format reports.
So it's up to you guys to play around with the format I tasked you to try to make your own format grab
a different format online you can use this one if you'd want to it's go for it's free just change out
the logos and you're good to go.
So build your own report and try to fill it in with base information on all the attack vectors that
we've already put ourselves through.
So grab a Windows host compromise it with Metis point without mentors whatever the case might be.
Show prevails escalation and then build the report yourself.
Go ahead and build it out try to fill in as much as you can at this point without going into the next
videos just yet and then you'll have your initial copy of your report of what you what it looks like
then go through the rest of the videos and at the end of the module rebuild that same report with everything
else you learn and then compare the two and see what the big differences are.