Case Study: Suspicious Network Traffic

In this post I describe a recent investigation of suspicious network traffic on an organization’s network. Although the traffic ended up not being malicious, the hope is that the basic investigation methodologies described may be helpful to those in similar situations. The tools used include Wireshark network monitor, select Sysinternals utilities, and those built into the Windows OS.

The Issue

Suspicion was raised by an admin who, while troubleshooting another issue using the netstat command, noticed connections to his workstation from a machine that should have no reason to communicate with him. The connection would close, but seemed to reappear at regular intervals, usually only being seen in the CLOSE_WAIT state.

Investigation

The initial step I attempted in the investigation was to identify the user of the offending workstation using the Sysinternals psloggedon utility, which revealed that no one was currently logged onto the machine. Not knowing the exact physical location of the machine, the next step taken was to start a packet capture in an attempt to further identify the nature of the traffic. Wireshark was used to log packets, and after about an hour a session from the suspect machine was logged. Examining the packets showed that the machine was initiating an SMB connection to TCP port 445. It would first connect to the IPC$ share, then attempt a null session connection to the named pipes \srvsvc (server service RPC server) and \wkssvc (workstation service RPC server), both of which would fail with “STATUS_ACCESS_DENIED” SMB messages. This pattern would repeat several times a day.

While there are valid reasons a null session MSRPC connection would be attempted, it could also be a sign of malicious intent. Needing more information, a remote command prompt was opened on the machine using psexec. This allowed for running netstat with the -o switch which shows the ID of the process associated with any open sockets. After repeating this command a number of times, a connection with the suspect traits finally appeared and the originating process ID was found. Once this was obtained, the tasklist command was used to get the process name associated with the PID. The process was identified as “rssensor”. The final step to identify the process was to search the hard drive for an executable by this name. This was done using the dir command to list directory contents then piping that output to the find command to only display files matching the search string: dir /s /b c:\ | find /I “rssensor”. Had this not yielded any results, a simple Google search likely would have worked.

The Culprit

The final step above found an ressensor.exe binary, and based on the installation path revealed that it was the McAfee Rogue System Detection software, a policy compliance option that had been deployed by an IT security group elsewhere in the organization. The software was supposed to be passive, but further research revealed that it “performed NetBIOS calls on systems to obtain additional information”, which is what we were seeing.

The methods used in this case were only several of many that could have been used to explore this issue further. The goal here was to show the ease with which such investigations could be conducted using a simple and readily available tool set. What other methods of identifying the source of this traffic may have been considered?

Originally published at TechScrawl.com

Subscribe to TechScrawl via RSS

Advertisements

One Response

  1. Usefull Articles, thanks for sharing

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: