Fingerprinting Windows versions, AV, wireless cards over the network—all without authentication

August 11, 2021, by

HD Moore

Correctly identifying and categorizing network-connected systems without credentials is a tricky challenge and one of the fun parts of working at Rumble. This process of “fingerprinting” uses thousands of rules, pattern matches, and internal databases to take observed properties of a system and produce a set of weighted matches. These matches cover the device type, operating system, physical hardware make/model, and services, but sometimes that isn’t enough.

A fingerprint challenge we’ve been wrestling with is being able to differentiate between the desktop and server versions of modern Microsoft Windows operating systems. The desktop (Windows 10/11) and server (Windows Server 2019/2022) variants look identical to most unauthenticated network scans. For example, build 10.0.19044 can refer to both the 21H1 versions of Windows 10 or Windows Server 2019.

Prior to Windows 10, SMB v1 could be relied upon to return the exact Windows edition, remotely and without authentication. With the retirement of SMB v1, the NTLMSSP handshake is used instead, and this only returns the build number, and not the edition or variant of Windows. To handle this case, we implemented heuristics to push the match to a desktop or server operating system based on things like the hostname or additional network services, but heuristics are imperfect, and our users needed something better.

Some thinking and experimentation surfaced a hypothesis: DCE/RPC, a 20 year old technology still heavily used in modern Windows, could contain the differentiator we needed. Folks working in security or IT in 2003 most likely encountered DCE/RPC when responding to the “blaster” worm, which exploited the MS03-026 vulnerability discovered by the Last Stage of Delirium research group. This worm was also the first widespread use of Metasploit shellcode, and is why TCP port 4444 is still blocked at various network gateways today.

Using Endpoint Mapper to enumerate services on DCE/RPC systems

The DCE/RPC Endpoint Mapper (EPM) listens on TCP port 135 and can be queried to return a list of available DCE/RPC services, similar to the SunRPC Portmapper on Unix-like systems. These requests are unauthenticated and available to the network by default in most enterprise deployments of Windows. This highlights the EPM as a potentially useful method for unauthenticated network fingerprinting.

In order to query the EPM, a DCE/RPC client must be able to connect to TCP port 135, send a bind request to the specific UUID, call the lookup function, and then repeatedly query this function with a server-provided handle until no more results are returned.

Quite a few tools are available to query the EPM, including rpcdump.exe from Microsoft, various network vulnerability scanners, and the open source Metasploit Framework, via the endpoint_mapper module:

Metasploit enumerating the DCE/RPC services available on a Windows 10 system

The Endpoint Mapper traffic is unencrypted by default, enabling easy diagnostics with a network protocol analyzer like Wireshark. Wireshark includes a DCE/RPC dissector (i.e. protocol parser) that makes it easy for us examine EPM requests and responses:

Wireshark showing enumerated DCE/RPC services on a Windows 10 system

Putting together data for analysis

The lookup responses from the EPM provide details about the DCE/RPC services on that Windows endpoint, including a unique identifier (UUID format) for each service, the protocols and endpoints supported by the service, an associated Object ID, and an optional text annotation. DCE/RPC services can run across a wide variety of protocols, including Local RPC (only available on the same system), Named Pipes, TCP, UDP, and even HTTP.

A single DCE/RPC service is often accessible through multiple protocols and endpoints. For example, enumerating the EPM of a Windows 10 system revealed the following:

Detail of two services Metasploit enumerated on a Windows 10 system

The output shows that the DfsDs service (UUID 7f1343fe-50a9-4927-a778-0c5859517bac) supports LRPC access and access via a named pipe. Notice that the other service shown (UUID 12345678-1234-abcd-ef00-0123456789ab) supports both LRPC access and access via TCP/IP connection. The string in brackets at the end is the system-provided annotation, an optional user-friendly description.

EPM enumerations can yield quite a bit of data; a typical Windows 10 desktop returns over 100 UUIDs, each with their own set of protocols, endpoints, and annotations.

We updated the Rumble scan engine to implement the EPM protocol and ran a few scans across our lab with the goal of determining whether a specific UUID, protocol, endpoint, or annotation would be useful for differentiating between Windows desktop and server installations.

Unfortunately, there were no obvious indicators, and we needed a bigger dataset.

Creating a bigger data set for our analysis

In order to get a broad view across DCE/RPC implementations, we scanned the entire internet subnet using Rumble. Of these 16.7 million IPv4 addresses, we found over 12,000 systems with the EPM exposed to the internet, each of which reported between dozens and hundreds of DCE/RPC services.

We were able to greatly increase our dataset, but we needed a better way to process the data in order to identify any patterns that could help improve our desktop-vs-server fingerprinting. We turned to a common app for dealing with numerical data: the humble spreadsheet.

We coerced the EPM enumeration data from our scan into a matrix. The unique EPM lookup results filled the first column, and the four Windows builds we surveyed filled the next 4 columns: Windows 10 (1809), Windows 10 (2004), Windows Server 2019 (1809), and Windows Server 2019 (2004). The remaining cells contained the percentage of Windows systems running a specific OS and version that reported that specific DCE/RPC entry.

This is what the spreadsheet looked like:

Initial spreadsheet

With over 1,300 rows in the spreadsheet, we needed a better way to visualize the numbers so we could surface patterns more quickly. We added conditional formatting to change cell coloring based on % value, which made it easier to discern patterns and large gaps in the data. For example, it’s easier to identify when there is a smaller percentage in one column and a larger percentage in another column in the same row.

Using the column headers, we sorted the Windows version we wanted to look at in descending order, then we looked for large gaps across each row. In this case, a red/orange cell adjacent to a green/yellow cell helped us surface a single EPM entry as a contender for our fingerprinting challenge:

Colorized spreadsheet

One thing to note is that the OS fingerprints in this dataset were determined using the Windows build number and heuristics. This leads to slightly fuzzy results; if we misclassified a desktop as a server, then the percentages would be slightly wrong, which in turn makes identifying differentiators even more difficult.

In the screenshot above, we noticed that the Security Center entry on line 57 had a 0% ratio against Windows Server 2019 (1809) systems, but appeared on most Windows 10 (2004) systems, and some of the Windows 10 (1809) systems. At first glance, this looked like a change specific to build 2004, but then we took a closer look. After reducing this data further to just systems that could be positively fingerprinted by hostname or SMB v1 responses, it was clear that the noise was due to inaccurate heuristic-based fingerprints.

The Security Center service was never observed on confirmed Windows Server 2019 systems and was also extremely rare to see on Windows Server 2016 systems, with only early technical preview releases claiming to run this service.

We found our winner!

If our fingerprinting is having a difficult time discerning if a Windows endpoint is running Windows 10 or Windows Server 2019, we can check if the Security Center service is present via an EPM lookup. If the Security Center service is present, we will know it’s Windows 10 since Windows Server 2019 does not have this service. This was somewhat obvious in retrospect, because the main difference between these variants is that Server 2019 does not offer a desktop interface, and therefore doesn’t support the Security Center.

We immediately implemented this method into the Rumble fingerprinting engine, replacing heuristics when the EPM is available, and started the cross-checking process to make sure it was as reliable as it seemed.

This re-checking process led to a surprising result; there was a lot more we could identify using the returned DCE/RPC service list.

Identifying WiFi and WWAN services

An interesting result of the DCE/RPC analysis was that certain hardware configurations were detectable based on the running services. Windows systems with a WiFi card installed indicated that the Wlan Service was running. Systems with a mobile/cellular network interface returned an entry for the Wwan Service. This method allows Rumble to flag whether any Windows system on the network has an active wireless card installed, again, without authentication.

Rumble shows assets with WiFi and WWAN adapters’

Identifying AV, EDR, and software agents

Network interfaces were far from the only thing discoverable by analyzing DCE/RPC services. A handful of Anti-Virus (AV), Endpoint Detection and Response (EDR), and other software agents made themselves known by registering specific DCE/RPC UUIDs.

As a result, Rumble is now able to flag systems running Avast, AVG, Checkpoint, Kaspersky, and McAfee software remotely, without credentials.

Rumble shows assets with EDR installed’

In addition to the AV and EDR agents, Rumble reports specific attributes indicating the presence of agents supporting Lenovo Vantage, Veeam Backup, F5 BIG-IP Edge Clients, Forefront TMG Clients, Netwrix, SmartBear, Varonis, Enteo, Arrellia, and Altiris.

Rumble shows attributes indicating software agents

What’s ahead

DCE/RPC provides a wealth of system information for Windows endpoints, without authentication. We plan to continue this work and have started adding fingerprints to detect Microsoft Exchange servers, Microsoft DHCP servers, and hardware-specific services, including those that support the Microsoft Surface products.

At Rumble, our goal is to build the best products for IT and security professionals through applied research. We hope that you found this write-up interesting and that you will try out Rumble.

Authors: Pearce Barry & HD Moore

Similar Content

November 2, 2021

Rumble 2.8: Synchronize your VMware inventory, import Censys scan data, and run RFC 1918 scans faster

What’s new with Rumble 2.8? Integration improvements Synchronize your VMware virtual machine inventory Import external scan data from Censys Scan, search, and self-hosted improvements Discover all RFC 1918 networks, faster Customize scan schedules with more options …

Read More

October 5, 2021

Rumble 2.7: New dashboard, multi-subscription Azure, AWS ELBs, Splunk add-on improvements, and faster discovery for Rumble Professional

What’s new with Rumble 2.7? User experience improvements Get insights, trends, and visualizations from your dashboard Easily navigate configuration pages for scans, imports, connections, and more Know when your connector credentials are invalid Integration …

Read More

September 30, 2021

Fingerprinting Windows build numbers

Our goal at Rumble is to help customers identify everything on their networks, quickly, and without authentication. This process is driven by research, which often leads to dead ends, but sometimes we learn interesting things along the way. This post explores recent research …

Read More