This article will show you how to quickly identify the process (application or service) that’s generating specific network communication on your system.
Sample scenario: Your network team tells you Server A is constantly making SMB requests to Server B according to firewall logs. They want you to stop the traffic on Server A.
To identify which process is causing it, you can use the built-in netsh command and the free Microsoft Netmon tool. Just follow these simple steps:
1. Start a Network Trace on the Server
Staring a network trace (aka “network capture”) on your server is pretty simple using the netsh.exe command.
Use the following command to start the trace:
netsh trace start persistent=yes capture=yes tracefile=c:\temp\NetTrace.etl
This will immediately start logging all network communication to an .etl file. The persistent switch will make sure it’s running across reboots of your system. So you can even troubleshoot issues happening during startup.
2. Stop the Network Trace Again
Once you think the communication you want to capture has taken place, you can stop the trace again. Use the following command:
netsh trace stop
3. Install Netmon on Your System
To analyze the trace file we need the free Netmon tool from Microsoft. Download it here.
You don’t need to install it on the same system where you did the network trace. Install it on your laptop and copy the .etl file to your system.
4. Analyze the Trace File Using Netmon
Start Netmon and open the .etl file:
The trace file most likely involves a LOT of information. To quickly identify the tracing info you need you must use a capture filter.
Netmon Capture Filters
Netmon supports custom filtering which makes it very easy to filter the data, once you get a hang of it. Let me give you a couple of examples:
To find all communication to a particular IP4 host use the following filter:
ipv4.DestinationAddress == 10.10.0.6
To find all communication to a particular subnet use the following filter:
ipv4.DestinationAddress >= 10.10.0.0 && ipv4.DestinationAddress <= 10.10.0.255
To filter out all broadcast, multicast and RDP communication use the following filter:
Ethernet.DestinationAddress != Broadcast && !(ipv4.DestinationAddress >= 224.0.0.0 && ipv4.DestinationAddress <= 239.255.255.255) && tcp.Port != 3389
After having implemented the right filters you’ll quickly find the communication you’re looking for.
In this particular customer case we were looking for a process generating ping requests towards the 10.10.0.0/24 network:
As seen in the above screenshot, the communication is generated by a process running with ID 12976.
5. Identify the Process
Since we know have the process ID we can log in to the server and identify what process this is:
PS C:\> Get-Process | ? {$_.Id -eq '12976'}
Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName
------- ------ ----- ----- ------ -- -- -----------
789 55 265648 68656 104,120.80 12976 0 CarboniteService
Summary
And there you have it. Identifying the process behind any type of communication on your system is actually quite easy: Use the built-in netsh command and the free Netmon tool from Microsoft.
This approach is very useful when investigating mysterious communication, analyzing GPO processing issues, network connection issues, etc.