Ever wondered what is flowing over your network? Is some compromised machine distributing spam? Are emails being sent over an authenticated connection? Are login credentials being transmitted unencrypted? These are some questions a network sniffer can help answering, opening a window on the network lifeblood.

In this article I will be using the Microsoft Network Monitor version 3.2. The first Network Monitor releases were included with Windows 2000 and 2003. This could be installed directly from the Add/Remove Programs applet. The latest release is downloadable from the Microsoft Download Center. Version 3.2 now supports Windows Server 2008, 2003, Vista and XP. At the time of writing version 3.3 Beta was being finalized as announced in the Network Monitor blog. So you may want to double check for a newer release.

Network Monitor Background

Network Monitor is made up of a driver that captures traffic reaching the local Network Interface Cards NIC and a UI that allows us to analyze the collected data. Even though the monitor interface does a good job in organizing and filtering captured data at the end we are still looking at raw network traffic. Thus a basic understanding of the transport protocol namely TCP and UDP certainly helps.

Avoiding excessive technicalities, the Monitor presents snippets of data packaged into frames. Each frame includes enough information to identify the protocol, the source and destination hosts amongst others. Depending on the application the frame will also carry data specific to that application protocol. As we shall see the monitor also packages a number of protocol specific parsers. These allow it to provide a richer view for frames from standard protocols.

Anyone new to Network Monitor and similar sniffing tools are likely to be initially overwhelmed by the amount of data presented to them. Installing the monitor on an Exchange server, we are likely to see OWA HTTP/SSL traffic, DNS queries, SMTP traffic, and a lot more. There is just too much going on. Indeed these tools are most useful when searching for something specific. For example we could be looking for SMTP email reaching the server from some specific IP.

Using Network Monitor

Follow this link to download Network Monitor v3.2 and proceed with the installation. The initial Monitor interface presents three panes. At the bottom left we can choose the network interfaces from which data is to be captured.

To illustrate the Monitor, it is best if we immediately start capturing frames. Click on New Capture to switch to the data capture view. At this point we will be presented with five empty panes. Click Start at the top and the captured data starts filling the views.

If you run this on a live server a large number of frames will quickly populate the interface. At the left we have processes organized in a tree structure. Here we can easily recognize Internet Explorer iexplorer.exe, DNS Server dns.exe and the Exchange 2007 SMTP Transport edgetransport.exe. Note that both Hub and Edge transport servers make use of the same executable edgetransport.exe.

If you run Network Monitor on a machine where you can tightly control what is running, you will be able to determine exactly when a process shows up in the left pane. For example here I submitted a DNS query using nslookup.exe and immediately dns.exe showed up at the monitor. Likewise using telnet I submitted one email to the test Exchange server and edgetransport.exe was added. This method enables us to identify processes that are listening to a specific port.

The top right tabbed view includes the Capture and Display Filters. The former allows us to immediately limit the amount of captured data. The latter allows us to filter which of the captured frames are visible. When running the monitor for a long period of time the Capture Filter is extremely important in order to only collect frames that are relevant to our investigation. Otherwise it is very easy to fill up the disk space allocated for the capture, whose properties are configurable from Tools | Options | Capture:

Here we find the maximum storage size the Capture can consume, disk path, the number of bytes to be saved per frame etc.

The middle right pane, Frame Summary, shows the list of captured frames. Whereas the bottom right panes show the selected frame in a tree format (parsed) and as raw data. From here we can see all the details including the Source and Destination IPs, Port and the actual data exchanged.

Frame Filtering

The Capture and Display filters allow us to isolate the frames that are of interest to us. But before doing that we could already greatly limit the amount of displayed frames by selecting a specific process or a Network Conversation. For example here I selected a DNS conversation between the local server EXCHSRV and another machine MARS.

Note how the monitor automatically resolves the IP addresses and shows the machine names. Here under Frame Details I am selecting the DNS query that was submitted by MARS to resolve the domain msn.com. We can see the domain name at the Hex Details pane showing the raw data.

This is already a very useful filter. A simple method to construct more powerful filters is to right click entries under the Frame Summary and select 'Add xxxx to Display Filter', where xxxx is the name of the selected column.

This will create a filtering condition in the Display Filter area. Clicking Apply the filter is enforced hiding any frames that do not match.

Of course filters support more complex syntax allowing us to be more selective. An example follows:

Here the filter is composed of three conditions joined by AND/OR operators:
(Source == "MARS " OR Destination == "MARS ") AND ProtocolName == "SMTP"

Note the extra whitespaces following MARS. These were automatically inserted on clicking Add to Display Filter and are required since otherwise no frames would show up. This is one reason why the Add to Display Filter functionality is a good method to construct filters for starters.

This filter will allow us to see the full SMTP conversation involving MARS. MARS is the Source when submitting SMTP commands such as EHLO, MAIL and RCPT. However MARS becomes the Destination when EXCHSRV responds back (for example with a 220 success response). Thus the first part of the filter is meant to include both commands and responses in an SMTP conversation. The final part specifies that only SMTP traffic should be captured. Between if you need a refresher on SMTP commands please refer to Telnet Port 25.

To construct this filter I used the right-click 'Add xxxx to Display Filter' functionality three times. In turn, I selected MARS from the Source column, MARS from the Destination column and SMTP from the Protocol Name column at the Frame Summary view. This functionality will join conditions using an OR operator. Thus we got:
Source == "MARS " OR Destination == "MARS " OR ProtocolName == "SMTP"

With all filter string conditions joined by an OR, we would see all conversations from all protocols to and from MARS, as well as all SMTP conversations independently of the source and destination machine. However all I wanted was to see SMTP conversations to/from MARS. Thus I had to edit the filter manually, adding the round brackets around the Source/Destination portion and replacing the OR by an AND for the protocol name. If the logic behind these changes is not entirely clear I suggest you to look at the Network Monitor User Manual.

Here we worked with the Display Filter. However note that the Capture Filter supports the same syntax. Thus we could first construct, test and fine-tune a filter at the Display Filter on a sample run of frames and then copy it to the Capture Filter.

Final Tips

Network Monitor gives us a good opportunity to see for ourselves the conversations engaged over the various network interfaces. Having an understanding of the various protocols in use certainly helps interpreting the data snippets each of the captured frames is delivering. If you have a good understanding of the Application Layer protocols such as SMTP, FTP and HTTP, you will already be able to follow what is going on in many frames even without in-depth knowledge of the lower layer protocols.

Filtering captured and displayed data is what truly empowers us. The filters you will find yourself using most often are those identifying the application protocol name, the source and destination host names or IPs. When capturing frames over a long period of time it is important to configure the Capture filter instead of relying exclusively on the Display Filter. A server is normally handling a large number of requests that will quickly fill up the Capture buffer potentially loosing frames relevant to your investigation.

References

Network Monitor 3.2 Download

Network Monitor Blog

Telnet Port 25