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.

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

The Access Management Team [Shell Sherpas]

June 18, 2014

When I participate in an exercise, with multiple target networks and a large red team, I favor splitting the team up into cells. Each cell owns a target network and is responsible for any objectives that must occur in that target network. These cells are supported by an access management team.

The access management team is a global support role and it’s the only team that touches all of the networks. Access managers offer red cells stable access to key assets in their target’s network. This enables on-going post-exploitation. This is their job.

I refer to access managers as shell sherpas, because they protect and herd shells.

In this post, I’d like to offer details on what an access management team does.

Payload Configuration

An access management team has to configure payloads that will walk through whatever static defenses are in play. They take a guess at all of the things the available payloads do, they reason about things that look strange on the wire, and they try to figure out how to adapt the available tools to get around these things.

Some target networks will not require this support. Others will. I see advanced payload configuration (and development) as a specialized skill, one that’s rarely co-equally available to all cells.

[I'm working to make payload modification accessible to non-developers though. I have a prototype language that offers fine-grained control over the indicators and behaviors of my Beacon payload. This will allow access managers to creatively bypass content filters, design communication schemes that blend in with the target's environment, and exercise a blue team's attribution process by replicating known malware.]

Manage Callback Infrastructure

Once we have a way out of a network and past static defenses, our second task is to make sure we have survivable communication. This involves diversifying our access and making sure each payload calls back to multiple hosts. If some of our hosts get blocked, it’s nice to know our access can still survive. Better, it’s best to avoid drawing attention to our access where possible. For this, we rely a lot on low and slow beaconing over DNS to maintain a lifeline to a host when no one is using it. As an access management team, we usually setup and manage this callback infrastructure.

Survivable Access

Third, we have to make sure that our payloads live in processes that are survivable. If we know that a defense team is good at host-based anomaly detection, we have to gear up to play in this space. Once we have survivable communication, our next priority is to find a process we can live inside of without drawing too much attention. notepad.exe is not the best option.

Survivable access is an interesting problem and the best answers to it are not always obvious. There’s a tendency to want malware that can survive any scrutiny and stay on any host no matter what. When I wear my access manager hat, I know I don’t have this magical malware. We get creative and think about other ways to survive in a network. We don’t need to survive on each host. We just need a way to regain access to key hosts at will.

On-disk Persistence

Fourth, we have the opportunity to worry about on-disk persistence and how to survive a reboot. This is its own can of worms though. Let’s say we land a user-level access. What do we do with it? We could stick an executable in a startup folder for the current user or schedule a process to kick off when the user is idle. If it’s an exercise, we’re probably dealing with application white-listing, so that won’t work. We could try to schedule a task with a PowerShell one-liner to avoid dropping an artifact. That might work, in some cases. Or… we could try to escalate privileges on the systems we land on. If these systems are a newer patch level of Windows 7 and there is little evidence the system is lived in (e.g., no installed software with configuration issues); our chances to escalate, without 0-day, are probably nil. We can try though. If we do escalate privileges somehow, then we have more options to fortify and secure access on the host.

I’ve participated in a number of exercises, both with and without an access management team concept. The access management team is the keystone of a large-scale red team operation. An access management team takes on tasks that are easy to execute on all networks at once, saving each cell this extra work. The access management team also serves as a clearing house for solutions to problems other teams had to solve. An access management team, given their control of long-haul infrastructure, is also a tool to provide red team leadership a sense of target health/difficulty across the board.

Tradecraft, part 9 discusses red team operations with Cobalt Strike and how a shell sherpa would fit into a team construct.

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

The Beachhead

June 5, 2014

I see egress as one of the biggest pains in the offensive space. If your target has zero egress controls—don’t worry about anything I have to say here. If you’re up against a harder target, read on—I think I’m close to cracking this problem.

You need different payloads for different phases of your engagement. I wrote Beacon for the beginning of the assessment. The time when you have a beachhead, but not much else. This is the most vulnerable time for an attacker. If you’re caught here, you have nothing to fall back on. You’re back at the beginning. If you can fortify your access and spread to other systems, you stand a fighting chance to make the network yours.

Beacon is an asynchronous payload that’s designed to call home to multiple hosts. I use asynchronous command and control because it’s harder to detect. Asynchronous command and control means your payload acts like a bot. It phones home every so often, requests tasks, and then goes back to sleep. I phone home to multiple hosts because this is resilient. If one of my callback hosts gets caught, I still have a fighting chance to keep my access.

beachhead

Much like Meterpreter, Beacon is a staged payload. This makes weaponization easier. Stagers are small and there are well set patterns to integrate stagers with different client-side exploits and user driven social engineering packages. The downside of stagers is that they’re fragile. They’re usually written in hand-optimized assembly and they’re optimized for a small size above all else.

The staging process is a vulnerable point for an attacker. I pay attention to this. If I can’t stage my Beacon payload, I’m not going to get very far. Beacon has a resilient DNS TXT record stager. This stager is designed to detect failure and recover from it. The end result is a reliable way to download a payload over DNS and inject it into memory.

Beacon also has a custom HTTP stager. This stager pays attention to the details that I warn about. This stager makes its requests look like they came from Internet Explorer. This is important as most proxy servers have a feature to whitelist which browsers are allowed out. A blank User-Agent doesn’t cut it. Beacon and Meterpreter are both proxy aware. These payloads use WinINet to communicate. This API provides transparent NTLM authentication and it pulls its proxy settings from Internet Explorer.

Automatic NTLM authentication doesn’t do much good against a proxy server that requires something other than domain credentials to get out. Beacon’s HTTP stager detects a proxy authentication error and prompts the user for credentials when it can’t get out. This prompt is the same one Internet Explorer uses. Once the user types their credentials once, the current process is good to egress until it dies.

I worry about networks with tough egress restrictions. It’s not unheard of to isolate workstations or key servers from the internet altogether. Their only channels out are through a proxy server or their local DNS server. Worse, sometimes systems are isolated from the DNS system altogether. They rely on their proxy server to resolve hostnames for them. In these cases, the only direct way out is the proxy server. Eep!

The Beacon stagers I’ve described are enough to get out of a network via DNS or through a tough proxy server. Still, counter-measures exist to defeat my technologies. A proxy server may only allow an application to visit sites that are in a white list. Or, the proxy server may require the user to respond to some sort of challenge before they can access an unknown site. Let’s assume neither of these things are in play.

At this point, we have a foothold, a beacon in our target’s network that phones home over HTTP or DNS. Let’s assume this Beacon is phoning home over DNS.

I’ve built a toolset into Beacon to escalate privileges, steal tokens, and execute commands. These tools allow you to grab an access token and use it to copy a file to another system and schedule it to run. I’ve even built a peer-to-peer Beacon that uses named pipes to communicate and egress through a parent Beacon. You can spread laterally with Beacon without resorting to interactive communication or worrying about egress with the other hosts.

Eventually, you will have multiple equities in your target’s network. At that point, it’s time for some heavy post exploitation. Right now, we’re communicating over DNS and named pipes because we continue to live with tough egress restrictions. How do we get our tools into the target’s network?

Pick a system that you’ve compromised. Pick one that isn’t patient zero (your beachhead). Look to see which processes are running. Do you see a 32-bit Internet Explorer process or a 32-bit Java Updater? Use Beacon’s inject command to inject an HTTP Beacon into that process.

When you inject an HTTP Beacon into a process, the user will see a prompt for the username and password of their restrictive proxy. This assumes a proxy authentication failure happens in the first place. You’re dealing with some strong egress restrictions if this is the case.

The prompt will come from the application that you injected into. If it’s Internet Explorer, the payload should inherit the user’s cached proxy credentials. If it’s the Java Updater, the user will see that the Java Updater is prompting them. Pretty sneaky, right?

When you inject an HTTP Beacon, take care to inject one from another team server. Cobalt Strike is designed to connect to multiple servers and manage them from one client. There’s a reason for this. You want different sets of command and control infrastructure for different phases of your engagement. When you’re ready to do noisy post-exploitation, you want to spawn accesses to alternate infrastructure. If the alternate infrastructure gets caught, it doesn’t blow the access you’ve worked to gain in your target’s network.

Once we get an HTTP Beacon on an alternate team server, we’re ready for post-exploitation. Since we’re here to do heavy lifting, we want to bring Meterpreter and other tools into this environment. Speed up Beacon’s communication with the command sleep 0. Then, request a meterpreter session, tunneled through Beacon: type meterpreter and press enter. When the Beacon checks in next, its communication will speed up and in approximately ten seconds—we will have a Meterpreter session.

Our current Meterpreter session exists because it’s tunneled through our Beacon. A lot of Metasploit Framework post exploitation actions create new Meterpreter sessions. If we can’t get these sessions out, we’re dead in the water. Not to worry though.

Cobalt Strike exposes obscure Metasploit functionality that forces a payload handler to set up a port forward on a host with a Meterpreter session. In Cobalt Strike, I call this a pivot listener. It’s a reverse listener that connects to you through a Meterpreter session. Right-click a host, go to Meterpreter -> Pivoting -> Listener… to set one up.

Once you have a pivot listener, the world opens up. Now you can run bypassuac, current_user_psexec, and other Metasploit Framework modules that allow you to escalate and expand your access. When you need to spawn a new session—point the module to your pivot listener. Pivot listeners are integrated into Cobalt Strike’s workflow the same way Beacon is.

At this point, all of the actions you take have a path out to the internet—through your Meterpreter session tunneled through an HTTP Beacon.

Once you get a beachhead, your first job is create a safe channel out of your target’s network. Once you have that channel, the next job is to spread to other systems. You don’t need to take the whole network at this point. Your goal is multiple systems that you may use as beachheads if one gets caught. Once your position is safe, then comes the heavy post-exploitation. I’ve discussed how Meterpreter can tunnel through Beacon to benefit from some of the extra features to defeat tough egress restrictions. With pivot listeners, you gain the freedom to work in your target’s network as if the egress restrictions didn’t exist at all.

Yes, there’s a method to all of this madness.

Follow

Get every new post delivered to your Inbox.

Join 12,433 other followers