NMAP has some useful active fingerprinting capabilities, sending a variety of packets and carrying out evaluation of virtually every packet bit. It is a great help if you have nothing more than an IP address to go on, and need to quickly narrow down the platform type (e.g. using nmap -O -sV ).
But what if you don’t have access to NMAP, and just have standard enterprise Windows tools and no specific privileges on the target system? I recently got asked this question.
A very basic approach is to look at packet properties produced by the target system. Implementations of the TCP/IP protocol suite and the supporting protocol ICMP vary in their responses, based on design choices and interpretations of standards.
These tell-tale signatures are one of the focus areas in the EC-Council CEH program.
One easy technique is to identify the Time To Live (TTL) values for ping packets, produced by the target OS. These vary based on the remote implementation, and can indicate on the one end of the scale the developer and on the other the specific product (if lucky).
In the case of an ICMP ping request, the TTL value is set in response to the ping by the target. As basic networking theory covers, the TTL value will be decremented by each device that handles the packet (i.e. the “hops”), and is designed to stop packets travelling around the Internet indefinitely. Each hop reduces the TTL value by 1, and if the TTL value reaches zero the packet is discarded. Easy stuff.
The value the sender uses is arbitrary, but has to be sufficient to cope with a reasonable number of hops typically seen on the Internet. The technique is pretty simple:
- Use traceroute to identify the number of hops to the target
- Use ping to ping the target and observe the TTL value
- Increment the TTL seen in ping by the number of hops to estimate the original TTL value
- Look up the original TTL value in TTL tables
It’s not that helpful in some cases however, particularly for recent Windows products that all share a common TTL (though it will help identify if a target could a Windows device). Combined with other information, it might be enough to produce an accurate estimate.
Remote system identification is not limited to TTL values, and any response that can be coaxed from a target might glean some useful information.
One source of information, along the same lines as TTL, is the TCP window size. This is often mentioned alongside the TTL preference of the remote system as an indicator. For instance, a TTL value of 64 applies equally to any Linux kernel 2.4 or 2.6 series. However the standard Linux kernel uses a window size of 5840, yet Google’s custom Linux uses 5720. There are many standard tables with both TTL and TCP window size data that can be used.
Another obvious source of information is a list of open ports, if available. NMAP relies on open and closed ports to start making its estimates. Using the many PowerShell scripts around for port scanning, this can easily be achieved. The list it produces may have enough content to characterise a target operating system.
Finally, it may be as easy as identifying information from an open service and grabbing either a banner or equivalent, or causing an error message to be generated and observing any version identifiers disclosed.
What NMAP offers is an automated way of fingerprinting, and beyond simple TTL values it’s a judgement exercise based on the information that can obtained. This will often require other information not obtained from the network, such as OS preferences of an organisation, contract data, and so on.
There are also some interesting passive options, using captured network data. Examples include Satori, NetworkMiner, and the command-line equivalent for Wireshark (tshark). A passive capture scenario will produce a large amount of information about the remote system fairly quickly, particularly if the system is very busy on the wire.
Of course, this is all a useful exercise in making the job of an attacker more difficult. Systems that are easier to identify make exploitation attempts much easier. If you’re not using host-based firewalls, you might be exposing a lot more information to a remote fingerprinting tool than intended. Your service configuration may be disclosing far more information than is necessary.
There is much more to this topic than I can do justice in this small post, but if I get the chance I’ll try to produce a more comprehensive write up including reviewing some of the more advanced techniques promoted in NMAP.