RFC: Asynchronous Pingback Payload

[smcintyre-r7]

Problem

Metasploit's payloads are currently synchronous and this leads to persistent connections in the case of most transports. Users often desire to have control over when the remote session will contact the C2 server (Metasploit in our case) and it's a feature that is showing up in most of the new C2s that are being published these days.

Solution

From a technical perspective, post modules require a synchronous session in order to run multiple commands (either OS or Meterpreter) making them not well suited for asynchronous operations. This is as opposed to other projects which implement their post modules as interpreted code that is transferred to the remote system and executed. This means that Metasploit's post-module capabilities would require a massive overhaul and in many cases a rewrite in order to function this way. This is not an ideal solution so as an alternative, a new asynchronous transport / payload / handler stack should be implemented which supports transitions to a synchronous session that would then execute a queue of actions such as post modules, OS commands, Meterpreter commands, etc.

Possible New Workflow

In this example, the new session type is referred to as SessionX

1. User establishes a SessionX session somehow, likely delivered through an exploit module.
   • The payload connects to Metasploit periodically in a user configurable manner. The user should be able to define multiple transports to use for checking in, and a configurable jitter to avoid easily recognized patterns.
2. User “queues” one or more actions to take / modules to run
   1. When the SessionX checks in next, it transitions to a traditional synchronous session like Meterpreter.
   2. Runs through the queued actions as usual
   3. The synchronous sessions are killed

UI Mock

The following example shows a SessionX session being established. The user then queues the post/linux/gather/checkvm module to be executed the next time the session checks-in. When the session checks in, Metasploit identifies that there are jobs in the queue and that it needs a Meterpreter session to execute them so it issues the necessary commands to the SessionX session to open a new temporary Meterpreter session. Once established the new Meterpreter session executes the jobs in the queue, in this case, the only job is post/linux/gather/checkvm. Once all of the jobs have been processed the Meterpreter session is closed. This would be a similar process to the user defining a resource script to run the post-module and setting it with the AutoRunScript option.

[*] SessionX session 1 opened (192.168.159.128:4444 -> 192.168.159.128:34310) at 2020-09-10 11:50:40 -0400
msf6 exploit(multi/handler) > sessions
Active sessions
===============
  Id Name     Type         Information Connection
  -- ----     ----         ----------- ----------
  1  sessionx python/linux jitter=5m   localhost.localdomain 192.168.159.128:4444 -> 192.168.159.128:34310 (192.168.159.128)
msf6 exploit(multi/handler) > use post/linux/gather/checkvm
msf6 post(linux/gather/checkvm) > set SESSION 1
SESSION => 1
msf6 post(linux/gather/checkvm) > queue
[*] Meterpreter session 2 opened (192.168.159.128:4444 -> 192.168.159.128:34310) at 2020-09-10 11:55:27 -0400
[*] Gathering System info ....
[+] This appears to be a 'VMware' virtual machine
[*] Post module execution completed
[*] 192.168.159.128 - Meterpreter session 2 closed.
msf6 post(linux/gather/checkvm) > sessions -i 1 -u meterpreter
[*] Meterpreter session 3 opened (192.168.159.128:4444 -> 192.168.159.128:34310) at 2020-09-10 11:00:13 -0400
[*] Starting interaction with 3…
meterpreter > 

Futher Consideration

This could potentially be a good idea to integrate with the user-provided payloads proposal. It's likely that users will want to write their own payloads that communicate asynchronously making these projects interdependent.

[wolfthefallen]

I have found in mature environments beckoning/asynchronous payloads greatly reduce the amount of data over a set period of time. By reducing the overhead data of a synchronous payload you bypass some of the detections I currently come across. Personally, I would like to see the BYOP but I could settle for this if the payload was designed for a couple of different transports.

Though I could see some exploits that utilize railgun to have issues. My recommendation would to allow the payload to switch temporarily over to full sync, run the exploit then return to normal operations. Or provide an option to temporary deploy a full sync payload use it and then kill it after the action has completed.