** 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.
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.
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.
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.
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.
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.
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.
What would cause a TCP CHECKSUM INCORRECT for every packet my client machine ACKs? Whether it be in response to MSN Messenger, browsing, file transfers or internet radio. The client seems to communicate with everything fine, but this is just strange.
If I try to subscribe via RSS I am getting a feed validation error on this article (XML failure). Specifically there seems to be an invalid character for the encoding at the end of the article title. The feed validator gives …
This feed does not validate.
line 168, column 74: ‘utf8’ codec can’t decode byte 0xa0 in position 23108: unexpected code byte (maybe a high-bit character?) [help]
Packet School 101 – Part 4?
I look forward to reading the articles!
Please reference http://www.chrissanders.org/?p=54 for more info about the differences (or lack thereof) between Ethereal and Wireshark.
I have asked about the bad TCP checksums myself, and been told that it is basically a problem Wireshark has with network cards that do on-board checksumming. If I remember the explanation correctly, if the OS knows that the NIC can do checksums in hardware, it will never calculate the correct checksum itself, but since Wireshark gets the packet before the NIC does, it picks the checksum up as invalid.
You can disable this warning in Wireshark, under the Preferences -> Protocols -> TCP settings there is a checkbox for “Validated the TCP Checksum if possible.” Assuming that you know the packets to be valid, disable that checkbox, just be aware that it may hide legitimately bad checksum warnings (though you will see other symptoms in response packets etc.)
I would like to run ethereal on a server(WIN2003) on 2 seperate NICs. How much system resource is required? Any latency added to ports? Ready for next installment of training. Thanks.
Who are these firewall admins who “when configuraing firewall filtering rules most administrators will completely ignore UDP and only focus on TCP”?
I work in network security, and I’ve never met any of them. I’ve never known anyone to distinguish between TCP or UDP when deciding whether to allow or block ports, only on require functionality … ie, allow that which the business needs, block everything else.
Otherwise, congratulations on an interesting and useful series of articles.
Regarding TCP checksum errors, the answer is in the wireshark / ethereal FAQs, which are well worth a skim;
The Packet School is really cool !
Please continue 🙂
When I try to download spyware.dmp–the first trace file listed above–avast! ver 4.7 gives a trojan horse warning: Win 32: Rbot-PH.
Any ideas? BTW, I’ve really enjoyed the Packet School segments you’ve posted thus far. As Craig said above, please continue.
Chris, this is great. I downloaded WireShark, and then read all 4 of your tutorials. I can’t wait to fire up WireShard and go through it again. Please keep the tutorials going.
yeah! more tutorials!
we’ll keep reading and learning!
Very good tutorial. Thank you. I saw a virus capture on wireshark but mcafee kept saying it WAS the virus. Any hopes for a tutorial on something like “ms701.exe”?
Great tutorial, many thanks
Hey this tutor roxx i have been using it for a few hours now and already i have found a fix many problems on my home network. thanx for tut. they where really helpful keep them comin.
Dude you are absolutely awesome!
Thanks for sharing all this information with us.
Just in the past hour I have learned more about wireshark than I have learned in a year.
Thanks a lot!
Hi Chris –
Thanks for your hard work on packet analysis. I was hoping for more lessons. Do you have any more samples?
practical examples … making the hard stuff easy to understand … really cool!
Thumbs up! Where is Part 5??
Well really cool to understand the concepts!
Fandabidozie, keep em comin please Chris, it has been very helpful! Thank you.
Excellent – thanks for having the mission to create such an excellent series. Just starting out with all this networking stuff and this has really given me an incentive to learn so much more.
Its really helpful, thanks for the great job done.
May i expect more tutorials from you on much more deeper aspects.
Thanks once again.
Please let me know whether you have more publications about sniffing. I read 4 articles from packets school 101. is there anythig more. really it was very helpful and really appreciate for your effort. please let me know the link where i can find more examples.
Hi, i just been following your tutorials and this is really a big help. When are updating this topic about Ethereal?