Hacking like APT

Lately, I’ve seen several announcements, presentations, and blog posts about “hacking like” Advanced Persistent Threat. This new wave of material focuses on mapping features in the Metasploit Framework to the steps shown in Mandiant’s 2010 M-Trends Report: The Advanced Persistent Threat. While this is an interesting thought exercise, there are a few classic treatments of the adversary emulation topic that deserve your attention.

Here are my favorite presentations.

Information Operations (2008)

This video discusses “techniques to attack secure networks and successfully conduct long term penetrations into them. New Immunity technologies for large scale client-side attacks, application based backdoors will be demonstrated as will a methodology for high-value target attack. Design decisions for specialized trojans, attack techniques, and temporary access tools will be discussed and evaluated.”

MetaPhish (2009)

MetaPhish describes how to attack a network like a real adversary. This presentation covers the information gathering phase (targeting), it lays out the needs for a spear phishing and web drive-by framework, and it discusses covert communication using Tor. You should read the MetaPhish white paper as well.

Modern Network Attack (2011)

In 2011, I spoke at the TSA ISSO meeting about how I view the penetration testing process. This talk is a breakdown of how I saw threat emulation. You’ll see hints of MetaPhish and Tactical Exploitation in here.

I wouldn’t call this my favorite presentation–it’s mine after all. But this is one of the first talks I gave when I was starting to participate in the open source security community. Adversary emulation is a topic near and dear to my heart. So much so, I built a product for it.

Adaptive Penetration Testing (2011)

This talk calls on the community to revisit the reasons we penetration test: We’re trying to simulate an adversary and go after something meaningful to the organization we’re testing. Included in this talk are a lot of stories, an argument for why social engineering should be in scope, and a lot of tactical things.

Tactical Exploitation (2007)

This is a classic talk by HD Moore and Val Smith on how to attack a network by leveraging functionality, not exploits. This talk is very reconnaissance heavy (go figure, so is threat emulation). I highly recommend reading the Tactical Exploitation white paper too.

Common Themes

If you’re interested in providing adversary emulation in your pen tests, it helps to mimic their tactics, their tools, and attack similar goals. How do you do this? Here are the common themes from these sources:

Offense in Depth

I regularly receive emails along the lines of “I tried these actions and nothing worked. What am I doing wrong?”

Hacking tools are not magical keys into any network you desire. They’re tools to aid you through a process, a process that requires coping with many unknowns.

If you’re interested in penetration testing as a profession, you’ll need to learn to think on your feet, get good at guessing what’s in your way, design experiments to test your guess, and come up with creative ways around the defense hurdles before you.

For the sake of discussion, we will focus on the process of getting a foothold. To get a foothold, we will assume the usual steps: craft a convincing message, embed some malware, and send it off to the user. Pretty easy, right?

Let’s walk through this process. The green bubbles represent milestones in an attack. As an attacker, I need to get to each of these milestones and evade defenses that are in place to stop or detect me. If I fail to achieve any of these milestones, my attack is a failure.


Goal: Message Delivered

Let’s begin our attack. At this point, I’ve researched targets. I’ve used Google, I’ve browsed LinkedIn, and I’ve created a list of targets. Go me! I’ve also spent time coming up with a convincing pretext and designed a message that will entice the user to open it. Now, I just need to send the message and get it to the user. Easy!

What can go wrong?

Email has evolved since 1997. It’s still trivial to spoof a message, but a number of mechanisms are deployed to make spoofing messages harder. Sender Policy Framework is one of them. Sender Policy Framework is a standard that uses DNS records to specify which IP addresses are authorized to send email for a domain. Some mail servers do not verify SPF records.

When you’re crafting that clever spear phishing email, you have to pay attention to which address you’re spoofing. If you’re really paranoid, register a typo of a domain, setup the proper SPF and DKIM records, and send phishes through your server.

Beware, this problem will get harder. Standards such as DMARC are pushing consistent deployment and use of the SPF and DKIM standards to make sure messages are from a system authorized to relay messages for that domain.

Let’s say your message doesn’t get squashed as spam. Next, it’s highly likely a gateway anti-virus device will look at your message. If the contents of your message is flagged by this device, game over.

To get a handle on these defenses, I recommend that you craft a message to a non-existent user at your target’s site and send it. The non-delivery notice that comes back may contain clues about which devices touched your message and how they interpreted it. I’ve used this technique to learn about the anti-virus and anti-spam mechanism I had to defeat.

Goal: Code Execution

Ok great, you can get a message to a user. Next, you need a package that will execute code on the user’s system. This package may exploit the user when they view content or it may require the user to allow some action.  If the user doesn’t open your file or follow through on an action you need them to take–all your hard work went for nothing.

If you send an exploit and the user isn’t running vulnerable software, your attack will fail. I wrote a System Profiler to collect system information from anyone who visits a website I setup. If you’re planning to execute a targeted phishing attack, you will want something like this in your arsenal. Visit browserspy.dk to learn what’s possible in a system profiling tool.

What can go wrong?

Assuming your attack is plausible and the user follows through, you have another problem: anti-virus. If anti-virus flags you, game over.

Evading anti-virus is part of the penetration tester’s tradecraft. If it’s a client-side exploit, you may need to modify it until it passes checks. If your attack is a dressed up executable, you have a lot of options to obfuscate it. This process is greatly helped by knowing the anti-virus product you’re up against.

Discovering the anti-virus product that’s in use is harder. You may find hints about the preferred product during your information gathering phase. Job postings and resumes are a goldmine. I once had success feeding a list of common anti-virus update servers to a DNS server susceptible to cache snooping.

Goal: Positive Control

You’d think that after a user gets the message, opens your file, and possibly performs some other action–you’re done. This is not true. Even after your code is executing on the target’s system, your attack is still vulnerable.

Many exploits corrupt memory to take control of a process. The amount of code an exploit may execute is usually very small. This constraint drives a design decision that ripples through the Metasploit Framework. Namely, payloads, the code that executes when an attack is successful, are split into two pieces.

The first piece, known as the stager, is small and limited. It connects to you, the attacker, and downloads the second part of the payload, the stage. In the Metasploit Framework, the stage is a reflective DLL. Once the stage is downloaded, the stager passes control to it and the stage executes. Saying “the payload is staged” means this process was successful.


What can go wrong?

You are vulnerable here. Functionally, there aren’t many stagers in the Metasploit Framework. You may stage a payload using a TCP connection or use a stager that takes advantage of WinInet to download the stage from a URL.

If firewall egress rules prevent your stager from connecting to you, then your payload will not stage. You will not get control of the system. You will have wasted all of that effort.

Once a payload is staged, you’re in good shape. The Metasploit Framework encrypts meterpreter traffic. If you’re using Beacon, you have a low and slow agent that’s periodically asking you for tasks.


Wireshark Capture of Meterpreter Staging

Beware though. The stager does not encrypt traffic! This means when your attack lands, a network admin has the opportunity to see an unobfuscated DLL coming over the network. Most Intrusion Detection Systems ship with rules to detect executables traversing the network.

The only stager that encrypts the stage is reverse_https. Keep this in mind when planning your attack.

Know Your Tools

This blog post is not a comprehensive list of defenses that will stop an attack. Rather, it is my hope to get you thinking about the attack process and the hurdles that you must get past. When you know your tools and how they work, you can use this information to plan your attack and actively think about the clues a defender may use to spot you. Likewise, as an attacker, you have to use clues to understand the defender’s game and know the attack surface.

If you’re a network defender who understands the attack tools and how they work, you can take advantage of this working knowledge to detect attack indicators or develop defenses to stop the less malleable pieces of the attacker’s toolkit.

Red Team Post Exploitation Videos

Each year, I play on a volunteer red team at several cyber defense exercise/competition events. Here’s a small collection of videos from this year and last year demonstrating the fun we have as a red team. One of the things that differentiates these events from a penetration test–we can do whatever we want (within reason).

Enjoy a little red team fun.

ISTS 2012: Team 12 TV

These videos are from the RIT Information Security Talent Search event. Here, we have access to a student’s system. We’re projecting his desktop onto the projector. At the same time, we’re logging his keystrokes and using proxychains to connect to his mail server via a pivot into his local system. We use his mail server to send friendly messages to him, some of which contain his password.

In case the screen is hard to read in the cell phone video, here’s the screen recording of these events:

PRCCDC 2012: A little VNC + key logging fun

This video is from the Pacific Rim CCDC regional event. It’s just a little harmless fun with VNC and a keystroke logger.

NECCDC 2011: Red Team Update

This video is the 2011 Red Team Update from NECCDC. This is a compilation of screenshots and other great moments from the 2011 event.