The packet analysts “self check”
One thing all members of our packet analysis team do every once in a while is to check what their own laptop/PC is doing on the network – meaning, that we just close all programs and run Wireshark to see what packets are still going in and out. If we’re in paranoid mode for some reason, we even grab a network TAP and an additional “known good” PC to capture the packets, just to make sure that no malware is hiding packets from us. Sometimes we also let some program run to see what it does while the user doesn’t do anything. And as my buddy and “trace connoisseur” Eddi (also, one of the most paranoid IT people I know ;)) always says: “You need to be able to explain each and every packet that goes in and out of your PC.”
So what happens if I find something I can’t explain? That’s when the detective work starts, of course. First of all, I check if the process that is doing the communication is still active, simply by running netstat on a command line. If it is, it allows me to identify the program executable doing the talking, which helps a lot of deciding if it is unauthorized or unwanted communication or not. Let’s take a look at an example where I found a conversation that was already ongoing when I started the capture on a test system and I couldn’t tell what it was:
So I fired up my trusty command shell and ran “netstat -ano” to get a list of all ports together with the process ID of the program that was using it. I found the conversation by comparing IP addresses and ports, and the session was still in “established” state. Since I had added the “-o” parameter the right most column told me the process ID (PID):
Next step is running the system’s task manager to find the process with the ID 1504 (or better yet, Process Explorer, but let’s see how to do it without). I selected the “Processes” tab and went into the menu to add two non-standard columns, by clicking on “View -> Select Columns” and putting a check mark to “PID (Process Identifier)” and “Command Line”, which gave me this output (yes, I know, it’s all Windows and no Linux/Mac OS, but the same idea works on those operating systems as well, just with different tools):
Well, looks like Skype is doing some things in the background even while I’m not using it actively – what a surprise (not)! 🙂
Anyway, that was the simple version of finding out what caused a conversation, and it can be done even with less hassle if you have administrative rights. Because (at least on Windows Vista and up) you’d be able to run “netstat -anb” which will list the processes with their executable names instead of the PIDs.That -b parameter only works in elevated mode, for which you need to run the command prompt as administrator.
The investigation gets a lot harder if you run netstat and the connection isn’t in the list anymore because it was already terminated. In that case you have a couple of options, all of which are a lot more time consuming:
- You can try to decode the packets and find out what they are used for. A lot of programs seem to use some sort of HTTP communication these days, so if you see GET requests you may be able to tell what the target host is, and what the parameters are. An example would be another tool that is running on a lot of PCs in the background: Dropbox.
And even if the program isn’t using HTTP you might still be able to read some of the content if it is in clear text.
- You can enable GeoIP look ups in Wireshark in the name resolution settings (actually, you also need to get GeoIP databases and unpack them first), which will often tell you what company owns the IP address your PC is talking to:
- And the last (but most complicated approach) would be to leave Wireshark running for a while, filtering on the target IP to see if it comes up again in another conversation. Maybe a quick “netstat -anb” can help to see the executable before it disappears again. Otherwise you could still look for DNS queries for the target IP to see what domain name it was. You can force Windows to forget its DNS cache by running “ipconfig /flushdns“, so it has to ask next time.
Discussions — No responses yet