Where does PH get its Network data from?

[stdedos]

I am in the middle of debugging some weirdly botched network situation.

One of the things that has caught my attention, is that PH claims a process (WSL1/packed process) has tons of open ports, while an netstat -ano shows that that's not the case.
Additionally, PH cannot "Go to process".

I am wondering "Where does PH get its Network data from?", and then, if I could somehow restart only that subsystem (instead of doing a reboot)

[dmex]

tons of open ports, while an

Is the connection state Bound or Listen?

netstat -ano shows that that's not the case

netstat -nq ?

PH cannot "Go to process"

This happens when a process duplicates the socket handle into a child process then exits. The Windows kernel doesn't update the ProcessId for the socket handle and the Windows network stack continues referencing the dead parent process instead of the current process and returning the wrong ProcessId owner.

For example: WSAStartup -> DuplicateHandle -> send/recv/sendto/recvfrom

Duplicate a socket handle from chrome/edge/firefox processes into malicious.exe... Netstat, Sysinternals TcpView, Process Hacker, Netlimiter, Antivirus and Firewall software (both user and kernel) start having various issues:

• show the owner of the duplicated socket as chrome.exe/edge.exe/firefox.exe instead of malicious.exe
• attribute all the traffic to chrome.exe/edge.exe/firefox.exe instead of malicious.exe
• apply firewall rules to chrome/edge/firefox instead of malicious.exe (i.e bypassing all firewall rules)
• allow malicious.exe to intercept, block and spy on the socket traffic (you can readprocessmemory the ssl/tls decryption keys for the socket from chrome/edge process memory by using the public pdb symbols available from Google and Microsoft)
• allow malicious.exe to send/receive data over the duplicated socket. The remote server assumes it's the existing authenticated session rather than a new session (identical to cross-site request forgery except now it's cross-process).

It's been mentioned to Microsoft more than once but they've never done anything to fix the behavior:

https://windows-internals.com/faxing-your-way-to-system/

[stdedos]

tons of open ports, while an

Is the connection state Bound or Listen?

"Bound"

netstat -ano shows that that's not the case

netstat -nq ?

Sadly, I had solved it 1.5h after I posted. The "dead process" was part of WSL's subsystem, which somehow made the Networking go bananas when I tried to connect to a PPTP VPN. While the process was "long dead", it seems that the WSL Subsystem never released its resources appropriately.

When WSL was "fully killed", and the subsystem was shutdown, all resources (and the weird Networking issue) disappeared magically

PH cannot "Go to process"

This happens when a process duplicates the socket handle into a child process then exits. The Windows kernel doesn't update the ProcessId for the socket handle and the Windows network stack continues referencing the dead parent process instead of the current process and returning the wrong ProcessId owner.

For example: WSAStartup -> DuplicateHandle -> send/recv/sendto/recvfrom

Duplicate a socket handle ...

Nice story! I'll definitely read that one sometime soon :-D