Persistent Listener [BUG]

[godylockz]

After receiving a meterpreter shell using the exploit/multi/handler, the port remains open within metasploit, however no jobs are active.

Steps to reproduce

How'd you do it?

1. Start a meterpreter handler (i.e. Port 443)
2. Obtain a meterpreter session (handler should stop listening)
3. List all jobs with jobs, no jobs should exist
4. Attempt to listen on the same port via netcat or list open ports with netstat:

netstat -panut | grep 443 | grep ruby
tcp        0      0 192.168.49.85:443       0.0.0.0:*               LISTEN      80900/ruby          
tcp        0      0 192.168.49.85:443       192.168.85.132:49727    ESTABLISHED 80900/ruby

nc -nlvp 443                         
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Listening on :::443
Ncat: bind to 0.0.0.0:443: Address already in use. QUITTING.

Expected behavior

The port should not be listening on all interfaces after a session is generated, unless the handler is persisted and is listening for more than 1 session. It would be a nice to keep the multi/handler open after a single session is generated, however it currently does not do this and not sure how to do this ... I was assuming run -j but that is not the case.

Current behavior

The port remains open, however no additional sessions can be generated, as the handler is not active.

Metasploit version

Framework Version: 6.2.9-dev

[yurgiur]

Experiencing same problem.

My used payload was windows/x64/meterpreter/reverse_https. When using windows/x64/meterpreter/reverse_tcp the socket get's closed normally after receiving the session.

[github-actions[bot]]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[github-actions[bot]]

Hi again!

It’s been 60 days since anything happened on this issue, so we are going to close it. Please keep in mind that I’m only a robot, so if I’ve closed this issue in error please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[MHichamB]

Was the issue fixed finally ? I'm experiencing the same again while using multi/handler, the only way to fix it is to kill the whole metasploit process on the OS to close the port

[adfoster-r7]

Could you post exact replication steps if you're hitting any issues :+1:

It might be easier to create a fresh issue to ensure the issue isn't lost

[TheKevinWang]

I am also experiencing this issue when running a task and it fails. Same bug happens regardless of exploit/multi/handler or payload/windows/powershell_reverse_tcp.

use payload/windows/powershell_reverse_tcp
use exploit/multi/handler
set exitonsession false
exploit -j
msf6 exploit(multi/handler) > sessions -c whoami
[*] Running 'whoami' on powershell session 7 ()
[*]  - Powershell session session 7 closed.
[*] Session stream closed.
msf6 exploit(multi/handler) > jobs

Jobs
====

No active jobs.

msf6 exploit(multi/handler) > 

[adfoster-r7]

@TheKevinWang Following your steps, the listener is still alive for me:

msf6 payload(cmd/windows/powershell_reverse_tcp) > [*] Command shell session 1 opened (192.168.123.1:4444 -> 192.168.123.147:49695) at 2024-01-18 10:12:28 +0000
sessions

Active sessions
===============

  Id  Name  Type             Information                                              Connection
  --  ----  ----             -----------                                              ----------
  1         shell sparc/bsd  Shell Banner: Windows PowerShell running as user vagran  192.168.123.1:4444 -> 192.168.123.147:49695 (192.168.12
                             t on WINDEV Copyright...                                 3.147)

msf6 payload(cmd/windows/powershell_reverse_tcp) > jobs

Jobs
====

  Id  Name                    Payload                    Payload opts
  --  ----                    -------                    ------------
  0   Exploit: multi/handler  generic/shell_reverse_tcp  tcp://192.168.123.1:4444

msf6 payload(cmd/windows/powershell_reverse_tcp) > sessions -c whoami
[*] Running 'whoami' on shell session 1 (192.168.123.147)
windev\vagrant
PS C:\Users\vagrant> 
msf6 payload(cmd/windows/powershell_reverse_tcp) > sessions

Active sessions
===============

  Id  Name  Type             Information                                                                      Connection
  --  ----  ----             -----------                                                                      ----------
  1         shell sparc/bsd  Shell Banner: Windows PowerShell running as user vagrant on WINDEV Copyright...  192.168.123.1:4444 -> 192.168.123.147:49695 (192.168.123.147)

msf6 payload(cmd/windows/powershell_reverse_tcp) > jobs

Jobs
====

  Id  Name                    Payload                    Payload opts
  --  ----                    -------                    ------------
  0   Exploit: multi/handler  generic/shell_reverse_tcp  tcp://192.168.123.1:4444

msf6 payload(cmd/windows/powershell_reverse_tcp) >

Potentially there's an edgecase in the error scenario? As it looks like your session closed, and then there was no handler present? 🤔