Process-to-port Mapping

During first responder activities, be they simple troubleshooting or incident response related, one of the important pieces of information that can really provide some insight into the behavior and status of a system is process-to-port mapping.

Why is this information important? Well, it really depends on what you're looking for, but if your initial indicator or notification of a potential security incident is "unusual traffic" originating from a system, then you'd want to know what process was generating that traffic...right? After all, there are a couple of truths you need to keep in mind when troubleshooting or performing IR activities. One is that network traffic never spontaneously emanates from a system without a cause...there's always some process involved. Another is that nothing happens on a system without some code executing as part of a thread/process.

Okay, moving on...

With NT, getting process-to-port mapping information wasn't easy. You had to use a tool like fport to get the information. The same was true for Windows 2000, and it was really cool that as of XP, netstat.exe had the '-o' switch added so that you could get the network connections with the associated PID all on one line (this is great for scripting! =) )

Many folks may not be aware that there was an update to Windows 2000 that added the '-o' capability to netstat.exe on that platform. If you've got Windows 2000 systems, this is a great update to add, so that (as an admin) you have the capability to get the information you need.

Another tool you can use to get this information during IR activities is tcpvcon. I prefer this tool because it can be included in a batch file (reducing overhead), and the output can be sent to .csv format, which is great for parsing with Perl scripts.

Analysis Tip: One of the things you might run across during an engagement is working with admins who are network-centric...or being one of those network-centric admins. For example, you may get some indication of an issue from traffic captures, or IDS/IPS/firewall notifications or logs. In such cases, you very often have a couple of pieces of information available to you, one of them being the source IP of the traffic, which you would likely use to locate the system from which the traffic originated (assuming that it wasn't spoofed). But guess what? You will very likely also have the source port for the traffic...and this will information (if you don't ignore it) may assist you in identifying the process from which the network traffic had been generated. Something as simple as "netstat -ano | find " may be all you need to do to find the process that generated the traffic.

How is this important? Well, one more than one occasion, incident responders such as myself have encountered those who've said, "...we saw some unusual traffic, found the system, and scanned it with [insert AV product name], and found a virus." In such cases, there may be no correlation whatsoever between the traffic and whatever the AV product found (could've been a DLL or a Registry key...) - this is "incident response by assumption/speculation", which is about as bad as "security through obscurity".