Which Process is Making the Network Connection?

Netmon netsh process

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:

Netmon open 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:

netmon etl file process

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.

Did you like this post? Maybe your friends will too!