Packet School 101 – Part 4

** Disclaimer to all new readers – This blog post is VERY old and not really representative of my current work. I’ve just left it up here for historical purposes. If you are interested in learning more about packet analysis I’d reccommend reading some of my newer posts or looking at my book, Practical Packet Analysis. **

In this segment of Packet School 101 we are going to take a look at the trace files of a computer infected with spyware and one suffering from an application fault.

Spyware Infection

In our first sample scenario, a user has called complaining that her computer is dropping its network connection three minutes or so after booting up. When this happens the computer also maxes out its processor utilization. After making some calls you verify that everybody else is running as they should be, so the problem is just isolated to this one computer. When looking at the computer, it is apparent that her problem does exist as told. So what do we do? We fire up our sniffer of course!

Examining the Packets

Click here to download the sample trace file (< 1MB)

In examining our trace file there are a lot of problems with many things going on but we are only going to focus on the one client machine we are looking out down. It’s IP address is 172.16.1.10. The first thing we notice at the beginning of the capture is that an outside IP address keeps trying to make a connection to our computer on port 26452. Our client doens’t know what to do with this traffic since it is not expecting it, and therefor sends repetitive RST packets effectively ending the communication. This obviously should not be happening, however it continues to do so until we get to packet 70 and see the client requesting a copy of a file called analiz.exe from this rogue IP address via TFTP. This file begins to download, and ironically enough, that is when the computer starts experiencing problems

The Resulting Analysis

After spending some time actually on the physical computer the process analiz.exe was found to be running. After terminating this process and removing the file via an autmated spyware scanning utility the computer began to run normally. What was happening in this case was that after a computer would boot up it would try to make a connection to the rogue IP address associated with this spyware. After a certain amount of time the client would then download an updated copy of this spyware file via TFTP and run it on the system.

This brings up several good security points to remember. The first one of these is the most obvious and that is to education your uses about spyware and how to avoid it. However, another key point to mention is that this infection did a lot of its dirty work through TFTP which is a UDP based protocol. A lot of the time when configuraing firewall filtering rules most administrators will completely ignore UDP and only focus on TCP. You can not neglect UDP protocols when doing this, as a lot of spyware will use this weakness to completely hammer your netork.

Application Fault

The next file we are going to examine is the trace of an appliciation fault that is causing a client computer to run incredibly slow. In this scenario we have a client who is complaining that their application is not working because the network is running to slow.

Digging Deeper

Click here to download the trace file (< 1MB)

When we open our trace file we can determine several things by looking at the first fewpackets. The first thing we see is communication taking place between our client and server machines. Looking at the packet times we can see those requests are happening at rates of less than a millisecond so that indicates that there shouldn’t really be any latency on the wire itself. Also, we see that the client and server are sending their data back at more than adequate rates so there shouldn’t be an issue with either of them acting sluggish.

When we get to packet 5 however, we begin to see something interesting. Our client machine is making a NetBIOS request to our server, and then in the following packet, our server (which is NOT running NetBIOS) returns an ICMP Destination Port Unreachable packet. So what is causing this NetBIOS traffic from our client? Well Wireshark provides a great interface for viewing data contained within a stream of data. In order to utilize this you will need to right click on packet number 4 and click “Follow TCP Stream”. This will show us the data contained in that stream of communication, including upper layer protocol information.

When we look at this stream of data it is clear to us what is going on. The user is attempting to use the AIDA32 application. Not only do we find out this information, but we can also see that they are doing this under the “Chadwick” user account which is in the administrators group of the local machine.

The Verdict

After looking at this TCP Stream data it is clear to see that the network is not at fault. What is happening is that the application is making a NetBIOS request to the server, and since the server isn’t running NetBIOS it responds to the applications request by saying it is busy. In the design of the application which is being used, there is no formal mechanism in place that lets the user know that the server is not accepting its communication. This means that the application is just sitting there doing nothing waiting for valid response, which it will never get. This being said, the proposed solution to this type of problem would be to enable NetBIOS on the server which the program is connecting to or find a program that uses an alternate means of communication.

Homework

Today we have analyzed to more trace files that have given us a further understanding of more packet related troubleshooting techniques. If you manage any type of network I would be willing to bet that you have problems with spyware on occasion. This being the case, the next time you see a computer with a spyware problem, sniff it’s communication. You would be amazed to see how often various spyware applications will silently “phone home” to download updates to the infection and perform various other tasks. In the next installment of Packet School 101 we will take a look at what a trace file looks like when a computer is the target of a port scan and attempted denial of service attack.

 

**UPDATE**

Enjoy Packets School 101? Check out Packet School 201!

You can have online degrees from well reputed institutions all over the world. Different constraints like; money, distance etc. will no more restrict you from getting valuable IT diplomas and certifications from any online university. Demand for professionals having MS 70-290 certifications has been increasing day by day. Presently, Microsoft is offering MS 70-536 certifications for the people interesting in learning the essentials of IT and MS 70-554 is more advance certification in this field.