Hello again!

I promised that I would continue this series of 101-level posts on penetration testing/red-teaming so… here I am. And we’re as done as a half-eaten sandwich. If you want to brush up, the first blog post in this series can be found here.

Today’s lesson will be on the general phases of a penetration test, as well as covering the Pre-Engagement and Reconnaissance (aka “recon”) phases. Some people and organizations will call different parts of a pentest engagement by different names, and/or lump different phases together. Here’s my interpretation:

Pre-Engagment [edited 8/19, per conversation with my betters]

• Reconnaissance
• Initial Access
• Persistence
• Lateral Movement/Privilege Escalation
• Achieving Goals
• Post Engagement Write-up and Reporting

Lets compare the phases I have laid out to another interpretation. Like, say, the Penetration Testing Execution Standard (PTES). They have their own belief on what the phases look like:

• Pre-Engagement Interactions
• Intelligence Gathering
• Threat Modeling
• Vulnerability Analysis
• Exploitation
• Post Exploitation
• Reporting

With regards to intelligence gathering, threat modeling, and vulnerability analysis, I feel like good pentesters do all of that as a part of the recon phase. The sole reason you’re gathering information is figure out how you’re going to breach their defenses and/or determine if there are other findings that, while they may not be exploitable, may be worth noting in your report since they represent some sort of a risk. Which is why recon is the most important phase of any pentest, and this will NOT be the last time I say this. The only reason I could see to have these broken out into separate steps, would be to break recon into more manageable portions to iterate just HOW IMPORTANT RECON IS »foot stomp«.

On the other hand, I take the exploitation/post exploitation phases and break it into initial access, persistence, lateral movement, and achieving goals. I feel its important to separate these steps out as they are all important portions of the exploitation/post-exploitation phase of a penetration test that all kinda get lumped together. I guess I’m a bit of a contradictory like that.

Phase 0: Pre-Engagement [Edited 8/19]

So originally, I had a blurb in here in how I kind of consider it crap that pre-engagement things are included as pentester responsibilities in the PTES. “In any normal scenario, this should be handled primarily by a sales rep/sales engineer, and/or a project manager to handle the hairy logistics and things that need to be negotiated before a penetration test.”

What are said, hairy things? little details like… agreeing on services to perform, rules of engagement, billing, scope, ip ranges, third party equipment/vendor (e.g. MSSPs) equipment that may or may not be in scope, ensuring that authorization forms of SOME sort are signed by an authoritative entity in the client organization (e.g. the “Get out of jail free card”), and finally organizing everything into a conherent contract that is the rational, reasonable solution that makes sense to the pentester as well as serves the clients needs (among other things).

On paper, this is what /should/ be done, but in reality… salespeople exist to make sales. While technically, I still think that pre-engagement should NOT be an activity that the penetration tester has any sort of primary responsibility over (in a perfect world), the fact of the matter is… if you aren’t present, the salespeople will do whatever they can and whatever the customer wants (including increasing the scope to a massive degree and/or sell things that cannot be delivered or make NO SENSE whatsoever) in order to make that sale, get that engagement, and get another client in the books. THEN, it will be YOUR job, as the pentester to deliver. It is in your own best interest to be present during these meetings to make sure you can answer the client’s questions (shows good customer support, especially if you practice good soft skills – which you need for social engineering anyway… more on that later), and ensure that salespeople or clients aren’t pulling anything stupid during contract negotiations.

I mean, it makes sense and I can’t believe I was actually against including it initially. I worked at a company that sold network security appliances that operated like this. Sales would promise them the world to get them to buy the security appliance, then deliver grains of sand. When the customers were dazed, confused, had no idea how to manage the systems and/or configure them.. Sales would point them towards technical support and we would be stuck fielding deployment issues for a customer who has no idea what they were doing, only that they were promised it performs X function(s)

The bottom line here is to be present for these meetings and ensure that terms make sense to both the client you are servicing, as well as you, the pentester who are going to be performing the work detailed in the contract. If you happen to be an independent pentester, then god help you, because you get to write up the statement of work for the engagement, ensure that it makes sense, ensure that the scope isn’t creeping out of control (that is, the client doesn’t keep piling things in), that billing is rational, and that the work actually gets performed. Keep an eye on the statement of work.

** (special thanks to @viss and @redteamwrangler) **

Phase 1: Reconnaissance

If you don’t have good recon, you just end up throwing attacks at something hoping to slip between the cracks.

Recon is important. Recon is important. Recon is important. I like turtles. Oh, and RECON IS IMPORTANT. Good recon can make or break an engagement. Your goal in recon is to recover as much information about the organization, its employees, business processes, technologies deployed, and/or security controls in place (physical and/or technical — depending on scope) as possible. Afterwards, you are responsible for analyzing this information and making inferences based on it in order to identify potential weaknesses that can be exploited in order for you to gain initial access. Additionally, as mentioned above, you have the responsibility of noting other potential issues as well. These issues might not net you a shell, or get you access to a juicy information dump but may possible represent some sort of risk that the client needs to be aware of. Food for thought.

For instance, if breaching physical security is considered in scope for the engagement, then sizing up the building, performing surveillance, RF spectrum analysis, wireless site survey, inspection of physical security controls, among other activities may be things you consider doing depending on time you have available. This may, for instance, lead to you identifying a rogue access point with no encryption or poor encryption capabilities (e.g. WEP) that could be abused to gain initial access to the client’s network. Or perhaps discovering that tailgating (the practice of allowing unauthorized individuals into secure spaces who are not authorized to be there) may be a common practice, allowing you to walk right into the building, set up to a conference room or wiring closet, and literally plug into the client’s network directly. You’d think such occurrences are infeasible, but… I’ve seen and heard of them happening.

Generally speaking, recon falls into two categories: active and passive recon. Passive recon involves making use of information about your target made publicly available from a variety of different resources. If you know intelligence community and/or natsec (national security) nerds, you might know passive recon by its other name: OSINT (Open-Source Intelligence). Essentially, any information that you can derive from freely available sources that does not involve you directly asking the questions yourself, or probing your client’s network infrastructure directly is considered passive recon/OSINT. Think of it as a giant game of “IM NOT TOUCHING YOOUUUUU”.

What are some examples of passive recon/OSINT resources? I did a talk related to this:

If videos aren’t your thing, the slide deck and a huge collection of web browser bookmarks to a ton of other resources can be found here (and as a backup, here). So for the most part, the resources I collected are mainly associated with blue-team or security operations and resources to help make their lives easier. However, there are choice data sources in there that penetration testers can use as well, such as shodan, censys, punkspider (Currently unavailable due to SSL issues), Hurricane Electric, ipintel, netcraft, and robtex.

Those are just for starters. You could use google street view to determine building layout, Wigle for gathering information about nearby wi-fi access points, various job posting boards to learning about technologies deployed in the company, social media (facebook, twitter, etc. — especially including linkedin) to find out more about the client’s employees and technologies, the SEC’s EDGAR database (if the company is publicly traded) to figure out who is at the director/board level (for social engineering, etc.), company websites and press releases surrounding new facilities, organization charts, new employees, new projects, preferred vendors, mergers and acquisitions and so. much. more. You can find mountains of information about different organizations, and most the time, you never have to send a single packet towards their infrastructure. That is the beauty of passive recon and OSINT: that data is out there and ripe for the taking.

If passive recon is looking at public information a client exposes to the world, then active recon is the opposite of that and actively looking for information about a client. Visiting their website(s) analyzing sitemaps, fingerprinting services, actively scanning network ranges owned by the client, visiting physical locations, interacting with employees in the building, or entering/leaving the building, asking probing questions about different aspects of business, calling various people or business units in the company in order to extract information about the client and so on and so forth. The idea here is that you are attempting to answer questions about the client, their employees, and their network that you cannot easily acquire answers to by finding direct (or in some cases, indirect) methods to ask them on your own.

Sometimes, you may choose to use tools and frameworks as a part of your recon investigations. There’s a variety of them out therealmost all of which I have never used, but for the sake of completion, and because I know most of you are clamoring for toys to play with, I linked to a few that I’m aware off the top of my head. Always be mindful, that as a penetration tester and a network security professional, the tools do not make you a good penetration tester. It is your skill, your curiosity, and your capability to ask questions and draw conclusions that will win you the day and separates you from script kiddies. The recon phase requires you to be a good detective and draw as many conclusions as you can in a limited amount of time. The tools are just icing on the cake.

That’s all I’m gonna cover for now. The next chapter will be Initial Access. Until then, this has been an RS_101 lesson.

DA_667

About the Author

Tony Robinson (@da_667) is a network security engineer. He is currently wrangled by hurricane labs. He had an affinity for network security monitoring, malware analysis, and threat intelligence. When not saving the internet, he can be found playing video games and savoring dank memes.