h1

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.

distops2

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.

dnscomms2

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.

beaconpivot

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.

smbc2

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.

malleablec2

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.

Summary

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.

h1

That was a fun fire drill…

August 18, 2014

Last week saw the release of Metasploit 4.10. Those who use Armitage and Cobalt Strike noticed that neither tool worked after running msfupdate on Kali Linux. That’s resolved now. Last night, I pushed Armitage and Cobalt Strike updates to fix the database.yml not found issue AND to make both tools compatible with Metasploit 4.10’s new database scheme for credentials. The latter was not a one-day change.

In this post, I’d like to share how I manage Metasploit Framework updates, my expectations for you, and what to expect from me the next time an incompatibility arises.

The Metasploit Framework is a core dependency for Armitage and Cobalt Strike. Some of you like to update this dependency very regularly. I don’t fault you for this. Know that with each update, there’s a possibility that Armitage and Cobalt Strike could break. This doesn’t happen often, but the possibility is still there.

To protect against this, I bless a particular Metasploit version with each release of Cobalt Strike and Armitage. I document this in the Cobalt Strike release notes and Armitage change log. This is the version of the Metasploit Framework that I QA’d Cobalt Strike against and certify as functional. I don’t always certify the latest version of the Metasploit Framework either. Sometimes, I find a framework bug that I consider a show stopper. At those times, I dig to find out which commit caused that bug. I report it to the Metasploit Framework team. I then QA an older version of the Metasploit Framework and certify my tools against it.

In general, if you use Cobalt Strike, you should use the version of the Metasploit Framework that I last blessed. This will help you avoid surprises. The quick-msf-setup script included with Cobalt Strike sets up an environment that went through my QA process.

Kali Linux users are a special case. Kali Linux users update the framework with msfupdate. This pulls the latest stable build of the Metasploit Framework blessed by Rapid7. Generally, this isn’t a problem and these updates work great. Last week was an exception.

If a Metasploit update impacts Cobalt Strike in a big way, I will communicate with you as soon as I know about it. My vehicle to do this is the Cobalt Strike Technical Notes mailing list [signup at the top]. I published a note about Metasploit 4.10 to the list on Thursday. I also announced my 4.10-compatible update to this list today. If you want to hear from me, I recommend that you sign up for that list.

If you’re an Armitage user, know this: I keep Armitage and Cobalt Strike’s codebases in sync. I have a good process to do this. If there’s a Metasploit change that affects both tools, I will update both tools at the same time. The latest Armitage version works with Metasploit 4.10 as well. The package is in Kali Linux now. Use apt-get update to get it.

h1

Puttering my Panda and other Threat Replication Case Studies

August 14, 2014

Cobalt Strike 2.0 introduced Malleable C2, a technology to redefine network indicators in the Beacon payload. What does this mean for you? It means you can closely emulate an actor and test intrusion response during a penetration test.

In this blog post, I’ll take you through three threat replication case studies with Cobalt Strike. In each case study, we will emulate the attacker’s method to get in, we will use a C2 profile that matches their malware, and we will analyze what this activity looks like in Snort and Wireshark.

Putter Panda

Putter Panda is an actor described by a June 2014 Intelligence Report from CrowdStrike. In this video, we replicate Putter Panda’s HTTP CLIENT malware and use a Document Dropper attack to deliver it.

String of Paerls

String of Paerls is an intrusion set described by Sourcefire’s Cisco’s VRT. In this video, we replicate the actor’s C2 with Beacon and use a macro embedded in a Word document to attack a target. We also reproduce the attacker’s phish as well.

Energetic Bear / Crouching Yeti / Dragonfly

This actor, known by many names, allegedly targets the energy sector. The best information on this actor came from pastebin.com without a slick PDF or PR team to back it up. In this video, we replicate this actor’s havex trojan with Beacon and use a Java drive-by exploit to attack a target.

With the right technologies, threat replication isn’t hard. Read about and understand the actor’s tradecraft. Craft a profile that uses the actor’s indicators. Launch an attack and carry out your assessment. Threat Replication is a way to exercise intrusion response and see how well a security program stands up to these actors.

h1

Introducing Morning Catch – A Phishing Paradise

August 6, 2014

Morning Catch is a VMware virtual machine, similar to Metasploitable, to demonstrate and teach about targeted client-side attacks and post-exploitation.

On this virtual machine, you will find: a website for a fictitious seafood company, self-contained email infrastructure to receive phishes, and two desktop environments. One desktop environment is a vulnerable Linux client-side attack surface. The other is a vulnerable Windows client-side attack surface.

Morning Catch uses a bleeding edge version of WINE to run a few vulnerable Windows applications AND experiment with post-exploitation tools in a fun and freely re-distributable environment.

You can download it via this torrent.

Login Screen

Your use of Morning Catch starts with the login screen.

Boyd Jenius is the Systems Administrator and his password is ‘password’. Login as Boyd to get to the vulnerable Linux desktop.

Richard Bourne is Morning Catch’s CEO and his password is also ‘password’. Login as Richard to get to the vulnerable Windows desktop.

You can also RDP into the Morning Catch environment.

logon

Windows Desktop

Richard’s desktop includes the Windows’ versions of Firefox, Thunderbird, Java, and putty. Open up Thunderbird to check Richard’s email.

You can send a phish to him too. This VM includes a mail server to receive email for users at the morningcatch.ph domain. Open up a terminal and find out the IP address of the VM. Make sure you relay messages through this server. Use [email protected] as the address.

Are you looking for some attacks to try? Here are a few staples:

Morning Catch’s WINE environment runs post-exploitation payloads, to include Windows Meterpreter and Beacon, without too much trouble.

theattack

Linux Desktop

Boyd’s desktop is the vulnerable Linux attack surface. Boyd has the Linux versions of Firefox, Java, and Thunderbird. Boyd also has an SSH key for the Metasploitable 2 virtual machine. Try to ssh to Metasploitable 2 as root and see what happens.

Webmail

Morning Catch also includes RoundCube webmail for all of its users. Use this as a target to clone and harvest passwords from.

roundcube

Hopes and Dreams

Morning Catch isn’t a replacement for a vulnerable Windows lab. It’s a safe and freely redistributable target to experiment with phishing and client-side attacks. It’s my hope that this environment will help more people experiment with and understand these attacks better.

Are you in Las Vegas for BlackHat USA or DEF CON? Stop by the Black Hat Arsenal on Wednesday at 10am for a demo of this new environment and a Morning Catch sticker. I’m also giving away DVDs with a revised Cobalt Strike pen testing lab that uses Morning Catch. Find me at the Cobalt Strike kiosk in the Innovation City portion of the Black Hat USA Exhibitor Hall. I will also give away these DVDs at the Cobalt Strike table in the DEF CON vendor area.

h1

Pass-the-Golden-Ticket with Cobalt Strike’s Beacon

July 30, 2014

Back in May, I wrote up some impressions about Meterpreter’s Kiwi extension. It’s Mimikatz 2.0, complete with its ability to generate a Kerberos “Golden Ticket” with domain-admin rights offline.

I’ve had a very positive experience with this capability since May. My best practice is to create a Golden Ticket catalog. When you capture a domain controller, get the krbtgt hash, and store it in this catalog. Keep this catalog for the duration of the engagement.

Golden Ticket Catalog

= Network Name =
1. DOMAIN NAME
2. Domain Administrator User
3. DOMAIN SID
4. krbtgt hash

If someone cleans you out of their systems: just phish another user, use the catalog information to generate a ticket, apply the ticket, and you’re right back at domain admin. It’s nice. The Golden Ticket capability really is a “persistent” attacker’s dream.

This assumes that the network owners don’t follow steps to re-roll the krbtgt user’s password. I suspect this will become part of a post-attack cleanup process, but it’ll take time for this practice to disseminate.

I recommend that you keep a catalog of ticket information over a collection of pre-made tickets. Here’s why: You may create a ticket for a user. If that account gets disabled, the ticket will no longer work. If you end up in this situation–use the net group command to query for the new domain admins and update your catalog accordingly.

To apply a self-generated Kerberos ticket to my current session: I have to either drop something to disk (mimikatz 2.0) or I have to switch to interactive command and control with Meterpreter. Those who’ve worked with me know that I dislike interactive C2. It has its place, but it’s also an opportunity to attract attention from a good network defense team. I’m also not a fan of touching disk–unless I really have to.

So, what does a hacker do when caught between two unlikeable choices? Make a third.

I’ve added support for self-generated Kerberos tickets to Cobalt Strike’s Beacon. Now, you may inject a Golden Ticket into a Beacon session and use it for lateral movement. This is a natural marriage.

Beacon’s lateral movement workflow requires its user to generate an artifact, copy it to a target host, and schedule it to run. I’ve built a minimal set of tools into Beacon (e.g., privilege escalation, token stealing, and now ticket injection) to support this. The rest of these steps happen using native tools on the target’s system. I’m a big fan of doing lateral movement with native tools as it’s less likely to look like hacker activity.

Seriously, if I have to answer for one more service named XtAx754A running a malicious ApacheBench–I’m going to scream!

Here’s a video that shows pass-the-ticket with Cobalt Strike’s Beacon:

If you’re headed to Las Vegas for BlackHat USA or DEF CON–you have an opportunity to hear more on Kerberos abuse at both conferences. Benjamin Delpy and Alva “Skip” Duckwall will deliver Abusing Microsoft Kerberos: Sorry You Guys Don’t Get It at BlackHat USA. Chris Campbell will deliver The Secret Life of KRBTGT at DEF CON. I expect that these talks will give this subject the authoritative treatment and depth it deserves. Be sure to check them out.

h1

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.

generator

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.

h1

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" "http://www.google.com";
        header "Pragma" "no-cache";
        header "Cache-Control" "no-cache";
        metadata {
            netbios;
            append "-.jpg";
            uri-append;
        }
    }

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

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:

etumbot

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 {
            netbios;
            append "-.jpg";
            uri-append;
        }

These lines define how to transform and store metadata:

transform

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

recover

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.

Follow

Get every new post delivered to your Inbox.

Join 12,809 other followers