Archive for the ‘Cobalt Strike’ Category


User-driven Attacks

October 1, 2014

A user-driven attack is an attack that relies on a feature to get code execution. Most penetration testers I know rely on user-driven attacks over public memory corruption exploits. User-driven attacks are less likely to see a patch and they usually target an application in a way that works across many versions. What’s not to like?

Cobalt Strike offers several user-driven attacks. In this post, I’ll give you a quick tour of what’s available. These are my options to help you get a foothold.

Document Dropper

This attack combines a payload stager and a document into an executable. When run, this executable drops the document to disk, opens it, and silently loads your payload. This attack is low on the sophistication scale, but it’s very common in targeted attacks. To help with evasion, the final executable is made by Cobalt Strike’s Artifact Kit.

Go to Attacks -> Packages -> Windows Dropper to create this package.

Tip: Use a resource editor to change the icon of the executable, burn it to a disk, and mail it to your target. Used this way, the document dropper is an effective attack.

Firefox Add-on

This attack stands up a website that asks the user to install a Firefox add-on. If the user installs the add-on, you get code execution. Cobalt Strike relies on the Metasploit Framework’s implementation of this attack.

Go to Attacks -> Web Drive-by -> Firefox Add-on Attack to start this attack.

HTML Application

An HTML Application is a Windows program made up of HTML and VBScript/JavaScript. This package makes an HTML Application that drops an executable to disk and runs it.

Go to Attacks -> Packages -> HTML Application to create this package.

Java Signed Applet

The Java Signed Applet attack is the ms08_067_netapi of user-driven attacks. It’s so common in demonstrations that you’d think it’s the only social engineering attack out there. This attack starts a web server that hosts a Signed Java Applet. You get code execution if the user allows the applet to run. Cobalt Strike’s Applet Kit uses JNI to inject your payload into memory.

Go to Attacks -> Web Drive-by -> Signed Applet Attack to start this attack.

Tip: By default, Java 1.7u51 and later do not allow applets with self-signed certificates to run. To get the most from this attack, buy a code signing certificate. Go to Help -> Arsenal in Cobalt Strike to download the source code to the Applet Kit. Sign the applet and load the included Cortana script to make Cobalt Strike use your applet.

Microsoft Office Macro

This is my favorite attack in this bunch. This package generates a VBA macro. Embed this macro into a Word document or Excel spreadsheet and send it to your target. The user has to click Enable Content to run your macro. If they do, look out! This attack will spawn a new process and inject your shellcode into it.

Go to Attacks -> Packages -> MS Office Macro to create this package.

Why Cobalt Strike?

In this post, I took you through Cobalt Strike’s user-driven attack options. These are staple attacks that integrate well with Cobalt Strike’s existing features. What are the benefits of using Cobalt Strike to execute these attacks?

Each of these attacks can deliver Cobalt Strike’s Beacon payload. Beacon is a “low and slow” post-exploitation payload that allows you to use custom indicators. Special care went into the shellcode that stages Beacon too. The HTTP stager takes steps to get out through restrictive web proxies. You may also stage Beacon over DNS as well. A well executed attack is no good if you can’t get out of your target’s network.

Cobalt Strike provides a path for evasion. The attacks that rely on executables use Cobalt Strike’s Artifact Kit. This is a source code framework to make executables that smuggle shellcode past anti-virus products. Source code for the Applet Attack is available if you need to change it as well.

The attacks that inject shellcode into memory intelligently account for 64-bit and 32-bit applications. You won’t lose a shell because the user ran your macro in 64-bit Microsoft Word. The attacks that inject shellcode also migrate your payload right away. This protects you if the user closes the application.

A lot of thought goes into each feature in Cobalt Strike. The user-driven attacks are no exception to this.


Cobalt Strike 2.1 – I have the POWER(shell)

September 23, 2014

For a long time, I’ve wanted the ability to use PowerUp, Veil PowerView, and PowerSploit with Cobalt Strike. These are useful post-exploitation capabilities written in PowerShell.

You’d think that it’s easy to run a script during the post-exploitation phase, especially when this script is written in the native scripting environment for Windows. It’s harder than you’d expect. Existing options require one-liners that Invoke-Module a local file or grab a script from a third-party web server. This hurdle prevents non-PowerShell developers from seeing what’s possible.

During this last development cycle, I decided to work on this problem. Beacon now runs your PowerShell post-exploitation scripts. This feature does not touch disk and it does not connect to an external host or site.


Here’s how to use it:

The powershell-import command loads a PowerShell script into Beacon. This script stays in memory for the duration of the Beacon session.

Use the powershell command to invoke expressions and cmdlets that reference the contents of the imported script. You may also tab complete cmdlets from the imported script with the powershell command too.

This video demonstrates privilege escalation with PowerUp and Invoke-Mimikatz with PowerSploit. All of this happens without leaving Beacon:

A lot of care went into designing this feature for its post-exploitation use case. Expressions run, in the background, for as long as necessary. Each time Beacon checks in, it will grab output from each PowerShell script that’s still running.

For the non-PowerShell developers reading this, welcome to a new world of post-exploitation. You’ll feel like a giddy kid in a candy store as you browse through Github and see the easy-to-use features available to you now.

PowerShell developers, there’s something here for you too. You no longer need to design post-exploitation capabilities that bundle their own communication and delivery methods. You can just load your favorite tools and use Beacon to drive them.

Covert VPN Revamp

While PowerShell integration is the headline feature, Cobalt Strike 2.1 has a lot of other goodies. The Covert VPN feature had a good deal of maintenance. The VPN client is now a Reflective DLL which makes deployment much smoother. Covert VPN also gained a TCP (Bind) data channel to tunnel frames through meterpreter.

HTML Application Attack

Cobalt Strike 2.1 also gains the HTML Application User-driven attack. I don’t think this is going to change anyone’s life, but you can never have too many options to get a foothold in a target network. This package generates an HTML Application that drops and runs an executable. I opted to tie this attack to an executable as this gives you flexibility to drop a silent executable, a document dropper executable, or something else.

Malleable SSL

This release also builds on the Malleable C2 feature added in Cobalt Strike 2.0. You may now specify values for the self-signed SSL certificate Beacon’s web server uses. This is an opportunity to introduce indicators that mimic SSL-enabled remote access tools.

There’s a lot more in this release. You’ll want to consult the Release Notes for the full picture. As usual, a 21-day trial is available at the Cobalt Strike sites. Licensed users may use the built-in update program to get the latest.


Evolution of a Modern Hacking Payload

August 26, 2014

One of the most important features in Cobalt Strike is its Beacon payload. This is my capability to model advanced attackers. In this post, I’d like to share my insights and reasons for the design decisions I made. If you’re a Cobalt Strike user, this post will help you reason about Beacon and fit it into your tradecraft.

From Raven to Beacon

I built Raven, an asynchronous persistent agent, for the 2012 Collegiate Cyber Defense Competition. I wanted a quiet way to hold access to compromised hosts.

Raven would connect to a web server every six minutes, request a file, and spawn a thread to execute the contents of the requested file. To task Raven, I would manually generate shellcode for a desired payload and save it to the file Raven would check for.

Later, I extended Raven to execute commands, change its sleep time, and inject arbitrary shellcode. I compiled Raven into a reflective DLL and built a user interface to generate tasks and host them on Cobalt Strike’s built-in web server. I also gave Raven a new name: Beacon.

Hybrid HTTP/DNS Communication

If you’re not familiar with Reflective DLLs, they’re significant. By compiling Beacon into a reflective DLL, I made it possible to inject the payload into memory and deliver it with a Metasploit Framework exploit.

Just before I pushed Beacon, I decided to build a variant that would use DNS. In one inspired night, I wrote Cobalt Strike’s initial DNS server. I then built the Beacon variant that would issue A record requests to check for tasks before it made a connection. I saw my DNS Beacon as an opportunity to very quietly hold access to a compromised host.

Distributed Operations

Beacon became my primary agent for persistent access to compromised systems. I noticed that I would dedicate my Cobalt Strike instance to it. When I wanted to interact with Meterpreter, I would do so from another Cobalt Strike instance. I built Cobalt Strike’s model for distributed operations to get ahead of this problem.

It’s a simple idea. Team servers have no awareness of each other. The Cobalt Strike client connects to multiple team servers and presents listeners from all of its team servers in its dialogs. This makes it trivial to task Beacon to send a session to another team server.


Cobalt Strike’s distributed operations model has shown itself as an ideal tool to organize a large red team during an exercise. The best practice is to create small cells that target each network and give each cell their own team servers. Each cell should have team servers for post-exploitation and staging. Post-exploitation servers are for noisy/interactive activity on hosts. Staging servers are where a cell holds their “low and slow” asynchronous accesses.

All cells are supported by an access management team. This team monitors health and access into target networks and works to keep these accesses alive. When a cell loses their access, an access manager connects to the cell’s staging server and passes a Beacon to it. I’ve seen Cobalt Strike provide coordination for large red teams in several exercise contexts. I realize this is a niche use case, but the fact it’s possible is quite impressive to me.

Post Exploitation

Originally, I saw Beacon as a complement to Meterpreter. I would hold access to systems with it and use Meterpreter for the heavy lifting. This model broke down on me. I saw several situations where a red operator had a Beacon on a host but they could not get or keep a Meterpreter session.

This drove a shift. I knew I would need to build a minimal set of post-exploitation tools into Beacon. It was not my intent to replace Meterpreter. I just wanted a way to work if I could not safely use an interactive agent like Meterpreter.

I decided to take advantage of Beacon’s asynchronous nature and build post-exploitation features that would benefit from it. For example, Beacon’s file download feature sends one file chunk with each check-in. Using the sleep time as a throttle, it’s possible to drip a large file out of a network without attracting attention.

DNS Command and Control

Several times, I had a Beacon on a system. I would see the A record request come in and Beacon’s check-in time would roll over. I couldn’t get Beacon to download its tasks though. I call this the child in the well situation. My compromised system would let me know it was there, but due to new egress restrictions or blocks, the Beacon couldn’t reach me.

I’ve always had interest in DNS for communication, but I did not know the best way to go about it. Initially, I thought I would build a pure DNS Beacon variant and it would always communicate over DNS. The child in the well scenario justified my interest in DNS for communication and it gave me an idea about how to do it best.

I updated the DNS Beacon to support multiple data channels. The A record response during the beacon step signals which data channel Beacon should use to download its tasks. By default, DNS Beacon uses HTTP as a data channel. When I run into a child in the well scenario, I tell Beacon to use DNS A or DNS TXT records to download its tasks.


For the sake of completeness, I built a stager to download Beacon over DNS and inject it into memory. I started with the dns_txt_query_exec module by corelancod3r to do this.

After this work, I could pair Beacon’s DNS stager with a user-driven attack and use a DNS data channel to control a compromised host–without direct communication.

I use the DNS Beacon for persistence and sometimes to evade tough egress restrictions. With a high sleep time and multiple beacon domains, DNS Beacon is hard to stop.

Communication Layer

With the DNS data channel built into Beacon, I had to revisit my post-exploitation feature set. I wanted to know that I could work even if Beacon is the only payload that can get out of a network. I decided that pivoting was the missing feature. If I could pivot through Beacon, I could do most things I would want to do on a network.

To support pivoting, I built a SOCKS proxy server into Beacon. This generic interface would allow the Metasploit Framework and third-party tools to tunnel through a Beacon. This led to a lot of wins.


I had a chance to use SOCKS pivoting in one engagement and I quickly saw a gap. There were many situations where I would want, but could not get, Meterpreter onto the pivot host. My work-around was to drop the host-based firewall and tunnel psexec with a bind payload through Beacon. This inspired Beacon’s meterpreter command.

With one command Beacon will setup a one-time use SOCKS proxy server and tunnel a Meterpreter session through it. I took care to build a bind stager that binds to localhost, to avoid interference from a host-based firewall. This feature is a big deal. It transforms Beacon into an alternate communication layer for Meterpreter and the Metasploit Framework. As Beacon gains new data channels and communication innovations, Meterpreter and the Metasploit Framework benefit from it.

Named Pipes

Beacon’s SOCKS proxy and post-exploitation tools made it suitable for most tasks. I ran into two problems. First, I found myself putting Beacon on almost all compromised systems. This is really stupid. If I make all compromised systems Beacon out to the same infrastructure with the same indicators, I’m easy to catch. Second, I had no way to put Beacon onto systems that could not reach my command and control infrastructure. I needed a solution to these problems.

I opted to abuse named pipes, an inter-process communication mechanism, for a communication channel. Fun fact: you may use named pipes for inter-process communication between hosts. This traffic is encapsulated within the SMB protocol. This channel blends in well with normal traffic.


I implemented this data channel and quickly ran into the killjoy that negates most covert communication options: I didn’t have a way to stage a Beacon over a named pipe. I created a payload listener that could stage over a reverse tcp connection. I also added a pseudo-listener to my psexec dialogs to stage SMB Beacon over a bind connection. Both solutions are awkward. A host-based firewall on the target disrupts the bind stager. Egress filters tend to negate reverse TCP payloads too. I added pivot listeners to Cobalt Strike to ease this, but a host-based firewall on the pivot host can create problems too.

Privilege Escalation and Lateral Movement

I found a solution to my woes with staged SMB Beacons. Why not deliver SMB Beacon without a stager? This makes a lot of sense for the phase of the engagement where you’re most likely to use an SMB Beacon: lateral movement.

I added an option to generate executables, DLLs, and other artifacts that contain Beacon in one file. This negated the need for an SMB stager.

I then added token stealing and privilege escalation to Beacon. I focused on the standard stuff: getsystem and bypassuac. The UAC Bypass Attack was a lot of fun to dig into. I even made Beacon’s version of this attack work against Windows 8.1.

Privilege escalation, token stealing, and SMB Beacon gave me the raw materials for covert lateral movement with Beacon. It’s simple, really. Steal a token to gain the network rights of a user. Generate an SMB Beacon artifact. Use the rights of an admin user to copy the SMB Beacon artifact to a target and run it. Link to the SMB Beacon from another Beacon to assume control of it. Better, you can do these steps from a Beacon with a high sleep time. This is how I do lateral movement now. I don’t use Metasploit’s psexec modules unless I’m in a hurry.

Malleable C2 Profiles

There’s one problem left. I use Beacon for all phases of post-exploitation. I use it as a communication layer, as a temporary placeholder, and as a persistent agent. It’s dangerous to use common indicators for each of these phases. Getting caught once could lead to the discovery of other attack infrastructure and compromised systems.

This led to several questions: Could I decouple Beacon’s network indicators from its built-in functionality? Could I provide a non-developer full control over these indicators? This thought process led to Malleable C2.

Cobalt Strike ingests Malleable C2 profiles. A C2 profile specifies what Beacon’s communication should look like. From a profile I derive how to send and receive data. If you want to evade detection, you can craft a profile that looks like something that blends in.


Malleable C2 solves the indicators problem. Now, each set of attack infrastructure gets its own profile. The Beacons for post-exploitation, staging, persistence, and other purposes do not need to look the same. Each team server can host Beacons with different profiles.

Malleable C2 also allows Beacon to look like other malware. It takes less than five minutes to write a profile. This allows for threat replication during an assessment. Use your adversary’s indicators to test your customer’s ability to analyze and attribute the attack. It’s an interesting idea.


The concepts in this blog post represent two and a half years of development and lessons learned on my part. I hope you enjoyed reading about Beacon’s journey from asynchronous placeholder for Meterpreter, to alternate communication layer, to a flexible capability to replicate advanced threats.


Use Cobalt Strike’s Beacon with Veil’s Evasion

July 24, 2014

The Veil Framework is a collection of  red team tools, focused on evading detection. The Veil Evasion project is a tool to generate artifacts that get past anti-virus. It’s worth getting to know Veil. It has a lot of capability built into it.

Cobalt Strike 2.0’s Payload Generator includes an option to output a Cobalt Strike payload in a format that’s Veil-ready. Go to Attacks -> Packages -> Payload Generator to open it. Choose your listener and set veil as the output type. Save the file it generates.


Now, go to Veil and choose the type of artifact you want to create. Veil will ask if you want to use msfvenom or supply your own shellcode. Select the option to supply your own shellcode. Paste in the contents of the veil file made by Cobalt Strike. Congratulations–you have made a Veil artifact with a Cobalt Strike payload.

Here’s a video that shows this process:

Before Cobalt Strike 2.0, there were ways to deliver Beacon with Veil. Cobalt Strike’s Beacon is compatible with the Metasploit Framework’s reverse_http and reverse_https stagers. You had the option to use the Metasploit Framework’s stagers to deliver Beacon. That said, Cobalt Strike’s Beacon has its own stagers that are not available to the Metasploit Framework. Cobalt Strike’s DNS stager will download Beacon over DNS and inject it into memory. Cobalt Strike’s HTTP/S stagers account for proxy restrictions that other HTTP/S stagers do not. This new option in Cobalt Strike’s Payload Generator lets you use these custom stagers with Veil.


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.


Get every new post delivered to your Inbox.

Join 13,176 other followers