- [Instructor] The process of completing a penetration test
will vary on many different factors.
And of course, the technology
and how you will actually hire
the scope of that engagement.
For example, in some cases,
actually you may be hired
just to look at one application
and one application itself.
And in other cases,
you actually looking at the whole organization, right?
So some best testing engagements
will last just a couple of weeks or a few days.
And other ones, in some cases,
actually may endure for a longer period of time.
I'm talking about months, in some cases.
There are also different
penetration testing engagements, right?
So you may be doing penetration testing
for a customer or for your client.
You may be hired by organization on an ongoing basis.
You're actually doing pen testing
across a very, very large enterprise,
and different sections of that enterprise.
And in some cases, especially you know,
a sister team of mine,
they actually do penetration testing
just specifically finding vulnerabilities
in products and services of a very large company.
So having said that, you know, of course
there's a lot of different dependencies
that you will encounter in this.
The networks and system being evaluated many times
are very high, complex.
And subsequently, you know
you can actually define it, very large scope.
And again, we're gonna go into scoping a little bit later,
throughout the presentation.
But why do we need to actually follow a methodology?
Right, for pen testing, right?
Now, when performing and penetration testing for a customer,
for example,
you must show that the methods you want to use
for the testing are actually, you know, true,
that you actually have done a good methodology before.
And not only that,
but allows you to organize your work
to then, you know, follow through.
But at the end of the day,
there are many different penetration testing
methodologies out there, right?
Methodologies for testing mobile applications,
networking infrastructure devices,
testing wireless networks, and so on.
But a few things that I want to,
or a few methodologies that I want to highlight to you,
is the Penetration Testing Execution Standard, or PTES,
and that's actually defined in different distinct faces.
Pre-engagement interactions, intelligence gathering.
So that means you are doing reconnaissance,
both passive and active reconnaissance
and we're gonna cover all these concepts
throughout the course.
You also do threat modeling
after you find, you know,
all the specific details, whether it's active
or in the passive reconnaissance exercise.
And then once you actually do the threat modeling,
you actually do the vulnerability analysis.
You move into the exploitation phase.
And in some cases, you may not be allowed,
depending on the scope on doing post exploitation.
But in most cases you may actually be able to do
a mimic true attacker, and do post exploitation.
And that means moving laterally or doing pivoting,
compromising other systems, extra trading data,
maintaining persistence,
and doing command and control.
And all these concepts you're gonna learn
throughout the presentation
and throughout this course.
Once you finish, you know,
your post exploitation and, you know,
conclude your assessment,
then you move into the reporting phase.
And of course, that's what you get hired for
is to actually create a report for your client.
And that report must also have a few other things.
That report should have mitigations,
it should have recommendations,
and also a method of rating
how severe are the vulnerabilities,
and the risks of those vulnerabilities.
And we actually gotta be covering that in detail
whenever we talk about, you know,
best practices of penetration testing reports.
Now there are a few other penetration testing
or I will say methodologies
for security testing out there.
One of the most popular as well,
basically is a document created
by the National Institute of Standards and Technology
for the purpose of providing organizations
with guidelines on planning
and conducting any information security testing.
If you look at the document,
they actually have four different phases,
but they pretty much align
with the penetration testing execution standard, right.
They just concise it in few others.
You also have the Open Source Security Testing
Methodology Manual, or the OSSTMM, for short.
And one of my favorite ones,
especially whenever it comes to penetration testing
for web applications is the OWASP penetration testing,
or the testing methodology, right?
And I'm actually highlighting these.
We actually gonna be covering a lot
of these concepts on methodologies throughout the course.
So, but these are amazing references
for you to become familiar with.
Now that I mentioned a few of the methodologies,
you know I want to also share with you
some of the most common terms used
for the types of penetration testing
that we actually see today, right?
And you may be testing a web application,
as I mentioned to you,
just focusing on that specific application
or several applications,
perhaps a cloud service.
And you do this by actually not only looking at
the traditional application itself,
like the front end and the back end of the database,
but we also look at things
that are a little bit more modern, like APIs
single sign on, and how authentication is actually done,
like open ID, and some other ones.
We will be covering that later in the course.
Now you also can take a little bit different approach
of testing infrastructure devices
and even testing the security devices
that are supposed to protect your network.
You also do testing of wireless networks
and in some cases, actually,
you're just hired to do that,
just to test the wireless infrastructure
of an organization.
You may also be hired to test just a physical facility.
So a physical assessment for that organization.
That means that can you use social engineering,
and bypass security, you know,
physical security implementations,
like, you know just a normal guard or gates,
or, you know, badges,
you can clone badges and so on.
Right, so there are many organizations
that actually that they have individuals
just focused on physical penetration testing.
Now another one is of course, social engineering, right?
And a lot of the compromises nowadays
actually start with some type of social engineering attack.
We will be covering this in detail
later in the course.
But of course, you know, in some examples,
or in some engagements,
you may be hire just to do social engineering
or to combine social engineering
with technical penetration testing capabilities.
Now that I'm talking about technical,
there's a few methods that you also hear out there.
One is called black box testing.
Another one is called white box.
And the third one is called gray box testing.
And basically a black box testing
is whenever you as a tester,
have a very, very limited amount of information,
in some cases, no information at all,
about your victim, right?
About the systems that you actually
may be attacking or assessing.
Now, in that case, of course,
at least you have to know some type of scope and permission,
but your client or your organization
may not give you a lot of information.
So you have to do a lot of reconnaissance for you.
And that's whenever, you know, of course
things get interesting,
especially around scope in some cases.
Now you also have the concept
of a white box penetration tester.
And that's whenever you have
a significant amount of information
about the organization,
the infrastructure, the applications,
in some cases, you even have access
to the source code of applications system designs,
documentation, engineering documentations,
and even documentations about APIs
like swagger files and WSDL files.
And we're gonna be covering all this later
in the presentation as well.
Right, but that's is what is a white box testing.
Now a gray box,
and you may be already figuring this out already.
You know, it's a permutation between the two, right?
So somewhere of a hybrid approach
between black and white box testing methodologies,
where you actually have some information,
but not a full documentation
of the network infrastructure
or not access to source code, for example