Starting from Windows Vista, Microsoft in its operating systems switched to a new network stack - Next Generation TCP / IP Stack. The stack includes many different buns: the Windows Filtering Platform, a scalable TCP window, and other goodies, but this is not about them at all, but about one specific behavior of the new network stack.
Any self-respecting network scanner must be able to determine the OS of the scanned node, and the more parameters are used, the more accurate the expected result. For example, the Nmap network scanner uses a very wide set of metrics to determine the operating system: various TCP metrics (behavior of timestamp values, TCP options reordering), IP metrics (packet sequence number generation algorithm, processing IP packet flags), and other metrics.
We at Positive Technologies also collect metrics and determine the OS version, so I would like to tell you about a metric I recently discovered that allows us to identify Windows systems with a new stack.
The method is based on the analysis of ICMP Timestamp responses. ICMP Timestamps (ICMP Timestamps) is a distant ancestor of the time synchronization protocols, allowing you to query the time set on a remote system. The structure of the request and response ICMP Timestamp is shown in Figure 1.
Figure 1 - Structure of the response to the request ICMP Timestamp
The standard ICMP header is highlighted in red, then there are the timestamp fields for the moment of sending the request, the moment of receiving the request by the user acting remotely, and the time the response was sent by this user. Timestamps - the number of milliseconds elapsed since midnight UTC. If the host does not have the ability to transfer data about his time to the accuracy of milliseconds, then he should set the most significant bit to one and transmit at least some data about the time. We are interested in the last label. The fact is that Microsoft, as is often the case, approached the RFC implementation rather frivolously: instead of the network byte order, Windows sends a timestamp with the host byte order and does not set the high bit to one, even though it sends timestamps with Accurate to the second. Moreover, starting with Vista, for reasons that can only be guessed, Windows systems create strange timestamps.
The expected behavior of the time stamps is depicted in Figure 2. The blue dots on the graphs are responsible for the time stamps received from the server, and the server time graph is marked in red. The abscissa axis on the graphs shows the time from the start of the experiment, the ordinate axis represents the value of time marks in seconds. The string <applied translation> indicates that a transfer was made from the network byte order to the host order.
Figure 2 - The normal behavior of time stamps
')
However, the picture shown in Figure 3 (in a higher temporal resolution) was actually observed.
Figure 3 - Behavior of time stamps on a large scale
It can be seen that with a period of one second, the value of the time stamp sent is increased from true to greater than true by 10,000 seconds. The gaps that are visible on the graph are just a consequence of the fact that the Windows scheduler decided that it was time to interrupt the execution of our program.
Probably, with such timestamps, Windows wants to confuse an attacker trying to find out the time on a remote host. This behavior is observed only for Windows systems with a new stack, which allows you to implement a new way to identify these systems.
Thanks for attention.
Sources:
Next Generation TCP / IP Stack in Windows Vista and Windows Server 2008Depths and Tops of the Network Stack by Vista Chris Kaspersky aka MyshchNmap Network Scanning. Chapter 8. Remote OS Detection