This page provides an overview of the techniques I used in to examine the snort log file provided by the Honeyney Project for this Challange.
The work done was simple Packet analysis, and some Passive OS Fingerprinting.
After verifying the scan log with md5, I loaded it into Ethereal to begin my analysis of the scan. It became apparent immediately that the attack originated from 192.168.0.9 because the initial pings, both ICMP and TCP, originated from this host, as did all all the scans.
Once I'd identified the machines involved in the scan, I filtered out all traffic with a source IP of 192.168.0.9, and searched for large blocks of similiar communication. I used these blocks as my boundries for the different scan types, which I mention in my answer to Question #5. I then focused on one scan block at a time, and with some help from the nmap man page, was able to identify each type of scan.
To identify what Operating System the attacker was using, I first checked the Honeynet Project's Whitepaper entitled Know Your Enemy: Passive Fingerprinting. I decided to look at the tools listed in that paper, and found that siphon was no longer available, so I turned to p0f. I ran p0f with the snort log as input, and it confirmed my suspicion that nmap was the scanner used, and also identified the attacker as using a Linux host, which could be pulled from the traffic block using the connect() scan.
One slightly confusing piece in the logfile, was sometimes, in between scans, there would be a flurry of packets, generally RST packets, sent from the attacker, to the target host. I assumed this was just by products from the people manufacturing the challange connecting to the target, and forgot about them, as they have to real bearing on any of of the answers to the following questions.
A binary log file is a capture of all the actual IP packets that are sent across the network. There is no decoding of the packet done by the network sniffer program that is collecting the traffic, so it is essentially a bit-for-bit copy of the traffic sent across the network. These files are created using Network Sniffers, such as tcpdump, or full Intrusion Detection Systems such as Snort.
MD5 is a program which provides a "checksum" of a file. A checksum is a number which is unique to that file. They are useful in guaranteeing that the data in a file was not corrupted becuase if a single bit in a file is changed, than it will produce a different checksum. These are often used for verifying data collected in an investigation to prove that the evidence was not tampered with. They can also be useful in downloads to ensure that the file you recieved was what was on the server.
The attacker appears to be at 192.168.0.9 because that is where the initial ICMP ping request originates from, which is notable because most port scanners by default Ping a host before scanning it to ensure that it is active. Also, during the scan, almost all traffic is between 192.168.0.9 and 192.169.0.99, and the initial connection (the SYN packet) originates at 192.168.0.9.
Since the traffic is mainly between 192.168.0.9 and 192.168.0.99 and 192.168.0.9 has been identified as the attacker, 192.168.0.99 is the system that is being scanned. This is also apparent because 192.168.0.99 sends a lot of RST packets back to 192.168.0.9, a sure response that the port is not open.
First, we have a standard SYN Scan (Packets 5-148005). A SYN scan by starting to initiate a connection with a service (sending a SYN packet to that port), and waiting for a response, either a RST packet if the port is not open, or a ACK packet if the port is listening. If an ACK packet is recieved, the scanner immediately sends a RST packet to kill the connection. The SYN scan is so widely used because many hosts will not log the scan because the TCP Handshake is never actually completed.
Next we have a NULL Scan (Packets 148011-150638). A NULL scan operates by sending a host packets with all flags set to NULL. By convention a closed port will send back a RST packet, while an open port will ignore this packet. This type of scan does not work against Windows Hosts.
The third scan is a XMas Tree scan (Packets 150759-153152). In a XMas Tree scan the FIN, PSH, and URG flags are all set in the packets. Like a NULL scan, this scan is based on the fact that any closed port would respond with a RST packet, while open ports are supposed to ignore such packets based on RFC 793.
The Fourth scan is a basic connect() scan (Packets 153251-155829). A connect() scan works by completing a full TCP/IP Handshake with an open port. This type of scan is the only one that can be completed on a Unix host without Superuser priveleges on the system. This scan is also the easiest to detect since all services on the system should log a connection that was made to them.
The final scan starts at packet 156008 in the file, and continues until the end of the file. This appears to be another XMas Tree Scan, this time using nmap's -D option for decoys. There are three decoy IPs used 192.168.0.1, 192.168.0.254, 192.168.0.199, though there are a few cases where not all three decoys were used. It is clear that those hosts are decoys because Ethereal reveals them as having the same MAC address as the known attacker host.
I used the p0f program, linked to above, and it identified much of the the scans, except the connect() scan, as nmap scans. I believed nmap to be the most likely scanner before runnig p0f, however, because nmap is very widely available, is incredibly full featured, and I had used it's manual page to identify the scans for Question #5.
Port scanning is used by an attacker to enumerate what services might be running on a machine. A port scan tells an attacker on what ports the target is listening, and allows the attacker to focus a few known open ports in their search for exploitable services.
Based on the Passive Fingerprinting tool p0f, analyzing the connect() scan part of the attack, the attacker was using some form of Linux that has uses the 2.4 tree (between 2.4.2 and 2.4.12)
I was very glad to see the Honeynet Project offering a "Beginners" challange. I'd been looking at the SotM challenges for a few months, and while they were very interesting, I was never able to put together a solution for the problem. I feel that this kind of challange is most useful in making someone who is just learning Computer Forensics techniques much more familiar with the tools at their disposal, which I learned a lot about how to use Ethereal.
I would like to thank the Ethereal developers for developing such a full-featured and relatively easy to use GUI application for analyzing large amounts of traffic. Also, Fyodor and the rest of the nmap developers for taking the time to put together such a complete man page for their application. The people in irc.openprojects.net/#security for pointing me to the Honeynet Project's paper on Passive Fingerprinting, the developers of p0f for making available such a helpful tool, and everyone else who has developed high quality open-source security software to make analyzing these situations