Friday, March 09, 2007

Tracking Down Random ICMP in Windows

Captain Ramius: Give me a ping, Vasili. One ping only, please.
- The Hunt For Red October

Posted to the incidents list in following some suspicious ICMP detection - behavioral detection, using flow data - using the QRadar tool. ICMP proves to be a nice control channel for Windows malware - often allowed through firewalls and hard to do host forensics on (compared to TCP and UDP). Netstat, fport, tcpview, TDImon don't do ICMP.

So how can an incident responder determine which process is generating ICMP in Windows? I came up with three potential methods:

1. use the tasklist command (see below) to determine which processes have iphlpali.dll or icmp.dll loaded (for example, I find ping.exe uses only iphlpapi.dll while tarcert.exe uses both)

C:\>tasklist /M Iphlpapi.dll

Image Name PID Modules
========================= ====== =============================================
SimpLite-MSN.exe 4048 iphlpapi.dll
GoogleToolbarNotifier.exe 5244 iphlpapi.dll
okclient.exe 4632 iphlpapi.dll
explorer.exe 4480 iphlpapi.dll
taskmgr.exe 4076 iphlpapi.dll
msnmsgr.exe 3588 iphlpapi.dll
OUTLOOK.EXE 396 iphlpapi.dll
tracert.exe 832 iphlpapi.DLL

C:\>tasklist /M icmp.dll

Image Name PID Modules
========================= ====== =============================================
tracert.exe 832 icmp.dll

2. use listdlls or process explorer to determine which process has these libraries loaded. Suspend them one by one and note when the ICMP traffic stops.

3. use a commercial tool called Socket Spy:

http://ircdb.org/

Socket Spy is multipurpose utility initially created for trapping Winsock, SNMPAPI, ICMP calls and network TCP/UDP traffic of already active or new processes. In other words you may investigate already running process or start a new one in Socket Spy debugging environment. SocketSpy can show File I/O operations (KERNEL32.DLL) and Windows Registry (ADVAPI.DLL) operations of tested process. For example, you may capture all network and/or file input/output traffic of IExplore, OutLook Express and other programs. It is possible to capture only file I/O, network I/O, Windows Registry access separately. The utility may be used for trojan and virus finding, high level network protocols study or software reverse engineering.

-----Original Message-----
From: Craig Chamberlain
Sent: Monday, January 22, 2007 8:20 AM
To: incidents@securityfocus.com
Subject: Tracking down random ICMP

Seem to be seeing more random bursts of ICMP traffic - sometimes unidirectional - with remote destinations that are mostly inexplicable.
Wondering if it's a covert control channel of some sort - if so I can see why they chose ICMP - often allowed through firewalls and it is seems to be hard to determine the originating process in Windows.

Is there a tool that can determine which process ID is generating ICMP packets or IRPs in Windows? TDImon seems to be TCP/UDP only. TCPview and netstat apparently can't do it.

- Craig

Update 1: Years later,  the netsh tool emerged which can take low-level packet captures that seem to get the ICMP endpoint process info most of the time. I wrote this follow-up post almost a decade later: https://randomuserid.blogspot.com/2015/06/windows-icmp-redux.html

No comments: