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.

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.