I Smell Packets

Solution to the Name That Exploit Packet Challenge
June 30, 2009, 2:14 pm
Filed under: Metasploit, Packet Challenge, snort, tcpflow

Sorry for the delay in posting the solution to last week’s challenge. The good news is that the delay allowed more people a chance to submit their answers. That was good. Perhaps from now on, when I post a challenge; I’ll wait a week before posting a solution.

So without further ado, here is how I made the challenge.

For this packet challenge I decided to capture an exploit traveling across the network. To do this, I setup two machines. One machine to use as an attacker, the other to use as a victim. I then started a packet capture. The victim machine in this case was an unpatched Windows 2000 server that was vulnerable to a buffer overrun in the server service. So, I ran Metasploit from the attacker machine and chose the MS06_040_netapi exploit. After the exploit and the payload ran, I then had shell access to the victim machine. Once I had access, I created an account on the box and added myself to the Administrators group.

This brings us to the challenge. By looking at the capture, how can you tell that this is what I did? The first question in particular that I asked was, which exploit did I use? There are a number of different ways to do this, but here is what I did.

Using Snort with a recent ruleset, run the following command:

snort -r 7.pcap -c my-snort.conf -l /tmp

In the above command the -r option specifies the name of file to read. The next option, the -c option, specifies the Snort configuration file to use. Finally the -l option specifies the directory to log.

Depending upon the the configuration and the rules used, there should be some alerts. On my system there were three alerts generated. These alerts are sent to an alert file which will be located in the log directory that was specified. The following is the output from the alert file that was created by Snort:

[**] [1:7250:8] NETBIOS SMB-DS srvsvc NetrPathCanonicalize WriteAndX little endian overflow attempt [**]
[Classification: Attempted Administrator Privilege Gain] [Priority: 1] 
06/20-17:31:47.011637 ->
TCP TTL:64 TOS:0x0 ID:2994 IpLen:20 DgmLen:1114 DF
***AP*** Seq: 0x8EA7338C Ack: 0xB47F07B3 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 97799385 21705 
[Xref => http://www.microsoft.com/technet/security/bulletin/MS06-040.mspx][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-3439][Xref => http://www.securityfocus.com/bid/19409]

[**] [1:7250:8] NETBIOS SMB-DS srvsvc NetrPathCanonicalize WriteAndX little endian overflow attempt [**]
[Classification: Attempted Administrator Privilege Gain] [Priority: 1] 
06/20-17:31:47.019978 ->
TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:1259
***AP*** Seq: 0x0 Ack: 0x0 Win: 0x0 TcpLen: 20
[Xref => http://www.microsoft.com/technet/security/bulletin/MS06-040.mspx][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-3439][Xref => http://www.securityfocus.com/bid/19409]

[**] [1:2123:4] ATTACK-RESPONSES Microsoft cmd.exe banner [**]
[Classification: Successful Administrator Privilege Gain] [Priority: 1] 
06/20-17:31:47.470358 ->
TCP TTL:128 TOS:0x0 ID:279 IpLen:20 DgmLen:157 DF
***AP*** Seq: 0xB481E281 Ack: 0x41E39895 Win: 0x4296 TcpLen: 32
TCP Options (3) => NOP NOP TS: 21710 97799389 
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=11633]

Looking at the above alerts, you can see that the Xref mentioned in the first two alerts refers to the MS06-040 exploit.

As for the second part of the challenge, I asked you to tell me what I did after gaining access to the machine. This was easy. To see what happened, simply open the the capture in Wireshark and look at the payloads of the packets. You should be able see me creating an account and then adding it to the Administrators group. The following are the two commands I used to do so:

net user chris ismellpackets /add

net localgroup administrators chris /add

Viewing the payload of each packet can be a pain and it’s definitely not pretty. For pretty output, in Wireshark, select any of the packets near the bottom of the capture. Then, to see the whole session decoded, goto the Analyze Menu and select Follow TCP Stream.

This can also be done from another neat little utility called tcpflow. Tcpflow can reconstruct the actual data streams and stores each flow in a separate file. To run tcpflow type:

tcpflow -r 7.pcap

Tcpflow will create a file for each of the flows in the capture. These files will have names such as:

The contents of the above file would be the data transmitted from port 4444, to port 52555. This is the stream we are looking for. The file can be viewed with any editor. For example:



Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-1999 Microsoft Corp.

C:\WINNT\system32>net user chris ismellpackets /add
The command completed successfully.

C:\WINNT\system32>net localgroup administrators chris /add
The command completed successfully.


There you have it. A little Snort, a little tcpflow, and you’ve got your answer. There were lots of answers sent in this time. The only one who got it exactly right was Alec R Waters (@alecrwaters on twitter) Congratulations to Alec for being the first person to win twice, and back to back wins at that. Maybe we should start keeping score.

Thanks to everyone else for sending in your answers. Hope you all enjoyed it. Until next time, keep smelling packets.

The following are some links to more information about this week’s challenge:

Microsoft Security Bulletin MS06-040
Vulnerability in Server Service Could Allow Remote Code Execution (921883)

tcpflow — A TCP Flow Recorder
Manpage of tcpflow


Leave a Comment so far
Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: