after migrate explorer.exe, how to emergency

[freedom-wy]

hi i am a emergency response engineer，I did an experiment

I generated the Trojan through kali metasploit and executed it in win7. The PID after execution was 2001, In kali I execute ps | grep explorer.exe result is 2890, I executed migrate 2890 then I checked netstat -ano and I could see that the PID was 2001 network connection，But process 2001 is dead I cannot see the network connection with PID 2890.

at kali，i execute getpid result is 2890

How should I emergency in this case? Restart the server?

[adfoster-r7]

Confirmed; Created a Meterpreter session:

We start of as pid 1360:

meterpreter > getpid
Current pid: 1360

Migrating to spooler:

meterpreter > migrate 1708
[*] Migrating from 1360 to 1708...
[*] Migration completed successfully.

netstat shows the 1360 is still connected:

c:\metasploit-framework>netstat -ano | findstr 1708
  TCP    0.0.0.0:49667          0.0.0.0:0              LISTENING       1708
  TCP    [::]:49667             [::]:0                 LISTENING       1708

c:\metasploit-framework>netstat -ano | findstr 1360
  TCP    192.168.123.132:49706  192.168.1.178:4444     ESTABLISHED     1360

But the original process is dead:

C:\Users\vagrant>tasklist | findstr 1708
spoolsv.exe                   1708 Services                   0     17,824 K

C:\Users\vagrant>tasklist | findstr 1360

I'm not sure if this is a bug or feature without code diving, maybe @zeroSteiner happens to know the answer without digging into things 🤞

[zeroSteiner]

Assuming that the reverse_tcp or bind_tcp stager is in use, I would guess that it's due to migrate duplicating the socket with WSADuplicateSocketA in server_transport_tcp.c#L847. The socket is probably marked as owned by the original process that created it before it was duplicated as part of the migration process. I don't think this is a bug and from my understanding of the question, nothing is broken. It's just undocumented how the transport socket is reported via netstat.

If your objective is to make the socket look like it's from the process that Meterpreter is running in, then sleep would probably do the trick by closing it for a couple of seconds and then reopening it in. That'd cause the socket to be closed and reopened so it'd be accurate until the Meterpreter migrates again.

If your objective is to find the process that Meterpreter is actually running in from the socket, maybe looking at the open handles with something like Process Hacker might help.