Exploit modules which start a handler automatically do not support bind payloads

[bcoles]

Based on reported issue #17885, a quick grep through the code base indicates that every module which offers a "Start an exploit/multi/handler" option with a per-module create_multihandler method likely suffers from a similar issue with bind payloads.

# grep -rn "def create_multihandler" modules/
modules/exploits/windows/local/persistence.rb:248:  def create_multihandler(lhost, lport, payload_name)
modules/exploits/windows/http/manageengine_adselfservice_plus_cve_2022_28810.rb:186:  def create_multihandler(lhost, lport, payload_name)
modules/post/multi/manage/shell_to_meterpreter.rb:360:  def create_multihandler(lhost, lport, payload_name)

All three of the above modules are unlikely to work with bind payloads. None of these modules allow specifying rhost which is necessary for bind payloads.

https://github.com/rapid7/metasploit-framework/blob/879f94571e9a662a7769ad23ecc94c8053a25e06/modules/exploits/windows/local/persistence.rb#L247-L252

shell_to_meterpreter (#17885) is uniquely problematic due to using PAYLOAD_OVERRIDE to set the payload name as a string (without validation), thus never allowing rhost to be set via command line even if bind payloads were supported. As such, this is a separate issue to #17885.

[bcoles]

Bind handler is created with invalid rhost:rport of :4444 :

msf6 exploit(windows/local/persistence) > set payload windows/meterpreter/bind_tcp
payload => windows/meterpreter/bind_tcp
msf6 exploit(windows/local/persistence) > set handler true
handler => true
msf6 exploit(windows/local/persistence) > set rhost 192.168.200.190
rhost => 192.168.200.190
msf6 exploit(windows/local/persistence) > run

[*] Running persistent module against TEST via session ID: 1
[+] Persistent VBS script written on TEST to C:\Users\user\AppData\Local\Temp\qGtMOp.vbs
[*] Installing as HKCU\Software\Microsoft\Windows\CurrentVersion\Run\aaQUJUKkFGtsU
[+] Installed autorun on TEST as HKCU\Software\Microsoft\Windows\CurrentVersion\Run\aaQUJUKkFGtsU
[*] Starting exploit/multi/handler
[*] Started bind TCP handler against :4444
[*] Clean up Meterpreter RC file: /root/.msf4/logs/persistence/TEST_20230421.5351/TEST_20230421.5351.rc

Job is created with no payload options (ignore the first two jobs - these are unrelated):

msf6 exploit(windows/local/persistence) > jobs

Jobs
====

  Id  Name                    Payload                              Payload opts
  --  ----                    -------                              ------------
  0   Exploit: multi/handler  windows/x64/meterpreter/reverse_tcp  tcp://192.168.200.130:1337
  1   Exploit: multi/handler  windows/x64/shell/reverse_tcp        tcp://192.168.200.130:1338
  2   Exploit: multi/handler  windows/meterpreter/bind_tcp

[bcoles]

This should be fixed for shell_to_meterpreter when #17917 lands.

For the other two modules, it kind of makes sense that we don't support bind payloads. Using a bind handler will poll the remote server every second for hours, days, weeks, ... until a user logs in, or the server is rebooted, or whatever condition is required to trigger the payload.

However, the fact that it does not work at all and provides no feedback to the user that this is a.) a bad idea; and b.) broken; is not great.

---

For exploit/windows/local/persistence, using multi handler is an advanced option (HANDLER) and non-default behaviour. As a user, I would kind of expect that persistence during a long-running campaign would require some form of handler, and usually I would create and manage this myself as needed. None the less, given that bind payloads are broken, a warning would be nice.

https://github.com/rapid7/metasploit-framework/blob/0436e8bad998d035e6558ebcbb2e878eaf898ce6/modules/exploits/windows/local/persistence.rb#L65-L67

As for exploits/windows/http/manageengine_adselfservice_plus_cve_2022_28810 on the other hand, this module uses multi handler by default and cannot be disabled - this is the expected mode of operation.

https://github.com/rapid7/metasploit-framework/blob/0436e8bad998d035e6558ebcbb2e878eaf898ce6/modules/exploits/windows/http/manageengine_adselfservice_plus_cve_2022_28810.rb#L178-L182

Fixing this requires more than presenting a warning.

[RahulTarafder]

How to fix it