Profiling an Operating System (Part 3)

If you would like to read the other parts in this article series please go to:

Profiling an operating system Part III

We finished off in part two having run the same test criteria of a SYN, RST, and an ACK packet against Windows XP Pro. The return stimulus, or lack of, was the same as that of the Windows 2000 Pro box. In this third part we will now try it against a Windows 2003 Standard box. After that is done we will carry on with another method of identifying a Windows or Win32 (Windows NT/2000/XP/2003) operating system.

On with the show

So we will now send a SYN packet to the W2K Standard box on its TCP port 135. The syntax used in Hping is as follows:

Hping -S 192.168.1.106 -p 135 -c 1

This will send a SYN packet as noted by the “-S” to the IP address of “192.168.1.106” on the TCP port 135 as seen in “-p 135”, and lastly it will only send one packet “-c 1”. The ability to send a precise amount of packets is one of the defining features of Hping in my mind. It gives the pen-tester the ability to be stealthy and blend into network traffic when performing a pen-test. Noted below is the SYN/ACK returned from the W2K3 box and the response from the laptop to this packet. Let’s take a look at it below.

16:21:27.062500 IP (tos 0x0, ttl 128, id 6801, offset 0, flags [DF], proto: TCP
(6), length: 44) 192.168.1.106.135 > 192.168.1.101.2607: S, cksum 0xbbd6 (correct), 4185246458:4185246458(0) ack 575040370 win 64320 <mss 1460>
0x0000:  4500 002c 1a91 4000 8006 5c1b c0a8 016a  E..,[email protected]…\….j
0x0010:  c0a8 0165 0087 0a2f f975 cafa 2246 6b72  …e…/.u..”Fkr
0x0020:  6012 fb40 bbd6 0000 0204 05b4            `[email protected]……..



In the above packet we see the W2K3 box respond on its port 135 with a SYN/ACK to the laptop. This is as it should be for there is a service listening on port 135. The “S” and the “ack” underlined portions tell you this packet is a SYN/ACK one, as does the “12” I underlined. This hex value of “12” breaks out to 18 in decimal and represents both the SYN and ACK being set in the flags field in the TCP header.

16:21:27.062500 IP (tos 0x0, ttl  64, id 3, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.1.101.2607 > 192.168.1.106.135: R, cksum 0x9352 (correct),575040370:575040370(0) win 0
0x0000:  4500 0028 0003 4000 4006 b6ad c0a8 0165  E..([email protected]@……e
0x0010:  c0a8 016a 0a2f 0087 2246 6b72 0000 0000  …j./..”Fkr….
0x0020:  5004 0000 9352 0000 0000 0000 0000       P….R……..


Now we see in this packet that the laptop sends back a RST packet back to the W2K3 box. Why does it do this? After all it did send a SYN packet to the W2K3 box, which in turn responded properly with a SYN/ACK. Well it returned an RST packet as there was nothing on the laptop that was trying to initiate a TCP/IP three way handshake. All that was sent was an SYN packet. There was no corresponding ACK to the W2K3’s SYN/ACK, hence the RST packet. In essence, what we saw is a typical SYN packet scan. Lastly you will note that the port pair of 135 and 2607 remains constant during the length of the session between the two computers. This is also as it should be. The ports would change were the session finalized and another attempt made to communicate.

Now in the interest of brevity I will say that the W2K3 box responded the same way to the RST and the ACK as did the W2K and the XP Pro ones. There was no response to the RST, and the ACK packet was responded to with an RST. So in essence the W2K, XP and the W2K3 all responded in the same way to the stimulus. There were no variations found. While the testing was not extensive, so far we have found no defining features to differentiate them apart. That is not to say that with other creative probing we could not find some differences. On that note I would encourage you to try some creative probing. We shall now go on to another method of identifying a Win32 computer. This entails sending a series of packets to a computer to see if the IP identifier (IP ID) number increments predictably. In the case of Win32 it will increment by one. Let’s give it a shot.

Hping -S 192.168.1.106 -p 135 -c 3

Now we can see in the packets displayed below that the IP ID numbers do indeed increment predictably. This oddity was first noticed by the creator of Hping, Salvatore Sanfillipo and reported to Microsoft. To this day Microsoft has yet to fix this. This predictability is useful in conducting what is known as “blind side scanning”.

16:37:03.203125 IP (tos 0x0, ttl 128, id 6810, offset 0, flags [DF], proto: TCP
(6), length: 44) 192.168.1.106.135 > 192.168.1.101.2715: S, cksum 0x63ff (corre
t), 1400886649:1400886649(0) ack 872893588 win 64320 <mss 1460>
        0x0000:  4500 002c 1a9a 4000 8006 5c12 c0a8 016a  E..,[email protected]…\….j
        0x0010:  c0a8 0165 0087 0a9b 537f d579 3407 4c94  …e….S..y4.L.
        0x0020:  6012 fb40 63ff 0000 0204 05b4            `[email protected]…….




16:37:04.218750 IP (tos 0x0, ttl 128, id 6811, offset 0, flags [DF], proto: TCP
(6), length: 44) 192.168.1.106.135 > 192.168.1.101.2716: S, cksum 0xccb5 (corre
t), 4098910578:4098910578(0) ack 18735612 win 64320 <mss 1460>
        0x0000:  4500 002c 1a9b 4000 8006 5c11 c0a8 016a  E..,[email protected]…\….j
        0x0010:  c0a8 0165 0087 0a9c f450 6972 011d e1fc  …e…..Pir….
        0x0020:  6012 fb40 ccb5 0000 0204 05b4            `[email protected]……..




16:37:05.218750 IP (tos 0x0, ttl 128, id 6812, offset 0, flags [DF], proto: TCP
(6), length: 44) 192.168.1.106.135 > 192.168.1.101.2717: S, cksum 0x1341 (corre
t), 600269850:600269850(0) ack 1314661395 win 64320 <mss 1460>
        0x0000:  4500 002c 1a9c 4000 8006 5c10 c0a8 016a  E..,[email protected]…\….j
        0x0010:  c0a8 0165 0087 0a9d 23c7 641a 4e5c 2413  …e….#.d.N\$.
        0x0020:  6012 fb40 1341 0000 0204 05b4            `[email protected]……




So we see that those IP ID numbers definitely do increase in a predictable fashion. Please note that I have not pasted in the SYN packets from the laptop that caused the generation of these SYN/ACK packets.

Wrap Up

What have we learnt so far? Well we saw that with a little creative packet crafting and some Internet based information as evidenced in the hyperlink in part one, we can make a pretty good guess of what operating system it is that we are looking at. That is what I mean by architectural profiling. Windows and specifically the Win32 variants, all have a default ttl of 128 and other specific TCP/IP stack metrics. By using those metrics you can say that you know the said operating system is a Win32 one, vice say SPARC, which has a lower ttl of 64, as well as other differences. In part four of this series we shall carry on with host profiling. You shall see just what it is that you can pull out of NBTSTAT and be shown how to read that information. Knowing how to understand the output of NBTSTAT can be very helpful to you as a pen-tester. After all, there is little point in attacking a computer with IIS 5 exploit code if it is only a simple workstation. On that note I shall see you soon.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top