Archive for the ‘Cobalt Strike’ Category

h1

Map of Cobalt Strike Features for Armitage Users

October 22, 2014

I wrote Cobalt Strike and I take it for granted that my users know where things are. This doesn’t come from nowhere though. The users who get the most from this tool have read the documentation, watched my videos, or had a lot of trial and error.

If you’re new to Cobalt Strike, consider this blog post my “Get Started with the Cool Stuff” cheat sheet.

Let’s start with the Cobalt Strike menubar:

menu_cobalt

Under the Cobalt Strike menu are options to control and configure your Cobalt Strike instance. Use New Connection to connect to another team server. Go to Interfaces to work with your Covert VPN interfaces. The Listeners item is where you setup payload handlers. This is also where you configure Beacon. Go to Close to disconnect from the current team server.

menu_view

The View menu is where you reach Cobalt Strike’s data. The Applications item takes you to the results from the System Profiler. Go to Beacons to manage your Beacon sessions. I like to use Ctrl+B to dock the Beacon tab to the bottom of my Cobalt Strike instance. The Web Log item shows the activity on Cobalt Strike’s Web Server. Go to Reporting to generate a report, jump to log files, or export data.

menu_attacks

I keep Cobalt Strike’s custom attacks under the Attacks menu. Visit Packages to generate an executable or a document tied to a listener. Use Web Drive-by to host a file on Cobalt Strike’s web server or start a web drive-by attack. This is where the applet attacks live. Go to Spear Phish to kick off a spear phishing campaign.

menu_help

Under Help, I have one item of special interest to licensed Cobalt Strike users. This is the Arsenal option. This menu takes you to a site where you may download source code to Cobalt Strike’s Applet Kit and Artifact Kit. The Artifact Kit is Cobalt Strike’s solution to swap anti-virus evasion techniques. I make this source code available to licensed users to allow changes for evasion purposes.

menu_login

Cobalt Strike’s workflow for lateral movement [psexec and friends] goes beyond Armitage. You get a few new options such as wmi (token) and psexec (token). All psexec dialogs are setup to work with Cobalt Strike listeners as well. Cobalt Strike also gives you a workflow to manage SSH keys too. Finally, the psexec menus that require executables use Cobalt Strike’s Artifact Kit to generate executables.

Several of Cobalt Strike’s post-exploitation capabilities work with Meterpreter. Let’s take a look at these:

menu_access

Try Access -> Bypass UAC to elevate from a medium integrity context to a high integrity context. This menu uses the Metasploit Framework’s bypassuac_inject module with an Artifact Kit DLL.

menu_interact

Go to Interact -> Desktop (VNC) to get to your target’s desktop via VNC. This option will use a Meterpreter script to stage a VNC server in memory on the target. Once the server is up, Cobalt Strike will connect to it with a built-in VNC client. I had to license the VNC client and I consider it money very well spent.

menu_explore

Explore -> Browser Pivot is the place to start Cobalt Strike’s man-in-the-browser session stealing technology for Internet Explorer. This feature allows you to browse to websites authenticated as your target user. It’s a really interesting pen tester take on a classic crimeware activity.

menu_pivoting

Jump to Pivoting -> Deploy VPN to run Covert VPN on your target’s system. This will create a layer-2 VPN into your target’s network. How this VPN communicates frames is up to you. It can tunnel through Meterpreter or connect to you over HTTP, UDP, or a TCP connection.

Finally, Pivoting -> Listener… creates a pivot listener. This is a little user-interface magic on top of a hidden Metasploit Framework feature. A pivot listener allows you to setup a reverse connection that tunnels through a Meterpreter session. You may use these listeners anywhere a normal listener would work.

And, that’s about it. This post is a good map to find Cobalt Strike’s feature set. You’ll notice this is not a lot of new interface elements. There’s a reason for this. I hate bloated user interfaces. Most of Cobalt Strike’s feature set is in its Beacon payload. Beacon gives Cobalt Strike its new communication channels [DNS, SMB], its indicator flexibility [Malleable C2], and new post-exploitation tools. Beacon has PowerShell integration and its bypass UAC attack works on Windows 8.1. If you want to get the most out of Cobalt Strike as a toolset, study Beacon. This payload will change the way you work.

h1

User-driven Attacks

October 1, 2014

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

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

Document Dropper

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

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

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

Firefox Add-on

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

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

HTML Application

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

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

Java Signed Applet

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

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

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

Microsoft Office Macro

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

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

Why Cobalt Strike?

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

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

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

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

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

h1

Cobalt Strike 2.1 – I have the POWER(shell)

September 23, 2014

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

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

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

beaconpowershell

Here’s how to use it:

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

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

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

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

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

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

Covert VPN Revamp

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

HTML Application Attack

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

Malleable SSL

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

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

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.

Follow

Get every new post delivered to your Inbox.

Join 13,543 other followers