a binary log file is a file containing network packets, stored in a form such that the packets can be interpreted by a packet capture tool. in general, a binary log file is created by a tool which captures packets received over a network, applies some (possibly trivial) filter to restrict capture to interesting packets, and stores those packets to a file in the appropriate format.

all of tcpdump, snort, and ethereal use the libpcap library routines to capture and log packets by default, so a binary log file made with any of these tools can be read by the others as well.

md5 is a message digest algorithm. it takes as input any amount of data, and produces a fixed-length (128-bit, in this case) "fingerprint" of that data. when a message (such as a file) is transmitted between two parties, the md5 signature of that message can be sent as well, or can be referenced from a trusted location. this decreases the likelihood that:

• the file has accidentally been changed in transit (because the fingerprint will change if a bit has been flipped), or
• the file has been intentionally corrupted in transit (because md5 is a relatively strong algorithm, so it is computationally hard for an attacker to come up with a second message which has the same md5 signature as the first.)

192.168.0.9

attack packets were also received from 192.168.0.199, 192.168.0.254, and 192.168.0.1, but it is likely that those source addresses were forged. (the ethernet addresses of packets from all four sources were the same, though that address probably corresponds to a router on the victim network rather than to the attacking machine itself.)

192.168.0.99

the five scans were as follows:

1. tcp SYN (half-open) scan of ports 1-65535.
   • in this scan, the attacker sends packets with the SYN flag set (as if to open a TCP connection). the victim responds with a RST if the port is closed, and a SYN/ACK if the port is open. if the victim responds with a SYN/ACK, the attacker does not send another ACK to finish the connection, but instead sends a RST. the hope of this attack is that the victim will not log the packets sent in this way, because the TCP handshake was never completed.
2. tcp NULL scan of 1152 ports (probably from a services file).
   • according to the TCP specification, if a closed port receives any packet, it must respond with a RST. if an open port receives an unexpected packet with no SYN or ACK flag set, it must disregard that packet. thus, open ports are those which do not respond to this scan, which can be used to get around firewalls that log SYN packets. also, some operating systems have TCP stacks which do not implement this requirement correctly, so this scan will fail, likely identifying the presence of such an OS. TCP was implemented correctly in this regard on the victim OS in this case.
3. tcp UPF (XMAS tree) scan of ports 1-1024.
   • this scan sets the URG, PSH, and FIN flags of the attack packets. it has the same advantages as the NULL scan, but, in this case, is being run on ports 1-1024. those ports are often more interesting to an attacker of a target machine running unix, because they can only be accessed by a process with root priviledges on that machine, so compromising a service running on one of those ports might be more likely to lead to root access.
4. tcp connect() scan of 1152 ports (as above).
   • this scan simply finds out whether a port is open by trying to form a TCP connection with the standard handshake. the attacker sends a SYN, and, if the port is open, the victim sends a SYN/ACK, and the attacker sends an ACK. after that, the attacker abandons the connection, closing it with a RST. this attack does not require root priviledges on the originating host, because it uses standard TCP packets rather than crafting its own.
5. tcp XMAS tree scan of 1152 ports (as above) from attacking host with three decoy IP addresses.
   • this is an XMAS tree scan as above, but has the additional feature that only 1/4 of the packets are labelled as originating from the attacker's IP. the remaining packets are forged from three other addresses. in this case, the attacker's actual IP address is easy to find due to the previous scans, but, in a real attack, this method could make it difficult for the victim administrators to block access from the attacking address without also blocking access from innocent IPs, possibly those belonging to legitimate users.

in addition, scans 2, 3, and 4 finish with some tests to try to identify the operating system on the victim hosts. these tests use various idiosyncracies of TCP implementations, such as responses to unused flag fields, to try to identify the operating system.

the tool used was probably nmap. this is my guess because:

• nmap generally starts each scan by pinging the victim host, and then by making a TCP connection to port 80 on the victim host. this behaviour was present in the log file.
• nmap has simple command-line arguments for:
  • performing tcp connect(), SYN, null, and XMAS tree scans
  • selecting a range of ports numerically or by including ports from a services file
  • using decoy ip addresses to mask the source of the scan
  in particular, the command lines used for the five scans were probably something like:
  1. nmap -sS -p1-65535
  2. nmap -F -O -SN
  3. nmap -p1-1024 -O -sX
  4. nmap -F -O -sT
  5. nmap -F -sX -D 192.168.0.1,192.168.0.199,192.168.0.254
• the identification of operating systems by crafted TCP packets is an nmap feature (-O), and nmap happens to implement it by making various types of connections to the first closed port found on the host (port 1), and the first open port found on the host (port 22). the scan done on the victim host in this case had that pattern.

the purpose of port scanning is to find out what ports are open (accepting connections) on a target machine, in the interest of launching a future attack on those ports. the fact that a port is open does not (in general) necessarily allow one to access the machine, but many port numbers are typically used for well-known services, so, if those ports are open, it is likely that the target machine is running those services.

further scans of different types can be used (on both open and closed ports, in some cases) to try to identify the operating system of the victim machine based on the details of its tcp/ip implementation, and, similarly, to try to identify the particular manufacturer and version of server program running a well-known service. these details make it possible to launch an attack on the first try which is likely to succeed on the target machine.

• 22 (well-known port for ssh server)
• 53 (well-known port for dns server)
• 80 (well-known port for http server)
• 111 (well-known port for sunrpc's portmapper)
• 443 (well-known port for ssl)
• 32768 (port frequently assigned to rpc.statd by portmapper on redhat linux)