Pivot Listeners

It’s good tradecraft to limit the number of direct connections from your target’s network to your command and control infrastructure. A pivot listener allows you to create a listener that is bound to a Beacon or SSH session. In this way, you can create new reverse sessions without more direct connections to your command and control infrastructure.

To setup a pivot listener, go to [beacon] -> Pivoting -> Listener…. This will open a dialog where you may define a new pivot listener.

figure 66 - Configure a Pivot Listener

A pivot listener will bind to Listen Port on the specified Session. The Listen Host value configures the address your reverse TCP payload will use to connect to this listener.

Right now, the only payload option is windows/beacon_reverse_tcp. This is a listener without a stager. This means you can’t embed this payload into commands and automation that expect stagers. You do have the option to export a stageless payload artifact and run it to deliver a reverse TCP payload.

Pivot Listeners do not change the pivot host’s firewall configuration. If a pivot host has a host- based firewall, this may interfere with your listener. You, the operator, are responsible for anticipating this situation and taking the right steps for it.

To remove a pivot listener, go to Cobalt Strike -> Listeners and remove the listener there. Cobalt Strike will send a task to tear down the listening socket, if the session is still reachable.

Asynchronous Pivot Beacons

Pivot Beacons have historically been limited in their ability to use an evasive sleep call (i.e., a technique such as ekko) because it was necessary to handle certain APIs, such as accept, recv, ConnectNamedPipe, and PeekNamedPipe, during masking while performing the following tasks:

  • Waiting for a client to connect over TCP

  • Waiting for data to be received over TCP

  • Waiting for a connection to a pipe

  • Waiting for data to be available on a pipe

A follow-on effect of this was that Sleepmask became more complicated than required, as it became necessary to utilize a PIVOT_ARGS structure to handle these different scenarios. Ideally, it would be better to handle a single Sleep or WaitForSingleObject call via BeaconGate.

As part of Cobalt Strike 4.12, any calls to synchronous networking and pipe APIs within Beacon related to the tasks mentioned above have been converted to their asynchronous equivalents. The consequence of this is that a 'sleep' for pivot Beacons now consists of a call to WaitForSingleObject on an I/O handle (i.e., analogous to Sleep for HTTP(S)/DNS Beacons). Once new data is available on the pipe/socket, the WaitForSingleObejct call will return and Beacon will continue as normal, allowing us to migrate completely to BeaconGate as we now only need to handle Sleep and WaitForSingleObject.

As a result, the Sleepmask has been updated to remove the need for the SLEEPMASK_INFO structure, which also contained the PIVOT_ARGS structure, and has been replaced by a pointer to a BEACON_INFO structure instead. As previously mentioned, all calls into the Sleepmask now go through BeaconGate, which means the pivot Beacon now supports our default evasive Sleepmask.

Sleepmask-VS and the Arsenal Kit Sleepmask implementations have also been updated to account for this. These are breaking changes that will require you to rebuild any custom Sleepmasks you have created that utilize either of these templates.

 

Related Topics