0

My company security team has informed me that my workstation is pinging some "blacklisted" IP addresses. The enterprise security tool reporting this information sits in place of the usual Windows firewall, but it seems it is unable to tell which process is the culprit.

I had the device rebuilt about six months ago for the same reason, and I'm pretty sure it's just an application that's using a content-delivery network that happens to have also been used by some malware at some point; hence the blocklisted IPs.

Normally in this situation a combination of Wireshark, netstat, TCPView and other tools would help me nail down which process is generating the traffic. For ICMP echo requests, however, it seems that the source process is always a system DLL.

Some googling led to a page which does have some advice on how to narrow down the process by checking which have got the icmp.dll or iphlpapi.dll loaded. I've currently got dozens of processes with iphlpapi.dll loaded, so trying to narrow down which might be sending these requests is going to take quite some time.

Another issue is that these ICMP requests are sent very infrequently. Maybe a couple of times a day. So at the point I'm looking, the process might not even be running.

What I really need is a tool that I can leave running which will look for ICMP requests to these IP addresses, and as soon as they're seen it will identify the process that made them. Does such a thing exist? Is there another low-effort approach that I'm missing?

Sai Chandra Gadde
  • 140
  • 7
Gordon Mckeown
  • 101
  • 2
  • 1
    What tools does the security team have on the endpoint? – Greg Askew May 05 '22 at 11:13
  • Many, many tools! For security reasons I won't list them all, but I think the one that's relevant here (i.e. the one that's flagging an issue) is CrowdStrike Falcon. – Gordon Mckeown May 05 '22 at 14:29
  • For a one-time capture, Sysmon Network Connections may show this, along with Process Creation. https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon – Greg Askew May 05 '22 at 20:36
  • I can't see anything in SysMon that might help specifically with ICMP traffic, but the process creation you mention might help correlate with the Wireshark log. I shall give it a try, thanks. – Gordon Mckeown May 06 '22 at 08:07
  • 1
    This type of activity is fairly easy to correlate in Sysmon. The challenge may be the infrequency. If Sysmon doesn't work, other options I can think of is forcing a crash or memory snapshot when the activity occurs, or use a more capable tool like Time Travel Debugger. https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview#ttd-availability – Greg Askew May 06 '22 at 13:33
  • Ultimately the solution was to use [netsh trace](https://www.51sec.org/2018/07/14/how-to-find-out-windows-process-sending-icmp-packets/) and then [etl2pcapng](https://github.com/microsoft/etl2pcapng) to convert the capture file into a format that can be read by Wireshark. The wireshark capture then includes a 'packet comments' section on the ICMP packets that includes the process ID. Culprint found: the Private Internet Access VPN software. – Gordon Mckeown Jun 24 '22 at 20:10

0 Answers0