Correlate PIDs with network packets in Wireshark


By default when you record a trace in Wireshark, you won’t find process IDs in it. And sometimes this information is necessary to investigate the problem you are facing. I run into one of such issues this week. I needed to locate a process on a Virtual Machine (local address 10.0.2.5) which was still using TLSv1 to connect to our load balancer. At first, I only recorded traces in Wireshark and filtered them (ssl.record.version == "TLS 1.0"):

initial-tls1-trace

Apparently, the requests were there. As the whole traffic (except handshake) was encrypted it was not possible to guess who was sending those packets. Fortunately, TLS is using TCP underneath and each TCP packet has a port number which uniquely identifies a process at a given time. So if we collect this information while recording the Wireshark trace, we will be able to finish our analysis. My preferred way to do this is by using Process Monitor. As the Process Monitor trace may grow very quickly it is a good idea to drop all events except TCP/IP category (Filter -> Drop Filtered Events):

procmon-trace-tls1

With procmon running, we may re-record the network traffic in Wireshark. When we finish, we need to change the default time format in Wireshark (View -> Time Display Format -> Time of Day or just press Ctrl+Alt+2) to the one used in Process Monitor. Now, it is time to locate one of the suspicious events and save its time and the source port:

highlighted-event-tls1-trace

With this information, we can locate the corresponding event in the procmon trace, and by checking its properties, learn a lot about the process which created a given network packet. The time of the event will slightly differ (Wireshark uses WinPcap/npcap driver while Process Monitor relies on ETW TCP/IP events) but usually, it shouldn’t be a problem. If you look at the procmon screenshot above you will see that the process I was looking for was ImageVerifier.exe.

If you need to perform such a diagnosis remotely and you have access only to the command line on the remote machine, you may consider using TShark and wtrace (with arguments: –filter TCPIP –nosummary) in place of Wireshark and Process Monitor.

Note: if you are using Microsoft Message Analyzer the process ID is in the trace. But because of its memory consumption and sluggishness I stick to Wireshark and Process Monitor.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.