Target Selection

00:00

Hello and welcome to another penetration. Testing execution Standard discussion. Today we're going to be looking at target selection

00:10

now. A quick disclaimer. The Pee test videos do cover tools that could be used for system hacking. Any tools discussed or use during the demonstrations or that we show during the videos should be researched and understood by the user. Please research your laws and regulations regarding the use of such tools. While we wanna have fun

00:30

and we want to learn, we want to ensure that we don't get into any trouble with the law.

00:34

So let's go ahead and look at our objectives for today's discussion.

00:39

So the first thing we're going to do is we're going to discuss identification and naming of targets. We're going to look back into the rules of engagement and make sure that we understand limitations to target selection and how we should treat those. We're going to discuss some considerations for time and why we should always

00:56

understand what our limitations are with respect to time. When we're looking at targets and looking at exactly what we're trying to do during the test

01:03

and then really looking at what the end goals for the test are and what the executive team is hoping to achieve, what the business owners are hoping to achieve, and then a line that test Thio

01:15

kind of meet those expectations based on the targets that we have available to us.

01:19

So let's jump into target van defecation and naming. So when approaching a target organization, it's important to understand that most companies have different top level domains and, in some cases, auxiliary businesses. I work with an organization one time

01:38

that had, ah 135 different domains that they used for business purposes and those domains. Each of those 135 domains had different sites, different content bodies, et cetera. And so it was very, very important to understand how those domains were linked to one another if they were

01:57

and which of those domains were in scope. And we're not in scope. And so always take into consideration that

02:04

some business owners run Maur than just a flower shopper run Maur than just a sandwich shop for ah, you know, a repair shop. Whatever the case may be taken to account that they may have multiple domains and multiple things running off of their infrastructure.

02:20

And so while this information should, you know, be discovered, of course, during the scoping phase. And so we always want that to come out. We always want the business owner to kind of explain to us what the business looks like and what other domains there aren't. What other business units there are that they run outside of the stuff that's within our purview?

02:37

It's not unusual to find additional servers and domains and companies that have not been a part of the initial scope when we were in that pre engagement phase. So, um, for example, a company may have a top level domain of dot com,

02:53

but they may also have a dot net dot co dot triple X. Whatever the case may be X x x here

02:59

referencing any other domain name.

03:01

And so these may need to be a part of a revised scope. Or they may be off limits, depending on whether that redirect to the DOT net is for some other business unit or the dot co or the dot i t. Or whatever the case may be. So

03:16

when we initially sit down and do our pre engagement and are scoping and our rules of engagement and things of that nature we need to take into consideration. That is, we get into the work. We may run into additional domains

03:32

as we're going through paperwork, er as we're asking additional questions. Or maybe we get to talk to the director of I T. Who maybe has not been a part of any discussions up to this point.

03:44

And he says, Oh, yeah, by the way, we've got seven domains. We've got

03:47

these business units. We take care of this infrastructure on premises. Well, well, now we need to take all that into consideration. So we may need to do some revision and make sure that we're, you know, adequately documenting everything in adequately testing. And with that comes into question the rules of engagement limitations.

04:05

And so at this point, it's a good idea to re review the rules of engagement. Um,

04:13

and it's common for these two get forgotten during a tense. So we get excited. We are getting ready to do some scan, and we're actually done with all the boring paperwork, and it's time to execute. But remember, as we find new assets as we get new information. We want to make sure that they were accounted for in the rules of engagement. So sometimes we get wrapped up

04:31

and finding that there is an I. P. Address that we could attack,

04:35

um,

04:38

or domains that we can attack our network that we can attack. But we maybe don't remember verbatim again what is and is not in scope. So always remember, take it and put it next to your laptop. Print out. You know, a rule of targets or a set of targets and keep him in a safe place in your office as you're working,

04:54

if you're about have a reference document on your laptop. So you're not carrying physical paper

05:00

and reference reference reference the rules of engagement to keep the test focused to keep you legal. And to ensure that scope creep doesn't impact your ability to finish the project on time as well as you know, with the clients goals and their focus

05:17

in mind. So if you accidentally skin and I p

05:20

or you accidentally attack an I P. Take note, you know, report that up the chain to your supervisor and sure that they're aware just, you know tell him it was an accident, whatever the case may be. But always

05:33

ensure that you stay within the bounds of your rules of engagement, especially if you find additional sites. And I know that there are a lot of tools out there that used, like a spider that you can then, you know, find other sites or other domains or other information on the site.

05:50

We want to make sure that if our rules of engagement dictate that we on Lee attack certain sites

05:56

that those sites are deemed as in scope and then anything else is considered out of scope. And if you've got the names of the other domains

06:04

in the tool I would put them is out of scope to ensure that the spider tool, you know, does not creep out into those other areas and test things that it should not be testing.

06:15

Now we also want to take into account time considerations. When we are doing any type of additional testing are open source information gathering or whatever the case may be intelligence gathering.

06:29

So

06:30

total time does impact. How much we can do Remember level one. So when we talked about level one that's just click a button and running tool. When we talked Level two, that's got a little manual analysis involved. And when we talked Level three. We're talking nation state

06:46

like in depth analysis, making connections where otherwise connections may not be seen.

06:51

And so, depending on the testing time like, let's say, in this case, we have two or three months

06:58

to do, you know, our testing Well, then we could spend a large amount of time looking at each core business unit and personnel in the company and making connections and

07:08

doing that kind of C S I style mind map where we've got photos and connections and little pieces of yarn connecting people. Maybe doing multi go instead. That's easier toe

07:17

to demonstrate. But

07:19

you know, when we've got that level of time, we can start to move, you know, into deeper level to analysis or deeper level three type analysis, where we're looking at records and court documents and financial reports and business contracts and things of that nature. But if we've only got four weeks to do testing,

07:39

then we need to be more tactical in the approach, and so we may have a specific Web application that may not require research of financial records of the company CEO. So, depending on the target, depending on the objective if its compliance driven, then we probably stay more within that level one area

07:58

and do some of the standard. You know, smash and grab with an automated tool.

08:03

And we don't get deep into records in public information. That's just the nature of how that would work.

08:09

And so we also need to take into account is mentioned towards the in here the testing end goal. So every test, every test has an in goal in mind. Regardless of what you you know, our goal is to reduce risk.

08:22

But the clients in goal

08:24

may differ. So a particular asset or process that the organization considers critical

08:31

okay is likely something to point out as one of their main goals.

08:37

And so, having results in mind, the intelligence gathering face should make sure to include all secondary and tertiary elements surrounding the in goal. So if I've got a critical business system

08:48

and that critical business system has connections to other business units, connections to other third party organizations, I may want to take those into consideration at least when I'm building a risk profile. Maybe. And you know, I can't attack those organizations and I can't, you know, potentially do anything with that data.

09:07

But I could use it to build a risk profile

09:09

and help the client to better understand the attack vectors and the threats and the opportunities. It would be there for a threat actor. So that is part of my job is the penetration testers to help them understand those things

09:22

and to help them, you know, really build controls around that. And then, you know, of course, they have fun and do some testing as well in the process. But

09:31

that is definitely a part of our our job and information gathering. So on again, this could be supporting technologies. Third parties, relevant personnel, Making sure the focus has kept on critical assets again assures that the lesser relevant intelligence are deep, prioritize and categorize as such

09:50

in order to not

09:52

intervene with the analysis process. And so

09:56

again, just ensuring that we're covering core business processes, core and critical systems, and gathering intelligence relevant to those systems is going to make this process that much better for the client and that much better from a risk reduction standpoint, which is our goal as testers.

10:13

So let's do a quick check on learning.

10:16

So which document concerns how a test should be conducted and any limitations?

10:22

Which document concerns how it should be conducted in any limitations?

10:28

Well,

10:30

if you need more time, pause the video and take a moment. So a test how it should be conducted in any limitations. So a non disclosure agreement is really when were scoping and we're discussing business units and possibly confidential information. A non disclosure agreement provides that protection rules of engagement

10:48

is actually the answer. So I skipped ahead. Their rules of engagement is the answer. That is what determines how the world will be conducted and any limitations. The word breakdown structure is just a listing of tasks throughout the project, and the scope of work

11:03

is the items with in scope that will be testing. But it does not include how we will test and what we will. Testa's faras wth e

11:11

conducting of the test. So limitations and how the systems were tested specifically are covered in the rules of engagement.

11:18

So let's go ahead and look at our summary for this discussion. So we identified

11:24

systems and how naming could work. So we discussed identification and naming. We discussed rules of engagement and limitations. We looked at time considerations, and we discussed testing and goals. Remember that if the client wants an in depth analysis nation state style,

11:41

it's going to take more time. And if you've only got four weeks to do a test,

11:45

you really can't do nation state style information gathering. You might be able to do level one, maybe a touch of level two gathering.

11:52

But if you've got more time, definitely consider that in the information gathering process. And so, in addition, rules of engagement and identification and naming remember that if we identify systems that were initially outside of the scope, that may need to be in the scope, we need to ensure that there's air added to the rules of engagement or

12:11

they are added as an off limits system and were aware that they should not be tested. And we configure our tools accordingly to ensure