All language subtitles for 004 Target List (OBJ 1.2)

Instructor: As we move forward with planning and scoping,

we need to find a valid target for us to attack.

This is conducted from a technical perspective

as we go through our information gathering

and vulnerability scanning phase.

But as a penetration tester,

we first are gonna conduct target selection

in the planning and scoping phase,

as we negotiate this with the targeted organization

inside of our contract and our statement of work.

We first need to ask:

Is our targets gonna be internal or external?

Are they gonna be first party or third party hosted?

And if we can do physical attacks,

or if we can go after the users,

if we can go after their wireless networks,

if we can target applications,

and numerous other scoping concerns.

That's what we're gonna focus on

in this lesson as we discuss target selection.

And we'll leave the more technical target selection

for later on when we cover information gathering

and vulnerability scanning

at a later phase in the engagement.

First, we have to determine if our scope is going to consist

of internal or external targets.

Internal targets are those

inside the organization's firewall

and require us to be on-site, gain access through a VPN,

or exploit a user's computer

inside the organizational network

and use that as a pivot point.

On the other hand,

external targets are publicly facing targets

which can be accessed directly across the internet,

such as a website, web application, email,

or DNS server in a screen subnet

that's outside of the protected local area network.

Second, we have first party and third party hosted assets.

Are the targets provided in our statement of work

hosted by the organization itself in their own data center,

in which case we call these first party hosted assets,

or are they gonna be hosted

by a third party service provider, like Amazon Web Services,

Microsoft Azure, Google Cloud, or other cloud providers?

Now, due to the massive migration of the cloud,

there are a lot of third party service providers out there

that are hosting different assets that you may

or may not be able to include in your assessment scope.

This includes the major cloud providers I just listed,

like Amazon Web Services, Microsoft Azure,

and Google Cloud, but there are also

numerous smaller cloud service providers as well out there.

During the planning and scoping phase,

the target organization needs to inform us

if we're only allowed to attack

their first party hosted servers

or are we allowed to also go

after the assets hosted in a third party environment.

For example, my company's website, diontraining.com,

is hosted by a third party cloud service provider.

If you are hired to conduct an engagement

of my company's e-learning platform, I have to first decide,

are you gonna be allowed to go

after our office networks and file servers

that we host locally using our first party model,

or are you also gonna be allowed to go after our website

and e-learning platform, which uses third party hosting?

Maybe I only want you to go

after third party hosted applications, and if so,

that has to be accounted for

during the planning and scoping phase

so that you can gain all the necessary permissions

from that cloud service provider in addition

to gaining permission from your client's organization.

Next, we need to discuss the physical aspects

of the engagement.

Are we gonna test the organization's physical security?

Do they want us to do an on-site assessment?

Should we try to sneak past the guards,

overcoming the security cameras, the pin pads,

and other physical security controls?

Again, this is something that must be answered

as part of the planning and scoping phase

to determine if a physical assessment is going to be used.

We have to know whether physical security

is part of the assessment, or are we just gonna be hired

to conduct a technical assessment of the network.

If a physical assessment is gonna be in scope,

you're also gonna need to determine which locations

are covered by the scope of the assessment.

For example, my small company has employees

and assets located across six different countries right now.

If I hire you for an engagement,

will you conduct an assessment

of all six locations or just our main officer headquarters?

Additionally, physical locations

of the organization's assets are usually gonna be defined

as either being on-site or off-site.

An on-site asset is any asset that is physically located

where the attack is being carried out.

For example, if you're trying to break into my offices

as part of a physical penetration test and gain access

to my infrastructure, my server room, or my employees,

these are all considered on-site assets or targets.

Conversely, off-site assets are defined

as any asset that provides a service for a company

but is not necessarily located

at the same place as that company.

For example, I used to be an IT director

for an organization whose data center was located in Italy,

but we also had regional satellite offices

located in four other countries spread across Europe.

Often, you're gonna find that these smaller regional offices

or satellite offices have less stringent security

than the main data center or headquarters.

So if those off-site locations

and assets are considered part of your engagement scope,

you might find an easier way into the headquarters

by pivoting through one of those off-site locations.

In today's deparameterization environment, it is common

that employee-owned devices may also be categorized

as an off-site location

because their home office is essentially an extension

of your headquarters network once they connect

into that organizational network using a VPN.

Next, we should also consider whether testing

of the users is considered authorized

or if it's considered off-limits.

Can we use spear phishing or even phishing attacks

against the organization's user base?

Can we do social engineering against them?

Can we try to trick the employees

in order to get them to let us into the building

and bypass their physical security?

Now, again, there's no right

or wrong answer to these questions.

It's all negotiable as part of the planning

and scoping for the engagement.

For example, in a past assessment, my team was told

that we could not target any of the executives,

but any of the regular users was considered fair game

for our social engineering attempts.

In other assessments, we've been told specifically

to target the sales department

to determine if the user awareness training

they received a few months earlier was effective or not.

Remember, users tend to be

the easiest attack vector to go after,

especially if they're considered

in scope for the assessment and you're allowed

to use various social engineering attacks against them.

The next area of concern we have

is regarding wireless networks.

I'm always careful to ask an organization

to specify which wireless network identifiers

or SSIDs or within the scope of my engagements.

If we're being asked

to conduct wireless penetration testing,

we need to ensure that we're only targeting equipment

that's owned and operated by the organization

that we're actually doing the testing for

because they're the only ones who can grant permission

for the networks they own and operate.

For example, at many offices,

there's a company wireless network

and a guest wireless network, or at a hotel,

there's one wireless network for the point of sale systems

and another one that's used by the guests of the hotel.

If we're gonna assess the hotel,

we need to negotiate which network is in scope

of the engagement and which one is outside of our scope.

Are you allowed to set up an evil twin

or rogue access point using the same

or similar service set identifier

as a organization's trusted wireless network?

Well, maybe you are. Maybe you aren't.

Again, there's no right or wrong answer here.

We just need to make sure that the penetration tester

and the organization are both agreeing to the scope

during the planning and scoping phase

so we're all on the same page.

As we consider the wired

and wireless organizational networks,

we also need to identify

which assets are gonna be considered in scope

based on their IP addresses or IP ranges,

the domain or subdomain associated with them,

or their DNS or domain name system servers.

Now, IP addresses of the in scope asset

should include the appropriate network ranges

and the autonomous system numbers known as ASNs.

These ASNs are used by the organization

as a globally unique identifier

that defines a group of one or more IP prefixes

that are run by one or more network operators

that maintain a single, clearly-defined routing policy.

ASNs are used with the Border Gateway Protocol,

and if they're changed inadvertently,

it can cause all sorts of disastrous routing issues

for the organization's traffic going over the internet.

It's also important to include a list of domains

and subdomains that are considered

in scope for the assessment.

For example, since I use an elastic cloud architecture

for my learning management system, we're constantly adding

and removing IP addresses behind our load balancer,

but our domain names

and our subdomain names are not changing rapidly.

Therefore, you should always have a list

of our domains and subdomains that are considered

in scope for the assessment.

For example, maybe my website, www.diontraining.com,

is considered in scope, but my support portal

at support.diontraining.com is not in scope.

By having a clear list of in scope

and out of scope domains and subdomains,

you can avoid any issues during the engagement.

Also, you need to know

if the organization will allow you to target

or modify their DNS servers and its records.

For example, are you allowed to conduct DNS poisoning?

How about a watering hole attack

as part of a social engineering campaign?

Again, there's no right or wrong answer here.

It's just up to you and your client

to determine the proper scope for the engagement based

on your objectives and goals that the organization has.

Now, the final area to think about is that of applications

and more specifically, web applications

and their application programming interfaces, known as APIs.

If we're gonna do a web application test,

are we gonna be focused on a single application

or all applications on a given web server?

For example,

if a penetration tester is assessing a web application,

are they only looking at the code developed by the company

or should they look

at the applications underneath the code as well?

Can the penetration tester target the Apache web server,

the MySQL database, the PHP code,

or even the underlying software development kits,

known as SDKs?

All of these things may or may not be

in the scope of the engagement

depending on what was contracted and agreed upon

by your company and your client organization.

A web application and its associate APIs

could be used for either public facing applications

or they may only be internal to the organization.

For example, in my company,

we have several APIs that we have developed

in order to deliver our courses, our labs, our textbooks,

and our exams to all of our students at diontraining.com.

For example, in the version

of this course located at diontraining.com,

we also include hands-on labs where students

can enter a cloud-based penetration testing environment

and practice with all different kinds of attacks

and tools that we cover in this course.

Our learning management system, though,

didn't have this capability initially,

so we had to develop our own API that accepts

the student's unique user identification number,

their email, and the lab they wanna access,

along with the secret authentication token, and in return,

the API provides the link to launch the lab,

and this allows the students to click a button

and access and utilize these cloud-based labs.

Now, during the scoping, it's also important to determine

if there's a particular application

on the client's system that's considered mission critical,

and therefore, the client cannot afford

to have it experience any downtime during the engagement.

For example, a credit card processing application

might be such a system in a retail environment.

While the patient record management application

in a hospital might be equally important

in that organization's situation.

The penetration tester and the client need to work together

to both understand which applications or systems

need to be excluded from the scope of the engagement

to ensure that the organization can still be able

to conduct its mission successfully during the attacks.

Once again, this really depends on your negotiations

with the client during the planning and scoping phase

of your penetration test.

(light upbeat music)