Blog Post

PrintNightmare: Using Network Detection and Response to Uncover CVE-2021-1675 and CVE-2021-34527 Exploitation Activity

Overview

Several days ago proof of concept exploit code for an unpatched vulnerability affecting domain controllers was accidently released into the wild. These vulnerabilities (CVE-2021-1675 and CVE-2021-34527) enable remote code executive via the Microsoft Windows Print Spooler service. In this blog post, we describe how the Awake’s network detection and response platform provides built-in detections that could identify the exploitation activity associated with the 0-day exploits without any updates. We will also discuss detecting these threats on the network even when the activity occurs over encrypted SMB v3. Finally, while we hope this is the last Print Spooler service vulnerabilities, is there anything we can do to detect future exploits? Read on.

How did Awake detect the initial 0-day proof of concept (PoC) exploits for this vulnerability without needing updates? Also, I thought some of the initial PoC exploits used encrypted SMBv3 traffic. How could you possibly detect those exploits?!

Awake is focused on identifying the activities and behaviors systems exhibit. While that sometimes means identifying interesting changes in a system, in this case it was the “consequential artifacts” that allowed us to detect these kinds of exploits out-of-the-box. Consequential artifacts are [many times] the behaviors a system exhibits in response to being exploited or compromised. In most cases, attackers have no control over these artifacts being produced. They can certainly attempt to clear these artifacts from logs or hide them from EDR agents, but the attacker has no control over the initial generation of these artifacts. Awake takes a formal approach to consequential artifact centric detection, which Awake has pioneered in its application to the network.

In the case of the initial PoCs for CVE-2021-34527 (aka PrintNightmare) and CVE-2021-1675, a second stage payload needed to be transferred. While it’s notable to point out that even if the exploit was sent over encrypted SMBv3 packets, the 2nd stage payload is transferred with the server making the request (the source of the session) using SMBv2. However, more notable is the mechanism by which the transfer takes place. Files transferred using SMB are a very common activity on most networks, however the vast majority of that activity is file transfers from a file system location from one device to the file system destination of another device. In this case, the 2nd stage payload transfer is not intended for a specific location on the destination file system (in this case, the exploited server is the destination). Rather, in these exploits, the file is requested by an exploited service (the Windows Print Spooler service) and is intended (initially) for use in that service’s memory address space, not the file system. This leads to the file transfer having a number of characteristics (including lack of file system related artifacts) that strongly separate it from the vast majority of normal SMB file transfers.

Awake has performed a deep analysis of these characteristics because they are common consequential artifacts of other tools like PsExec, Mimikatz, Cobalt Strike, and others. Because of this, Awake has detections and hunting “skills” (built-in queries) for these types of transfers, and all the examined initial PoCs matched these AML (Adversarial Modeling Language) detections or skills.

How were Awake’s threat models enhanced in response to examining the vulnerable operation (AddPrinterDriverEx) in SPOOLSS service endpoint?

Of course, a model was added to detect the actual exploit within 24 hours. Furthermore, Awake’s Threat Research Team proactively performed a retroactive hunt in all customers for any past exploit-related activity. While this vulnerability should hopefully be patched and mitigated soon, it may be worth auditing exploit attempts for the near future.

Probing related to PrintNightmare should be audited for the near future.Figure 1: Probing related to PrintNightmare should be audited for the near future.

Additionally, a model was added that provides for much greater sensitivity to any request from a server for executable code (EntityIQ automatically identifies and classifies servers within the network and tags them with the appropriate type and role – see Figure 2). This includes the types of file transfers with the characteristics mentioned in the previous section, however this new model is less stringent (will trigger more easily) on activity originating from a server.A new adversarial model is particularly sensitive to executable code transfers requested by servers-PrintNightmare

Figure 2: A new adversarial model is particularly sensitive to executable code transfers requested by servers (in the pictured case, a Domain Controller).

What happens when some other obscure operation (like AddPrinterDriverEx in PrintNightmare) is exploited in the future?

First, this is very likely. There has been a lot of buzz in the exploit community recently about the age of the code not-only in SPOOLSS, but also its close relative IREMOTEWINSPOOL, as there has been an increase of exploitable vulnerabilities in these interfaces over the past few years. Awake’s Threat Research Team has also investigated the in-the-wild usage of the AsyncAddPrinterDriver operation that exists within the IREMOTEWINSPOOL DCERPC interface endpoint. While AsyncAddPrinterDriver may not have the same vulnerable APD_INSTALL_WARNED_DRIVER bypass object access check vulnerability found in the SPOOLSS function, the increased attention to spooler functions in general could likely lead to other undisclosed 0-days in these functions.

Using Awake’s Adversarial Modeling Language (AML), both the models and the UI itself is extensible by users of the platform. It is possible for instance, to create custom functions for your queries and even custom visualizations within the UI. In this case, our Threat Research Team quickly created custom UI elements for investigating the usage of all functions exposed by both the SPOOLSS and IREMOTEWINSPOOL interfaces (Figure 3). As always, these custom functions and UI elements are added to libraries shared with customers and can be modified or adapted as necessary within the organization.A custom model and visualization for detecting usage of the PrintSpooler functions-PrintNightmare

Figure 3:. A custom model and visualization for detecting usage of the PrintSpooler functions.

Analysis of the operations (aka: functions) commonly executed on the spooler interfaces showed that many of the recent vulnerabilities exploited target operations that are obscure in the enterprise – including the operation exploited by PrintNightmare. Before this exploit code, the AddPrinterDriverEx operation was virtually unseen in all enterprises. It turns out that very few of the available functions exposed by the spooler interfaces are commonly utilized in the wild. Figures 4 and 5 show the usage of functions exposed by SPOOLSS and IREMOTEWINSPOOL on the networks we monitor. As can be seen there is a long tail with most being rarely used on a typical network.Most-to-least common usage of various operations in the SPOOLSS interface in the wildMost-to-least common usage of various operations in the IRemoteWinSpool interface in the wildFigures 4 and 5: Most-to-least common usage of various operations in the spooler interfaces in the wild.

If you’ve studied these DCERPC interfaces deeply, you might notice only 40% of the available IREMOTEWINSPOOL functions and only a measly 15% of the available SPOOLSS functions are shown in the graphs. Figures 4 and 5 contain only the most consistently encountered functions in the wild, and even within that subset, only a few of those are commonly seen.

Because this research showed that so many of the recent print spooler vulnerabilities have targeted functions that are virtually unused in the enterprise, a new model has been developed to identify when a device on the network begins accessing functions in DCERPC interfaces that were not commonly used by other devices on the network before that point. This provides extremely effective detection of future 0-day exploitation of obscure interface functions, which has been common in the recent vulnerabilities targeting DCERPC interfaces.

Figure 6: AML models are being tested that alert to new usages of DCERPC interfaces that were not commonly used before.

The model shown in Figure 6  (recipes.hunting.machineLearning.characteristicArtifactMatchingAQL.foregroundCountLessThan) is a powerful new form of customizable threat detection that can be used for many cases and protocols besides DCERPC. More on that in a follow-up blog. In short, this open model (it has been added to shared libraries with customers) allows threat analysts to identify activities that are persistent, but have characteristics that are uncommon for other devices in the network. We then filter to only those outliers with the characteristics the analyst is interested in. At a very high-level, the model in figure 6 will identify when a device begins executing extremely uncommon operations (device.characteristic.dcerpc.call.opnum) against either of the named interfaces (IREMOTEWINSPOOL, SPOOLSS).

Summary

Like most Windows vulnerabilities, especially those of the unpatched variety, defenders should look at countermeasures that can help mitigate risk: ensuring privileges are as tight as possible, disabling the Print Spooler service and remote printing if possible, especially for external facing vulnerable infrastructure. At the same time, it is clear this is not going to be the last of these kinds of vulnerabilities and so defenders must ensure their detection and response and threat hunting methodologies and tools are enabled to uncover future activity and new zero days.

Subscribe!

If you liked what you just read, subscribe to hear about our threat research and security analysis.

Gary Golomb
Gary Golomb

Co-Founder & Chief Scientist