"Have I got this straight, Jonesy? A million dollar computer tells you you're chasing an earthquake, but you don't believe it, and you come up with this on your own?"
-Captain Mancuso,
The Hunt For Red October
Possibly you're wondering, at this point, why we care about something as arcane as identifying a process sending ICMP packets. I personally care about this because I hate it when there is nothing to the left of the equals sign - where the status of the case is having to say "we don't know" (something engineers hate to say, and will only say under duress and in a sort of low, pathetic tone). Tracking down the process connected to an ICMP packet stream under Windows has historically been hard and made many people sad - including myself, when I wrote the original post what seems like a lifetime ago. A wide range of replies and suggestions ranged from "use Ethereal (now Wireshark)" to "run the Sysinternals thingy" to "run that thing that does..things". Sniffers don't generally give you a process name or ID, of course, and members of the venerable Sysinternals suite like Process Monitor and TCPview don't catch ICMP due to differences in the way the protocol is implemented. I've asked Microsoft about this over the years, and talked with Russinovich at a conference in 2011 or 2012, and for a long time there wasn't a simple answer.
ICMP is a pretty good protocol option for someone who wants to use a network to do things - say scans, data exfil or even C2 - without being noticed because it tends to have free reign. Security teams rarely interfere with ICMP because networks teams tend to regard it as both critical to normal operations and somewhat shrouded in mystery (at least as to what exactly needs to be able to ping what, in order to avoid failing and taking half the business with it). With that combination, any interference is often regarded as tantamount to recklessly introducing risk of disruption and chaos. The upshot is that ICMP is often subject to few or no access controls. ICMP is absolutely vital in the devops and software maintenance fields, as anyone who has listened to network complaints from developers can attest, as these often feature a sort of customary preamble that goes something like "I cannot ping the things, so that means the firewall has taken down the network, and that makes me sad." ICMP, it would seem, is the primary network diagnostic tool for most kinds of distributed applications.
Security and network teams tend not to notice ICMP traffic unless it becomes annoying or disruptive due to quantity or volume. Security analysts and hunters may not look twice at anomalous ICMP traffic because of the familiarity or availability heuristics - analysts are often quick to assume that ICMP activity is "normal" because they see the protocol used constantly on their networks. (Interestingly, these heuristics are thought to increase under cognitive load and may explain some of the "we didn't see the alert" breach and incident scenarios. Security incident analysts increasingly fail to recognize indications and warnings when they are task saturated or working in interrupt-driven roles like support or administration). Security teams may avoid investigation of anomalous ICMP activity and instead hope it is harmless because it has been hard to reach a conclusion without a lot of tedious mucking about in a debugger or other low level tools (which tends to be annoyingly disruptive and consequently makes everybody sad). A threat actor with persistence on a network manager's Windows PC could do almost anything with ICMP with little or no expectation of being discovered and shut out.
Sometime around 2010, Network Monitor (the Microsoft sniffer for Windows) added the ability to display pids (process IDs) and image names (process names) in the trace data. This data is not in the IP protocol specs, of course, and is therefore not present in any captured packets; Network Monitor obtains this detail through some magic of the Windows API. This is incredibly useful but, as with the Sysinternals tools, ICMP endpoint process details are not captured. However, there is another way. It turns out that netsh added a "trace" command in Windows 7 which takes packet captures. This is the syntax for "netsh trace":
The following commands are available:
Commands in this context:
? - Displays a list of commands.
convert - Converts a trace file to an HTML report.
correlate - Normalizes or filters a trace file to a new output file.
diagnose - Start a diagnose session.
dump - Displays a configuration script.
help - Displays a list of commands.
show - List interfaces, providers and tracing state.
start - Starts tracing.
stop - Stops tracing.
These netsh packet captures are taken somewhat differently than in Network Monitor - I don't know just what the differences in the implementation details are - because they (mostly) include process details for ICMP traffic. For example, here is a netsh trace of ICMP activity viewed in Network Monitor:
In this case we can see the process is nmap, which is not something generally expected of a user, even if they were the sort expected to be running tools that ping everything in sight all day long. If the process were something unknown, or unidentified, we could locate the binary and start malware analysis as usual (and round up twice the usual number of suspects).
The process is multi-step but simple and quick:
1. Take a network trace using netsh trace start capture=yes
2. Stop the trace when finished using netsh trace stop
3. Open the capture file in Network Monitor. The tree on the left will not be organized as usual and instead contains a list of things called "NetEvent Activity ID x". You may have to search (click Find) or trawl through the data to locate the traffic you're interested in.
No comments:
Post a Comment