Hi everybody and welcome to the penetration testing methodology video.
So what is a penetration testing methodology.
This type of match methodology is a set of procedures or steps that are performed when doing an assessment
or engagement.
So a quick way to think about this is similar to a recipe for a cake.
So you want to make sure that you have done all the steps in order or sometimes not in order depending
on the type of cake you're making or the type of engagement but you want to make sure that all the steps
are accounted for.
Otherwise the end result is not going to be what you're expecting so why is this type of methodology
needed.
So it gives a structure to a red teaming assessment like I was saying before.
It also provides consistency so it makes sure that all of the tests whether you ran it one month and
you ran the same test the next month it was all under the same parameters it followed the same steps
same methodology.
It's very important to have consistency in Red Team engagements or assessments to allow for anybody
coming in after the fact or a high level executive to look at this and see or even auditors for that
standpoint to be able to identify whether or not a framework is being put in place so another way to
say methodology in this particular case would be a framework.
So it avoids missing required components such as the reporting or maybe you're scanning a particular
target and you didn't scan UDP as an example.
So that would be an issue of missing data.
So that's failing the reconnaissance phase which will go over in a second.
So it it allows you to not miss required components which is very key.
So a method the methodology that I'm showing you here is is one that's proven and tested that I've used
over the years.
There are a thousand different ways to use different methodologies.
Some are very similar some are very different but in a general sense it will cover all of these aspects
at some point due out the test.
Now we're going to go into each one of these and there will be a module for each one of these steps
that will go into much more detail.
So in the first particular case we're gonna start with scope identification.
Moving down to reconnaissance to gather some more information then we're going to exploit the target.
So now we've got access to the machine.
We can do some post exploitation fun stuff so stuff like moving up to administrator or route.
And second to last is covering your steps.
This may or may not be required depending on the engagement that you're looking at.
And then the final step is reporting which should always be there.
So scope identification.
So what is scope.
So this will be going over in a separate module but scope in a nutshell is being able to understand
the wide variety of options that could go into place with an engagement.
So stuff like goal identification so knowing what the end goal happens to be do you need to notify anybody
of that the test is about to occur.
Are there any stability or service considerations that have to be took into place such as a service
being let's say we have a job a service that is specifically finicky about receiving a lot of traffic
that would be something you'd want to take into consideration in the scope identification phase.
So this is more of the paperwork side of things.
So it's still very important there needs to be a paper trail around your assessments.
So think of this as a cover your ass type situation.
This is your get out of jail free card if you're a freelancer or a consultant.
The next step is the reconnaissance phase.
So what does reconnaissance reconnaissance has two particular things.
It's an active or passive check.
So this is where you either on the active side you are actually touching the target looking at information
running scans performing enumeration which is just information gathering or you're being passive about
it using Google you're using third party tools to actually touch the organization.
So this will all go into more detail but this is the first core concept of running a test of any engagement
is identifying the information that you need and all the information available whether it's small or
large because you never know what you're going to need or what's going to let you actually get through.
So the fun stuff the exploitation phase.
So what is exploitation.
We're actually attacking the host.
We're gaining access of some kind.
We're validating our findings that we found in the reconnaissance phase.
Again explain the target them ensuring the stability of the exploits as well.
So there'll be more on a few videos on this on how to make sure an exploit is not unstable for the machine.
There's also based on the scope identification phase you should know what services you're attacking
or can't attack.
That will have a better affects on the stability of the system.
So the Post exploitation so this is where it starts to get a little bit interesting.
So post exploitation in a nutshell is around the task of gaining full access to the machines starting
from a low level user access to full add or root access.
So this is considered privilege escalation in this particular phase you want to get your persistence
on the machine so make sure you don't have to re-explain a service that may have crashed you want to
be able to be able to get onto the box again quickly without any issues.
So again moving laterally as part of this as well where you might gain access to one host but let's
say you're from the you're you're attacking from the internet's perspective.
Now you have a foothold in the network.
So moving laterally laterally for you.
Is moving to different machines being able to scan from there and then looking for some good fun stuff
such as password hash is going through emails that might be left in the system who's logged in key logging
in.
There's a lot of varieties of things that can be done here.
Covering your tracks.
So this module when you get there we'll be going over why you cover your tracks and if it is required.
So this depends on the engagement sometimes your wanting to have the logs there.
So that reporting tools can catch what you're doing.
However sometimes clearing them will alert that somebody is there.
So depending on the engagement or assessment you may want to change this up.
So we'll go over where log files are in each different type of OS where their locations are what they
are whether or not you should wipe the logs will go into different beautiful ways of hiding your persistence
or whether that's do a rootkit or whether that's through hiding it just with the OS level calls.
So we'll go over that in its own module and then cleaning up.
So in a lot of times engagements you'll need to clean up after yourselves whether that's you've changed
the password configuration etc. It's important that you go and clean up depending on the engagement
so you don't leave a foothold for somebody else.
So reporting is the last section of the methodology but it's also one of the most important similar
to scope identification.
So you'll understand only to understand why we do reporting the audience that you're reporting to other
that's executives or another red team or so you'll also want to know how to build the report and we'll
have a full video series on how to build a report how it's supposed to look how to report for different
audiences.
It's also important for the feedback loop.
So you've done the test.
You need to get the report to somebody who can actually perform actionable things on it such as building
detections patching systems et cetera.
You're also gonna be able to prioritize business risk based on the findings so in some cases in this
organization remote code execution may be more prevalent in one but not in the other depending on where
the system was found.
So we'll go all out like I said all of this is going to be in more detail and each step of the methodology
is going to have its own module.