Archive for the ‘Cobalt Strike’ Category


Cobalt Strike 2.0 – Malleable Command and Control

July 16, 2014

I define threat replication as a penetration test that looks like an attack from an APT actor. Assessments that involve threat replication are more than a test of technical controls. Threat Replication is a full exercise of a customer’s analytical process and ability to attribute and respond to an APT.

These definitions are all well and good, but the big question remains–how do we replicate an advanced threat in a penetration test?

I have an answerBeacon’s network indicators are now controlled by a Malleable C2 profile. C2 Profiles are simple programs that define how to transform data and store it in a transaction. Think of it as user-defined covert communication. Load a profile and now you look like that actor during your penetration test.

Etumbot APT Profile

Here’s a C2 Profile made by Will Schroeder that emulates the Etumbot APT Backdoor:

set useragent "Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/5.0)";

http-get {
    set uri "/image/";
    client {
        header "Accept" "text/html,application/xhtml+xml,application/xml;q=0.9,*/*l;q=0.8";
        header "Referer" "";
        header "Pragma" "no-cache";
        header "Cache-Control" "no-cache";
        metadata {
            append "-.jpg";

    server {
        header "Content-Type" "img/jpg";
        header "Server" "Microsoft-IIS/6.0";
        header "X-Powered-By" "ASP.NET";
        output {

To load this profile, place it in a file, and tell Cobalt Strike to use it:

root@kali:~/cobaltstrike# ./cobaltstrike --profile etumbot.profile

You may also specify a profile when you start a team server. Here’s what Beacon’s communication looks like, with this profile loaded:


With this profile–every action you take with Beacon looks like Etumbot on the wire. Combine this with Beacon’s ability to tunnel Meterpreter through it and you can conduct your entire engagement with Etumbot’s indicators.

Profile Language

Profiles do two things: (1) They dress up each transaction with extra indicators. Client and server blocks may add or override headers. Clients may add arbitrary parameters to a URI too. (2) Profiles also define how to transform and store data in a transaction. You can see this in lines 10-14 of the Etumbot profile:

        metadata {
            append "-.jpg";

These lines define how to transform and store metadata:


Lines 10-14, interpreted backwards, also extract and recover data from a transaction.


This ability to transform and recover data from the same profile is the magic of Malleable C2. Profiles are simple and easy to write. Cobalt Strike also includes c2lint, a program to sanity check a profile for mistakes.

To learn more about C2 profiles, take a look at the documentation or the profiles on Github.

Malleable C2 is available in today’s 2.0 release of Cobalt Strike. For a full list of changes, read the release notes. Cobalt Strike users may use the built-in update program to get the latest. A 21-day trial is available too.


HTTP Proxy Authentication for Malware

June 25, 2014

I spend a lot of time thinking about what my tools can and can’t do. One of the weakest points for penetration testing tools is their (in-)ability to get past some egress restrictions. I previously wrote about why this is a problem and how you might get past different egress restrictions.

My general advice is this: reverse TCP payloads are a dead option. HTTP and HTTPS payloads are fine for transparent proxies or proxy servers that use NTLM authentication. Use DNS as an egress channel otherwise. If DNS fails you, then you’re out of luck.

Keep in mind, this advice assumes a hardened target.

My general advice isn’t bad, but it falls short in this situation: What happens if your target sets up a proxy server that requires the user to authenticate with a separate set of credentials to get out to the internet. Further, let’s assume that these workstations are otherwise isolated from the internet and they also can’t resolve DNS names for external systems. What do you do in this situation?

Recently, I decided to look into this problem. Here’s what I found:

WinINet is the Windows Internet API and it’s the library that manages the cache, credential store, and communication for Internet Explorer and other applications. If you configure a proxy server in Internet Explorer, WinINet applications will communicate through it.

When WinINet connects to a URL (through a proxy server), it first checks its credential store for a username and password. If there is no value in this credential store, WinINet will attempt to get the URL through the proxy server.

If the proxy server requires authentication, WinINet will get a 407 Proxy Authentication Required response from the server. What happens next is up to the program that made the WinINet call.

If that program is Internet Explorer, the user will see a dialog where they are asked to enter their username and password for the proxy server. The user also has an option to check the Remember my credentials box. This option will put the username and password into the credential store.


The proxy username and password, when stored in the credential store, are available to any application that runs as the current user. If my target uses Internet Explorer and uses the Remember my credentials option to save retyping, then Meterpreter and Beacon get a free pass to authenticate and communicate through the configured proxy server—no code changes required. Better, these remembered credentials survive a reboot too.

It’s possible for a network administrator to change this behavior though. There is a GPO to disable storage of passwords and credentials for network authentication. When this option is set to enabled, the user will see the same dialog as above. The user will even see the Remember my credentials option. The main difference is that the automatic authentication will only happen for the current application. When the current application closes, the proxy username and password go with it. The user will have to re-authenticate to the proxy the next time they run that application.

Google Chrome and Mozilla Firefox use WinINet to get ahold of proxy settings, but they manage proxy authentication on their own. The behavior of Google Chrome and Mozilla Firefox is similar to Internet Explorer with the disable storage of passwords and credentials for network authentication option turned on.

If you’re worried about establishing a communication channel, through a proxy server, what does all of this mean to you?

If your target uses Internet Explorer (*cough*System Profiler*cough*) and this GPO is not enabled (it’s off by default)—then you likely have a free pass through the target’s configuration.

If your target uses Google Chrome, Mozilla Firefox, or the network authentication GPO is enabled, then you have a little more work to do.

Beacon and Meterpreter’s HTTP stagers use WinINet to communicate. If either of these go through a proxy server without the credentials to authenticate to it, then they will fail. Neither of these stagers know how to prompt the user for their credentials in the same way Internet Explorer does it.

Fortunately, the above problem isn’t too hard to solve. Microsoft provides an API to analyze an HTTP response for “hidden errors”. A 407 HTTP response is an example of a hidden error. The same API will also prompt the user with the appropriate dialog to get the information it needs, fix the request, and allow the application to retry the request. The magical function that does all of this is InternetErrorDlg.

In the most recent release of Cobalt Strike, I updated Beacon’s HTTP stager to use InternetErrorDlg to find and correct hidden proxy authentication errors. This little change now allows Beacon’s HTTP stager to get through authenticated proxy servers very reliably. If credentials for the proxy server are in memory, this updated stager will use them like before. If there are no credentials in memory, this updated stager will prompt the user with the same dialog Internet Explorer uses. Once the user puts in their credentials, Beacon’s HTTP stager gets a free pass to the internet.

Pretty cool.


Cobalt Strike – Innovative Offense or “just a GUI”?

June 12, 2014

In June 2012, I announced Cobalt Strike to the world. Thanks to Cobalt Strike‘s users, I build and research offensive technologies, full-time, and have done so for the past two years. In this post, I’d like to show what has come from these two years of user-funded work.

The Big Ideas

Modeling Advanced Attackers with Beacon

The Beacon payload is THE threat emulation tool in Cobalt Strike. It speaks multiple protocols, it’s asynchronous [read: covert], and it has a complement of remote access tool features. With its communication sped up, Beacon may also tunnel traffic too. Beacon is compiled as a reflective DLL, which allows Cobalt Strike to deliver it directly into memory or fire it with a Metasploit Framework attack.

Several of the “threat emulation” features in Cobalt Strike (e.g., named pipe communication) are realized through Beacon. It’s the keystone feature of this whole toolset.

Distributed Operations

A lot of folks know Armitage for its red team collaboration capability. Cobalt Strike extends this red team collaboration model to multiple attack servers. The idea is this: team servers do not communicate with each other. Instead, a Cobalt Strike client may connect to one or more team servers. When a user is connected to multiple servers, the client will pool listeners from all of the servers. This allows any user to easily pass sessions between servers. I also took care to update Cobalt Strike’s reporting engine to merge data from all of the servers into one report.

This model of operations allows a red team to have many team servers, each with different purposes (e.g., post-exploitation, attack, and persistent callbacks). Members of the red team may connect to the sub-set of servers that meet their needs. I’ve exercised this model at almost twenty events since February 2013. It scales well to large teams and it’s natural to the end-user.

What’s Next? False Flag Operations

Under development, I have a domain-specific language to let the user redefine the indicators in Beacon’s communication. This technology will let you cloak your actions to look like an actor your customer is watching for. Think of this as a False Flag capability for penetration testers. It’s enough to go from engagements that exercise security controls to engagements that exercise intelligence support to computer network defense.


Special Focus: Egress and Communication Options

DNS Communication

There are many demos and proof-of-concept tools that communicate over DNS. I wanted something weaponized. I consider a technology weaponized when it’s mature and it interoperates well with my existing attack kit. To do this, I had to build a DNS server into Cobalt Strike to support the server-side of DNS communication. I then added DNS TXT and DNS A record data channels to Cobalt Strike’s Beacon payload. Staging was a problem though. I modified Peter Van Eeckhoutte‘s DNS TXT record stager to build a DNS stager that tolerates failures and downloads a large payload over the internet. The end result? Cobalt Strike has a turn-key capability to deliver a DNS payload in an executable or user-driven attack package.

Named Pipe Communication

Several Advanced Threat payloads communicate, peer-to-peer, over named pipes (e.g., DUQU, Red October, and Uroburos). This traffic is wrapped in SMB and it blends in quite well. I opted to explore this communication channel and implemented it into Cobalt Strike’s Beacon. I’ve found named-pipe communication is a nice way to control systems that can’t reach the internet and to limit which compromised systems connect directly to my internet infrastructure.

Staging through Authenticated Proxies

Payloads in Cobalt Strike (and Metasploit) are staged. This process is brittle and it’s a weak point for the attacker. As an ongoing project, I look at ways a defense team can defeat an HTTP/S stager and try to design workarounds for it. Beacon’s HTTP stager dresses up its communication to look like Internet Explorer. This same HTTP stager now prompts the user for credentials when it encounters a proxy authentication error.

While DNS communication, named-pipe communication, and improved HTTP staging are Beacon technologies, Meterpreter benefits from these features too. With one command, you may stage and tunnel a Meterpreter session through a Beacon.

Tactical Successes

Anti-virus Evasion with Artifact Kit

Artifact Kit is my strategy to evade anti-virus. It’s a source code framework to build executable and DLL artifacts that smuggle known shellcode past anti-virus. Cobalt Strike uses these artifacts when it needs to generate an executable or DLL. Artifact Kit gives users control over this process by allowing them to load new artifacts into Cobalt Strike, if needed. Each set of artifacts recover obfuscated shellcode by performing an action that most anti-virus products won’t emulate.  If the base artifact is caught by a product, you can recompile it to change its signature. If the technique the base artifact uses doesn’t get past a product, then you have the option to use or build a base artifact with another technique.

Bypass UAC on Windows 8.1

The UAC bypass attack is an important privilege escalation option. I spent some quality time with the Metasploit Framework’s bypass UAC module and the original POC to understand its left and right bounds. I learned that this attack is “patched” on Windows 8.1 and I wanted to know why. I found the Windows 8.1 problem and a few other areas for improvement. Beacon gained a Bypass UAC attack that works on Windows 7 through the latest release of Windows 8.1.

Production-ready User-driven Attacks

Over the past two years, Cobalt Strike has gained new or updated implementations of common user-driven attacks. These attacks are popular in penetration tests because they do not rely on memory corruption and generally, they’re not patchable.

Cobalt Strike user-driven attacks include the venerable Java Signed Applet attack, the Microsoft Word and Excel macro, and the File dropper [popular in targeted attacks!].

Cobalt Strike’s applet and macro attacks inject payloads directly into memory, account for an x86 versus x64 host application, and auto-migrate the payload to protect it from the user closing the application.

VPN Pivoting

Covert VPN is my implementation of VPN pivoting. It uses libpcap to capture frames from a target’s network and relay them to a tap interface on the attacker’s system. Likewise, it captures frames from a TAP interface on the attacker system and injects them into the target’s network, also via libpcap. Covert VPN communicates over UDP, TCP, and HTTP.

Red Team Training

Since its first release, I asserted that Cobalt Strike is more than software. It’s documentation, online training, and a set of tools to replicate an advanced threat. Keeping with my commitment to this, I produced the Tradecraft course and made it available for free. Tradecraft is a 9-part course that covers how to get a foothold in a modern enterprise, conduct asynchronous and interactive post-exploitation, and abuse trust relationships to attack fully patched systems. I see tools and process as inseparable. Tradecraft is the process Cobalt Strike was built to support.


Browser Pivoting

Browser Pivoting is a man-in-the-browser attack to hijack authenticated web sessions. It uses Internet Explorer’s communication API to fulfill [and re-authenticate] requests for an attacker’s browser. This technology can hijack sessions secured with cookies, session cookies, server authentication, and client SSL certificates.

One of my friends defined my business as outsourced research and development for red teams. This is a great example of this. Some organizations use smart card technology as a two-factor authentication mechanism for their web applications. Red teams who work in these environments need a way to demonstrate risk and work, even when this technology is present. Browser Pivoting is my look at this problem.

What’s Next?

Everything on this page represents progress after Cobalt Strike’s initial release two years ago. I will continue to swing for the fences on one big idea per year. This year, my goal is help penetration testers cloak their activity to resemble another actor. Then we will have true “threat emulation”!

I will continue to build options to evade static defenses and get past tough egress restrictions. This work isn’t done yet!

In terms of the tactical successes, a lot of these are customer driven. This product has a pretty amazing user base. They won’t ask me to implement “check the box” compliance reports any time soon. Cobalt Strike’s users continue to make this work possible.


Connecting to a Metasploit RPC server on Windows is not supported

May 29, 2014

When a user launches Armitage or Cobalt Strike on Windows and presses Start MSF, they’re presented with a curious error. It states: You must connect to a team server hosted on Linux. Connecting to a Metasploit RPC server on Windows is not supported.


This error generates a lot of requests for help in various forums and I occasionally get email about it too.

Armitage and Cobalt Strike are clients designed to connect to a server. There are two options for this server. They may connect to the Metasploit Framework directly via its RPC server. Or, they may connect to a team server.

The Metasploit Framework’s RPC server is a version of the Metasploit Framework that allows third-party tools to interact with and control it. You can read about what it provides in the Metasploit API documentation.

A team server is an Armitage (and Cobalt Strike) construct that wraps the Metasploit Framework RPC server and provides additional services. I originally built the team server  to share a Meterpreter session among multiple users and to provide needed functions to use the Metasploit Remote API from a remote client.

In November 2013, I made the decision to drop Windows support for the server side of Armitage and Cobalt Strike. This means that you can not setup a team server on Windows (this was never supported) and the tools do not allow you to start the Metasploit Framework and connect to it on Windows.

You may still use Cobalt Strike and Armitage from Windows though. Start a team server on Kali Linux or one of the other supported environments. Tell Armitage or Cobalt Strike to connect to this remote team server. Everything will work fine.


Covert Lateral Movement with High-Latency C&C

April 30, 2014

High latency communication allows you to conduct operations on your target’s network, without detection, for a long time. An example of high-latency communication is a bot that phones home to an attacker’s web server to request instructions once each day.

High latency communication is common with advanced threat malware. It’s not common in penetration testing tools. I designed Cobalt Strike’s Beacon to provide penetration testers with a robust payload for high-latency communication. Today, you can conduct much of your engagement through Beacon.

In this post, I’ll show you how to abuse trust relationships to move laterally with Beacon. You will learn how to find targets with built-in Windows commands, escalate privileges, impersonate access tokens, and use the rights a token holds to run code on a remote system. I’ll show you how to carry out each of these steps from a Beacon configured with a high sleep time.


Beacon’s shell command will run a command on a host and post its output back to you. You can do a lot with this command alone. For example, to find out which domain you’re on:

shell net view /DOMAIN

To see Windows hosts on the same domain with some sort of sharing enabled, use:

shell net view /DOMAIN:domain

At this point, we have a few targets to work with. The next step is to check if the current user is a local administrator on any of these systems. To check your rights, try to access an admin-only share on a target host:

shell dir \\host\C$

If you get a directory listing, then your user is a local admin. You’re ready to get code execution.

Privilege Escalation

If your current user isn’t a local admin on a target system, then you will need to escalate your privileges to go further. To start this process, I like to use whoami /groups to find out which groups my current user is in. You can do this with the shell command too.

shell whoami /groups

If I’m living in a standard user context (a medium integrity process), but my user is a local admin on the current host—there’s an opportunity to escalate. Beacon includes its own version of the bypassuac attack that’s built for this situation. Bypass UAC elevates you from a medium integrity context to a high integrity context. The command to do this in Beacon is bypassuac.

bypassuac beacon listener

At this point, you will get a new Beacon. If all went well, this Beacon will show a * next to the username. This * is Beacon’s way to tell you that it’s running in a high integrity context. Remote Access Tools built for an XP world tend to omit this information. On a modern target, you have to know whether you’re in a high or medium integrity process.

Token Stealing

Now that we’re in a high integrity process, we can look for tokens to steal. An access token is a data structure that tracks the user’s rights and, if applicable, other information needed for single sign-on to work. There are different types of tokens, but I’d like to call your attention to impersonation and delegation tokens. An impersonation token allows a process or thread to carry out actions as the identified user on the current system. A delegation token allows a process or thread to carry out actions as the identified user on remote systems on the same domain.

We will use Beacon to steal a token from a process. Run the tasklist program to list processes on the system:

shell tasklist /v

Each process will have a user associated with it. If you see a process run by another domain user, use Beacon’s steal_token command to impersonate that token.

steal_token pid

You may now execute commands with the security context of the stolen token. Try to see if the impersonated user is a local admin on other systems within your reach. If the user is an admin elsewhere, we’re in luck and we can try to get code execution.

Generate Artifact

How do we get code execution on a remote host? Copy a file to the remote host and schedule it to run. These steps raise a question though. What do we want to copy and run? You could export an executable for Beacon that talks to your command and control server. I will caution you against this though.

As an attacker, you do not want every compromised system to call home to your command and control infrastructure on the internet. Some hosts can’t talk out to the internet. Other hosts (e.g., domain controllers) may get more attention from a network security monitoring team.

Not all Beacons have to connect to the internet. You may link Beacons together in a way that allows each Beacon to get its tasks and send output through its parent Beacon. Cobalt Strike’s Beacon uses named pipes to do this.

If you want to stay quiet, I recommend that you export a fully staged SMB Beacon and copy it to your target’s host and schedule it to run. A staged artifact is beneficial as it does not need to connect to us over the internet to download the rest of itself. Go to Attacks -> Packages -> Windows Executable (S) to export a fully staged Beacon. Choose the SMB Beacon as your Beacon type and select the type of output you would like. You may export a (staged) Beacon as a PowerShell script, DLL, executable, or Windows service executable. Press Launch and save the artifact.

File Copy

To copy a file, change Beacon’s current working directory to a folder that you can write to. If you’re a local admin in a high integrity context, try c:\windows\temp.

Use Beacon’s cd command to change the current directory:

cd c:\windows\temp

Use Beacon’s upload command to select a file from your local system and upload it to the current directory:


To copy the uploaded file to the remote system, use the shell command. This command will copy foobar.exe to c:\windows\temp on the remote host.

shell copy foobar.exe \\host\C$\windows\temp

Beacon queues its commands. If you have a high sleep time, don’t worry about typing one command at a time and waiting for output. Issue every command that you can think of. When Beacon checks in next, it will grab its tasking, execute the actions you gave it, and show the output to you.

Remote Code Execution

We need to to run foobar.exe on our target. There are many ways to do this. Here are four methods that I recommend that you learn about.

#1: WMIC

You may use wmic to run a process on a remote host. Here’s the syntax to do it:

shell wmic /node:host process call create “c:\windows\temp\foobar.exe

#2: AT

You may also schedule a program to run with at. The at command is deprecated by Windows 8. You will not be able to use this option from or against a Windows 8 target. That said, the syntax for this option is easy to remember.

First, find out what time it is on the remote system:

shell net time \\host

Next, use at to schedule foobar.exe to run sometime in the near future.

shell at \\host HH:MM c:\windows\temp\foobar.exe


Another option to run code on a target system is schtasks. The syntax for schtasks is a little more complicated, but why not:

shell schtasks /create /tn foobar /tr c:\windows\temp\foobar.exe /sc once /st 00:00
           /S host /RU System
shell schtasks /run /tn foobar /S host

You should clean up your task after it executes. Here’s the syntax to do that:

shell schtasks /F /delete /tn foobar /S host

#4: SC

A fourth option to execute a program on a remote host is to create a service and start it. You may use the sc command to do this:

shell sc \\host create foobar binpath= “c:\windows\temp\foobar.exe”
shell sc \\host start foobar

The sc command requires an executable that responds to Service Control Manager commands. If you do not provide such an executable, your program will run, and then immediately exit. Cobalt Strike’s dialog to generate a staged executable gives you the option to generate a Service Executable. Make sure you pay attention to this detail.

Here’s the syntax to delete your service after it runs:

shell sc \\host delete foobar

Establish Control

Once an SMB Beacon is run on a remote system, you may gain control of it with Beacon’s link command. From Beacon, use:

link host

This command will instruct the current Beacon to link to the remote Beacon over the SMB protocol. You will see a new Beacon show up in the Beacon console with the parent Beacon listed as its external address. From here, you may repeat this entire process. Look for tokens, impersonate them, see where you’re an administrator, and try to take those systems. That’s it.

Part 7 of Cobalt Strike’s Tradecraft course covers lateral movement as well.


Cobalt Strike 1.49 – HTTP Proxy Authentication? No Problem.

April 23, 2014

I spend a lot of time on the road in March and April—using my tools. During these months, I take careful notes of the usability issues I’d like to address and small tweaks that would make life better for Cobalt Strike’s hacker corps.

Today’s Cobalt Strike release is the result of notes and my first-hand experience from five different exercises. There’s a lot of great stuff here, particularly for Beacon users.

Beacon’s HTTP stager uses WinINet to communicate [even before this update]. This has a benefit. The HTTP stager will authenticate to a proxy server when stored credentials are available. Sometimes, the current process does not know the credentials needed to get through a web proxy server. Beacon’s HTTP stager now detects this situation and prompts the user for credentials. The dialog is the same one Internet Explorer uses. Between Beacon’s new HTTP stager and DNS stager—you now have the tools to defeat most tough egress restrictions.

Cobalt Strike’s Staged Executable Generator now gives you options to output Beacon as a raw blob of position independent shellcode. You also have the option to output a fully-staged Beacon as a PowerShell script too.

You may now assign a tiny note/label to each Beacon. This label is immediately visible to your teammates too. This makes Beacon management much easier.

13.19.43 Beacons

Beacon’s process injection code now falls back to an alternate method when CreateRemoteThread fails. This means you’ll have an easier time injecting into explorer.exe and other processes across logon sessions.

Beacon’s session spawning now creates patsy processes in a suspended state. This allows you to use spawnto with almost any program you can think of. And hurrah! Beacon no longer uses notepad.exe as the default process to spawn and inject code into.

These changes are the highlights. For a full accounting of changes, give the Release Notes a read. Licensed Cobalt Strike users may use the update program to get the latest. A 21-day trial is available too.


Listeners: Cobalt Strike’s Glue Feature

March 27, 2014

Listeners are Cobalt Strike’s abstraction in front of the Metasploit Framework’s payload handlers. A handler is the exploit/multi/handler module. This module sets up a server that waits for a payload on a compromised system to connect to you.


Cobalt Strike’s listeners feature is a way to configure handlers that start when Cobalt Strike starts. A listener consists of a user-defined name, a payload, a host, a port, and whether or not you would like the payload to automatically migrate.

Many Cobalt Strike features let you choose a listener to quickly configure a payload. When you take advantage of this, you’re certain that the information is correct. Here are the ways you can use listeners:

  • You can quickly configure a Metasploit Framework exploit to use a pre-defined listener. Double-click the PAYLOAD option to choose one of your listeners. This action will populate the module’s options for you.
  • When you task a Cobalt Strike Beacon to spawn a session—you get to choose a listener from any of the Cobalt Strike team servers you’re connected to. This is an incredibly seamless way to pass shells to different team servers.
  • All Cobalt Strike social engineering packages allow you to choose a listener to pair with the attack.


Listeners are an abstraction. They’re the one-stop shop to set up handlers in Cobalt Strike. Given that this convention works well—Cobalt Strike’s Listener Management feature becomes the place to hook in Cobalt Strike-specific stuff.

Beacon is a good example of this. To Cobalt Strike users–Beacon feels like a first-class payload. It’s not an external tool or something that is awkwardly integrated. Beacon doesn’t exist in the Metasploit Framework though. It’s a Cobalt Strike payload that stages as the windows/dllinject/reverse_http payload when used with a Metasploit Framework feature. Listeners made it possible for me to define Beacon as a payload alongside Meterpreter’s various options.

Listeners are also my opportunity to expose some hidden functionality in the Metasploit Framework to my users. For example, not many people know that it’s possible to tunnel reverse_tcp payloads through a Meterpreter session.  Cobalt Strike helps you do this through pivot listeners.

A Pivot Listener is a listener that is set up to route back to you through a Meterpreter session. This is really an incredible feature. A lot of privilege escalation actions will spawn a new session. If I care at all about stealth—I want to make as few outbound connections from a compromised system as possible. With a Pivot Listener—I can generate Cobalt Strike EXEs and DLLs that tunnel through an existing session. This is very powerful. Once the listener is set up, I just use it without having to recall the details behind it.


Cobalt Strike’s Listeners also setup stage encoding for Windows payloads as well. Once you get code execution, the stub of code sent with the attack downloads the rest of the payload to inject into memory. This transaction is easy to catch as the downloaded payload is a DLL with a little bootstrap code prepended to it. For nearly a year now, Cobalt Strike’s Listeners have helped users avoid detection by setting up stage encoding for them.


Listeners also make it possible to enjoy a wider variety of Metasploit Framework payloads. For example, if I want to do callbacks over IPv6, I can configure an IPv6 listener and provide it the right LHOST once. I don’t have to remember my IPv6 address every time I set LHOST. Cobalt Strike’s Listener keeps track of this information for me.

Listeners make Cobalt Strike redirector friendly too. A redirector is a server with iptables rules or port forwarding software that sends traffic to your attack server. Once you have redirector infrastructure setup—you can create Cobalt Strike listeners that call home to it. Redirectors are a way to obfuscate the true location of your attack server. You may assign a different redirector to each listener you create. After this initial setup, it just works. Cobalt Strike’s Beacon payload may also stage through a redirector and call home through multiple redirectors.

One danger with an abstraction, like Cobalt Strike’s listeners, is that they hide some output and information from you. Cobalt Strike mitigates this by making it possible for you to watch the output of any Metasploit Framework handler managed this way. Go to Cobalt Strike -> Listeners, right-click the listener, and choose Debug. Cobalt Strike will stop the handler and start it again in its own console. Through this console, you may see all output associated with that handler.

Listeners are the glue that holds Cobalt Strike together. They allow seamless cooperation between team servers, use of redirectors, and they save you and your team the trouble of remembering the configuration information for these shared assets.

If you’d like to learn more about Cobalt Strike’s listeners, review the documentation or watch Part 3 of the Tradecraft course.


Cobalt Strike 03.13.14 – NECCDC Edition

March 13, 2014

I’m writing this from a New Hampshire Bed and Breakfast where I’ve apparently received the Jacuzzi suite. I’m here for a romantic weekend running psexec and managing Beacons inside of student networks for the North East Collegiate Cyber Defense Competition event. This is my seventh year with this event.

I made a lot of development progress early into my recent development cycle and I like to show up with my latest stuff, so everyone gets a Cobalt Strike update today. This release polishes the Cobalt Strike user experience and it adds a few features CCDC red teams will find very useful.

Export Staged Beacon Artifacts

You may now export an executable, service executable, 32-bit DLL, or 64-bit DLL with a fully staged Beacon. These fully staged artifacts are generated by Cobalt Strike’s Artifact Kit for anti-virus evasion.

This feature is a big win for stealthy lateral movement. Now you can copy SMB Beacon [the whole thing!] to a target host, schedule it to run, and link to it from another Beacon. This allows you to gain control of a system and control it over the SMB protocol only. You can do these things without ever lowering Beacon’s sleep time to something that could get caught.

A complete artifact is also an ideal candidate for persistence. Beacon is designed to call home to multiple sites. If one address doesn’t work, Beacon will try another one. If there’s an error, Beacon gracefully recovers from it and tries again. These are traits you want in a persistent agent.

Beacons don’t always have to call out though. Export an SMB Beacon and persist it on a host. So long as port 445 is open, you can link to that Beacon over an SMB named pipe. SMB Beacon is the perfect bind backdoor for Windows.


Beacon now includes its own timestomp command. This command will match the Modified, Accessed, and Created times for one file to another.

Cleaning House

This release also benefits from a thorough scrub of Cobalt Strike’s codebase. This cleansing changes how Cobalt Strike waits for results when it calls into the team server or requests information from the user. Now, in most cases, these actions will not block any other actions from taking place. The result is a snappier and more robust Cobalt Strike client. You will also notice that Cobalt Strike is better with large file transfers to and from the team server and that it also responds to disconnections better.

If you’re a Cobalt Strike license holder, use the built-in update program to get the latest.  A 21 day trial of Cobalt Strike is also available.


Cobalt Strike 02.27.14 – Details Matter

February 27, 2014

Cobalt Strike 1.48 (02.27.14) is now available. This release is the byproduct of a very intense development cycle. The theme of this release is: details matter. Read on for a sense of what I mean by this.

Pivot Listeners

This Cobalt Strike update introduces pivot listeners. A pivot listener is a handler for a  reverse payload that stages and tunnels through an existing Meterpreter session.

Because Cobalt Strike is built for targeted attacks, I always assume that my users are external to their target’s network. One way to keep a low profile is to limit how many connections you make to your command and control infrastructure. Unfortunately, a lot of post-exploitation actions you take will require a new session. Privilege escalation and lateral movement are prime examples.

A pivot listener allows you to spawn sessions through an existing Meterpreter session. Pivot listeners work anywhere you would use a normal Cobalt Strike listener. This gives you a way to limit your post-exploitation activity to one channel out of your target’s network.


Stager Tweaks

A topic that is near and dear to my heart is egress filtering. Cobalt Strike now uses a custom HTTP stager to deliver its Beacon. This custom stager takes steps to disguise itself as Internet Explorer. The native Metasploit Framework stager sends a blank User-Agent which is an opportunity for a proxy server to stop you or a defense team to catch you.

If you can get Beacon on a system, you’re just one step away from Meterpreter. Type ‘meterpreter’ and Beacon will act as a tunnel to stage and communicate with your session. Beacon’s ‘meterpreter’ command now uses a custom stager that avoids a popup from the Windows firewall.

Token Stealing and Privilege Escalation

This release also adds token stealing to Cobalt Strike’s Beacon payload. The usual repertoire of getuid, rev2self, and steal_token are present. The ability to steal tokens is key for lateral movement.

Before you can steal tokens, you need the ability to escalate your privileges. I’ve added getsystem to go from an administrator user to SYSTEM on a box, through Beacon.

UAC Bypass

Speaking of privilege escalation, this release adds bypassuac to Beacon as well. This command spawns a session in a process with elevated rights. This privilege escalation technique takes advantage of a loophole in the default UAC settings on Windows 7 and later. This command will not work if the current user is not in the Administrators group or if UAC is set to its highest setting.

The UAC Bypass attack has several steps to it. The last step is to get code execution through DLL search order hijacking of a program that automatically elevates itself to full rights. The public versions of this attack rely on a hijacking opportunity that works in Windows 7 only. Beacon’s UAC bypass uses different opportunities for Windows 7 and Windows 8.

Beacon’s UAC Bypass is also evasion friendly. The one DLL it drops to disk is made by Cobalt Strike’s Artifact Kit. All other UAC bypass logic happens in memory. And yes, the UAC Bypass cleans up after itself.

Details matter

Tools that succeed in production have to pay attention to details. Sometimes, new research makes it into Cobalt Strike. Other times, the work in this product is on the details. The small stuff that makes a big difference when you’re on an engagement.

You can grab a 21-day trial of Cobalt Strike. Licensed users should use the update program to get the latest. Consult the release notes file for a full list of changes.


What took so long? (A little product philosophy)

February 20, 2014

Cobalt Strike’s  January 8, 2014 release generates executables that evade many anti-virus products. This is probably one of the most requested features for Cobalt Strike.

Given the demand–why did it take so long for me to do something about it?

One-off anti-virus evasion is trivial. In 2012, I wrote a one-off stager for Windows Meterpreter. Few products caught it then. Few catch it now. Why? Because very few people use it. There’s no reason for an anti-virus vendor to write signatures against it.

When I use Cobalt Strike–I always bring a collection of private scripts to generate artifacts when I need them. I’ve never had a problem with anti-virus. Many of my users have their own process to generate artifacts. Good stuff is available publicly too. For example, Veil is a fantastic artifact generator.

If anti-virus evasion is so trivial–why didn’t I build new artifacts into Cobalt Strike until now?

Long-term Utility

Every feature I build has to have long-term utility. I want tools that will help get into networks and evade defenses five to ten years from now.

If I built short-term features, my work would hit a local optima that I may not escape. Over time, each improvement would serve only to balance the faded utility of the old things next to it. Without maintenance, a product with short-term features would decay until it’s not useful.

Long-term focus has the opposite benefit. If I do my job right, each release is more useful to my users than any previous release. New features interact well with existing ones and all features become more useful. This sounds like common sense… but it’s not a natural course for software.

Imagine a toolset built around locating known service vulnerabilities and launching remote exploits. Seven years ago–this hypothetical toolset could rule the world. Today? This toolset’s utility would diminish with each day as it’s built for yesterday’s attack surface. Even with patchwork improvements, the best days for this kit are in the past. A few client-side attacks next to a rusty Windows 2003 rootkit creates an image of a dilapidated amusement park with one ride that still works. The world does change and sometimes these changes will obsolete what was otherwise good. At this point, it’s time to reinvent. I feel this is where we are with penetration testing tools.

Expected Life

Every time I build something–I ask, how does this give my users and I an advantage today, tomorrow, and next year? Or better put–what is the expected life of this capability?

On the offense side–a lot of our technology has a comically short expected life. Exploits are a good example of this. Once the vulnerability an exploit targets is patched–the clock starts ticking. Every day that exploit loses utility as fewer opportunities will exist to use it. I don’t build exploits and it’s not a focus of my product. A single exploit is not a long-term advantage. A team or community of exploit developers? They’re a long-term advantage. I leverage the great work in the Metasploit Framework for this. But, in terms of value add, I have to find other places to provide a long-term advantage.

What types of technologies provide a long-term advantage? Reconnaissance technologies are a long-term advantage. NMap will probably have use in the hacker’s toolbag for, at least, our lifetime. A reconnaissance tool is a life extender for your existing kit of attack options. A three-year old Internet Explorer exploit isn’t interesting—except when a reconnaissance technology helps you realize that your target is vulnerable to it. This is why I put so much effort into Cobalt Strike’s System Profiler. The System Profiler helps my users squeeze more use out of the client-side exploits in the Metasploit Framework.

Can you think of other technologies that provide a long-term advantage? Remote Administration Payloads. Meterpreter is almost ten years old. Even though it’s gained features—the Windows implementation is the same core that Skape put together a long time ago. Any effort to make post-exploitation better will pay dividends to users many years from now. So long as there’s a way to fire a payload and get it on a system–it has utility. Well, almost. There’s one pain point to this.

The Big Hunt

On the offensive side–we are in the middle of a shift. My ass was kicked by it three years ago. If you haven’t had your ass kicked by this yet–it’s coming, I promise. What’s this offensive ass kicking shift? It’s pro-active network security monitoring as a professional focus and the people who are getting good at it. Our tools are not ready for this. Our tools assume we have the freedom to get out of a network and communicate as much as we like through one channel. These assumptions hold in some cases, but they break in high security environments. What’s the next move? I’ll give you mine.

I’ve built a multi-protocol payload with ways to control its chattiness, flexibility to use redirectors, peer-to-peer communication to limit my egress points, and in a pinch–the ability to tunnel other tools through it. Why did I do this? If I can’t get out of a network with my existing tools–I’m out of the game. If I can’t maintain a stable lifeline into my target’s network–I’m out of the game. If all of my compromised systems phone home to one system–I’m easy to spot and take out of the game.

We had a free pass to use a compromised network without contest. This is coming to an end. Sophisticated attackers evolved their communication methods years ago. We need tools that provide real stealth if we’re going to continue to claim to represent a credible threat.

I work on stealth communication with Beacon, because I see a long-term benefit to this work. I see Browser Pivoting as a technique with a long-term benefit as well. Two-factor authentication hit an adoption tipping point last year and it will disrupt our favored ways to get at data and demonstrate risk. Browser Pivoting is a way to work in this new world. When I look at the offensive landscape, I see no lack of problems to solve.

Anti-virus Evasion – Revisited

What’s a problem that I didn’t touch, because of the short life expectancy of any one solution? I didn’t want to build a public artifact collection to get past anti-virus.

I remember when the US pen tester community became aware of Hyperion. Researchers from wrote a paper on a novel way to defeat any anti-virus sandbox. The technique? Encrypt a payload with a weak key and embed it into an executable with a stub of code to brute force the key. Anti-virus products would give up emulating the binary before the key was brute forced–allowing the executable to pass.

This technique is a long-term advantage. Any one of us can write our own anti-virus bypass generator that uses the Hyperion technique. So long as we keep our generator and its stub to ourselves, it will last a long time. We didn’t do this though. We took the Hyperion proof-of-concept and used it as-is without changes. What happened? Eventually anti-virus vendors wrote signatures for a stub of code in the public binary and then the technique left our minds, even though it’s still valid.

Let’s go back to the original question. Why didn’t I add anti-virus evasion artifacts until now? I didn’t work on this problem because I didn’t have a sustainable plan. I do now.

I wrote an Artifact Kit. The Artifact Kit is a simple source code framework to generate executables that smuggle payloads past anti-virus. Better, the Artifact Kit is able to build DLLs, executables, and Windows dropper executables. I expect that, in the future, Artifact Kit will also build my persistence executables as well.

I updated Cobalt Strike to use the Artifact Kit to generate executables. My psexec dialogs use it. My Windows Dropper attack uses it. I even found that the Metasploit Framework’s Firefox add-on module fired with an Artifact Kit executable becomes a nice way to get a foothold on a fully patched system. This is an example of a new feature complementing existing tools and extending their life and utility.

Artifact Kit’s techniques have a limited lifetime. The more use it gets–the more likely an analyst will spend the time to write signatures and negate the utility of the Artifact Kit. One technique isn’t sustainable. What’s the plan then?

I published the source code to Artifact Kit along with different techniques to a place my customers have access to. I also provided Cortana hooks to make Cobalt Strike use any changes that I or my customers can dream up. Now, anti-virus evasion in Cobalt Strike doesn’t hinge on one technique. It’s a strategy. As soon as one kit gets burned, swap in a new one, and magically everything in the tool that uses it will work. It took some time to think up a flexible abstraction that makes sense. I’m pretty happy with what I have now.

If you’re a developer of offensive capabilities–ask a few questions before you commit to a problem. What is the shelf-life of your solution? Is there a way to extend the life of your solution–if it runs out? And, finally, does your solution have the potential to extend the life of other capabilities? These are the questions I ask to make sure my output has the most impact possible.


Get every new post delivered to your Inbox.

Join 12,302 other followers