Beginners Scan of the Month Challenge
Richard La Bella, South Florida Honeynet Project
September 30, 2002
This was the first beginner scan of the month challenge. This challenge took place during the month of September 2002. The South Florida Honeynet team manually generated five different types of portscans from the Internet to a single honeypot. The portscans were captured to a binary log file in tcpdump format. The challenge was to answer eight questions plus a bonus question by decoding the analyzing the binary file. The South Florida Honeynet Project and the Honeynet Research Alliance congratulate everyone who took a stab at this challenge. You all did great.
We used the following tools and binaries to help us analyze the binary log file on a Red Hat Linux 7.3 system running kernel 2.4.18-3.
Before we can answer any of the Challenge questions we must first download the binary log file to our system using the "wget" command:
# wget http://old.honeynet.org/scans/scan23/sotm23.tar.gz
Next, we must verify the integrity of the sotm23.tar.gz file we just downloaded by running a command known as "md5sum" on Red Hat Linux to verify the hash.
# md5sum sotm23.tar.gz
The resulting output returned back to us looks like so:
# 9d28c5ee9ce7b77e3099a07ad303811f sotm23.tar.gz
Now let's compare the md5sum from the Challenge page where we downloaded the file from to our output above. We go back to http://old.honeynet.org/scans/scan23 to check if the results match. They do. So far everything looks good.
At this point, we can unpack and verify the archive.
# tar zxvf sotm23.tar.gz
Two files were successfully unpacked. They are:
The first one is the binary log file we are going to use during our analysis. The second one is an md5 hash of the binary log file.
Let's verify the checksum of the snort.log binary file. Remember, we do this to check the integrity of files. Specifically the email@example.com file just like we did with the archive file in Step 2.
# 0ce142f18c23d9ab00f992a57ad097d4 firstname.lastname@example.org
Let's compare our output with the md5 hash email@example.com by the South Florida Honeynet Project.
# cat firstname.lastname@example.org
# 0ce142f18c23d9ab00f992a57ad097d4 email@example.com
As we can see from our work above the integrity of the snort binary file is in good standing. Now, we can get started with our analysis and begin the Challenge.
1. What is a binary log file and how is one created?
A binary log file is a file capture of binary data 1's and 0's. Binary logging is sometimes referred to as "raw" traffic capture because we are capturing packets in their most raw form (ones and zeros). For network intrusion detection systems placed in high traffic areas of a network, binary capture is much more beneficial. (1) We are in a better position not to lose packets during the capture phase, and (2) binary files are lower in size than say, an ASCII text file. Traffic can be captured in binary form using a promiscuous mode interface, a hub, a tap, or from a span port off a router or switch. The underlying functionality used to capture traffic off the wire is a packet capture library known as the Libpcap library. Libpcap is a standard library used for sniffing traffic on a network segment using tcpdump, snort, and ethereal. A windows version of the libpacp library is winpcap. This allows us to run tools like Ethereal and Snort in a Windows environment as well.
To create a binary log file using Snort:
# snort -l /var/log/snort -b
To read the file back:
# snort -vde -r snort.log
To create a binary log file using tcpdump:
# tcpdump -w ./log
To read the file back:
# tcpdump -r log
To create a binary log file using Ethereal at the command line:
# tethereal -w log
To read the file back on the command line:
# tethereal -r log
You can use Ethereal's GUI to read binary log files as well. Just type ethereal at the command line to run the GUI version of Ethereal.
2. What is MD5 and what value does it provide?
The MD5 algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA.
The value MD5 provides is one-way hashing used to cryptographically secure the integrity and authenticity of a message, data, a file, etc.
3. What is the attacker's IP address?
To figure out what the attacker IP address is we opened up the binary log file into Ethereal. We can see right away the source IP of our attacker is 192.168.0.9 due to the ICMP ECHO request, HTTP ACK, and SYN flag scans sent to the victim, 192.168.0.99. Ping's or ICMP ECHO Requests are common tactics used to test if a host is up or responding to ICMP. 192.168.0.9 is our attacker.
4. What is the destination IP address?
The destination IP address is 192.168.0.99. By still observing the first five scans in Ethereal we can confirm the destination IP.
5. We scanned the honeypot using five different methods. Can you identify the five different scanning methods and describe how each of the five works?
Scan #1- SYN Scan
# nmap -sS -p 1-65535 192.168.0.99
TCP SYN scan: This technique is often referred to as "half-open" scanning, because you don't open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and you wait for a response. A SYN|ACK indicates the port is listening. A RST is indicative of a non-listener. If a SYN|ACK is received, a RST is immediately sent to tear down the connection (actuallyour OS kernel does this for us). The primary advantage to this scanning technique is that fewer sites will log it. Unfortunately you need root privileges to build these custom SYN packets. This is the default scan type for privileged users.
Scan #2- NULL Scan with O/S Detection
Scan #3-XMAS Scan with O/S Detection
# nmap -sX -p 1-1024 -O 192.168.0.99
Stealth FIN, Xmas Tree, or Null scan modes: There are times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to restricted ports, and programs like Synlogger and Courtney are available to detect these scans. These advanced scans, on the other hand, may be able to pass through unmolested.
The idea is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the packets in question (see RFC 79364). The FIN scan uses a bare (surprise) FIN packet as the probe, while the Xmas tree scan turns on the FIN, URG, and PUSH flags. The Null scan turns off all flags. Unfortunately Microsoft (like usual) decided to completely ignore the standard and do things their own way. Thus this scan type will not work against systems running Windows95/NT. On the positive side, this is a good way to distinguish between the two platforms. If the scan finds open ports, you know the machine is not a Windows box. If a -sF,-sX,or -sN scan shows all portsvclosed, yet a SYN (-sS) scan shows ports being opened, you are probably looking at a Windows box. This is less useful now that nmap has proper OS detection built in. There are also a few other systems that are broken in the same way Windows is. They include Cisco, BSDI, HP/UX, MVS, and IRIX. All of the above send resets from the open ports when they should just drop the packet.
Scan #4-TCP Connect Scan with O/S Detection
# nmap -sT -PT -F -O 192.168.0.99
TCP connect() scan: This is the most basic form of TCP scanning. The
connect() system call provided by your operating system is used to open a
connection to every interesting port on the machine. If the
port is listening, connect() will succeed, otherwise the port isn't
reachable. One strong advantage to this technique is that you don't need
any special privileges. Any user on most UNIX
boxes is free to use this call. This sort of scan is easily detectable
as target host logs will show a bunch of connection and error messages for
the services which accept() the connection just to have it
immediately shutdown. This is the default scan type for unprivileged
The -O option used in Scan #2, Scan #3, and Scan #4 are used for remote host identification via TCP/IP fingerprinting. In other words, it uses a bunch of techniques to detect subtleties in the underlying operating system network stack of the computers you are scanning. It uses this information to create a ´fingerprint´ which it compares with its database of known OS fingerprints (the nmap-os-fingerprints file) to decide what type of system you are scanning.
Scan #5-XMAS Scan with Spoofed Decoys
# nmap -sX -F -D 192.168.0.1, 192.168.0.254, 192.168.0.199 192.168.0.99
-D Causes a decoy scan to be performed which makes it appear to the remote host that the host(s) you specify as decoys are scanning the target network too. Thus their IDS might report 5-10 port scans from unique IP addresses, but they won't know which IP was scanning them and which were innocent decoys. While this can be defeated through router path tracing, response-dropping, and other "active" mechanisms, it is generally an extremely effective technique for hiding your IP address.
6. What scanning tool was used to scan our honeypot?
I made this part easy for myself. I ran the snort.log binary file through our Snort NIDS using the ACID console database. This way the snort.conf file would know exactly what to do with the alerts. In our case the snort.conf file was configued to log all alerts to our snort MySQL database where could view the file through ACID. ACID is known as the Analysis Console for Intrusion Databases.
# snort -vde -r firstname.lastname@example.org -c /usr/local/snort/eth3/snort.conf
After searching the database for a while, I clicked on "unique alerts". Unique alerts showed me a total of six (spp_stream4) NMAP FINGERPRINT (stateful) detection signatures, and six SCAN nmap TCP attempted-recon. At this point I could be very confident the tool used was Nmap.
7. What is the purpose of port scanning?
The purpose for port scanning is to identify listening ports on a target system. This can be done for both good and evil. The good guys and girls will portscan a system to find unnecessary listening ports that don't need to be listening. Those ports can be closed to help protect the system from unneccessary compromise or enumeration. The evil guys and gals will port scan thousands of systems until they find a port that is exploitable then try to take over that system.
8. What ports were found open on our honeypot?
Simply by running a filter in Ethereal we could view which ports were open on our honeypot. The following filter shows all the SYN | ACK's sent back to our attacker from the victim machine.
The filter is:
tcp.flags = = 18
The following ports that answer with a SYN | ACK back to the attacking
machine are as follows:
9. Bonus Question: What Operating system was the attacker using?
The attacker is running Linux with kernel version 2.4.2 - 2.4.14. We were able to figure this out after reading the Honeynet Projects paper, Know Your Enemy: Passive Fingerprinting and then examining the database of a passive fingerprinting tool known as p0f. In Know Your Enemy: Passive Fingerprinting the Honeynet Project points out the following parameters as being key for discovering our enemy's O/S.
After looking at p0f's passive fingerprinting database, p0f.fp we collected the following information until we could make a match. For example:
Window Size 5840
DF 1 = on
Window Scaling 0
declared packet "? only one we could not find"
Next, we compared the parameters from our enemy's packets to the p0f.fp database and found that the signature above is that of Linux 2.4.2 - 2.4.14 (1).
For questions, comments and suggestions please send correspondences to