OS fingerprinting techniques (also called OS detection techniques) and how they identify a remote operating system.
This guide is split into three parts. This page covers how operating systems are identified from protocol behaviour. Part 2 covers Nmap OS detection and TCP/IP fingerprinting, and part 3 covers the p0f fingerprint database and NAT detection.
Os Detection Techniques – Background information
This is a list of Os Detection Techniques, with explanations for all the active and passive Os Detection Techniques I can find for remote operating system identification – there is a massive list of sources at the end.
Background information: Os Detection Techniques
Active fingerprinting – Active fingerprinting is the process of transmitting packets to a remote host and analysing corresponding replies.
Passive fingerprinting – Passive fingerprinting is the process of analysing packets from a host on a network. In this case, finger printer acts as a sniffer and doesn’t put any traffic on a network.
Common Os Detection Techniques are based on analysing:
IP TTL values; IP ID values; TCP Window size; TCP Options (generally, in TCP SYN and SYN+ACK packets); DHCP requests; ICMP requests; HTTP packets (generally, User-Agent field). MDNS ARP / NDP / SEND DNLA UPNP – SSDP M-SEARCH Bonjour / Zeroconf NetBIOS SSH / SSL / TLS SDP SNMP
Other Os Detection Techniques are based on analysing:
Running services; Open port patterns. Limitations
Many passive fingerprinters are getting confused when analysing packets from a NAT device.
Os Detection Techniques – IP TTL values + TCP Window size
Certain parameters within the TCP protocol definition are left up to the implementation. Different operating systems, and different versions of the same operating system, set different defaults for these values. By collecting and examining these values, one may differentiate among various operating systems, and implementations of TCP/IP. The TCP/IP fields that may vary include the following:
Initial packet size (16 bits) Initial TTL (8 bits) Window size (16 bits) Max segment size (16 bits) Window scaling value (8 bits) “don’t fragment” flag (1 bit) “sackOK” flag (1 bit) “nop” flag (1 bit) These values may be combined to form a 67-bit signature, or fingerprint, for the target machine Just inspecting the Initial TTL and window size fields is often enough in order to successfully identify an operating system, which eases the task of performing manual OS fingerprinting.
Active measures, like those employed by Nmap, are unfortunately not available when doing passive analysis of live traffic or when analyzing previously captured network traffic. Passive analysis requires much more subtle variations in the network traffic to be observed, in order to identify a computer’s OS. A simple but effective passive method is to inspect the initial Time To Live (TTL) in the IP header and the TCP window size (the size of the receive window) of the first packet in a TCP session, i.e. the SYN or SYN+ACK packet.
Below are some typical initial TTL values and window sizes of common operating systems:
IP ID values
TCP Options (generally, in TCP SYN and SYN+ACK packets);
Os Detection Techniques – DHCP requests
9.13. Vendor class identifier
This option is used by DHCP clients to optionally identify the vendor type and configuration of a DHCP client. The information is a string of n octets, interpreted by servers. Vendors may choose to define specific vendor class identifiers to convey particular configuration or other identification information about a client wich are useful OS Detection Techniques. For example, the identifier may encode the client’s hardware configuration. Servers not equipped to interpret the class-specific information sent by a client MUST ignore it (although it may be reported). Servers that the DHCP functionality supports the DHCP vendor class identifier option (option 60).
This support allows DHCP relay to compare option 60 strings in received DHCP client packets against strings that you configure on the router. You can use the DHCP relay option 60 feature when providing converged services in your network environment-option 60 support enables DHCP relay to direct client traffic to the specific DHCP server (the vendor-option server) that provides the service that the client requires. Or, as another option, you can configure option 60 strings to direct traffic to the DHCP local server in the current virtual router.
** you can also use this information to identify devices and operating systems
ICMP requests
Os Detection Techniques – ARP (Address Resolution Protocol)
The function or purpose of Internet Protocol is to move datagrams through an interconnected set of networks. This is done by passing the datagrams from one internet module to another until the destination is reached. The internet modules reside in hosts and gateways in the internet system. The datagrams are routed from one internet module to another through individual networks based on the interpretation of an internet address. Thus, one important mechanism of the internet protocol is the internet address.
By querying ARP you can get mac addressees, you can then use an OUI to look up manufacturer information, which can lead you to some other OS Detection Techniques.
Os Detection Techniques – Mac Addresses
A media access control address (MAC address) of a device is a unique identifier assigned to a network interface controller (NIC). For communications within a network segment, it is used as a network address for most IEEE 802 network technologies, including Ethernet, Wi-Fi, and Bluetooth. Within the Open Systems Interconnection (OSI) model, MAC addresses are used in the medium access control protocol sublayer of the data link layer. As typically represented, MAC addresses are recognisable as six groups of two hexadecimal digits, separated by hyphens, colons, or no separator (see Notational conventions below).
A MAC address may be referred to as the burned-in address, and is also known as an Ethernet hardware address, hardware address, and physical address (not to be confused with a memory physical address).
A network node with multiple NICs must have a unique MAC address for each. Sophisticated network equipment such as a multilayer switch or router may require one or more permanently assigned MAC addresses.
MAC addresses are most often assigned by the manufacturer of network interface cards. Each is stored in hardware, such as the card’s read-only memory or by a firmware mechanism. A MAC address typically includes the manufacturer’s organisationally unique identifier (OUI). MAC addresses are formed according to the principles of two numbering spaces based on Extended Unique Identifiers (EUI) managed by the Institute of Electrical and Electronics Engineers (IEEE): EUI-48, which replaces the obsolete term MAC-48,[1] and EUI-64.[2]
An organisationally unique identifier (OUI) is a 24-bit number that uniquely identifies a vendor, manufacturer, or other organisation.
OUIs are purchased from the Institute of Electrical and Electronics Engineers (IEEE) Registration Authority by the assignee (IEEE term for the vendor, manufacturer, or other organisation). They are used to uniquely identify a particular piece of equipment through derived identifiers such as MAC addresses, Subnetwork Access Protocol protocol identifiers, World Wide Names for Fibre Channel devices.
In MAC addresses, the OUI is combined with a 24-bit number (assigned by the assignee of the OUI) to form the address. The first three octets of the address are the OUI.
https://standards-oui.ieee.org/oui36/oui36.txt https://standards-oui.ieee.org/oui28/mam.txt https://standards-oui.ieee.org/oui/oui.txt https://standards-oui.ieee.org/iab/iab.txtThe Neighbour Discovery Protocol (NDP, ND) is a protocol in the Internet protocol suite used with Internet Protocol Version 6 (IPv6). It operates at the link layer of the Internet model (RFC 1122), and is responsible for gathering various information required for internet communication, including the configuration of local connections and the domain name servers and gateways used to communicate with more distant systems.[2]
Os Detection Techniques – NDP
The protocol defines five different ICMPv6 packet types to perform functions for IPv6 similar to the Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) Router Discovery and Router Redirect protocols for IPv4. However, it provides many improvements over its IPv4 counterparts (RFC 4861, section 3.1). For example, it includes Neighbour Unreachability Detection (NUD), thus improving robustness of packet delivery in the presence of failing routers or links, or mobile nodes.
The Inverse Neighbour Discovery (IND) protocol extension (RFC 3122) allows nodes to determine and advertise an IPv6 address corresponding to a given link-layer address, similar to Reverse ARP for IPv4. The Secure Neighbour Discovery Protocol (SEND), a security extension of NDP, uses Cryptographically Generated Addresses (CGA) and the Resource Public Key Infrastructure (RPKI) to provide an alternative mechanism for securing NDP with a cryptographic method that is independent of IPsec. Neighbour Discovery Proxy (ND Proxy) (RFC 4389) provides a service similar to IPv4 Proxy ARP and allows bridging multiple network segments within a single subnet prefix when bridging cannot be done at the link layer.
Os Detection Techniques – Bonjour / Zeroconf
Zero-configuration networking (zeroconf) is a set of technologies that automatically creates a usable computer network based on the Internet Protocol Suite (TCP/IP) when computers or network peripherals are interconnected. It does not require manual operator intervention or special configuration servers. Without zeroconf, a network administrator must set up network services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS), or configure each computer’s network settings manually.
Zeroconf is built on three core technologies: automatic assignment of numeric network addresses for networked devices, automatic distribution and resolution of computer hostnames, and automatic location of network services, such as printing devices.
Service discovery Name services such as mDNS, LLMNR and others do not provide information about the type of device or its status. A user looking for a nearby printer, for instance, might be hindered if the printer was given the name “Bob”. Service discovery provides additional information about devices. Service discovery is sometimes combined with a name service, as in Apple’s Name Binding Protocol and Microsoft’s NetBIOS (including SMB as supported on non-Microsoft operating systems).
NetBIOS Service Discovery OS Detection Techniques – NetBIOS on Windows (and its sibling SMB on other operating systems) supports individual hosts on the network to advertise services, such as file shares and printers. It also supports for example a network printer to advertise itself as a host sharing a printer device and any related services it supports. Depending on how a device is attached (to the network directly, or to the host which shares it) and which protocols are supported however, Windows clients connecting to it may prefer to use SSDP or WSD over using NetBIOS. NetBIOS is one of the providers on Windows implementing the more general discovery process dubbed ‘Function Discovery’ which includes built-in providers for PnP, Registry, NetBIOS, SSDP and WSD of which the former two are local-only and the latter three support discovery of networked devices. None of these need any configuration for use on the local subnet. NetBIOS has traditionally been supported only in expensive printers for use in companies and the cheapest devices of some brands today still don’t have support for it, but home and SOHO users would connect printers to a computer over say a parallel port or USB and share it from the computer. However, today even entry-level printers with Wi-Fi or Ethernet support of some brands support it natively, allowing the printer to be used without configuration even on very old operating systems (combined with a generic PostScript driver, for example).
WS-Discovery – Web Services Dynamic Discovery (WS-Discovery) is a technical specification that defines a multicast discovery protocol to locate services on a local network. It operates over TCP andUDP port 3702 and uses IP multicast address 239.255.255.250. As the name suggests, the actual communication between nodes is done using web services standards, notably SOAP over UDP.Windows supports it in the form of WSD and WPDS and many device and appliance manufacturers support it, such as HP and Brother printers.
DNS-based OS Detection Techniques use service discovery DNS-SD allows clients to discover a named list of service instances, given a service type, and to resolve those services to hostnames using standard DNS queries. The specification is compatible with existing unicast DNS server and client software, but works equally well with mDNS in a zero-configuration environment. Each service instance is described using a DNS SRV ( RFC 2782) and DNS TXT (RFC 1035) record. A client discovers the list of available instances for a given service type by querying the DNS PTR (RFC 1035) record of that service type’s name; the server returns zero or more names of the form “.”, each corresponding to a SRV/TXT record pair. The SRV record resolves to the domain name providing the instance, while the TXT can contain service-specific configuration parameter. A client can then resolve the A/AAAA record for the domain name and connect to the service.
Apple Bonjour Bonjour (formerly known as Rendezvous) from Apple, uses mDNS and DNS Service Discovery. Apple changed its preferred zeroconf technology from SLP to mDNS and DNS-SD between Mac OS X 10.1 and 10.2, though SLP continues to be supported by Mac OS X.
Apple’s mDNSResponder has interfaces for C and Java[29] and is available on BSD, Apple Mac OS X, Linux, other POSIX based operating systems and MS Windows. The Windows downloads are available from Apple’s website.[30]
Os Detection Techniques – UPNP – SSDP M-SEARCH
Universal Plug and Play (UPnP) is a set of networking protocols that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices to seamlessly discover each other’s presence on the network and establish functional network services for data sharing, communications, and entertainment. UPnP is intended primarily for residential networks without enterprise-class devices.
The UPnP technology was promoted by the UPnP Forum, a computer industry initiative to enable simple and robust connectivity to stand-alone devices and personal computers from many different vendors. The Forum consisted of over eight hundred vendors involved in everything from consumer electronics to network computing. Since 2016, all UPnP efforts are now managed by the Open Connectivity Foundation (OCF).[1]
UPnP assumes the network runs Internet Protocol (IP) and then leverages HTTP, on top of IP, in order to provide device/service description, actions, data transfer and eventing. Device search requests and advertisements are supported by running HTTP on top of UDP (port 1900) using multicast (known as HTTPMU). Responses to search requests are also sent over UDP, but are instead sent using unicast (known as HTTPU).
Conceptually, UPnP extends plug and play-a technology for dynamically attaching devices directly to a computer-to zero configuration networking for residential and SOHO wireless networks. UPnP devices are “plug and play” in that, when connected to a network, they automatically establish working configurations with other devices.
UPnP is generally regarded as unsuitable for deployment in business settings for reasons of economy, complexity, and consistency: the multicast foundation makes it chatty, consuming too many network resources on networks with a large population of devices; the simplified access controls don’t map well to complex environments; and it does not provide a uniform configuration syntax such as the CLI environments of Cisco IOS or JUNOS. UPnP leads to a number of different OS Detection Techniques.
The UPnP architecture allows device-to-device networking of consumer electronics, mobile devices, personal computers, and networked home appliances. It is a distributed, open architecture protocol based on established standards such as the Internet Protocol Suite (TCP/ IP), HTTP, XML, and SOAP. UPnP control points (CPs) are devices which use UPnP protocols to control UPnP controlled devices (CDs).[2]
The UPnP architecture supports zero configuration networking. A UPnP compatible device from any vendor can dynamically join a network, obtain an IP address, announce its name, advertise or convey its capabilities upon request, and learn about the presence and capabilities of other devices. Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) servers are optional and are only used if they are available on the network. Devices can disconnect from the network automatically without leaving state information.
OS Detection Techniques: Discovery
Once a device has established an IP address, the next step in UPnP networking is discovery. The UPnP discovery protocol is known as the Simple Service Discovery Protocol (SSDP). When a device is added to the network, SSDP allows that device to advertise its services to control points on the network. This is achieved by sending SSDP alive messages. When a control point is added to the network, SSDP allows that control point to actively search for devices of interest on the network or listen passively to the SSDP alive messages of device. The fundamental exchange is a discovery message containing a few essential specifics about the device or one of its services, for example, its type, identifier, and a pointer (network location) to more detailed information.
OS Detection Techniques: Description
After a control point has discovered a device, the control point still knows very little about the device. For the control point to learn more about the device and its capabilities, or to interact with the device, the control point must retrieve the device’s description from the location (URL) provided by the device in the discovery message. The UPnP Device Description is expressed in XML and includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, (presentation) URLs to vendor-specific web sites, etc. The description also includes a list of any embedded services. For each service, the Device Description document lists the URLs for control, eventing and service description. Each service description includes a list of the commands, or actions, to which the service responds, and parameters, or arguments, for each action; the description for a service also includes a list of variables; these variables model the state of the service at run time, and are described in terms of their data type, range, and event characteristics.
Os Detection Techniques – SSDP
Simple Service Discovery Protocol (SSDP) is a UPnP protocol, used in Windows XP and later. SSDP uses HTTP notification announcements that give a service-type URI and a Unique Service Name (USN). Service types are regulated by the Universal Plug and Play Steering Committee. SSDP is supported by many printer, NAS and appliance manufacturers such as Brother, certain brands of network equipment, and in many SOHO firewall appliances, where host computers behind it may pierce holes for applications. It is also used in home theater PC systems, where media exchange between host computers and the media center is facilitated using SSDP.
Os Detection Techniques – MDNS
In computer networking, the multicast DNS (mDNS) protocol resolves host names to IP addresses within small networks that do not include a local name server. It is a zero-configuration service, using essentially the same programming interfaces, packet formats and operating semantics as the unicast Domain Name System (DNS). Although Stuart Cheshire designed mDNS as a stand-alone protocol, it can work in concert with standard DNS servers.[1]
The mDNS protocol is published as RFC 6762, uses IP multicast User Datagram Protocol (UDP) packets, and is implemented by the Apple Bonjour and open source Avahi software packages. Android contains an mDNS implementation. mDNS has also been implemented in Windows 10, but its use there is limited to discovering networked printers.
mDNS can work in conjunction with DNS Service Discovery (DNS-SD), a companion zero-configuration technique specified separately in RFC 6763.
Os Detection Techniques – DNLA
Digital Living Network Alliance (DLNA) (originally named Digital Home Working Group, DHWG) was founded by a group of PC and consumer electronics companies in June 2003 (with Intel in the lead role) to develop and promote a set of interoperability guidelines for sharing digital media among multimedia devices under the auspice of a certification standard. DLNA certified devices include smartphones, tablets, PCs, TV sets and storage servers; in a typical use case, a user sends videos, pictures or music from their smartphone or storage server through their home WLAN to a TV set or tablet for display.
The DLNA Certified Device Classes are separated as follows:[10]
Home Network Devices
Digital Media Server (DMS): store content and make it available to networked digital media players (DMP) and digital media renderers (DMR). Examples include PCs and network-attached storage (NAS) devices.
Digital Media Player (DMP): find content on digital media servers (DMS) and provide playback and rendering capabilities. Examples include TVs, stereos and home theaters, wireless monitors and game consoles.
Digital Media Renderer (DMR): play content as instructed by a digital media controller (DMC), which will find content from a digital media server (DMS). Examples include TVs, audio/video receivers, video displays and remote speakers for music. It is possible for a single device (e.g. TV, A/V receiver, etc.) to function both as a DMR (receives “pushed” content from DMS) and DMP (“pulls” content from DMS)
Digital Media Controller (DMC): find content on digital media servers (DMS) and instruct digital media renderers (DMR) to play the content. Content doesn’t stream from or through the DMC. Examples include tablet computers, Wi-Fi enabled digital cameras and smartphones. Generally, digital media players (DMP) and digital media controllers (DMC) with print capability can print to DMPr. Examples include networked photo printers and networked all-in-one printers
Mobile Digital Media Server (M-DMS): store content and make it available to wired/wireless networked mobile digital media players (M-DMP), and digital media renderers. Examples include mobile phones and portable music players.
Mobile Digital Media Player (M-DMP): find and play content on a digital media server (DMS) or mobile digital media server (M-DMS). Examples include mobile phones and mobile media tablets designed for viewing multimedia content.
Mobile Digital Media Uploader (M-DMU): send (upload) content to a digital media server (DMS) or mobile digital media server (M-DMS). Examples include digital cameras and mobile phones.
Mobile Digital Media Downloader (M-DMD): find and store (download) content from a digital media server (DMS) or mobile digital media server (M-DMS). Examples include portable music players and mobile phones.
Mobile Digital Media Controller (M-DMC): find content on a digital media server (DMS) or mobile digital media server (M-DMS) and send it to digital media renderers (DMR). Examples include personal digital assistants (PDAs) and mobile phones.
Mobile Network Connectivity Function (M-NCF): provide a bridge between mobile handheld device network connectivity and home network connectivity.
Media Interoperability Unit (MIU): provide content transformation between required media formats for home network and mobile handheld devices.
The specification uses DTCP-IP as “link protection” for copyright-protected commercial content between one device to another.
DLNA is another suite of standards that uses UPnP for its discovery of networked devices, which has a long list of manufacturers producing devices that support it, such as TVs from most if not all large brands, NAS devices and so forth. As such, it is also supported by all major operating systems.
DNLA leads to a number of OS Detection Techniques as devices tend to identify their capabilities on the network when queried.
Os Detection Techniques – NetBIOS / SMB / NTLM
NetBIOS over TCP/IP (NBT, or sometimes NetBT) is a networking protocol that allows legacy computer applications relying on the NetBIOS API to be used on modern TCP/IP networks.
NetBIOS was developed in the early 1980s, targeting very small networks (about a dozen computers). Some applications still use NetBIOS, and do not scale well in today’s networks of hundreds of computers when NetBIOS is run over NBF. When properly configured, NBT allows those applications to be run on large TCP/IP networks (including the whole Internet, although that is likely to be subject to security problems) without change.
NBT is defined by the RFC 1001 and RFC 1002 standard documents.
NetBIOS provides three distinct OS Detection Techniques / services:
Name service for name registration and resolution (ports: 137/udp and 137/tcp) Datagram distribution service for connectionless communication (port: 138/udp) Session service for connection-oriented communication (port: 139/tcp) NBT implements all of those services.
Although its main purpose is file sharing, additional SMB Protocol provides other functionality such as:
Network browsing Printing over a network SMB Protocol is most often used as an Application layer or a Presentation layer protocol, and it relies on lower-level protocols for transport.
The transport layer protocol that Microsoft SMB Protocol was often used with was NetBIOS over TCP/IP (NBT) over UDP ports 137 and 138 and TCP ports 137 and 139. NBT for use by NetBIOS is supported on Windows Server 2003, Windows XP, Windows 2000, Windows NT, and Windows Me/98/95. NetBIOS is not supported on Windows Vista, Windows Server 2008, and subsequent versions of Windows. SMB/NBT combination is generally used for backward compatibility. The NetBIOS over NetBEUI protocol provides NetBIOS support for the NetBEUI protocol. This protocol is also called NetBIOS Frames (NBF). NBF is supported on Windows 2000, Windows NT, and Windows Me/98/95. NetBEUI is no longer be supported on Windows XP and later. However, SMB Protocol can also be used without a separate transport protocol directly over TCP, port 445. NetBIOS was also supported over several legacy protocols such as IPX/SPX. The SMB “Inter-Process Communication” (IPC) system provides named pipes and was one of the first inter-process mechanisms commonly available to programmers that provides a means for services to inherit the authentication carried out when a client[clarification needed] first connects to an SMB server.[citation needed]
Some services that operate over named pipes, such as those which use Microsoft’s own implementation of DCE/RPC over SMB, known as MSRPC over SMB, also allow MSRPC client programs to perform authentication, which overrides the authorization provided by the SMB server, but only in the context of the MSRPC client program that successfully makes the additional authentication.
SMB signing: Windows NT 4.0 Service Pack 3 and upwards have the capability to use cryptography to digitally sign SMB connections. The most common official term is “SMB signing”. Other terms that have been used officially are “[SMB] Security Signatures”, “SMB sequence numbers”[5] and “SMB Message Signing”.[6] SMB signing may be configured individually for incoming SMB connections (handled by the “LanManServer” service) and outgoing SMB connections (handled by the “LanManWorkstation” service). The default setting from Windows 98 and upwards is to opportunistically sign outgoing connections whenever the server also supports this, and to fall back to unsigned SMB if both partners allow this. The default setting for Windows domain controllers from Windows Server 2003 and upwards is to not allow fall back for incoming connections.[7] The feature can also be turned on for any server running Windows NT 4.0 Service Pack 3 or later. This protects from man-in-the-middle attacks against the Clients retrieving their policies from domain controllers at login.[8]
The design of Server Message Block version 2 (SMB2) aims[citation needed] to mitigate this performance limitation by coalescing SMB signals into single packets.
SMB supports opportunistic locking-a special type of locking-mechanism-on files in order to improve performance.
SMB serves as the basis for Microsoft’s Distributed File System implementation.
Os Detection Techniques – SDP
Protocols There are many service discovery protocols, including:
Bluetooth Service Discovery Protocol (SDP) DNS Service Discovery (DNS-SD), a component of Zero Configuration Networking Dynamic Host Configuration Protocol (DHCP) Internet Storage Name Service (iSNS) Jini for Java objects. Link-Layer Discovery Protocol (LLDP) standards-based neighbor discovery protocol similar to vendor-specific protocols which find each other by advertising to vendor-specific broadcast addresses (versus all-1’s), such Cabletron (Enterasys) and Cisco Discovery Protocol (both referred to as CDP but different formats). Multicast Source Discovery Protocol (MSDP), usually used for unicast exchange of multicast source information between anycast Rendez-Vous Points (RPs) to service mcast clients. Service Location Protocol (SLP) Session Announcement Protocol (SAP) used to discover RTP sessions Simple Service Discovery Protocol (SSDP) a component of Universal Plug and Play (UPnP) Universal Description Discovery and Integration (UDDI) for web services Web Proxy Autodiscovery Protocol (WPAD) WS-Discovery (Web Services Dynamic Discovery) XMPP Service Discovery (XEP-0030) XRDS (eXtensible Resource Descriptor Sequence) used by XRI, OpenID, OAuth, etc.While not specific for OS Detection Techniques bluetooth can be used to identify devices and can be combined with other OS Detection Techniques to identify devices.
Efforts toward an IETF standard protocol Service Location Protocol (SLP) is supported by Hewlett-Packard’s network printers, Novell, and Sun Microsystems. SLP is described in RFC 2608 and RFC 3224 and implementations are available for both Solaris and Linux.
AllJoyn AllJoyn is an open source software stack for a myriad of devices, ranging from the tiniest IoT devices to the largest computers, for discovery and control of devices on networks (Wifi, Ethernet) and other links (Bluetooth, ZigBee, etc.). It uses (amongst others) mDNS and HTTP over UDP.
Os Detection Techniques – SNMP
Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.[1] This makes the protocol available for various OS Detection Techniques.
SNMP is widely used in network management for network monitoring. SNMP exposes management data in the form of variables on the managed systems organized in a management information base ( MIB) which describe the system status and configuration. These variables can then be remotely queried (and, in some circumstances, manipulated) by managing applications.
Many SNMP implementations include a type of automatic discovery where a new network component, such as a switch or router, is discovered and pooled automatically. In SNMPv1 and v2c this is done through a community string that is broadcast in clear-text to other devices.[10] Because of its default configuration on community strings, they are public for read-only access and private for read-write[8]:1874 SNMP topped the list of the SANS Institute’s Common Default Configuration Issues and was number ten on the SANS Top 10 Most Critical Internet Security Threats for the year 2000.[28] System and network administrators frequently do not change these configurations.[8]:1874 The community string sent by SNMP over the network is not encrypted. Once the community string is known outside the organisation it could become the target for an attack. To prevent the easy discovery of the community, SNMP should be configured to pass community-name authentication failure traps and the SNMP management device needs to be configured to react to the authentication failure trap.[25]:54
SSH / SSL / TLS Os Detection Techniques
SSH fingerprinting Hash is a new SSH Fingerprinting standard used to accurately detect and identify specific Client and Server SSH deployments. These fingerprints uses MD5 as a default storage method, for later analysis, usage and comparison when needed. These methods can be used for Os Detection Techniques.
While SSH is a fairly secure protocol, it has a few drawbacks when it comes to analyzing interaction between client and server. In this case, using Hassh can help in situations that include:
Managing alerts and automatically blocking SSH clients using a Hassh fingerprint outside of a known “good set”. Detecting exfiltration of data by using anomaly detection on SSH Clients with multiple distinct Hassh values. Forensic investigation as SSH connection attempts are now easier to find, with greater granularity than researching by IPSource. The Hassh will be present within SSH client software, this will help to detect the origin even if the IP is behind a NAT and is shared by different SSH clients. Detecting and identifying specific client and server SSH implementations. This works by using the MD5 “hassh” and “hasshServer” (created from a specific set of algorithms by SSH clients and SSH server software) from the final SSH encrypted channel. This generates a unique identification string that can be used to fingerprint client and server applications.
The final MD5 can be easily translated into examples such as these:
c1c596caaeb93c566b8ecf3cae9b5a9e SSH-2.0-dropbear_2016.74 d93f46d063c4382b6232a4d77db532b2 SSH-2.0-dropbear_2016.72 2dd9a9b3dbebfaeec8b8aabd689e75d2 SSH-2.0-AWSCodeCommit Hassh is a brand new project, online since their Github repo a few months ago.id It looks like a solid solution, one that can shed light on the typical SSH client-server connection problems seen for decades. Thanks to this new fingerprint standart, debugging SSH connections will be easier.
SSL fingerprinting JA3, as their creators said, is an SSL/TLS fingerprint method. This helps to create fingerprints that can be produced by any platform for later threat intelligence analysis.
In the same case as the previous technology (HASSH), using JA3 + JA3S as a fingerprinting technique for the TLS negotiation between both ends (client and server) can produce a more accurate identification of the encrypted communications.
This helps identify clients and servers with high probability in almost all cases, as you see below with Tor client and Tor server:
Standard Tor Client:
JA3 = e7d705a3286e19ea42f587b344ee6865 (Tor Client) JA3S = a95ca7eab4d47d051a5cd4fb7b6005dc (Tor Server Response) This provides researchers a higher level of trust that this activity is indeed Tor traffic, and nothing else.
More information can be found at https://github.com/salesforce/ja3/
HTTP packets (generally, User-Agent field).
Os Detection Techniques using HTTP. In computing, a user agent is software (a software agent) that is acting on behalf of a user. One common use of the term refers to a web browser that “retrieves, renders and facilitates end user interaction with Web content”.[1] There are other uses of the term “user agent”. For example, an email reader is a mail user agent. In many cases, a user agent acts as a client in a network protocol used in communications within a client–server distributed computing system. In particular, the Hypertext Transfer Protocol (HTTP) identifies the client software originating the request, using a user-agent header, even when the client is not operated by a user. The Session Initiation Protocol (SIP) protocol (based on HTTP) followed this usage. In the SIP, the term user agent refers to both end points of a communications session.[2]
In HTTP, the User-Agent string is often used for content negotiation, where the origin server selects suitable content or operating parameters for the response. For example, the User-Agent string might be used by a web server to choose variants based on the known capabilities of a particular version of client software. The concept of content tailoring is built into the HTTP standard in RFC 1945 “for the sake of tailoring responses to avoid particular user agent limitations.”
OS Detection Techniques using the User-Agent string. The User-Agent is one of the criteria by which Web crawlers may be excluded from accessing certain parts of a website using the Robots Exclusion Standard (robots.txt file).
As with many other HTTP request headers, the information in the “User-Agent” string contributes to the information that the client sends to the server, since the string can vary considerably from user to user.[5]
Format for human-operated web browsers The User-Agent string format is currently specified by section 5.5.3 of HTTP/1.1 Semantics and Content. The format of the User-Agent string in HTTP is a list of product tokens (keywords) with optional comments. For example, if a user’s product were called WikiBrowser, their user agent string might be WikiBrowser/1.0 Gecko/1.0. The “most important” product component is listed first.
The parts of this string are as follows:
product name and version (WikiBrowser/1.0) layout engine and version (Gecko/1.0) During the first browser war, many web servers were configured to only send web pages that required advanced features, including frames, to clients that were identified as some version of Mozilla.[6] Other browsers were considered to be older products such as Mosaic, Cello, or Samba, and would be sent a bare bones HTML document.
For this reason, most Web browsers use a User-Agent string value as follows:
Mozilla/[version] ([system and browser information]) [platform] ([platform details]) [ extensions]. For example, Safari on the iPad has used the following:
Mozilla/5.0 (iPad; U; CPU OS 3_2_1 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Mobile/7B405 The components of this string are as follows:
Mozilla/5.0: Previously used to indicate compatibility with the Mozilla rendering engine. (iPad; U; CPU OS 3_2_1 like Mac OS X; en-us): Details of the system in which the browser is running. AppleWebKit/531.21.10: The platform the browser uses. (KHTML, like Gecko): Browser platform details.
Mobile/7B405: This is used by the browser to indicate specific enhancements that are available directly in the browser or through third parties. An example of this is Microsoft Live Meeting which registers an extension so that the Live Meeting service knows if the software is already installed, which means it can provide a streamlined experience to joining meetings. Before migrating to the Chromium code base, Opera was the most widely used web browser that did not have the User-Agent string with “Mozilla” (instead beginning it with “Opera”).
Since July 15, 2013,[7] Opera’s User-Agent string begins with “Mozilla/5.0” and, to avoid encountering legacy server rules, no longer includes the word “Opera” (instead using the string “OPR” to denote the Opera version).
OS Detection Techniques – User-Agent Sniffing
The term user agent sniffing refers to the practice of websites showing different content when viewed with a certain user agent. On the Internet, this will result in a different site being shown when browsing the page with a specific browser. One example of this is Microsoft Exchange Server 2003’s Outlook Web Access feature. When viewed with Internet Explorer 6 or newer, more functionality is displayed compared to the same page in any other browsers. User agent sniffing is now considered poor practice, since it encourages browser-specific design and penalizes new browsers with unrecognized user agent identifications. Instead, the W3C recommends creating HTML markup that is standard,[11] allowing correct rendering in as many browsers as possible, and to test for specific browser features rather than particular browser versions or brands.[12]
Websites specifically targeted towards mobile phones, like NTT DoCoMo’s I-Mode or Vodafone’s Vodafone Live! portals, often rely heavily on user agent sniffing, since mobile browsers often differ greatly from each other. Many developments in mobile browsing have been made in the last few years,[when?] while many older phones that do not possess these new technologies are still heavily used. Therefore, mobile Web portals will often generate completely different markup code depending on the mobile phone used to browse them. These differences can be small, e.g., resizing of certain images to fit smaller screens, or quite extensive, e.g., rendering of the page in WML instead of XHTML.
Common Platform Enumeration (CPE)
https://nvd.nist.gov/products/cpe
Common Platform Enumeration (CPE) is a standardized way to name software applications, operating systems, and hardware platforms. As such, it is perfect for OS Detection Techniques – Nmap includes CPE output for service and Os Detection Techniques.
Structure of a CPE Name – A CPE name is a URL that encodes seven ordered fields:
cpe:/::::::
Some of the fields may be left blank, and empty fields may be left off the end of the URL. The main division of CPE names is in the field; this can take on only three values:
a for applications, h for hardware platforms, or o for operating systems. By looking at the beginning of the URL you can easily see that cpe:/a:microsoft:sql_server:6.5 names an application, cpe:/h:asus:rt-n16 names a kind of hardware, and cpe:/o:freebsd:freebsd:3.5.1 names an operating system.
Nmap can output all three kinds of CPE names: OS detection can print h and o; and service detection can potentially output all three. The CPE names are mixed in with normal OS and service output, for example:
Example 13.13. Normal output with CPE highlighted
Running: Linux 2.6.X OS CPE: cpe:/o:linux:linux_kernel:2.6.39 OS details: Linux 2.6.39 Network Distance: 10 hops Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
CPE names for applications (with part a) are not shown in normal output, but they are present in XML. CPE is represented as a cpe element that can be a child of service or osclass.
Standard Discovery Protocol
Efforts toward an IETF standard protocol Service Location Protocol (SLP) is supported by Hewlett-Packard’s network printers, Novell, and Sun Microsystems. SLP is described in RFC 2608 and RFC 3224 and implementations are available for both Solaris and Linux.
Tools
Os Detection Techniques – Active fingerprinters
Nmap
Os Detection Techniques – Passive fingerprinters
NetworkMiner
p0f
Satori
Os Detection Techniques – Others:
Scapy
check out these linux commands
A list of TCP/OS Fingerprinting Tools
Ettercap – passive TCP/IP stack fingerprinting.
NetworkMiner – passive DHCP and TCP/IP stack fingerprinting (combines p0f, Ettercap and Satori databases)
Nmap – comprehensive active stack fingerprinting.
p0f – comprehensive passive TCP/IP stack fingerprinting.
NetSleuth – free passive fingerprinting and analysis tool
PacketFence[8] – open source NAC with passive DHCP fingerprinting.
PRADS – Passive comprehensive TCP/IP stack fingerprinting and service detection
Satori – passive CDP, DHCP, ICMP, HPSP, HTTP, TCP/IP and other stack fingerprinting.
SinFP – single-port active/passive fingerprinting.
XProbe2 – active TCP/IP stack fingerprinting.
Device Fingerprint Website[9] – Displays the passive TCP SYN fingerprint of your browser’s computer (or intermediate proxy)
queso – well-known tool from the late 1990s which is no longer being updated for modern operating systems
fpdns
Hassh
check out these linux commands
Continue reading: Part 2: Nmap OS detection and TCP/IP fingerprinting and Part 3: the p0f fingerprint database and NAT detection.
https://subinsb.com/default-device-ttl-values/ https://securitytrails.com/blog/cybersecurity-fingerprinting https://forensicswiki.org/wiki/OS_fingerprinting https://en.wikipedia.org/wiki/Zero-configuration_networking#Service_discovery https://en.wikipedia.org/wiki/Service_discovery https://en.wikipedia.org/wiki/Server_Message_Block https://en.wikipedia.org/wiki/List_of_products_that_support_SMB https://en.wikipedia.org/wiki/NetBIOS https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol https://en.wikipedia.org/wiki/User_agent