Session passing is using one payload to spawn another payload. Sometimes, the payloads are from the same toolset. Other times, they’re not. Session passing options allow you to hand-off accesses between toolkits and infrastructure.
In this blog post, I’ll take you through the session passing options in Cobalt Strike.
If you want to pass access from one Cobalt Strike instance to another, the best option is to connect your Cobalt Strike client to both servers. Go to Cobalt Strike –> New Connection. Once you connect, Cobalt Strike will show a server switchbar at the bottom of the Cobalt Strike window. This allows you to choose which Cobalt Strike server to work with.
When Cobalt Strike connects to multiple servers in this way, listeners from all servers are available in Cobalt Strike’s workflows. To pass a session from a Beacon on one server to a Beacon on another server, go to [beacon] -> Spawn and choose the listener on the other server. That’s it.
This form of session passing works with Cobalt Strike’s x86 and x64 Beacon. It also takes advantage of any Malleable C2 configuration associated with the payload stager (e.g., the User-Agent).
Foreign Listeners are Cobalt Strike’s way to define a listener for a payload handler that is not in your immediate control. The foreign listener generates a stager that downloads and runs a payload from the host and port you specify. Cobalt Strike’s foreign listeners are compatible with the Metasploit Framework’s staging process. This means you can use a foreign listener to easily pass Meterpreter sessions to Metasploit Framework users.
You may use a foreign listener throughout Cobalt Strike’s workflows. To quickly pass a session, try the spawn command in Beacon. I also recommend that you look at the inject command too. The inject command will let you inject a payload listener (foreign or not) into a specific process.
Beacon’s powerpick command runs a process and injects a DLL that runs PowerShell scripts via a .NET API, no powershell.exe needed. This command is one way to run a loader for a PowerShell agent (e.g., PowerShell Empire). Another option is the psinject command. The psinject command is like powerpick, except it injects into a process you specify. This is a way to spawn a PowerShell agent without creating a new process.
Finally, there’s the shinject command. This command injects a local file containing shellcode into a process of your choosing. Use this to run payloads that have stages or stagers available as a binary blob of position-independent code.
The shinject command is also a way to pass Cobalt Strike sessions without a stager. Go to Attacks -> Packages -> Windows Executable (S) and export a stageless Beacon with raw output. This file is a position-independent blob of code that loads the Beacon stage and runs it. This file is ready-to-use with shinject. This method is the only way to pass SMB Beacon sessions between team servers.
Beacon’s dllinject command will inject a Reflective DLL into a process of your choosing. Cobalt Strike is smart enough to pull the architecture from the DLL’s PE header. If you try to inject an x86 DLL into an x64 process it will complain. The dllinject command is a great way to spawn payloads compiled as a Reflective DLL.
Whatever your needs, Cobalt Strike has many options to spawn a payload into another process.