Wednesday, July 02, 2008

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".

7 comments:

Anonymous said...

Hey, great post. I was not aware of the different versions of the netstat command for Windows 2000, but now it makes sense what my colleague was seeing in memory. He had told me that there were different versions of tcpip.sys and at times different memory structures representing ports with the same major operating system version. We had to find a single approach that found all the ports associated with a PID across Windows 2000, XP, and 2003 using only raw memory. Now I understand the reason for the changes we were seeing.

Thanks,
Jamie

Anonymous said...

Do you know of a similar tool to gather udp connection data?

H. Carvey said...

Do you know of a similar tool to gather udp connection data?

Not sure I follow...netstat gets UDP 'connection' info, as does tcpvcon.

What is it that you're looking for that these tools do not show?

Anonymous said...

keydet89 - My problem is probably better done through packet capture and not on the host.

It is difficult to locate a process while it is sending off a UDP packet every once in a while. A TCP connection can have a longer lifespan and be easier to spot in this way. A single UDP packet is harder.

H. Carvey said...

In such cases, I would look at all running processes, and check what DLLs they have loaded, as well as their handles. Even if a process only sends out a limited amount of (UDP) traffic intermittently, there *has* to be some process running...processes don't spontaneously start themselves.

Anonymous said...

On later OSs, you can also use netstat -b to get the process names (instead of just PID with netstat -o).

I believe this works on XP SP2 and Win2k3 SP1 and later but I would have to double-check that.

AW said...

Jamie,

I'm glad you were finally able to figure it out. As you start to analyze more images, I'm sure you will learn a lot of other things you didn't expect. I noticed you are doing training on open source tools. Since you are taking advantage of the hard work put into those tools, do you plan on actually contributing back at some point? The Volatility Team can't wait to see you in Vegas! Should we expect any new shadiness (ie, deceptive patents) this year?

AW