Inside Red Team Operations, Part 1: Planning, Recon and Equipment

by July 30, 2012 07/30/12
1 of 3 in the series Inside Red Team Operations
Inside Red Team Operations
  1. Inside Red Team Operations, Part 1: Planning, Recon and Equipment
  2. Inside Red Team Operations, Part 2: Analyzing Recon Data and The Dry Run
  3. Inside Red Team Operations, Part 3: Execute, Execute, Execute!

In this three part series we’re going to go through what it takes to perform a security vulnerability assessment that would ultimately end in the penetration of the target.

In part 1 we’ll talk about planning the operation, digital & physical recon and some of the kit we might need. In part 2, we’ll analyze the information gathered during the recon, plan and rehearse the operation and perform a dry run. This will test what we’ve learned and polish our plan. In part 3 we’ll execute the operation and plan for contingencies when things don’t go as planned.

What is a Red Team?

In the world of computer and information security, a red team is a group of highly skilled experts hired to provide adversarial services, i.e. to act like attackers. The goal of red team operations is to continuously challenge the plans, defensive measures and concepts of the organization.

These exercises result in a better understanding of possible adversaries and help to improve counter measures against future threats. Red teams are also tasked with probing physical security measures, sometimes as part of an overall digital/physical assessment and sometimes as a project of its own.

This series will focus on a combination of both physical and digital vulnerability assessments, as well as penetration of the target. This way you can see the techniques needed for both.

It is important to mention that each project/operation is different and the techniques described here will have to be adapted, changed or completely dropped based on the target. It is also important to mention that I will keep the technical details to a minimum. I’m doing this for two reasons; one, because not everyone reading this has a background in computers and two, because I don’t want to show the bad guys any technique they can use.

With all this in mind, let’s begin.

The Project

We’re tasked with penetrating the internal network of a fortune 100 company. If successful, we are also tasked with acquiring highly sensitive marketing documents.

There are many ways to try to penetrate their network and systems but we are going to focus on two. We will try a purely digital approach first, if it fails, we’ll try a physical approach that might give us a way into their network.

The digital approach usually entails scanning their public facing systems in search for a vulnerability to exploit, or a more direct approach that includes social engineering (hacking people into providing information) and a well placed weaponized document or attack code. A physical approach is just that. Physically penetrating the premises, trying to either get to a computer inside or connecting your laptop to their network and trying to find the documents. More often there’s a backdoor to access the network remotely from the convenience of your office/TOC.

Planning and Initial Recon

The initial recon and planning phase is critical. Some operations fail because of lack of information about the target, others are highly successful because the recon was carefully performed and all the possible weak points were identified.

Digital Recon

Let’s start with information in the public domain. Open source intelligence (OSINT) gathering is our first priority. You’d be surprised how much information about companies, their employees and the technology they use in their networks is really out there.

We can start using Google, Yahoo, DuckDuckGo and other search engines, however it would be good to use a search engine aggregator that can search across all search engines at once. It’s also useful sometimes to use the local search engines if we’re targeting a company or organization in another country.

There are services that provide a list of local search engines, or you can try local Google or Yahoo versions. For example, for russia try google.ru and ru.yahoo.com, for Argentina google.com.ar or for France google.fr. You get the picture.

We begin by searching for the company’s web sites, domains, press releases that might indicate the use of a certain technology, names of employees, high level executives, etc.

Press releases are a great resource, for example, they usually detail new products with names of technology, executives and other snippets of information that we can use for a social engineering approach.

Next we search for emails. We can type “@companydomain” and usually you’ll get a list of sites where people used their company email address for various tasks. This is a great source of information about employees (possible targets for social engineering) but more importantly, a lot of times IT people go to technical forums to request help about the technology they are using. It’s a great way to start mapping their operating systems, web servers, databases, firewalls, routers, etc. without having started the mapping part of the recon.

OSINT will usually take a few weeks. We want to gather as much information as we can and built a logical map of what we now know: people, systems, products and connections between all these.

Another great way to gather information is to call the company phone number off hours and if you get a voice mail probe for default passwords. Chances are you’ll get several hits. You can get a lot of good intel via this method. Getting the company’s different phone numbers is relatively easy.

The next phase of the digital recon is mapping the public facing digital assets. We want to know their digital footprint: IP address ranges, domains, websites and security devices if possible. This should be done very carefully, we don’t want to tip their security devices that we are mapping them.

We start searching the different “whois” databases for their different IP ranges. Since our target is a fortune 100 organization, chances are they have acquired a set of IP addresses that is static to that company. Knowing the IP ranges will allow us to also map those servers that might be connected to the internet but do not necessarily provide services (like a company website or e-commerce site do). You would be amazed at what you can find sometimes. In one project I found a server that had a Telnet service up and running, needless to say it was my way in. A developer enabled this for a project and forgot to disable it later. Humans… They are always the weakest link.

We want to map the ports open, the services behind those ports, operating systems, web server software, database software, versions of the software, email servers, file transfer services, etc. Once we have this information we can perform a very simple and fast vulnerability assessment and see what is exploitable right then and there. Sometimes this is all it takes, but most of the time it’s more complicated than this.

There are countless tools to do this, some open source, some commercial. Check online for more information.

Physical Recon

Now for the physical part. If we’re considering the possibility of a physical penetration we need to recon the target.

I usually divide the recon into two different methods: covert and overt. In a covert recon you’re usually either away from the target, using binos or scopes to surveil the target, or you are performing recon at night completely hidden. An overt recon usually means walking into the target’s premisses and pretending to be someone you’re not, while trying to collect as much information as you can by either observing or taking to people (social engineering).

During a physical recon I would also perform a scan of the premisses for any wireless, bluetooth or other RF that I can find. Many times during projects I found open wireless access points and routers. I logged right into them and used them as a channel in. As part of the kit, it’s useful to not only have a lightweight laptop during a physical recon, but also a wireless signal finder/scanner, wifi antenna booster, a good set of stumblers and other software to map all the signals you might find.

I found it very useful to perform a physical recon with a team of 2 or 3 members. You can send one around the premises to check any possible ways in (in case we need a covert entry), while the others maintain a tight surveillance. Key items to map are dress code of employees, badges or IDs they have, working hours, guards and their schedule, different access points to the building, daily activities (day & night) and also paying attention to trash collection, product delivery, etc.

Equipment

A good camera, scopes and other observation gear is needed here. Usually hunting stores have great gear you can get.  All this will provide a clear picture of what’s going on around the building, but not inside. Like I mentioned, sometimes you have to perform an overt recon.

For these, I find it very useful to have a small voice recorder and have it on as soon as you walk in. It will record any information people might give you, while also recording atmospherics: a loudspeaker announcing company news or the name of an employee, normal working noise, etc.

Also carry a USB or a small wireless card with you, sometimes during the recon you’ll find yourself in the position of having a brief access to a computer inside the company. Plug that wireless router/card (pre-configured to a certain name/password) and try connecting to it later when you leave. Carry a set of lock picking tools, I like the Bogota Entry Toolset. It’s small, easy to conceal and in most cases work like a charm.

Also, I like to carry a small LED light, which is useful to check inside server racks and other tight spots, a small knife, a pen and a notepad.

Pen and paper might seem a bit outdated but it’s a great way to create a sketch of the site: doors, elevators, access points, guard and camera locations, etc. It’s is an invaluable tool for a physical recon.

Summary

We’ve just gone through the initial information gathering and recon phase. This is a critical phase and can make or break our operation.

You need knowledge to perform the technical part, but overall you have to be creative. Think outside the box, think like an attacker, try to figure out what they would do to gather information. For example, large corporations usually have a cafeteria or restaurant inside their building. This is a weak spot during lunch time, with a lot of activity. You could sneak in dressed as a cook, or even a server and you’re inside.

Bend the rules.

Stay tuned for part 2 where we’ll talk about analyzing the data gathered during our recon, as well as the planning and execution of a dry run!


Are you getting more than 14¢ of value per day from ITS Tactical?

Please consider joining our Crew Leader Membership and our growing community of supporters.

At ITS Tactical we’re working hard every day to provide different methods, ideas and knowledge that could one day save your life. Instead of simply asking for your support with donations, we’ve developed a membership to allow our readers to support what we do and allow us to give you back something in return.

For less than 14¢ a day you can help contribute directly to our content, and join our growing community of supporters who have directly influenced what we’ve been able to accomplish and where we’re headed.

Click here to learn about all the benefits and Join!


Tanja
Tanja

Spot on with this write-up, I actually think this website needs far more attention.

I'll probably be returning to read through more, thanks for the info!

Tanja
Tanja

Spot on with this write-up, I actually think this website needs far more attention. I'll probably be returning to read through more, thanks for the info!

Anderson
Anderson

I was wondering when part three is coming out.

Medic Steve 2
Medic Steve 2

Uri,

Mazels on a great article! Glad to see you posting on one of my other favorite sites!

Medic Steve 2
Medic Steve 2

Uri, Mazels on a great article! Glad to see you posting on one of my other favorite sites!

u. fridman
u. fridman

Correct, that is my blog. I am contributor for ITS Tactical and this post was writing first and foremost for ITS Tactical. Red Teams even links to this.

skvola
skvola

One tool to look at for the digital assessment is Katana, this tool will crack passwords on machines and Backtrack is great but look into blackbuntu as well, great tools. One item you might find useful in this kit would be an RF spoofer, RF id is so common in most corporate environments now that all it may take is a wave over the badge of the badge of a security guard and you could have total building access.

Mark
Mark

This appears to be the exact same article as on redteams.net I am going to assume that they are a contributor not that this article was blatantly plagiarized...

Brandon Franklin
Brandon Franklin

It looks like there's a depth limit on the comment threads so I'm going to have to reply to your latest comment here. I agree that you need to collect intelligence to identify attack surfaces, but I think the concept of attack surface is critical to ensuring you thoroughly collect intelligence. For example, without the concept of attack surfaces, I'm compiling a list of marketing personnel emails @fortune100.com. With the concept of attack surfaces, I realize a) these people probably have laptops, and b) probably have non-work email accounts that utilize inferior virus protection, at which point I go a little deeper and use a site like LinkedIn to correlate corporate emails with alternate emails. I now have a superior mechanism for spear phishing or supplying a trojan, and we both know how marketing _loves_ to click on attachments.

Of course, all this is moot depending on why the client engaged the red team. The vast majority of these engagements that I have been part of, the goal has not been just to break in. The goal has been to enumerate the methods of getting in. After all, replacing 1 pane of glass on a broken window is useless if you have 3 others that are broken too.

I'd argue that red team scenarios where you aren't enumerating all attack mechanisms fall under one of two flavors: a security manager is trying to convince his executive leadership that there needs to be a bigger investment, or one is trying to generate metrics on time-to-detection for the internal security program. The former normally doesn't happen because red team normally requires executive sign off as a get-out-of-jail-free card for the assessor, and because there's more ROI on just having a proper thorough assessment done.

So I disagree that a framework like OSSTMM constricts the creativity and effectiveness of the assessor. The goal remains to get in by any means necessary. The difference is you have a methodology to ensure that

a) you are providing a thorough assessment to the client,

b) you are able to repeatably perform the assessment,

c) you are able to generate accurate, meaningful data regarding the change in security posture, and

d) you aren't going to have egg on your face when they bring in a different assessor next year that finds things you missed.

OSSTMM only provides some broad categories of "how" as guidelines. Instead, it's value is in enumerating the surface, testing the surface, and documenting the results in a standardized fashion.

u. fridman
u. fridman

Thanks. Please see the comments I left above.

u. fridman
u. fridman

Martino, thanks for the reply and some good examples.

I left all the details out on purpose for a reason. Sure, the people working on the field (both white- and black-hats) already know how to map networks and systems, they know how to bypass locks or weaponized a PDF. However, the "uninitiated" as you said, more often than not don't have the right knowledge start playing with this. If you run a simple vulnerability scan software unaware that some of those checks can cause serious problems, like a denial of service, then you are asking for trouble.

I can walk you through each aspect of a vulnerability exploitation, from finding it all the way to writing the actual exploit. Are you aware that those exploits can cause harm 80% of the time? Do you know enough ASM, C, python, whatever to be able to safely write that shell code needed to patch that memory space? Moreover, do you know how to react if you are in the middle of a physical pentest and you get discovered and find yourself in front of two very scared and underpaid security guards with weapons trained at you?

I rather leave this a bit vague and encourage the people trying to get into this field to seek places to learn. Whether by going as interns on a security company or by learning online and playing with their own systems. Beside, there is so much to learn, and each project / operation is so different that it would be very difficult to go deep into each subject.

my 2 cents.

Brandon Franklin
Brandon Franklin

While I appreciate the effort that went into writing this, I always have a bone to pick with these "in between" articles about security. They generally have the following things in common:

- Hand waving about technical details,

- Not enough implementation information to be useful in a realistic production environment, and

- Not enough application information to be useful to a novice home user.

Ultimately, you end up with something more suited for a journalistic piece that covers the secret world of hackers that tries to straddle the line between useful and overwhelming, and somehow manages to be neither.

Given the nature of this site, this article would have been a great vehicle to discuss attack surfaces and identifying trust boundaries. While they don't have the glitz of talking about sneaking into facilities, they're much more fundamental concepts that have a wider applicability to everyday decision making.

I also think it's a huge disservice to not discuss using a methodical approach to assessments, and at least introducing a few of the frameworks that ensure you're paying attention to the details.

But hey, props for getting me to pony up for membership to be a security curmudgeon!

Brandon Franklin
Brandon Franklin

While I appreciate the effort that went into writing this, I always have a bone to pick with these "in between" articles about security. They generally have the following things in common: - Hand waving about technical details, - Not enough implementation information to be useful in a realistic production environment, and - Not enough application information to be useful to a novice home user. Ultimately, you end up with something more suited for a journalistic piece that covers the secret world of hackers that tries to straddle the line between useful and overwhelming, and somehow manages to be neither. Given the nature of this site, this article would have been a great vehicle to discuss attack surfaces and identifying trust boundaries. While they don't have the glitz of talking about sneaking into facilities, they're much more fundamental concepts that have a wider applicability to everyday decision making. I also think it's a huge disservice to not discuss using a methodical approach to assessments, and at least introducing a few of the frameworks that ensure you're paying attention to the details. But hey, props for getting me to pony up for membership to be a security curmudgeon!

Alexander
Alexander

I'm only halfway through and this is great. Alot of things to think about here. I look forward to the next parts. I agree that I wish it was more specific in some areas. The only people being kept in the dark are the uninitiated, I would assume anyone actively using these techniques knows how or where to look for these things already.

Mike Petrucci
Mike Petrucci

Loved this writeup. This is such an interesting and foreign world to me and you share some great information. Stay safe out there and I'm looking forward to Part 2!

martino
martino

A computer or computer program is only as 'smart' as the person(s) who wrote it. I'm not really surprised or amazed at what can be found to be honest - you said it yourself: humans are the weakest link indeed, so why are we continually surprised and amazed at the mistakes we make? ;o)

Great job on this article though, I applaud your efforts to summarise this exciting area of the IT Security industry/community/whatever-you-call-it which collides with the real-world physical security aspects.

Other digital recon avenues worth mentioning are checking the Edgar database if it's a publicly traded US company (and chances are if it's a fortune 100 company it will be eh?) as well as Job sites (monster.com, hotjobs.com) which give away technical information about systems and people most times and good old Google maps (for physical recon), Google phone book, and war dialing in addition to the war driving which you touched on, to detect exposed modems and voice systems.

Full disclosure (and openly discussing attack tools and techniques) benefits us white-hats to a greater degree than it does the black-hatted attackers. Fearing that attackers will learn and use your imparted experience/knowledge isn't a very good or likely fear I think (not that you need one - you can do what you want, but I don't agree is all I am saying). They will either know it already and be using it against those who are missing out on knowing about it because of the secrecy you're practicing, or they will figure it out on their own anyway). A quick google search for instruction will turn up lots of hits but the uninitiated will likely end up being compromised while trying to learn better how to defend against compromise (LOL).

Case in point: locks and handcuffs. So many people are fooled by the perception of the security of locks - on their house, their suitcases, handcuffs, etc. They don't realize how simple they are to bypass and/or defeat and in many cases could have possibly escaped wrongful confinement or prevented/detected an unauthorized attempt/access had they known.

Why? Secrecy. Many other factors too, but secrecy is a common element that benefits attackers more than it does defenders.

This very site promotes and condones disclosing said practices and techniques for the point of defending against their use wrongful use.

True, that information can be used against legitimate situations as you mentioned, but chances are it's more likely to benefit the defender than it is the attacker in most situations (not all, but I'd rather take my chances *WITH* the knowledge than *NOT* with the knowledge of how to defend against most implementations of an attack; wouldn't you?).

Anyway - I look forward to your next segments :)

martino
martino

A computer or computer program is only as 'smart' as the person(s) who wrote it. I'm not really surprised or amazed at what can be found to be honest - you said it yourself: humans are the weakest link indeed, so why are we continually surprised and amazed at the mistakes we make? ;o) Great job on this article though, I applaud your efforts to summarise this exciting area of the IT Security industry/community/whatever-you-call-it which collides with the real-world physical security aspects. Other digital recon avenues worth mentioning are checking the Edgar database if it's a publicly traded US company (and chances are if it's a fortune 100 company it will be eh?) as well as Job sites (monster.com, hotjobs.com) which give away technical information about systems and people most times and good old Google maps (for physical recon), Google phone book, and war dialing in addition to the war driving which you touched on, to detect exposed modems and voice systems. Full disclosure (and openly discussing attack tools and techniques) benefits us white-hats to a greater degree than it does the black-hatted attackers. Fearing that attackers will learn and use your imparted experience/knowledge isn't a very good or likely fear I think (not that you need one - you can do what you want, but I don't agree is all I am saying). They will either know it already and be using it against those who are missing out on knowing about it because of the secrecy you're practicing, or they will figure it out on their own anyway). A quick google search for instruction will turn up lots of hits but the uninitiated will likely end up being compromised while trying to learn better how to defend against compromise (LOL). Case in point: locks and handcuffs. So many people are fooled by the perception of the security of locks - on their house, their suitcases, handcuffs, etc. They don't realize how simple they are to bypass and/or defeat and in many cases could have possibly escaped wrongful confinement or prevented/detected an unauthorized attempt/access had they known. Why? Secrecy. Many other factors too, but secrecy is a common element that benefits attackers more than it does defenders. This very site promotes and condones disclosing said practices and techniques for the point of defending against their use wrongful use. True, that information can be used against legitimate situations as you mentioned, but chances are it's more likely to benefit the defender than it is the attacker in most situations (not all, but I'd rather take my chances *WITH* the knowledge than *NOT* with the knowledge of how to defend against most implementations of an attack; wouldn't you?). Anyway - I look forward to your next segments :)

u. fridman
u. fridman

Thanks for the tips. Yes, I was going to talk about the duplication of ID cards, especially those that are RFID based.

martino
martino

I see your point, and I think what you are really trying to get across is that those details aren't dangerous to share per se, but they are really just out of scope for this article? I agree, it'd be a rather LARGE post as you suggest to cover the multitude of different types of apps and utilities alone (The SANS Institute devotes 5 days on the incident handling course alone and that just touches the surface!).

I don't think an example for some of the various standard motions would've hurt though. Anyone can download junk off the web and think it's ok till they realize they are pwned...A pointer from a reputable source (i.e. You! :o) would actually reduce the risk of a newbie shooting themselves in the foot with malware vs. misuse of a vulnerability scanner like Nessus (a firm disclosure at the start of the article advising the risk of using referenced software could be dangerous and cause massive issues - buyer beware? Use at your own risk and GET PERMISSION IN WRITING if you even think of doing something on a network/system that doesn't belong solely to you? Etc.).

LOL@ scared security guard situation - I've often wondered how a red-team would handle that without getting clobbered, shot, or detained for hours till someone could vouche for you.

"No really, I'm a pen-tester!!!!" LOL Wonder how often they hear that from the bad guys eh?

martino
martino

Yes, precisely what I was trying to get across (but failed miserably and side-tracked into other areas LOL).

u. fridman
u. fridman

Brandon, thank you for your message.

Like I said above, giving to much information about a subject like this is like giving you enough rope to hang yourself.

the point of this article was to introduce mindset and some of the basic ideas that we used on a security assessment.

Sure, I can talk endlessly about frameworks, what? Metasploit? Sure, go online and you have thousands of good articles, examples and books about this great tool. Will this knowledge make you a better security guy? maybe. In my opinion this is just a tool, learning how to use it it's up to you.

The same applies to picking a lock, ITS Tactical has you covered on that one, no point for me to explain this, it is irrelevant to what I am trying to convey.

I presented some of the ways I go about trying to find OSINT about my target. Are these all? Heck no, but if I were to mention every technique I've ever used to find information about a target I would have ti write a 100000 pages book. Again, the point of the article was to show the methodology behind the assessments, the what we do and when appropriate the how to do it (as you will see in Part 2 and 3).

I hope I managed to explain myself better, if not please accept my apologies.

u. fridman
u. fridman

Brandon, thank you for your message. Like I said above, giving to much information about a subject like this is like giving you enough rope to hang yourself. the point of this article was to introduce mindset and some of the basic ideas that we used on a security assessment. Sure, I can talk endlessly about frameworks, what? Metasploit? Sure, go online and you have thousands of good articles, examples and books about this great tool. Will this knowledge make you a better security guy? maybe. In my opinion this is just a tool, learning how to use it it's up to you. The same applies to picking a lock, ITS Tactical has you covered on that one, no point for me to explain this, it is irrelevant to what I am trying to convey. I presented some of the ways I go about trying to find OSINT about my target. Are these all? Heck no, but if I were to mention every technique I've ever used to find information about a target I would have ti write a 100000 pages book. Again, the point of the article was to show the methodology behind the assessments, the what we do and when appropriate the how to do it (as you will see in Part 2 and 3). I hope I managed to explain myself better, if not please accept my apologies.

u. fridman
u. fridman

Martino, thanks for the reply and some good examples. I left all the details out on purpose for a reason. Sure, the people working on the field (both white- and black-hats) already know how to map networks and systems, they know how to bypass locks or weaponized a PDF. However, the "uninitiated" as you said, more often than not don't have the right knowledge start playing with this. If you run a simple vulnerability scan software unaware that some of those checks can cause serious problems, like a denial of service, then you are asking for trouble. I can walk you through each aspect of a vulnerability exploitation, from finding it all the way to writing the actual exploit. Are you aware that those exploits can cause harm 80% of the time? Do you know enough ASM, C, python, whatever to be able to safely write that shell code needed to patch that memory space? Moreover, do you know how to react if you are in the middle of a physical pentest and you get discovered and find yourself in front of two very scared and underpaid security guards with weapons trained at you? I rather leave this a bit vague and encourage the people trying to get into this field to seek places to learn. Whether by going as interns on a security company or by learning online and playing with their own systems. Beside, there is so much to learn, and each project / operation is so different that it would be very difficult to go deep into each subject. my 2 cents.

Brandon Franklin
Brandon Franklin

Oh, I certainly agree that too much technical detail is a bad idea. But again, as mentioned, concepts like trust boundaries and attack surfaces are general methods of thinking about the exercise that can be pulled to everyday life. I think these topics are more germane to a security mindset than Google-hacking a target.

When I referred to a discussion of frameworks, I was more thinking along the lines of pointing people at some "light" reading of, e.g., the OSSTMM manual. I'm a firm believer that the security mindset is built on constantly checking one's assumptions and paying attention to details. Assessment frameworks provide the mechanism to ensure that the assessor is thoroughly examining a target, rather than naturally biasing towards the attack vectors that he or she is most comfortable with.

I entirely agree with you that the important thing in an article like this is to introduce the mindset. I just feel like the mindset was given short shrift compared to the much sexier components of an assessment.

Thanks for your response!

Brandon Franklin
Brandon Franklin

Oh, I certainly agree that too much technical detail is a bad idea. But again, as mentioned, concepts like trust boundaries and attack surfaces are general methods of thinking about the exercise that can be pulled to everyday life. I think these topics are more germane to a security mindset than Google-hacking a target. When I referred to a discussion of frameworks, I was more thinking along the lines of pointing people at some "light" reading of, e.g., the OSSTMM manual. I'm a firm believer that the security mindset is built on constantly checking one's assumptions and paying attention to details. Assessment frameworks provide the mechanism to ensure that the assessor is thoroughly examining a target, rather than naturally biasing towards the attack vectors that he or she is most comfortable with. I entirely agree with you that the important thing in an article like this is to introduce the mindset. I just feel like the mindset was given short shrift compared to the much sexier components of an assessment. Thanks for your response!

martino
martino

I see your point, and I think what you are really trying to get across is that those details aren't dangerous to share per se, but they are really just out of scope for this article? I agree, it'd be a rather LARGE post as you suggest to cover the multitude of different types of apps and utilities alone (The SANS Institute devotes 5 days on the incident handling course alone and that just touches the surface!). I don't think an example for some of the various standard motions would've hurt though. Anyone can download junk off the web and think it's ok till they realize they are pwned...A pointer from a reputable source (i.e. You! :o) would actually reduce the risk of a newbie shooting themselves in the foot with malware vs. misuse of a vulnerability scanner like Nessus (a firm disclosure at the start of the article advising the risk of using referenced software could be dangerous and cause massive issues - buyer beware? Use at your own risk and GET PERMISSION IN WRITING if you even think of doing something on a network/system that doesn't belong solely to you? Etc.). LOL@ scared security guard situation - I've often wondered how a red-team would handle that without getting clobbered, shot, or detained for hours till someone could vouche for you. "No really, I'm a pen-tester!!!!" LOL Wonder how often they hear that from the bad guys eh?

u. fridman
u. fridman

I agree with you. Don't forget this is a 3 part article. The 2nd part is the planning and dry run. Here's where we analyze what we've discovered and start using our "think out of the box" to find the wholes. Here's where the mindset really comes into play.

Attack surfaces cannot, in my humble opinion, be listed without a proper understanding of the target, and to do this you need good intel. Trust boundaries on this kind of security assessments are a bit difficult to qualify. There are some you can play with, but we are not analyzing a product, but a sum of all the possible products used on a system or building. True, these also have their own trust boundaries and they can be defined on a threat assessment, but unless you are doing just that (a treat assessment) and not a full on penetration exercise, then they server no real purpose here.

Now, for the OSSTMM. Those guys have a lot of great information and you can learn a lot from just reading their documents. Still, they are trying to frame a very dynamic activity into a structure that doesn't work for all cases. Again, it's a good source of info if you are doing a defensive analysis, but this is pure offense. We are thinking like an attacker, hence I can do whatever I damn please, whether it fit the well defined infosec "rules" or not.

Thanks again for the good criticism.

Brandon Franklin
Brandon Franklin

It looks like there's a depth limit on the comment threads so I'm going to have to reply to your latest comment here. I agree that you need to collect intelligence to identify attack surfaces, but I think the concept of attack surface is critical to ensuring you thoroughly collect intelligence. For example, without the concept of attack surfaces, I'm compiling a list of marketing personnel emails @fortune100.com. With the concept of attack surfaces, I realize a) these people probably have laptops, and b) probably have non-work email accounts that utilize inferior virus protection, at which point I go a little deeper and use a site like LinkedIn to correlate corporate emails with alternate emails. I now have a superior mechanism for spear phishing or supplying a trojan, and we both know how marketing _loves_ to click on attachments. Of course, all this is moot depending on why the client engaged the red team. The vast majority of these engagements that I have been part of, the goal has not been just to break in. The goal has been to enumerate the methods of getting in. After all, replacing 1 pane of glass on a broken window is useless if you have 3 others that are broken too. I'd argue that red team scenarios where you aren't enumerating all attack mechanisms fall under one of two flavors: a security manager is trying to convince his executive leadership that there needs to be a bigger investment, or one is trying to generate metrics on time-to-detection for the internal security program. The former normally doesn't happen because red team normally requires executive sign off as a get-out-of-jail-free card for the assessor, and because there's more ROI on just having a proper thorough assessment done. So I disagree that a framework like OSSTMM constricts the creativity and effectiveness of the assessor. The goal remains to get in by any means necessary. The difference is you have a methodology to ensure that a) you are providing a thorough assessment to the client, b) you are able to repeatably perform the assessment, c) you are able to generate accurate, meaningful data regarding the change in security posture, and d) you aren't going to have egg on your face when they bring in a different assessor next year that finds things you missed. OSSTMM only provides some broad categories of "how" as guidelines. Instead, it's value is in enumerating the surface, testing the surface, and documenting the results in a standardized fashion.

u. fridman
u. fridman

I agree with you. Don't forget this is a 3 part article. The 2nd part is the planning and dry run. Here's where we analyze what we've discovered and start using our "think out of the box" to find the wholes. Here's where the mindset really comes into play. Attack surfaces cannot, in my humble opinion, be listed without a proper understanding of the target, and to do this you need good intel. Trust boundaries on this kind of security assessments are a bit difficult to qualify. There are some you can play with, but we are not analyzing a product, but a sum of all the possible products used on a system or building. True, these also have their own trust boundaries and they can be defined on a threat assessment, but unless you are doing just that (a treat assessment) and not a full on penetration exercise, then they server no real purpose here. Now, for the OSSTMM. Those guys have a lot of great information and you can learn a lot from just reading their documents. Still, they are trying to frame a very dynamic activity into a structure that doesn't work for all cases. Again, it's a good source of info if you are doing a defensive analysis, but this is pure offense. We are thinking like an attacker, hence I can do whatever I damn please, whether it fit the well defined infosec "rules" or not. Thanks again for the good criticism.

The Latest
Squawk Box

Whether your GPS has run out of power or you’re in a survival or E&E situation, the ability to navigate using a map and compass is one of the most valuable skills you can have and something that everyone should take the time to learn to do. Get started or brush up on your land nav skills by checking out our past articles on itstactical.com.

8 hours ago
Leave a Comment