Cobalt Strike Penetration Testing Labs (Download)

June 4, 2015

My primary conference give away is a DVD with a self-contained penetration testing lab. This DVD covers the Metasploit Framework‘s capability to target a server. It also covers the client-side attack process in Cobalt Strike. It’s a pretty neat set of labs and they don’t take too long to go through.

Cobalt Strike Boxed Set

I’ve had several requests to put these labs online. If you’re one of those interested parties, then today is your lucky day. The Cobalt Strike Pen Testing Lab DVD material is now available for download.

To start, you’ll want to grab the necessary virtual machines:

1. Morning Catch (Phishing Target)

2. Metasploitable 2

3. Xubuntu Attack VM with CS dependencies and stuff to support the labs

Next, you’ll want to download the penetration testing lab book. Last, you’ll need to grab a trial of Cobalt Strike and install it on the Xubuntu virtual machine above.

Once you have these things, you’re ready to rock. If you get stuck, here’s a video of me going through the labs:



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].yourmaliciousdomain.com. 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 “www.youtube.com” to add ?q=www.youtube.com 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.


Under the DIRWALK (Lyrics)

May 5, 2015

To the tune of Under the Boardwalk written by Kenny Young and Arthur Resnick, recorded by The Drifters.

Oh, when the domain is done and on all servers you’re root
And the hashes are so many, you wish your cracking rig were fireproof
Under the DIRWALK, down by the C:
Running my implant as SYSTEM is where I’ll be

(Under the DIRWALK) Out to the remote node
(Under the DIRWALK) We’ll be exfiling some stuff
(Under the DIRWALK) NSM watching all of us
(Under the DIRWALK) We’ll be doing what we want

From the screenshot you see, a user checking their ‘mail
Mmm, you can almost take the plans to all the stuff they sell
Under the DIRWALK, down by the C:, yeah
Running my implant as SYSTEM is where I’ll be

(Under the DIRWALK) Out to the remote node
(Under the DIRWALK) We’ll be exfiling some stuff
(Under the DIRWALK) NSM watching all of us
(Under the DIRWALK) We’ll be doing what we want

Oh, under the DIRWALK, down by the C:, yeah
Running my implant as SYSTEM is where I’ll be

(Under the DIRWALK) Out to the remote node
(Under the DIRWALK) We’ll be exfiling some stuff
(Under the DIRWALK) NSM watching all of us
(Under the DIRWALK) We’ll be doing what we want


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.


User-defined Storage-based Covert Communication

April 23, 2015

One of my favorite Cobalt Strike technologies is Malleable C2. This is a domain specific language for user-defined storage-based covert communication. That’s just a fancy way of saying that you, the operator, have control over what Cobalt Strike’s Beacon looks like when it communicates with you.


When I do red team work, I see the same blue audiences again and again. If the red teams I worked with were to persist the same way or have the same indicators during each engagement, the blue audiences would quickly learn these things and cease to get training value from our activity.

There’s two ways to solve this problem. One way is to use new tools during each engagement. That means the red teams either need to buy or build new tools for each repeat encounter they expect to have. This is expensive and not tractable. The other alternative is to build hacking tools that give their users flexibility to change behavior and indicators during an engagement. This line of thought is what led to Malleable C2.

Malleable C2 Profiles

The heart of Malleable C2 is a communication profile. This profile specifies what Beacon’s communication should look like on the wire. You can do the really easy stuff, like say, “I want my User-Agent to be ___________________”. That’s a simple option.

You can also dress up a Malleable C2 transaction too. The header keyword lets you add arbitrary headers to Beacon’s HTTP client requests and server replies. The parameter keyword lets you dress up Beacon’s HTTP client requests with additional parameters too.

You can also do cooler things, like say, “I want to base64 encode Beacon’s encrypted taskings and store the result inside of an HTML comment” [havex.profile] or “I want to add the encrypted Beacon tasks to a 1×1 pixel GIF file” [webbug.profile]. This is made possible by a Malleable C2 concept that I call a data transform. A data transform is a series of transforms that you may apply to data Beacon has to send. These transforms include append this string, base64 encode the data, prepend this string, and netbios encode the data.

        metadata {
            append "-.jpg";

Malleable C2 allows you to chain these transforms together into a program. This program is interpreted to transform Beacon’s data, one instruction at a time, into a string that looks like whatever you want.


Critically, each of these data transforms is trivially reversible. If I base64 encode some data, I simply need to use a base64 decode operation to recover that data. If I append a string to Beacon’s data, I just need to remove that many characters when I receive data from a Beacon to recover the original data.


The presence of an inverse operation for each transform is the magic that allows Cobalt Strike to derive how to send AND receive data from one specification.

The last piece of Malleable C2 is the ability to define where the data you transform is stored. Each data transform ends with a statement like print, which means send this data to the other end. More interesting statements include header and parameter which let you store the transformed data into an arbitrary HTTP header or parameter. The uri-append statement appends the transformed data to the requested URI.

This gives you an additional piece of flexibility. Not only can you define how to transform data that Beacon needs to send, you get to define where in the transaction this data goes.

Virtual Machines for Malware Communication

The challenge of Malleable C2 is that a Beacon needs to both send and receive information. This means Beacon, written in C, needs to transform data and recover data from a transform. The same goes for Cobalt Strike’s Java back-end that services Beacon’s HTTP requests.

To make this work I built a compiler for the C2 profiles. This compiler does all of the things you’d expect a traditional compiler to do. It parses the profile into an abstract syntax tree, it checks for errors, and it outputs a simple set of instructions that I wrote an interpreter for.

In effect, the Beacon payload and its server have built-in virtual machines to transform strings in different ways. Instead of CPU registers or a stack, this virtual machine operates on buffers. The active buffer maps directly to a part of a communication request. If I’m sending data from Beacon, there are buffers for parameters, headers, the URI, and in the case of a POST request–the data the client wants to send. Instructions in this Malleable C2 machine language allow the profile to set which buffer is the active one and populate/transform the data in this active buffer.

Likewise, to recover data, the Malleable C2 machine has instructions to populate a buffer with data from the transaction and to conduct inverse transforms on the data.

I could have built a simple XML format or made a few options to change static strings in Beacon’s communication. I went with this approach to give my users flexibility to look like other malware or legitimate traffic with very high fidelity. This isn’t possible with a few configuration options to change static strings. It really requires the ability to rewrite how the client and server expect to send and receive data from each other.

How I use Malleable C2

You may ask, what’s the use of Malleable C2? I’ve had a prototype of this technology since early 2014. I pushed it into production in July 2014. Now, after some time with it, I can offer some use cases.

I do use Malleable C2, for its stated use case, to emulate specific actors. The Malleable C2 Github repository has several example profiles that re-create the C2 traffic of known malware. I tend to use profiles tied to known malware when I want to get caught or when I want to exercise a blue team’s ability to analyze the attack.

Just as often, I will also modify a profile to make myself look like a variant of known malware. I do this to avoid getting caught with default signatures, but to make my activity identifiable as malicious for training audiences doing traffic analysis.

While Malleable C2 gives me a vote in how I want to get caught, it’s just as effective at evasion too. Once I know an environment’s browser configuration and sites users are likely to visit, I’ll load some of these sites in a VM, capture traffic, and craft profiles to look like this traffic. One time, I pulled down a PDF file from a document archive and made a profile to insert Beacon C2 into the middle of the PDF content. I do the same thing with JavaScript files that are common in an environment too. I also made favicon into a channel once. I didn’t spend days or hours crafting these. I built these on the fly, as needed, to support the engagement objectives.

When I stand up red team infrastructure, I always diversify my indicators. My long-haul persistence servers have different indicators from my staging and post-exploitation servers. If you use Cobalt Strike, I highly recommend you do this too. If one Beacon gets caught, you don’t want its traffic pattern to make it easy to identify all of your other Beacons. Malleable C2 makes it trivial to have indicator diversity with one tool.

Malleable C2 has helped defeat “blinky box” appliances as well:

One red team I worked with had to deal with a network appliance that whitelisted which sites clients could browse to. In this situation, we could use a client system to seed our access and troubleshoot our outbound communications. It was still our responsibility to figure out something that would work though. On a whim, we modified our profile’s HTTP GET and POST components to add a parameter with a whitelisted host in it:

http-get {
	client {
		parameter "q" "www.youtube.com";

http-post {
	client {
		parameter "q" "www.youtube.com";

And, it worked. We were able to get a fully-staged HTTP Beacon past the device. Apparently this vendor didn’t check whether or not we were visiting a whitelisted domain, they just cared that a whitelisted string existed in the URL.

I’ve seen several situations where a proxy server allows certain browsers out and denies other browsers the opportunity to leave the network. These situations represent the real power of Malleable C2. If some specific part of the Beacon payload is holding you back, Malleable C2 gives you the flexibility to do something about it. I consider that a huge win for empowering my end users to get the most out of the Cobalt Strike toolset.

Malleable C2 isn’t hard to learn. I recommend grabbing an example and tweaking it. You can also read the documentation to get a feel for what Malleable C2 can do.


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 15,539 other followers