Now we left off in part one having looked at the opening packet sequence sent by Nmap. The sequence sent began with an ICMP echo reply to ascertain whether or not a computer or network was assigned to the IP address. Furthermore, we were able to take a guess that the victim computer network was likely a Microsoft Windows based one, based on the ttl in the ICMP echo reply packet it sent back to the attacker. What we shall now do is carry on looking at the remaining packets in the Nmap scan, and pull out the remaining information which will allow us to profile the victim network.
10:52:59.078125 IP (tos 0x0, ttl 49, id 9808, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.111.17.37668 > 192.168.111.23.80: ., cksum 0xfd46 (correct), ack 85042526 win 2048
0x0000: 4500 0028 2650 0000 3106 0407 c0a8 6f11 E..(&P..1…..o.
0x0010: c0a8 6f17 9324 0050 67d1 a55e 0511 a55e ..o..$.Pg..^…^
0x0020: 5010 0800 fd46 0000 P….F..
10:52:59.078125 IP (tos 0x0, ttl 128, id 397, offset 0, flags [none], proto: TCP(6), length: 40) 192.168.111.23.80 > 192.168.111.17.37668: R, cksum 0x6813 (correct), 85042526:85042526(0)win 0
0x0000: 4500 0028 018d 0000 8006 d9c9 c0a8 6f17 E..(……….o.
0x0010: c0a8 6f11 0050 9324 0511 a55e 0511 a55e ..o..P.$…^…^
0x0020: 5004 0000 6813 0000 0000 0000 0000 P…h………
The above two packets came right after the ICMP based ones we looked at in part one. Nmap sent an ACK packet to the victim network IP of 192.168.111.23 on port 80. In terms of profiling information we do not have a whole lot here. We saw that the ACK packet received from the hacker elicited an RST packet back, as this ACK was unexpected. In essence it did not belong to a previously established connection. We still have a ttl of 128, which corresponds to the ttl we saw earlier.
10:52:59.296875 IP (tos 0x0, ttl 58, id 45125, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.111.17.37644 > 192.168.111.23.21: S, cksum 0x37ce (correct), 2010644897:2010644897(0) win 3072
0x0000: 4500 0028 b045 0000 3a06 7111 c0a8 6f11 E..(.E..:.q…o.
0x0010: c0a8 6f17 930c 0015 77d8 01a1 0000 0000 ..o…..w…….
0x0020: 5002 0c00 37ce 0000 P…7…
10:52:59.296875 IP (tos 0x0, ttl 128, id 398, offset 0, flags [DF], proto: TCP (6), length: 44) 192.168.111.23.21 > 192.168.111.17.37644: S, cksum 0x4f58 (correct), 1685290308:1685290308(0) ack 2010644898 win 64240 <mss 1460>
0x0000: 4500 002c 018e 4000 8006 99c4 c0a8 6f17 E..,..@…….o.
0x0010: c0a8 6f11 0015 930c 6473 7d44 77d8 01a2 ..o…..ds}Dw…
0x0020: 6012 faf0 4f58 0000 0204 05b4 0000 `…OX……..
10:52:59.296875 IP (tos 0x0, ttl 128, id 110, offset 0, flags [none], proto: TCP(6), length: 40) 192.168.111.17.37644 > 192.168.111.23.21: R, cksum 0xca50 (correct), 2010644898:2010644898(0) win 0
0x0000: 4500 0028 006e 0000 8006 dae8 c0a8 6f11 E..(.n……..o.
0x0010: c0a8 6f17 930c 0015 77d8 01a2 77d8 01a2 ..o…..w…w…
0x0020: 5004 0000 ca50 0000 P….P..
Following the ACK and RST packet exchange we now see the actual SYN packet sent from the hacker to the victim network, as evidenced in the packet with the S highlighted. This then elicits a SYN/ACK packet back from the victim network on its port 21. This exchange is then finalized by the RST packet sent back from the hacker’s computer to the victim network. These three packets now hold a much richer harvest in terms of profiling information.
We have the same ttl of 128 from the victim computer, but we also have the window size of 64240. Though this value is not on the list I hyperlinked to earlier, it is indeed a window size I have seen many times before from a Win32 (32 bit variants of Microsoft Windows such as Win NT, 2K, XP and 2K3). Another defining feature of a Microsoft Windows computer is that of predictably incrementing IP ID numbers. In this case we only have an IP ID value, in this case 398 in the middle packet above. We would need at least one more before being able to say with more confidence that this computer is indeed an MS Windows one. On that note let’s take a look at the remaining packets from the Nmap scan.
10:52:59.312500 IP (tos 0x0, ttl 59, id 54025, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.111.17.37644 > 192.168.111.23.80: S, cksum 0x3393 (correct), 2010644897:2010644897(0) win 4096
0x0000: 4500 0028 d309 0000 3b06 4d4d c0a8 6f11 E..(….;.MM..o.
0x0010: c0a8 6f17 930c 0050 77d8 01a1 0000 0000 ..o….Pw…….
0x0020: 5002 1000 3393 0000 P…3…
10:52:59.312500 IP (tos 0x0, ttl 128, id 399, offset 0, flags [DF], proto: TCP (6), length: 44) 192.168.111.23.80 > 192.168.111.17.37644: S, cksum 0x7913 (correct), 1685345101:1685345101(0) ack 2010644898 win 64240 <mss 1460>
0x0000: 4500 002c 018f 4000 8006 99c3 c0a8 6f17 E..,..@…….o.
0x0010: c0a8 6f11 0050 930c 6474 534d 77d8 01a2 ..o..P..dtSMw…
0x0020: 6012 faf0 7913 0000 0204 05b4 0000 `…y………
10:52:59.312500 IP (tos 0x0, ttl 128, id 111, offset 0, flags [none], proto: TCP(6), length: 40) 192.168.111.17.37644 > 192.168.111.23.80: R, cksum 0xca15 (correct), 2010644898:2010644898(0) win 0
0x0000: 4500 0028 006f 0000 8006 dae7 c0a8 6f11 E..(.o……..o.
0x0010: c0a8 6f17 930c 0050 77d8 01a2 77d8 01a2 ..o….Pw…w…
0x0020: 5004 0000 ca15 0000 P…….
The first piece of information that the hacker looks at is to see if the IP ID number increments to 399. This IP ID indeed is 399 as seen in the middle packet. With this information the hacker is quite confident that he is dealing with either NT, 2K , XP, or 2K3. Also seen in this packet sequence is that port 80 on the victim network seemingly has a service, as evidenced by the SYN/ACK, The SYN/ACK packet is ascertained by verifying the flag field in the TCP header, in this case the underline hex value of 12 or decimal 18. This value is reached by the SYN flag value of 2 being added to the ACK flag value of 16.
On to enumeration
With the hacker now knowing that both port 21 and 80 are open for business, he moves on to the enumeration stage. What he needs to know now is what type of webserver is listening for connections. It would be pointless for him to use an Apache exploit on an IIS web server. With that in mind he opens up a cmd.exe session and fires up netcat.
C:\>nc.exe 192.168.111.23 80
HTTP/1.1 400 Bad Request
Date: Mon, 06 Aug 2007 15:11:48 GMT
<html><head><title>Error</title></head><body>The parameter is incorrect. </body>
We can see in the above noted netcat or nc.exe syntax that he types in the victim’s IP address as well as port number 80. Once he hits enter he types in the HTTP verb of GET followed by some gibberish. This causes the victim network webserver to send back its system information as it does not understand the request. In essence it enumerates itself :-). So the hacker now knows that he is looking at Microsoft IIS 5.0. Excellent news indeed, as he has a variety of exploits for this version of IIS. All nicely bundled within the Metasploit framework.
With the hacker having scanned the victim network using Nmap a crucial series of packets were then received by the hacker. Buried within those packets, as we saw, was enough information for the hacker to take a very educated stab at the operating system, architecture, and with netcat, also the server type.
- We had an incrementing IP ID number which point to MS Windows.
- We had a ttl of 128 which again points to MS Windows.
- The ttl of 128 also points to an Intel x86 architecture vice say SPARC.
- Via netcat we then saw that the webserver was MS IIS 5.0.
All in all, not a bad haul of information. This allowed the hacker to profile the host, architecture, and service offered. With this information in hand the hacker was now ready to launch an attack on the victim networks webserver. In part three we will see just that. See you then.
If you would like to read the other parts in this article series please go to:
- Analyzing a Hack from A to Z (Part 1)
- Analyzing a Hack from A to Z (Part 3)
- Analyzing a Hack from A to Z (Part 4)