Archive for the ‘Cobalt Strike’ Category

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

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.

h1

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.

proxy

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.

h1

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.

h1

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.

nowindows

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.

h1

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.

Reconnaissance

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:

upload

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

#3: SCHTASKS

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.

Follow

Get every new post delivered to your Inbox.

Join 13,049 other followers