How to identify that the session is connected by the payload

[n1ngod]

I found that the listener will think of any data received as being transmitted by the payload，So i did the following tests. First, i create a shell listener and it works normally.

msf5 > use exploit/multi/handler 
msf5 exploit(multi/handler) > set PAYLOAD windows/x64/shell/reverse_tcp
PAYLOAD => windows/x64/shell/reverse_tcp
msf5 exploit(multi/handler) > set LHOST 10.91.4.101
LHOST => 10.91.4.101
msf5 exploit(multi/handler) > set LPORT 4444
LPORT => 4444
msf5 exploit(multi/handler) > set EXITONSESSION false 
EXITONSESSION => false
msf5 exploit(multi/handler) > run -j
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.

[*] Started reverse TCP handler on 10.91.4.101:4444 
msf5 exploit(multi/handler) > 

Now i use another computer to telnet 10.91.4.101 4444,I will get the following information from msfconsole

msf5 exploit(multi/handler) > [*] Sending stage (336 bytes) to 10.91.22.142
[*] Command shell session 1 opened (10.91.4.101:4444 -> 10.91.22.142:55795) at 2019-05-30 03:38:43 +0000

msf5 exploit(multi/handler) > sessions

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

  Id  Name  Type               Information  Connection
  --  ----  ----               -----------  ----------
  1         shell x64/windows               10.91.4.101:4444 -> 10.91.22.142:55795 (10.91.22.142)

msf5 exploit(multi/handler) > sessions -i 1
[*] Starting interaction with 1...

ls

It can't execute any commands and get any result,obviously it is wrong. Worse, it also treats nmap scanning features as sessions.When i execute 'nmap -Pn -sS -sV -p 4444 10.91.4.101',it will always generate new session.Finally I got more than 100 invalid sessions.

msf5 exploit(multi/handler) > 
[*] Sending stage (336 bytes) to 172.28.0.9
[*] Command shell session 2 opened (10.91.4.101:4444 -> 172.28.0.9:33706) at 2019-05-30 03:43:38 +0000
[*] Sending stage (336 bytes) to 172.28.0.9
[*] Command shell session 3 opened (10.91.4.101:4444 -> 172.28.0.9:33714) at 2019-05-30 03:43:49 +0000
[*] Sending stage (336 bytes) to 172.28.0.9
[*] Command shell session 4 opened (10.91.4.101:4444 -> 172.28.0.9:33718) at 2019-05-30 03:43:54 +0000
[*] Sending stage (336 bytes) to 172.28.0.9
[*] Command shell session 5 opened (10.91.4.101:4444 -> 172.28.0.9:33722) at 2019-05-30 03:43:59 +0000
[*] Sending stage (336 bytes) to 172.28.0.9
[*] Command shell session 6 opened (10.91.4.101:4444 -> 172.28.0.9:33726) at 2019-05-30 03:44:04 +0000
[*] Sending stage (336 bytes) to 172.28.0.9
[*] Command shell session 7 opened (10.91.4.101:4444 -> 172.28.0.9:33730) at 2019-05-30 03:44:09 +0000
[*] Sending stage (336 bytes) to 172.28.0.9
[*] Command shell session 8 opened (10.91.4.101:4444 -> 172.28.0.9:33734) at 2019-05-30 03:44:14 +0000
[*] Sending stage (336 bytes) to 172.28.0.9
[*] Command shell session 9 opened (10.91.4.101:4444 -> 172.28.0.9:33738) at 2019-05-30 03:44:19 +0000
[*] Sending stage (336 bytes) to 172.28.0.9
[*] Command shell session 10 opened (10.91.4.101:4444 -> 172.28.0.9:33742) at 2019-05-30 03:44:24 +0000

msf5 exploit(multi/handler) > sessions

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

  Id  Name  Type               Information                                                                       Connection
  --  ----  ----               -----------                                                                       ----------
  2         shell x64/windows                                                                                    10.91.4.101:4444 -> 172.28.0.9:33706 (172.28.0.9)
  3         shell x64/windows  _S_O_?G_,_`~_{_w_<=_o_n_(_ _f_e_d_c_b_a_`_ _                                      10.91.4.101:4444 -> 172.28.0.9:33714 (172.28.0.9)
  4         shell x64/windows  _i_e_U_random1random2random3random4_/_ _9_0_ _,_*_                               10.91.4.101:4444 -> 172.28.0.9:33718 (172.28.0.9)
  5         shell x64/windows  _u_ _f_e_d_c_b_:_9_8_5_4_3_2_/__ _ _@_i<+_@_o_,M __)_                         10.91.4.101:4444 -> 172.28.0.9:33722 (172.28.0.9)
  6         shell x64/windows                                                                                    10.91.4.101:4444 -> 172.28.0.9:33726 (172.28.0.9)
  7         shell x64/windows  OPTIONS / HTTP/1.0                                                                10.91.4.101:4444 -> 172.28.0.9:33730 (172.28.0.9)
  8         shell x64/windows  OPTIONS / RTSP/1.0                                                                10.91.4.101:4444 -> 172.28.0.9:33734 (172.28.0.9)
  9         shell x64/windows  _(r__|_                                                                          10.91.4.101:4444 -> 172.28.0.9:33738 (172.28.0.9)
  10        shell x64/windows  __version_bind_                                                                  10.91.4.101:4444 -> 172.28.0.9:33742 (172.28.0.9)
msf5 exploit(multi/handler) > 

I need to deploy the listener to the public network, but it will inevitably be scanned by others, I will get a lot of invalid sessions.Do I have any way to solve this problem? Sorry my poor English,thanks.

Version

metasploit v5.0.10-dev

[sempervictus]

Shell sessions are, for the most part, raw l4 sockets. You'd need a magic string or something sent first by the session to perform such validations. The udp shells have to send a byte because they're stateless, but the magic bytes would also flag every ids like an eicar string. Basically, only advanced sessions which have their own transport metadata can do this properly, shell sessions are just sockets.

[n1ngod]

It means i can't solve the problem if it's shell sessions. I can not control the listener so i have no way to verify the magic bytes. if I want to avoid it，i can only use meterpreter sessions. It's right？Do you consider adding magic bytes settings to shell sessions to avoid similar problems?

[sempervictus]

Framework is open source, you can fix anything, but it may not be suitable for upstream. That said, this is nontrivial work with questionable benefit as I wrote above - plus, you'd have to add the magic byte senders to all of the relevant payload constructs. Alternatively, you may be able to auto-unregister any session which fails sysinfo, but that could have false positive disconnect side effects. If you're running long-term handlers, shell sessions as they are will register any connection. If a meterp is available for your use case, definitely use that as it has encrypted comms and a hell of a lot more functionality.

[n1ngod]

Your suggestion is very useful,maybe i can try it. Thanks!

[sempervictus]

@n1ngod: we are actually currently implementing some related functions, actually its all @zerosteiner doing the implementing and I'm just riding his coat-tails, but you'll soon see a good placeholder for magic data in shells

[n1ngod]

I found that not only the shell listener，meterpreter listener also has this problem，payload is “windows/x64/meterpreter/reverse_http”，it also treats scanning features as sessions. : (

[void-in]

@n1ngod With meterpreter you have the choice of paranoid mode to check the TLS certificate fingerprint and UUID before establishing a session. You can find the details at https://github.com/rapid7/metasploit-framework/wiki/Meterpreter-Paranoid-Mode

[n1ngod]

@void-in It seems that it only works for https，not http？

[void-in]

@n1ngod That is right.

[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.