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:
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:
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:
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 120.0.0.0/8 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:
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:
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.
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.
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.
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 it out.
