Archive for the ‘Red Team’ Category


Advanced Threat Tactics – Course and Notes

September 30, 2015

The release of Cobalt Strike 3.0 also saw the release of Advanced Threat Tactics, a nine-part course on red team operations and adversary simulations. This course is nearly six hours of material with an emphasis on process, concepts, and tradecraft.

If you’d like to jump into the course, it’s on YouTube:

Here are a few notes to explore each topic in the course with more depth.

0. Introduction

This is a course on red team operations and adversary simulations.

To learn more about Adversary Simulations and Red Team Operations:

Advanced Threat Actors:

Tools used in this course:

1. Operations

Advanced Threat Tactics starts with a high-level overview of Cobalt Strike’s model for distributed operations and red team collaboration.

To learn more about Cobalt Strike’s model for collaboration and operations:

  • Watch Force Multipliers for Red Team Operations. This is my favorite talk I’ve given. Here, I summarize my work and insights on the red team collaboration problem. Today, I consider this a completed research project with the following blog posts capturing lessons learned on how to build infrastructure and organize a large red team to support operations (primarily in an exercise context).
  • Read A Vision for Distributed Red Team Operations to learn more about Cobalt Strike’s model for distributed operations with multiple team servers.
  • Read The Access Management Team [Shell Sherpas]. This blog post discusses the Access Manager role in depth.
  • Read about The Post Exploitation Team. These are my notes on the folks who interact with targets to complete objectives and find interesting information.
  • Read Infrastructure for Red Team Operations. Infrastructure is the foundation of any engagement. This post is my best practices for organizing infrastructure to support a long-term op with multiple targets.

2. Infrastructure

Infrastructure is the collection of domains, servers, and software that support your operation. One of Cobalt Strike’s strengths is its variety of communication channels and the flexibility you have to configure them. This lecture goes through the HTTP/HTTPS, DNS, and named pipe channels and shows you how to use special features with each. I also take you through how to stand up redirectors and test your infrastructure before an engagement.

To learn more about payload staging:

Beacon Communication:

3. Targeted Attacks

This lecture goes through a process to execute a targeted spear phishing attack to get a foothold in a modern enterprise.

To learn more about this material:

User-Driven Attacks:

4. Post Exploitation

This lecture shows how to use Beacon for post-exploitation. If you have to operate with Beacon, this is good core material to know.

To learn more about this material:


  • Buy the Red Team Field Manual. This is a must-own for anyone working in this space. The tips and tricks here are quite applicable for all Beacon operators.

5. Privilege Escalation

Think of this lecture as post exploitation, part 2. We dive into how to elevate privileges and use these privileges to harvest credentials and password hashes.

To learn more about User Account Control and the Bypass UAC attack:

Privilege Escalation:

  • Read Windows Privilege Escalation Fundamentals. This tutorial has a number of command-line recipes to find files with credentials and other things you should look for when trying to elevate your rights.
  • Read What you know about ’bout GPP? This blog post offers a look at the Group Policy Preferences privilege escalation vector. This is one of those issues that, while patched, remains an issue because the patch does not cleanup the problems created by this feature when it was last used. I didn’t have time to cover this problem in the course [six hours is enough!]; but this is a staple thing you should always check for.



6. Lateral Movement

This lecture is the use and abuse of native Windows capability and behavior to trade-up privileges and move around a network.

To learn more about enumeration and reconnaissance in a Windows Active Directory network:

  • Watch Passing the Torch: Old School Red Teaming, New School Tactics? Here David McGuire and Will Schroeder go through their tricks to understand a Windows enterprise network the old school way (net view /DOMAIN and friends) vs. the new school way (with PowerShell).
  • Read PowerView: A Usage Guide to understand this wonderful tool from Will Schroeder to automate enumerating trusts, users, and hosts in an active directory environment.
  • Check out Netview by Rob Fuller. This tool enumerates systems using the Win32 Network Management API. I believe it was one of the original inspirations for PowerView and it certainly inspired Beacon’s net module as well.
  • Read Trusts You Might Have Missed by Will Schroeder for a quick primer on domain trusts in Windows Active Directory networks. You’ll really want to go through all of Will’s blog to understand this topic fully. He posts a lot about domain trusts and user hunting. Too much for me to keep up with here.
  • Also, read I Hunt Sys Admins by Will Schroeder (him, again!) to learn different ways to find where a particular user lives on the network. This is important for targeting systems that may have trust material that gets you closer to the data you want or to DA rights on the network.

Remote Management without Malware:



Remote Code Execution:

7. Pivoting

SOCKS, SOCKS, SOCKS! This lecture is about how to pivot with Beacon. You could also think about it as using and abusing SOCKS forwards, backwards, and any other way you want it.

More on this topic:

8. Malleable C2

Malleable C2 is Cobalt Strike’s domain specific language to change indicators in the Beacon payload. This ability to make Beacon look like other malware is arguably what makes it a threat emulation tool.

More on this topic:

9. Evasion

The Advanced Threat Tactics course concludes with a deep dive into evasion. This video is my to-the-minute notes on this topic.

To learn more about phishing and e-mail delivery:

Anti-virus evasion:

Application Whitelisting:

Egress Restrictions:

  • Read An Unnecessary Addiction to DNS Communication. I often hear from folks who insist that DNS is the only way out of their network and the only way to reach servers that are otherwise isolated from the network. This post goes into depth on the evasion options with Cobalt Strike’s DNS communication scheme and it digs into the capability available in Cobalt Strike’s other Beacon variants.
  • Read HTTP Proxy Authentication for Malware to understand how Beacon’s HTTP/S stagers react to proxy authentication failures.

Active Defenders:

  • Watch Operating in the Shadows given by Carlos Perez at DerbyCon 2015. In this talk, Carlos goes over the different advancements in blue’s ability to instrument Windows and the impact it will have on red teams and penetration testers who need to challenge them. This is a sign of things to come.
  • Read Advances in Scripting Security and Protection in Windows 10 and PowerShell V5. Windows 10 will change the security game in a big way. This post from Microsoft goes through the new logging hooks to understand PowerShell activity on a system and the hooks that allow anti-virus engines to look for malicious PowerShell.
  • Take a look at Microsoft’s Advanced Threat Analytics technology. This defense tracks which systems/users pull which active directory objects, when, and how often. It’s designed to catch that awesome stuff discussed in part 6 of this course.
  • Also, check out UpRoot, an agentless host-based IDS written in PowerShell that leverages WMI subscriptions. UpRoot reports process creates, new network connections, and other host activity. Tools like UpRoot show the scrutiny red operators will need to learn to cope with when working with a mature hunt team.

WinRM is my Remote Access Tool

July 22, 2015

One of my favorite blog posts last year was Adversary Tricks and Treats from CrowdStrike. In this post, CrowdStrike details the tradecraft of an actor they dub Deep Panda. In an attempt to skirt advanced malware hunting capability, Deep Panda leverages native tools to control target systems and spread laterally in a network. With the exception of their foothold, they don’t use malware to complete their objectives.

This is an important idea. One of my favorite red team tasks is to provide a credible adversary to exercise new ideas for network defense. There’s a positive shift away from the passive blinky boxes to the inquisitive analyst who has tools to ask questions at scale. As red operators, we have a neat opportunity to nurture and grow these analysts into formidable defenders.

All that future talk aside, it’s important to think about how to do this. One way I do it is by looking at different ways to operate. I think it’s important to have multiple concepts of offense and ways to simulate an on-going offensive operation. One of my favorite ways now is to play like Deep Panda and limit my use of malware as much as possible.

I’m keenly aware that skilled network defenders watch some assets more than they watch others. A domain controller is no-man’s land. A skilled team armed with techniques that don’t scale will watch their domain controller’s like hawks when they know a red team is exercising them. Workstations are… less important.

I like to live on the workstations with my malware and use native tools to interrogate and control servers as much as possible.

There are a lot of ways to abuse a trust relationship to run commands on a remote system. at, schtasks, sc, and wmic are among my favorites. I’m a WinRM fan too.

WinRM is the Windows Remote Management service. It listens on port 5985. It’s off by default, but some system administrators turn it on to enable easy remote management of their servers [hence the name, right?]

When WinRM is on, you can use PowerShell to remotely interrogate a server and control it. Or, if you’re feeling lucky, you can turn WinRM on yourself. Here’s how to enable WinRM via Beacon:

powershell Enable-PSRemoting -Force

The output will look like this:


WinRM does require a trust relationship with the target system. You’ll need a token for a domain user that is a local administrator to the target. You can steal one of these, make one with runas, or use Mimikatz to create a token to pass a password hash.

To control a target via WinRM from Beacon, here’s the syntax:

powershell InvokeCommand -ComputerName TARGET -ScriptBlock { dir c:\ }

PowerShell will run, via WinRM, whatever you specify inside of the script block. After this command completes, PowerShell will return the output to you.

The ability to run commands on a remote target AND get output back is nice. In most cases, this is enough capability to operate and achieve an objective. One of my favorite things though is the ability to run Mimikatz this way. PowerSploit’s Invoke-Mimikatz cmdlet allows you to specify a -ComputerName argument. Fun fact: this argument can be array of systems to run Mimikatz on. With this option specified, PowerSploit will run mimikatz via WinRM, in memory on the remote target, and report the output back to you.

Here’s the syntax to do it:

powershell-import /local/path/to/PowerSploit/Exfiltration/Invoke-Mimikatz.ps1
powershell Invoke-Mimikatz -ComputerName TARGET

Here’s a video of these concepts in action:

Between Mimikatz and the ability to run arbitrary commands remotely, I have a lot of operating capability right there. If you want to emulate a long-term embedded actor who does things a little differently, this is certainly a good TTP to try out.


Models for Red Team Operations

July 9, 2015

Recently, I had an email from someone asking for a call to discuss different models of red team operations. This gentlemen sees his team as a service provider to his parent organization. He wants to make sure his organization sees his team as more than just dangerous folks with the latest tools doing stuff no one understands. This is a fair question.

In this post, I’ll do my best to share different models I see for red team operations. By operations, I mean emulating the activities of a long-term embedded adversary in a network, one that works from a remote location. This ability to gain, maintain, and take action on access over a (potentially) long period of time is a different task from analyzing an application to find flaws or quickly enumerating a large network to identify misconfigurations and unpatched software.

You may ask, what’s the point of emulating a (remote) long-term embedded adversary? Two words: Security Operations. I’m seeing a shift where organizations are leveraging their red assets to validate and improve their ability to detect and respond to intrusions.

With all of that said, let’s go through a few of the different models:

Full Scope Penetration Tests

A full scope penetration test is one where a hired or internal team attempts to gain a foothold into their customers environment, elevate their rights, and steal data or achieve some desired effect. These engagements mimic the targeted attack process an external actor executes to break into an organization. When a lot of my peers think about red team operations these assessments are immediately what comes to mind.

Full scope penetration tests provide a data point about the state of a security program, when all aspects are exercised in concert against an outside attacker. Unfortunately, full scope assessments are as much a test of the assessor as they are of the organization that commissioned these tests. They are also expensive and assessors have to cope with restrictions that are not placed onto a real adversary [less time, fewer resources, compliance with the law].

Given time, resources, and competent execution, a full scope engagement can offer valuable insight about how an external actor sees an organization’s posture. These insights can help identify defensive blind spots and other opportunities for improvement. These engagements are also useful to re-educate executives who bought into the hype that their organization is un-hackable. Making this point seems to be a common driver for these assessments.

Long-term Operations

I see several red teams building long-term operations into their services construct. The idea is that no organizational unit exists in isolation of the others. The organizational units that commission engagements from their internal assets are not necessarily the organizational units that are most in need of a look from a professional red team. To deal with these situations, some red teams are receiving cart blanche to gain, elevate, and maintain access to different organizational units over long period time. These accesses are sometimes used to seed or benefit future engagements against different organizational units.

Long-term Operations serve another purpose. They allow the red team to work towards the “perfect knowledge” that a long-term embedded adversary would have. This perfect knowledge would include a detailed network map, passwords for key accounts, and knowledge about which users perform which activities that are of value to a representative adversary.

It’s dangerous to require that each red team engagement start from nothing with no prior knowledge of a target’s environment. A long-term embedded adversary with a multi-year presence in a network will achieve something that approximates perfect knowledge.

For some organizations, I’m a fan of this approach and I see several potential benefits to it. The perfect knowledge piece is one benefit, but that is something an organization could white card if they wanted to. There’s another key benefit: our common understanding of long-term offensive operations is weak at best. Maintaining and acting on access over a long period of time requires more than a good persistence script and a few VPS nodes. The organizations that take time to invest in and get good at this approach will find themselves with interesting insights about what it takes to keep and maintain access to their networks. These insights should help the organization make investments into technologies and processes that will create real pain for a long-term embedded actor.

War Games

Several organizations stage red vs. blue war games to train and evaluate network defense staff. These exercises usually take place in a lab environment with multiple blue teams working to defend their representative networks against a professional opposing force. The role of this opposing force is to provide a credible adversary to train participants and keep pressure on them throughout the event.

Each of these events is different due to their different goals. Some events white card the access step completely. Some also white card the perfect knowledge of the long-term embedded adversary. It all depends on the event’s training objectives and how the organiser’s want to use their professional red team assets.

To an outsider, large scale Red vs. Blue events look like a chaotic mess. The outsider isn’t wrong. Red vs. Blue events are a chaotic mess. They’re chaotic because they’re fast paced. Some compress a multi-year attack scenario into an event that spans days or weeks.

There’s value to these events though. These events provide a safe opportunity to exercise processes and team roles in a fast-paced setting. They’re also an opportunity to field immature or new technologies to understand the benefit they can provide. Unlike more structured tests, these events also give blue participants opportunities to observe and adapt to a thinking adversary. Done right, these events encourage full disclosure between red and blue at the end so participants can walk away with an understanding of how their blue TTPs affected the professional adversary.

Threat Scenarios / Cyber Security Exercises / Attack Simulations

Another use for red assets is to help design and execute cyber security exercises to train and assess network defense teams. These exercises usually start with a plausible scenario, a representative or real actor, and a realistic timeline.

The red asset’s job is to generate realistic observable activity for each part of the timeline. The red operator is given every white card they need to execute their observable effect. Each of these carefully executed items becomes a discussion point for later.

These exercises are a great way to validate procedures and train blue operators to use them. Each unique generated activity is also an opportunity to identify procedure and technology gaps in the organization.

While this concept is new-ish to security operations, it’s by no means new. NASA has had a concept of an Integrated Training Team led by a Simulation Supervisor since the beginning of the US space program. NASA’s lessons learned in this area is a worthwhile study for security professionals. When I think about emerging job role of the Threat Emulator, I see these folks as the equivalent of NASA’s Simulation Supervisors, but for Security Operations.

Who is doing this?

I see several red teams re-organizing themselves to serve their organizations in different ways from before. Established teams with custom tools for long-term operations are trying to retool for engagements that require full disclosure afterwards. Other teams mirror external consulting firms in their services. These teams are now trying to give their leadership a global long-term perspective on their organization’s security posture. Day-to-day these teams are working towards the credibility, capability, and skills to bring the benefits of long-term operations to their organization. I see a trend where many internal red teams are expanding their services to benefit their organization’s at the tactical and strategic levels. It’s an exciting time to be in this area.


How to Pass-the-Hash with Mimikatz

May 21, 2015

I’m spending a lot of time with mimikatz lately. I’m fascinated by how much capability it has and I’m constantly asking myself, what’s the best way to use this during a red team engagement?

A hidden gem in mimikatz is its ability to create a trust relationship from a username and password hash. Here’s the mimikatz command to do this:

sekurlsa::pth /user:USERNAME /domain:DOMAIN /ntlm:HASH /run:COMMAND

The sekurlsa:pth command requires local administrator privileges. This command spawns the process you specify and modifies its access token. The local Windows system will still think the process was run by your current user. The parts of the token designed to support single sign-on will reference the username, domain, and password hash you provide.

If you use the above to spawn another payload (e.g., Meterpreter, Beacon); your actions that attempt to interact with a remote network resource will use the username, domain, and password hash you provide to authenticate.

In practice, spawning a new payload to pass-the-hash is a pain. It’s much easier to spawn a bogus process (e.g., calc.exe) and steal its token. Beacon’s steal_token command will impersonate a token from another process. The token stolen from our bogus process will continue to reference the username, domain, and password hash you provide. Any actions to interact with a remote resource, while Beacon holds this token, will pass the hash for us.

Let’s assume I have a foothold in a target environment and I’ve elevated my privileges. Here’s how I’d use this for lateral movement with Beacon:

1) Run hashdump to dump password hashes for the local users.


2) Run mimikatz sekurlsa::pth /user:Administrator /domain:. /ntlm:… /run:”powershell -w hidden”


We do powershell -w hidden to create a process without putting a Window on the desktop. Mimikatz doesn’t hide Windows for the processes it creates.

3) Use steal_token 1234 to steal the token from the PID created by mimikatz


4) Use shell dir \\TARGET\C$ to check for local admin rights


5) Try one of the lateral movement recipes (wmic, sc, schtasks, at) from this blog post to take control of the system.


To get a feel for how this works, I’ve put together a video:

This method of pass-the-hash has several advantages over traditional pen tester methods. Which advantage resonates with you will depend on the situations you face.

When I work with a mature network defense team, I try to avoid non-asynchronous communication. This means I can not speed up my Beacon to tunnel PsExec or another Metasploit module through my Beacon. This interactive communication will get caught right away. This plays well with an asynchronous post-exploitation workflow.

This method also gives me a great deal of flexibility. I’m relying on Windows to pass my credential material for me. What I do to interact with a remote network resource is up to me. If I’m only interested in data, I can list and copy files via a UNC path to the target. If I want to execute code, I have options beyond the service control manager to do so. When dealing with a mature target, this is important.

Finally, I prefer to use native tools over hacker tools to carry out my actions. I favor native tools because they blend in better and they’re more likely to work consistently. This method of pass-the-hash caters well to this preference.


An unnecessary addiction to DNS communication

May 14, 2015

I regularly hear stories from my users about how they got past a tough situation and had success that they claim was not possible without Cobalt Strike. As a developer, these emails are fun to read, and they give me a lot of job satisfaction.

One of the features these users love is DNS Beacon. Beacon is Cobalt Strike’s post-exploitation payload to model an advanced attacker. Beacon has DNS, HTTP, and SMB variants. The DNS Beacon is a flexible beast. It beacons over DNS, but downloads tasks over HTTP, DNS A records, or DNS TXT records. It’s possible to stage DNS Beacon over DNS TXT records or an HTTP GET request.

Many of my users use DNS Beacon to defeat very tough egress restrictions. That’s cool and for a while, we’ve had a free pass with DNS. Today, a few products are catching up to the idea that DNS is a communication channel attackers will abuse. We’re starting to see common sense heuristics to detect this abuse and help a network defense team identify and stop it.

Some of my users are feeling the pain of this. They write to me and ask for ideas on how to make Cobalt Strike’s DNS communication work against heuristic X. These are interesting emails because the right answer is context dependent.

Sometimes, there’s some play in DNS as a communication channel. Cobalt Strike’s Beacon is a flexible post-exploitation agent and I put a lot of power into my user’s hands. Other times, DNS communication is off of the table and it’s time to adapt. In this post, I’ll take you through my thoughts on these topics.

Staging over DNS

The most fragile part of the DNS communication options in Cobalt Strike is the staging process. DNS Beacon’s stager uses DNS TXT records to download Beacon and inject it into memory. I use TXT records to do this because it’s an efficient way to transmit a payload over DNS. By efficient, it’s still over one thousand requests. If an organization is watching for DNS abuse, this will stand out.

If staging is your pain point, you have the option to export the DNS Beacon without a payload stager. Attacks -> Packages -> Windows Executable (S) is the dialog to export a stageless Beacon. You get the option of raw position independent code, an executable, a service executable, PowerShell, a 32-bit DLL, and a 64-bit DLL. One of these options is bound to satisfy your needs to get a Beacon onto a box.

If your target can egress over HTTP, Cobalt Strike’s DNS Beacon can stage over HTTP too. I put this last because a lot of times folks use DNS Beacon to control systems that can’t directly reach the internet. We’ll go into this use case a little more in a moment.

Flexible DNS Communication

I mentioned earlier that the technologies that detect DNS communication are heuristics. If you feel like you’re getting detected, it would help to figure out how that detection works, and see if there’s a Cobalt Strike option to get around it.

First, Cobalt Strike communicates over DNS two different ways. The mode dns-txt command tells DNS Beacon to use DNS TXT records to download its tasks. This method of DNS communication is common in malware that uses DNS and it’s probably the method most prone to detection. I like the DNS TXT record channel, when I can get away with it, because it’s the more efficient of the two channels.

The mode dns command tells DNS Beacon to download its tasks with A records. If you have a 32 byte tasking, DNS Beacon will issue eight requests to download that tasking. Sometimes you can get away with DNS A records as a channel when TXT records won’t fly. Just know that it will take awhile for Beacon to download large taskings from you. To get the most from any tool, you should always know how it works and the limitations of each option.

To send data back to you, both the DNS A and DNS TXT record channels ask the target system to resolve [encoded and encrypted data] This is a gross simplification, but it’s fine for this discussion.

Some technologies detect DNS abuse by looking for long hostnames in a DNS record request. Cobalt Strike’s Malleable C2 technology gives you control over this. The maxdns option allows you to restrict the length of these requests. It will take longer for DNS Beacon to send data back to you, but this option may also help you avoid detection.

Other technologies detect DNS abuse by looking at how many requests are made to a given domain in a short period of time. Sometimes, this threshold is high. If this is the case, here’s my advice:

1. Use the Malleable C2 option sleeptime to change the default sleep time between each Beacon interval. I recommend 1 to 3 minutes at a minimum for these situations.

2. Swear off interactive command and control. This means you do not get to lower the sleep time of your Beacon. You’ll need to conduct all of your post-exploitation in an asynchronous way. Asynchronous post-exploitation is the only way to operate against harder targets. There’s tradecraft and tool support for this. Both are getting better over time.

3. Use multiple domains with your DNS Beacon. If a technology blocks a domain, hopefully you’ll just lose use of that domain, but not your access. If a technology kills your process, that’s a different
situation altogether.

I primarily use DNS Beacon as a persistent lifeline to spawn an access back into a network. On those rare instances where DNS is the only possible channel[tm], I continue to follow best practice and split my infrastructure up into different tiers. I use a post-exploitation server for post-exploitation activity. I avoid any interactive activity from my long-haul server for persistent callbacks. If you’re convinced that DNS is your only channel and you’re under this type of scrutiny, I recommend you fortify your key accesses to separate infrastructure. You don’t want a post-exploitation misstep to get you kicked out of your target’s network.

I like HTTP footholds!

For my userland footholds in a network, I use the HTTP Beacon as my workhorse payload. If it’s possible for a user to browse to websites with Internet Explorer, it’s probably possible to egress with HTTP Beacon as well. Possible is different from turn-key though. To defeat tough egress restrictions, as with all hacking activities, you have to get enough of the details right.

First, I make sure to have fully qualified domain names for all pieces of my infrastructure. I never try to egress to an IP address. For really tough situations, I use redirectors heavily. I also take care to stage through one redirector and configure the beaconing step to happen through the others. Cobalt Strike separates these options for a reason.

Some proxy servers use URL whitelisting to defeat malicious activity. I once got past this with Malleable C2. I used parameter q “” to add ? to each GET and POST request. The device in place checked for a whitelisted string in the whole URL. It didn’t care where it was.

I also take steps to match my Malleable C2 profile to the workstations I expect to egress from. A low hanging fruit item is to make my User-Agent match the User-Agent of the browser the user most commonly uses. The System Profiler is a great reconnaissance technology to capture this information.

Does the target environment have a HIPS product that limits which processes can egress? Fine! You can play this game and win. One of my favorite tricks is to modify the macro attack to spawn Internet Explorer and inject my Beacon payload into it. The same option exists for Cobalt Strike’s Applet Attacks [just download the Applet Kit, modify it, recompile, and rock it out!]

Pay attention to the Content-Type header as well. Some proxy devices whitelist which Content-Types are allowed. Malleable C2 lets you make HTTP Beacon look like something other than an arbitrary binary blob. It’s great for these situations.

Pivoting with Beacon

I speculate that a lot of my users like DNS Beacon for the same reason I like it for persistence. DNS Beacon will likely communicate with you, when run as SYSTEM, and from servers that can’t normally egress. This is a fine use for DNS Beacon, but if you have one HTTP foothold as a user on a workstation–there’s a better way to assume control of other Beacons. Let’s talk about the SMB Beacon.

The SMB Beacon is a Beacon variant that uses a named pipe to link to another Beacon. All of the SMB Beacon’s tasks and output come and go through the parent Beacon. It’s possible to link multiple Beacons together into a chain.

I use SMB Beacon a lot for privilege escalation. I may know I can’t egress as SYSTEM, but if I run an SMB Beacon, I can egress through my Beacon running in a user process. It’s nice.

I also use SMB Beacon for lateral movement. Named pipes work for host to host communication and this traffic is encapsulated in SMB. Those juicy Windows workstations that can’t reach the internet often have port 445 open. The SMB Beacon is the perfect payload to control these servers and make them egress through a user process on a workstation. I’m a big fan of operating this way.

When HTTP egress is possible, anywhere on a network, DNS communication is not necessary. It’s much easier to use that foothold to help all of my SMB Beacons reach me.

What’s the point?

If a network architecture or defense technology successfully mitigates a tactic, then it’s time to switch tactics. No single technique is the right answer for all situation into perpetuity. If you’re finding yourself challenged by a defense, think about what it’s doing. Know your tools and their options. You may have some room to get past that defense and continue on your merry way. If that’s not enough, try something else. This ability to reason about defenses and adapt to a situation is the stuff of great red team operators.


2015’s Red Team Tradecraft

April 29, 2015

“There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened.”

― Douglas Adams, The Restaurant at the End of the Universe

This blog post is a walk-through of how I do red team operations, today. I’ll take you through the primary tools and tactics I use for each phase of a simulated attack.

Assume Compromise

When I play red, it’s usually with a team tasked to work as a representative adversary in a compressed time frame. Things that might take months or a year as part of a real-world campaign have to happen in a few weeks or days. The purpose of these engagements is usually to train and assess security operations staff.

In a compressed adversary simulation, it’s common to white card access. Sometimes, a trusted agent opens every link or file the red team sends. Other times, the red team gets remote access to a few systems to serve themselves. This is the assume breach model and I’m seeing a lot of internal red teams adopt it for their activities.

While the engagements I do now are almost always assume compromise, I feel it’s important to have the capability to execute a campaign, beginning to end. Cobalt Strike will always contain the tools to execute a targeted attack process and get a foothold in a production environment.

Initial Access

Assume Compromise gives a red team a cooperative insider. It does not defeat static defenses. Red Teams still have to worry about anti-virus, egress restrictions, application whitelisting, HIPs, and other measures.

For my initial access I get by with one of Cobalt Strike’s user-driven attacks. Sometimes I’m lucky and a zipped executable is enough to start with. The Java Applet Attack is still a favorite. It’s helpful to download the Applet Kit and sign Cobalt Strike’s Applet Attack with a code signing certificate. I also lean heavily on the Microsoft Office macro.

When these fail me, I often resort to the HTML Application Attack. More and more, I’m finding that I have to modify the HTML Application Attack, on the fly, to run a PowerShell script rather than drop an executable. Using my tools in an engagement helps me understand which features provide value to a red team and which need improvement. As a developer, I understand my toolset’s strengths and shortcomings really well.

My initial access payload is always a Beacon of some sort. The HTTP and HTTPS Beacons are my workhorse. When HTTP Beacon is run as a user, it’s well equipped to defeat most egress restrictions. I use Malleable C2 to tweak my Beacon User-Agent and other indicators to something that will pass through a conservative proxy configuration. I fall back to a DNS Beacon with its DNS stager when I can’t egress with an HTTP Beacon.

Privilege Escalation

Once I have a foothold, my first goal is to elevate privileges. In a situation with fully patched systems, I run harmj0y’s PowerUp script. The PowerUp script is good at finding misconfigurations that I can act on for elevated rights. Beacon solved the PowerShell weaponization problem last year and it’s a wonderful agent to use offensive PowerShell capability with.

Recently, I was in a situation where the operating systems were held back to an older patch level. We had an opportunity to elevate with a Metasploit Framework local exploit–assuming we could get a Meterpreter session. More and more this is not a given for the situations I see. Our way around this was to port the needed Metasploit Framework local exploit to a stand-alone executable and use it to elevate. [Note: This wasn’t a refusal to use Meterpreter. It was simple fact–we couldn’t.]

If I know credentials for a local admin, I will use Beacon’s runas to run a Beacon as that user. I added runas to Beacon in January and this command is pure gold. I’ve gotten use out of it many times. [It beats doing this. See pg. 31, Red Team Field Manual]

Bypass UAC deserves an honorable mention too. If the current user is a local admin, Beacon gives me this option to spawn a Beacon into a high integrity process. I almost always run whoami /groups, right away, to see if this is an option.

Harvesting Credential Material

Once I elevate, one of my first priorities is to move away from patient zero (the initially compromised system). My options to move are dictated by the trust relationships I have access to. Now that Beacon has hashdump and wdigest, I run these commands as soon as I have the necessary privileges. Before Cobalt Strike 2.4, I would use PowerShell to run PowerSploit’s Invoke-Mimikatz cmdlet. I also use ps to see which processes are running as users other than my current one.

Lateral Movement

I think of lateral movement in four steps. First, I need to find my potential lateral movement targets. Next, I need to make use of an available trust to assume an identity that may give me rights on a remote system. Next, I check whether or not my remote target sees my current identity as an admin. Finally, I use my validated trust relationship to get remote code execution.

To discover targets, I use Windows net commands and I make heavy use of PowerView. PowerView is a very powerful tool, but it has a learning curve. I’m slowly transitioning my process to its capabilities.

To assume an identity as another user, I usually try to steal an access token from another process. If I know credentials, I use net use to connect to C$ or admin$ on a remote system. Now, I also use runas to spawn a Beacon running as the user whose credentials I know. This gives me flexibility that a net use does not. If I have a golden ticket, I run kerberos_ticket_use in Beacon to add it to my Kerberos tray. If I only have hashes, I try Mimikatz’s sekurlsa::pth command to spawn a Beacon with a token that passes the username and hash I provide. I’m still working to make this method of pass-the-hash a seamless part of my process. YMMV.

If it’s possible to meet my objectives without putting a Beacon onto a target, I do so. If I decide a Beacon is the right way to go, I export it as some sort of artifact. I upload it to the host that holds my assumed identity and I copy my artifact to the target system.

For lateral movement, I almost always use Cobalt Strike’s “stageless” SMB Beacon as my payload. This allows me to control compromised systems over a named pipe. All egress happens through the Beacon I link to other Beacons from. Named pipe communication is encapsulated within the SMB protocol. This method of communication with compromised systems is very stealthy. It’s also great for controlling systems that can not egress.

To execute my payload, I rely on native tools. I use wmic, at, sc, schtasks, and PowerShell’s Invoke-Command to run things on remote targets. I like having multiple options for remote code execution. I do not assume that I will always get to remotely manipulate the service control manager. I really want a bumper sticker that says, “Lateral Movement: It’s more than just PsExec”.


While I operate through Beacon and think a lot about Windows systems, this isn’t the whole game. It’s important to pivot other tools into a target environment and use these to interrogate, attack, and conduct post-exploitation on other systems.

Before I pivot, I usually inject a Beacon instance into another process and have it call back to separate infrastructure with different indicators. I consider these Beacons OK to sacrifice. Next, I speed up the new Beacon so it communicates interactively with its command and control server. Interactive communication is a recipe to get caught, that’s why I like to limit it to infrastructure marked for sacrifice.

To pivot, I open up a SOCKS proxy server that tunnels traffic through the new Beacon. I then make this SOCKS proxy server available to my teammates who want to use other tools. SOCKS and proxychains are sufficient to get most tools into an environment. Some situations may require a VPN pivot. I can count, on one hand, the number of times I’ve had to use a VPN pivot. It’s nice to have options.

User Exploitation

Once I have my footholds in a network and control the other systems I find interesting, the next step is user exploitation. Notice, I didn’t say post-exploitation. There’s a reason for this. Beacon and other agents are good at post-exploitation. They allow a red team to interact with and control compromised systems with the ease a system administrator might enjoy.

User exploitation is observing the user’s activity, identifying a target of opportunity [possibly time limited], and acting on it.

Riddle me this Batman… let’s say you control thirty, forty, or more workstations–with active users. How do you know what is happening on each of those workstations at any given time? How do you keep this knowledge of what’s happening fresh without giving up your presence to a watchful defender? How do you watch these systems with limited resources on your red team?

The answer: Today’s tools, including mine, were not built with this problem in mind. I’m working to remedy this and Cobalt Strike 2.4‘s refactor of Beacon features into jobs was a first step. Expect more to come on my end.

What’s Next?

You’ll notice, the process in this blog post is similar to what I teach in Tradecraft. You’ll also notice that the execution is different. The methods in this post were, for a long time, my fallback way to operate [see #4]. Sometime last year, Beacon hit a tipping point, and this has become my primary way to use Cobalt Strike. This style of hacking is what I teach in Advanced Threat Tactics today. The Veris Group’s Adaptive Red Team Tactics course is similar in mindset too. The demonstrated advantage of these new school red team tactics have forced me to re-think my tool’s dependencies, workflows, and user experience. These are interesting times.


So, you won a regional and you’re headed to National CCDC

April 17, 2015

The 2015 National CCDC season started with 100+ teams across 10 regions. Now, there are 10 teams left and they’re headed to the National CCDC event next week. If you’re on one of those student teams, this blog post is for you. I’d like to take you inside the red team room and give you my perspective on what you can expect and some ideas that may help you win.

The stakes at National CCDC are high. Last year’s winning team, University of Central Florida, had their picture posted in Times Square.

They were also personally congratulated by Vice President Joe Biden at the White House in Washington, DC. This is a big honor and it’s evidence of how prominent the CCDC event is becoming.


With all of that motivational stuff out of the way, let’s jump into the event specifics.

The Opening Salvo

Your National CCDC experience will start on a comfortable San Antonio, TX day. During my years at National CCDC, the blue teams always receive a clean network.

This network stays clean for about five seconds. The red team gets permission to attack at the same time you get permission to touch your systems. We sit in the red team room and wait until our Team Captain tells us Go! Once that happens, we press enter and a script attacks and backdoors your networks six ways to Sunday.

Each year, that I’ve participated in National CCDC, it’s happened this way. There’s nothing you can do about it. The fact that the red team “got in” with default credentials and easy vulnerabilities in the first few minutes is not in your control. It also happens to everyone evenly. When I’m the guy running those scripts, I make it my first priority to verify that every team is hooked the same way before I move on to anything else. Keeping things fair is a priority for myself and everyone else I’ve worked with at National CCDC.

Your Network

Each regional event is different, so I’d like to take a moment to describe the network you will defend at National CCDC. [Keep in mind, all of this is subject to change. I have no insider knowledge of the 2015 National CCDC event. I’m giving you what I and return competitors know.]

First, you will defend a network with a variety of operating systems. Expect a 50/50 mix of Windows and UNIX systems. If I had to venture a guess, I suspect you will see an even mix of dated operating systems and modern ones. Likely, these systems will be part of an Active Directory domain.

At your regional, you probably defended one network. At past National CCDC events, your peers had to defend two networks. One network is setup to act as your local site, in accordance with the scenario. The other network is a “cloud” site and you have to control and defend these systems with remote administration tools.

The makeup of operating systems in the two networks is usually similar.

I’m a fan of the cloud network. I see many blue teams use defense tactics that don’t scale well. The local network and cloud networks, combined, are still a small network. Even so, these extra remote systems are enough to stress the blue teams. Each year, I see most teams protect their internal network relatively well, but struggle in big ways with the cloud network. The top teams get both of these networks under control.

The National CCDC Red Team

The National CCDC red team organizes itself into cells of two to three red teamers per blue team. You may think this is unfair and you may have concerns that the red teamers you get will affect your chances of winning. Don’t worry about this. A lot of effort goes into making this construct fair.

First, the assignment of which red teamers will work together is carefully thought out. Each cell lead is someone who proved themselves at a previous year’s National CCDC event. While we each have specialties (I do a lot more Windows); the expectation is that each lead could handle a blue team by themselves, if necessary.

Second, the initial “malware drop” is scripted across all teams. You and your peers will get the same pile of malware [and configuration changes] to deal with.

Different cells will favor different toolsets, but the National CCDC red team is good at handing off accesses. If one cell loses access with their favored toolset, they have the shell sherpas (red teamers who manage the persistent malware) let them back in. No cell is kicked out of a network until you defeat or get rid of all the malware in your network.

Tempo and Timeline

On the first day, the National CCDC red team is expected to stay silent. In past years, the standing order is to do nothing to give away our presence. The goal is to get you to think we’re the worst red team ever and that there is no red team presence in your network. There’s a reason for this plan. The National CCDC red team wants you to action your injects, snapshot your work, and build up an environment that you’re invested into and trust.

On the second day, your red cell will destroy every system they have access to. You may opt to revert to a snapshot. If you do, the red team’s persistent backdoors will call home. The red team will destroy the system again. This dance will go on for about four hours.

What can you do to escape this?

There are a few options. First, you can revert to a base snapshot from before the event. You’ll lose all of your work and you’ll be vulnerable to the red team trying default things again. If it’s not going to cost you accrued points, I would take the risk and try to get your network up and running as quickly as possible. Red Team is fast, but I have yet to work with one that was really good at re-exploitation of default things in a timely manner. We’re too busy.

Your other option is to analyze network traffic, figure out how the red team is communicating with your systems and block it. We don’t typically use pre-implanted time bombs to destroy your systems. If we can’t talk to a system or it can’t talk to us, we probably can’t affect it.

Tools, Techniques, and Procedures

A common question to the red team is, what tools did you use? Each cell will conduct post-exploitation with what they have the most comfort with. Some cells use the Metasploit Framework for post-exploitation. Others take advantage of Cobalt Strike and its Beacon payload. Some red teamers operate with their private tools. This was the case with Brady Bloxham from Silent Break Security last year. I’ve even seen Core Impact make an appearance at National CCDC here and there.

The post-exploitation toolset is usually different from the persistence toolset. Like a real attacker, the National CCDC red team wants to stay in your network, and they take several precautions to limit your opportunity to observe their persistent backdoors.

The red team will use a variety of public and custom tools to persist in your network. These tools will beacon out of your network in a variety of ways. Their purpose isn’t post-exploitation. These tools are a lifeline. If the red team gets kicked out of your network, they will task one of these tools to let them back in with their preferred tool.

It’s common to see blue teams stuck in a whack-a-mole mindset. They see Meterpreter, Poison Ivy, or something else that’s noisy and obvious. They kill it. Five minutes later the attacker’s back. This isn’t because the attacker re-exploited their system. It’s because the defender took action against the attacker before they understood how the attacker was getting back in. If you don’t defeat an attacker’s persistence or their command and control–you accomplish very little by knocking out their loud post-exploitation agent.

I’ll offer one caveat to the above… you don’t know when your red cell is on their last shell in your network. If you see something obvious, feel free to kick it out. Maybe it’s the last thing you need to do send your red cell packing. Some teams reach this nirvana state.

For post-exploitation, the red team will use direct outbound TCP connections if they can get away with it. They will also use HTTP and HTTPS as data channels. In rare instances, we will use DNS, but only if we have to.

Expect that we will have infrastructure for post-exploitation and persistence within the competition environment and out on the internet. I’m known to take heavy advantage of Amazon’s Elastic Computing Cloud during CCDC. I also know one blue team likes to block all of EC2’s IP ranges. I think this is kind of silly, but we do put infrastructure in other places too.

For persistence, expect all kinds of things and expect this to get painful. Expect that the red team will use custom and public tools to slowly call back to them over DNS and HTTP. Again, the red team will have infrastructure locally and in the cloud.

Last year, one of the red team members brought a backdoor that would try multiple ways to get out of your network. It would try a TCP direct connection, HTTP, DNS, and if those failed it would scrape a shared Google Docs file for instructions.

How to Defeat the Red Team

I’m sharing all of this for a reason. I’ve seen some teams get fixated on a specific toolset. They take steps to defeat the Metasploit Framework. Some take steps to defeat Cobalt Strike’s Beacon payload. Others take steps to defeat things we don’t even use.

If you fixate on one specific toolset, you will put yourself at a major disadvantage. If you want to slow down the red team at National CCDC you’re going to have to fall back to generic best practices that defeat whole classes of bad guy activity.

Let’s go through some of the defense practices I see at CCDC…


I’ve seen many teams install EMET as part of their standard system hardening. I’ve never understood this and I’ve never felt any pain from it. The red team gains most of its accesses in the first five minutes before you have a chance to do much about it. After that, we’re not doing much in the way of memory corruption exploits. Our malware is on your system and we’re just hanging out and doing bad things with it.

Anti-virus Products

Most teams install an anti-virus product or malware scanner. You’re welcome to install one of these products, if you feel there’s nothing more important to do. You may get lucky and catch some off-the-shelf malware with one of these products. In general though, the National CCDC red team uses custom tools and artifacts. I wouldn’t expect much from an anti-virus product.

Hunting for Malware

All blue teams use the Sysinternals Suite from Microsoft to find red team activity. This requires constant vigilance with TCPView and Process Explorer. Sometimes, a team will get lucky and they’ll see something that directs them to the process we live in. If you see SYSTEM processes spawning new processes (especially cmd.exe), that’s probably bad.

I’ll add one caveat to this–a lot of red team post-exploitation activity happens in an asynchronous way. We queue up our tasks, our payload downloads them with one request, executes them, and reports the results. After that, our payload disconnects from our command and control server and there’s nothing for you to see until it wakes up and connects to us again. All of this happens very quickly and if you blink, you might miss it.

Fighting the red team off of your systems, one process at a time, isn’t going to work over the long term. It’s fine to kick the red team out when you see them, but remember–if you don’t get rid of all of the persistence, you didn’t get rid of the red team.

Restrict Egress

So, what’s the winning strategy? If you want to hurt the red team, you need to make it hard for the malware in your network to talk to the red team. Anything you can do to restrict egress will inflict great amounts of pain on the red team.

There’s a balance here. In a real enterprise, you have to make sure your users can do their job and that the business can functions. In the CCDC events, you have to make sure the scorebot can communicate and you have to satisfy the Orange team.

Make sure you whitelist which outbound ports are allowed. If there’s no need for your network to initiate outbound connections on port 4444, you shouldn’t allow it. Ideally, you should figure out what has to connect out and allow only these things. The National CCDC red team shouldn’t be allowed to control your network with an arbitrary outbound TCP connection.

Proxy Servers

Once you restrict outbound connections, you should force all web traffic to go through a proxy server.

In many cases, the Red Team’s HTTP/S persistent agents will run as SYSTEM. If you put in place an authenticated proxy and make it the only way out, you will prevent this malware from ever leaving your network. If our persistent agents can’t communicate with us, we can’t get back into your network and do bad things to it.

I won’t give away any team’s secret sauce here, but I’ve seen blue teams do creative and legitimate things with proxy servers. You can do a lot with a proxy to restrict malware from getting out of your network without impacting users.

DNS Egress

If you do all of the above well, then the next common channel is DNS. There are misconceptions about how this channel works. If your plan is to block port 53 outbound for all systems, except your internal DNS server, you may want to read this blog post.

Your best bet during CCDC is to detect malicious DNS and block it. Detecting isn’t too bad. Configure a sensor to log all DNS queries and sort this log to see which domains have the most activity. The malicious ones in a CCDC event should bubble to the top.

If you have time and want to put in the effort, you can re-architect your network to isolate internal workstations and servers from the global DNS system. If a workstation needs to browse to a website, let the proxy server handle the DNS resolution for it.

Other Egress

All of the above will make life very painful for the red team. I don’t have a good solution to defeat a red team that uses Google Docs or Twitter for command and control. The best I can offer is this: the more you box the red team in and take away options, the harder you make it for them to do things to you. Even if you can’t defeat all things within the realm of possible, you can slow the red team down a lot, and in a competition–this is good enough to get ahead of your peers.

The Dirtiest of Red Team Tricks

You’ll recall that I mentioned the red team is organized into cells. Each cell is focused on one team. In the red team room, no one wants their blue cell to win. You should expect that your red cell will do everything within their power to take points away from you. When a red cell steals a database with lots of PII that costs points–every other red cell drops what they’re doing and goes after the same data.

Once we exhaust the data that we can steal, we do everything we can to make it so the scorebot can not reach your services. We don’t necessarily need access to all of your systems to inflict great pain either. In previous years, we’ve used static ARP entries and ARP poisoning to good effect to create hard to track down layer-2 issues. We’ll also go the old fashioned route and just stop your scored services and delete files that are critical to their operation.

Closing Thoughts

You may read this post and think, wow, those red team folks are mean. That’s really not the case. We’re volunteers who care about your success. If you won a regional, we feel you can handle a great challenge and we want to make sure we give you one.

One of my favorite parts about National CCDC is the interaction I get to have with my blue team. Because the National CCDC red team splits up by team, you’ll find that your red cell has very detailed feedback for you. Once the event is over, I recommend that you track down your red cell and extract as much information from them as you can. You’ll find that your red cell are eager to share what they did, give you advice, AND to learn from you. I participate in CCDC because each year, I see things that impress me and I learn things that make me think about offense and defense in different ways.

I hope you get the most out of your National CCDC experience. I also hope this blog post helps level the playing fields for those of you coming to the event for the first time.

Good luck and do your best!


Get every new post delivered to your Inbox.

Join 17,110 other followers