Archive for the ‘Cobalt Strike’ Category


Cobalt Strike 3.11 – The snake that eats its tail

April 9, 2018

Cobalt Strike 3.11 is now available. This release adds to Cobalt Strike’s in-memory threat emulation and evasion capabilities, adds a means to run .NET executable assemblies without touching disk, and implements the Token Duplication UAC bypass attack.

In-Memory Threat Emulation

One of the things that makes Cobalt Strike different is its ability to emulate multiple toolsets with one agent and one platform. Malleable C2 (2014) was the start of this. Malleable C2 focused on wire indicators because that’s what defenders could most easily observe. Today, wire indicators have their place, but defenders are just as likely to rip a DLL from memory to extract indicators and understand what they’re up against.

Cobalt Strike 3.7 introduced Malleable PE to give Beacon indicator flexibility in-memory. Cobalt Strike 3.11 takes this further.

1. Malleable C2 profiles now have the ability to specify the checksum, entry point, exported DLL name, and rich_header of the Beacon DLL.

2. This release also adds a peclone utility to Cobalt Strike’s Linux package. The peclone utility parses a DLL and reports a ready-to-use Malleable C2 stage block. This allows red teams to quickly extract and apply indicators from a malicious executable or DLL to Cobalt Strike’s Beacon.

3. The stomppe option controls whether or not Beacon’s loader stomps the MZ, PE, and e_lfanew values after loading. This option controls a common in-memory evasion tactic. Set this option to false and Beacon becomes a more obvious in-memory target.

4. Of course, flexible indicators have little utility without ground truth to give to the blue team. The Indicators of Compromise report in Cobalt Strike 3.11 now includes more information about the profiles used during the engagement. Each profile is presented as a unique “malware sample” with a summary of PE headers, contacted hosts, an HTTP traffic sample, and interesting strings.

Here’s the IOCs report with the HaveX Malleable C2 profile loaded:

In-Memory Evasions

February 2018’s In-memory Evasion course discusses heuristics to find injected DLLs in memory, explains why these heuristics work, and offers strategies to push back on these defenses. Cobalt Strike 3.11 adds more options to challenge and train defenders that use memory hunting techniques.

Less DLL, Please

One way to avoid detection as a memory injected DLL is to not look like an injected DLL at all (go figure). Cobalt Strike’s existing Malleable PE obfuscate option provides some help here. It masks Beacon’s import table and other fields in Beacon’s DLL. Cobalt Strike 3.11 takes this to the next level. Now, when obfuscate is set to true, Beacon’s Reflective Loader will situate Beacon in its new memory without bringing over any of its DLL headers.

Of course, the above raises a problem. It’s nice that the final Beacon DLL is better disguised. What about the memory that contains Beacon and its self-bootstrapping Reflective Loader? That package still has the MZ, PE, and e_lfanew values.

Set the cleanup option to true. This hint asks Beacon to release the memory associated with its loader. When this operation succeeds, your Beacon will live in-memory without the package that put it there.

Together, obfuscate and cleanup allow Beacon to live in-memory without content that screams memory-injected DLL.

Module Stomping

The above does raise another problem. What about the permissions of that memory? We still have pages with execute permissions that are not tied to a loaded module. These permissions exist in legitimate applications, but these properties are a warm flame that attracts the hunters from their cyber blinds.

Cobalt Strike 3.11 also adds module stomping to Beacon’s Reflective Loader. When enabled, Beacon’s loader will shun VirtualAlloc and instead load a DLL into the current process and overwrite its memory.

Set module_x86 to a favorite x86 DLL to module stomp with the x86 Beacon. The module_x64 option enables this for the x64 Beacon.

While this is a powerful feature, caveats apply! If the library you load is not large enough to host Beacon, you will crash Beacon’s process. If the current process loads the same library later (for whatever reason), you will crash Beacon’s process. Choose carefully.

In-memory .NET Assembly Execution

In Modern Defenses and YOU!, I advised that operators who depend on PowerShell should brush up on working without it. I also advised that payload developers, myself included, would do well to embrace the use of .NET assemblies in their platforms.

Cobalt Strike 3.11’s execute-assembly command makes good on this. This command accepts a path to a local executable assembly and runs it on the target in a temporary process. This temporary process benefits from all of your session prepping steps (e.g., ppid, spawnto, etc.). You may pass arbitrary arguments, quoted or not, to this program as if you ran it from a command shell. Scripters may build on execute-assembly with &bexecute_assembly.

This video demonstrates the Internal Monologue attack with help from execute-assembly:

Token Duplication UAC Bypass

But wait, there’s more! Cobalt Strike 3.11 adds a module that implements the Token Duplication UAC Bypass discovered by James Forshaw and originally weaponized by Ruben Boonen.

This UAC loophole allows a non-elevated process to use a token, stolen from an elevated process, to launch an elevated process of the attacker’s choosing. This loophole requires the attacker to remove several rights assigned to the elevated token. The abilities of your new session will reflect these restricted rights (e.g., you can’t interact with processes outside of your current desktop session).

This attack can bypass Always Notify. This requires that an elevated process is already running in the current desktop (as the same user). This attack also works on Windows 7 and later.

Use elevate uac-token-duplication [listener] to bypass UAC and get a session. This module does run a PowerShell one-liner to run a payload stager. Optionally, use runasadmin [command] [arguments] to bypass UAC and run an arbitrary command in an elevated context. The runasadmin command does not use PowerShell.

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


Beware of Slow Downloads

March 9, 2018

I often receive emails that ask about slow file downloads with the Beacon payload. Here are the symptoms:

  • It takes multiple hours to grab a few megabytes
  • The sleep time makes no difference
  • File uploads are fast and not affected by this “slowness”

When I get these emails, I usually ask the user about their Malleable C2 profile. Malleable C2 is a technology to change the network and memory indicators for Cobalt Strike’s Beacon payload. In some cases, it can alter the tool’s behavior too.

I sometimes get a reply that the operator is using a custom profile derived from one of the Malleable C2 profiles on my Github repository. Inevitably, I’ll learn that the base profile is a profile that uses HTTP GET requests to download tasks from AND send data back to Cobalt Strike’s team server.

Cobalt Strike’s Beacon payload downloads tasks from its team server via an HTTP GET (or POST) request. The payload limits itself to 1MB of encrypted data per request. This is enough to download most task packages in one request.

By default, Cobalt Strike’s Beacon payload sends data back to Cobalt Strike’s team server with an HTTP POST request. In this default, the Beacon payload embeds its encrypted data into the body of the POST request. Here, the limit is again, 1MB. If you’re downloading a file, Beacon will deliver it in 512KB pieces. This 1MB limit is enough to send a 512KB file piece and some output in one HTTP POST request.

The default is what most Cobalt Strike users are used to and it’s the behavior most Cobalt Strike users expect when they use the HTTP and HTTPS Beacon payloads.

Cobalt Strike 3.6 extended Malleable C2 to allow operators to change where, in the HTTP request, Beacon embeds data it sends back to the team server. The default is still to embed data into the body of an HTTP POST request. But, you also have the flexibility to embed Beacon’s data into the URI, an HTTP header, or a URI parameter. You can also change the HTTP verb associated with this request too. This is amazing flexibility to put into an operator’s hands.

The above flexibility has consequences though. I can stick 1MB of data into the body of an HTTP POST request, no problem. I can’t stick 1MB of data into a URI, an HTTP header, or a URI parameter. That won’t work. What does Cobalt Strike’s Beacon do in these situations? Beacon chunks its output.

The chunker will divide any data, destined for the team server, into ~100 byte chunks. Each piece is sent back to the team server in its own HTTP request. This is where the behavior change comes.

I can send a 512KB file piece in the body of one HTTP POST request. That same file piece requires over 5,240 HTTP requests when divided into 100 byte chunks. Beacon does not make these HTTP requests in parallel. Rather, it makes one request, and waits for the response. It then makes the second request and waits for its response. This happens until all needed HTTP requests are made. The latency associated with each request is the thing that affects your download speed.

If you’ve seen this behavior in your use of Cobalt Strike, I hope this blog post helps clarify why you’re seeing it.


Cobalt Strike 3.10 – Хакер vs. 肉雞

December 11, 2017

Cobalt Strike 3.10 is now available. This release adds Unicode support to the Beacon payload, introduces a built-in report based on MITRE’s ATT&CK matrix, and performs endodontics on the Beacon payload.

A Strategy for Unicode

One of Cobalt Strike’s limitations is its ham-fisted handling of text. Cobalt Strike treats everything sent to and received from Beacon as binary data. This creates headaches for Cobalt Strike users that come across non-ASCII characters in usernames, passwords, file names and other data.

Cobalt Strike 3.10 addresses this problem. Beacon now encodes text input and decodes text output with a character encoding appropriate to the target and situation.

The end result is on systems with a Chinese locale, Cobalt Strike will display Chinese output and accept Chinese input. On systems with a Japanese locale, Cobalt Strike will display Japanese output and accept Japanese input. The same goes for other languages.

Be aware that your font may not have definitions for the characters in your target’s language. If you see boxes where you expect characters, try changing your fonts:

Go to Cobalt Strike -> Preferences -> Cobalt Strike to edit the GUI Font value. This will change the font Cobalt Strike uses throughout its GUI, dialogs, and tables. This option is new in 3.10.

Cobalt Strike -> Preferences -> Console and Graph change the fonts used by Cobalt Strike’s console tabs and pivot graph.

Integration with MITRE’s ATT&CK Matrix

Cobalt Strike 3.10 integrates The MITRE Corporation’s ATT&CK Matrix into its reporting engine. ATT&CK is a project to describe adversary post-exploitation behaviors with their detection and mitigation strategies. Each behavior is assigned a Tactic ID.

Cobalt Strike 3.10 associates Beacon actions with one or more ATT&CK tactics. Scripts have the option to do this with the &btask function too.

Cobalt Strike uses this information to generate a Tactics, Techniques, and Procedures report. This report presents your Cobalt Strike activity on a tactic-by-tactic basis. Each tactic includes a description, mitigation, and detection narrative.

A Root Canal for the Beacon Payload

This release took many steps to remove functionality from the Beacon payload and restore that functionality with changes in the Beacon controller.

One such change removed the logic to spawn cmd.exe and powershell.exe from inside the Beacon payload. In their place is a more generic primitive to run programs and send output to Cobalt Strike. The updated shell and powershell commands use this primitive instead. The &beacon_execute_job function builds on this primitive too. Here’s a script that re-implements Beacon’s powershell command:

alias powershell {
	local('$args $cradle $runme $cmd');

	# $0 is the entire command with no parsing.
	$args   = substr($0, 11);

	# generate the download cradle (if one exists) for an imported PowerShell script
	$cradle = beacon_host_imported_script($1);

	# encode our download cradle AND cmdlet+args we want to run
	$runme  = base64_encode( str_encode($cradle . $args, "UTF-16LE") );

	# Build up our entire command line.
	$cmd    = " -nop -exec bypass -EncodedCommand \" $+ $runme $+ \"";

	# task Beacon to run all of this.
	btask($1, "Tasked beacon to run: $args", "T1086");
	beacon_execute_job($1, "powershell", $cmd, 1);

These changes remove a few unique strings from the Beacon payload. This is where the root canal analogy comes in. A root canal not only removes (signs of) infection, it replaces the infection with something benign. That’s here too!

Cobalt Strike 3.10 extends Malleable PE with options to add ASCIIZ and wide character strings to the Beacon payload. This example adds several havex specific strings to Beacon’s havex Malleable C2 profile:

stage {
	# strings gathered from Yara rules and sandbox string dumps
	stringw "%s <%s> (Type=%i, Access=%i, ID='%s')";
	stringw "%02i was terminated by ThreadManager(2)\n";
	stringw "main sort initialise ...\n";
	stringw "qsort [0x%x, 0x%x] done %d this %d\n";
	stringw "{0x%08x, 0x%08x}";
	stringw "Programm was started at %02i:%02i:%02i\n";
	stringw "a+";
	stringw "%02i:%02i:%02i.%04i:";
	stringw "**************************************************************************\n";

These changes recognize the fact that some analysts use tools driven by YARA rules to detect and identify payloads in an environment. These rules often target unique strings observed by the rule’s creator. Knowing these strings, red teams have an opportunity to deliver more interesting adversary simulations and exercise another aspect of their blue team’s detection and response capability.

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

NOTE: An in-place update of Cobalt Strike with live sessions is never recommended. With Cobalt Strike 3.10, this is especially true. Cobalt Strike 3.10 cannot control sessions from previous versions of Cobalt Strike.


Kits, Profiles, and Scripts… Oh my!

October 3, 2017

If I had to describe Cobalt Strike in one word, I’d say ‘flexible’. There are a lot of options to control Cobalt Strike’s features and indicators. In this post, I’ll introduce these options, explain the rationale for each, and point you to resources to explore them further.

Aggressor Script

Aggressor Script is Cobalt Strike’s built-in scripting language. It is the preferred way to add features to Cobalt Strike, override existing behaviors (kits take advantage of this), and automate your engagements.

Several public scripts add new workflows and features to Cobalt Strike. For example, CACTUS TORCH adds user-driven attack options to Cobalt Strike with x64 and stageless variations too. Tyler Rosonke wrote a script to add persistence options for Beacon.

Cobalt Strike also ships with a headless client, agscript, that connects to a team server and hosts an Aggressor Script for you. This client is designed for long-running bots. Common uses of headless Aggressor Scripts is to force DNS beacons to “check in” or notify an operator, via a text or email, that they have a new session.

If you’d like to dig deeper into Aggressor Script, jump over to the Aggressor Script documentation. I also regularly post Aggressor Script snippets as Github gists. Finally, Lee Kagan has created an Aggressor Scripts Collection that aggregates many of the publicly available scripts into one place.

Applet Kit

A kit is source code to a Cobalt Strike feature coupled with a script that forces Cobalt Strike to use your implementation over the built-in one. Kits give you control over the artifacts and processes that deliver the beacon payload.

The concept of kits in Cobalt Strike came out of necessity.

For a long time, Java Signed Applets and Java Applet exploits were a staple client-side attack option. In January 2013, I implemented Cobalt Strike-native versions of these attacks. The Smart Applet attack bundled several Java exploits into one package. The Java Signed Applet attack hosted a self-signed Java applet on Cobalt Strike’s web server. If a vistor let the applet run, it’d result in code execution for the attacker.

While the above options were great, at the time, my users needed an option to modify these attacks to evade detection. This is where the Applet Kit came in. The Applet Kit is the source code to Cobalt Strike’s Java Applet attacks. Included with the Applet Kit is an applet.cna script. When you load this script, Cobalt Strike uses your applet attacks instead of its built-in options.

The Applet Kit is available from the Cobalt Strike arsenal. This is a one-page site available to licensed Cobalt Strike users. Go to Help -> Arsenal from Cobalt Strike to reach it.

As Java in the browser became more constrained, Cobalt Strike users would often sign the built-in Java Signed Applet attack with their code-signing certificate. The use of a valid code-signing certificate kept this attack alive past its expected expiration date.

Artifact Kit

Introduced in January 2014, the Artifact Kit controls Cobalt Strike’s process to generate executable and DLL files.

The contract of the Artifact Kit is simple. Cobalt Strike provides shellcode and meta-information to a scripted function. The scripted function is responsible for returning an executable or DLL that runs that shellcode.

The Artifact Kit is also available from the Cobalt Strike arsenal. The arsenal hosts my implementation of the default artifacts in Cobalt Strike. A few variations are available in the Artifact Kit distribution as well.

To use the Artifact Kit: download the default implementation, make changes, build it, and load the artifact.cna script that registers itself to handle executable and DLL file requests in your Cobalt Strike.

Resource Kit

Many Cobalt Strike attacks and workflows take advantage of PowerShell, Python, and VBA scripts to get the job done. The Resource Kit controls the PowerShell, Python, and VBA script templates in Cobalt Strike.

Again, the contract here is simple. Cobalt Strike provides a registered script with shellcode, meta-information, and a description of what it wants. The registered script returns a script that executes the shellcode.

The Resource Kit is also available in the Cobalt Strike Arsenal.

Many Cobalt Strike users combine the Resource Kit with Invoke-Obfuscation to make Cobalt Strike’s PowerShell scripts much less obvious.

Elevate Kit

It’s a goal of Cobalt Strike to make it easy to combine your team’s “secret sauce” with the toolset. One spot where this comes together well is privilege escalation. Aggressor Script exposes APIs that allow scripts to register privilege escalation exploits with Beacon’s elevate command and Elevate Privileges dialog.

The Elevate Kit is a collection of public privilege escalation exploits integrated with Cobalt Strike via these APIs. The Elevate Kit demonstrates how to integrate Reflective DLL implementations of privilege escalation attacks from the Metasploit Framework. It also shows how to repurpose attack POCs implemented in PowerShell as well.

The Elevate Kit is hosted on Github. Load the elevate.cna script and you’re ready to go. Don’t be afraid to extend or add to the Elevate Kit. It’s pretty easy. During a recent cyber exercise, I was able to recompile a POC from Github as a Reflective DLL and fire it with Cobalt Strike. The entire process took less than 30 minutes.

Custom Reports

Cobalt Strike’s built-in reports are designed to convey red team activities and indicators to a blue team training audience. While the built-in reports are serviceable, it’s not well-known that you can write custom reports for Cobalt Strike too.

The Aggressor Script documentation covers Custom Reports and hosts the source code for the built-in reports too.

I’ve used this feature to generate variations of Cobalt Strike’s built-in reports, split up by IP address ranges, to give tailored information to the blue teams at a large cyber defense exercise.

External C2

I’ve had quite a few requests for third-party command and control options with Cobalt Strike’s Beacon payload. The External C2 specification (November 2016) was my answer to these requests.

External C2 documents how to control Beacon over a named pipe and provides a TCP/IP interface to configure an SMB Beacon stage, receive it, and relay traffic between the SMB Beacon and Cobalt Strike. How this traffic is transported and relayed is up to your imagination.

I never announced External C2 as a feature. I wrote the specification, implemented it, and distributed it to customers who requested this feature. I wanted to see what (if anything) these users would do with the specification.

The fine folks at Outflank B.V. were the first, that I know of, to build and use an external C2 with Cobalt Strike. They contacted me to share the success story from one of their engagements. They also asked if (and when), they could publish a blog post to share their code and document the feature. This led to the Cobalt Strike over external C2 – beacon home in the most obscure ways post on their blog. Their External C2 uses a corporate file server as a dead drop for communication between a hard-to-reach target and their Beacon controller. Their external_c2 source code is on Github too.

Shortly after Outflank’s post, MWR Labs posted their thoughts on External C2 and demonstrated a POC to control Beacon via Office 365 Tasks. In both cases, I’m very impressed and I find these first results encouraging. Needless to say, even though it’s not announced, the External C2 specification is public and is implemented as-described in Cobalt Strike today.

Malleable C2 Profiles

Malleable C2 profiles control the indicators and behaviors in the Beacon payload and its stagers. I consider Malleable C2 the most important technology in Cobalt Strike today.

I introduced Malleable C2 as part of Cobalt Strike 2.0 (July 2014). The first release of Malleable C2 controlled the indicators in Beacon’s HTTP communication. Malleable C2 made it possible to use Beacon, but look like the havex trojan or something completely innocuous.

Today, Malleable C2 isn’t just network traffic. Malleable C2 profiles control which SSL certificate Cobalt Strike uses. Profiles also specify the code-signing certificate used to sign executables and DLLs. Malleable C2 profiles have options to influence Beacon’s memory indicators too.

I very much intended Malleable C2 as a threat emulation technology, but it’s much more than that. I didn’t imagine domain fronting when I added Malleable C2 to Cobalt Strike. Yet, when this technique became known, Cobalt Strike was a go-to platform to take advantage of it. Today, I heard about a customer using the string replace feature (for Beacon’s stage) to alter how Beacon runs PowerShell scripts. Again, I wouldn’t have thought of that.

The Malleable C2 Profiles Github repository has several example profiles to start with. You can use one of these, but the barrier to making your own “never seen” profile is very low. I recommend reading the Malleable C2 documentation as well.

Closing Thoughts

Today, there are few things in Cobalt Strike that users don’t have direct control over. Through these tools you may add to Cobalt Strike’s features, modify behaviors that get in your way, change the files that deliver the Beacon payload, and edit the product’s indicators. As red team needs and tradecraft evolve, this flexibility is how Cobalt Strike keeps pace.


Cobalt Strike 3.9 – Livin’ in a Stager’s Paradise

September 20, 2017

Cobalt Strike 3.9 is now available. This release brings several additions to Malleable C2 with an emphasis on staging flexibility.

Malleable HTTP/S Staging

Stagers are tiny programs that download the Beacon payload and pass control to it. Stagers are a way to use a size-constrained attack to deliver a large payload like Beacon. While I recommend working stageless, stagers are helpful in some situations. Wouldn’t it be nice if you could disguise staging to look like something else? That’s possible now.

This release introduces Malleable C2 flexibility into Beacon’s HTTP and HTTPS stagers. Cobalt Strike 3.9 profiles may modify the HTTP staging URI, add client headers, add URI parameters, and place arbitrary data before or after the encoded payload stage. Here’s the Malleable C2 profile for the above screenshot:

http-stager {
	set uri_x86 "/_init.gif";
	set uri_x64 "/__init.gif";

	client {
		parameter "key1" "value1";
		parameter "key2" "value2";
		header "Host" "yeah this works too";

	server {
		header "Content-Type" "image/gif";

		output {
			prepend "\x01\x00\x01\x00\x00\x02\x01\x44\x00\x3b";
			prepend "\xff\xff\xff\x21\xf9\x04\x01\x00\x00\x00\x2c\x00\x00\x00\x00";
			prepend "\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00\x00\x00";

And, here’s a recorded demonstration:

More Malleable C2 Features

While the HTTP staging gains the most flexibility in this release, 3.9 enhances Malleable C2 in other ways too.

The dns_stager_prepend option places a string before the encoded payload stage delivered via DNS TXT records. This offsets the content in this process and pushes back on signatures that target fixed TXT records in Cobalt Strike’s DNS staging process.

set dns_stager_prepend "v=spf1 mx -all other:";

This release adds an obfuscate setting to the Malleable PE directives. This option masks the Beacon DLL’s import table. Together, the obfuscate setting and strrep (introduced in 3.7), give you a lot of control over which strings are visible in the Beacon stage.

stage {
	set obfuscate "true";

And, Malleable C2 gains a mask statement for its data transform blocks. The mask statement generates a random 4-byte value, masks your data with this value, and prepends this 4-byte value to the masked data. This last step makes it possible to reverse the mask step. The mask statement is interpreted and applied with each Beacon transaction. The mask statement makes it possible to randomize parts of your profile.

Authorization Files

The licensed version of Cobalt Strike 3.9 and later now requires an authorization file to start. The update program, distributed with the Cobalt Strike trial, downloads this authorization file.

The authorization file includes your license expiration date and a unique customer ID. Cobalt Strike 3.9 and later embeds this ID into the Beacon payload stage and any stagers generated by Cobalt Strike. This value is the last 4-bytes of the Beacon payload stager.

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


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.