PrintNightmare, the name given to a group of vulnerabilities affecting the Windows Print Spooler service, continues to be a hot topic. Our previous blog on this subject explains urgent mitigations to be taken for the first two reported vulnerabilities, CVE-2021-1675 and CVE-2021-34527. However, cybersecurity researchers are still uncovering new, related vulnerabilities that can be exploited.
The reasons that the Windows Print Spooler service is receiving so much attention are:
- The high impact of the vulnerabilities coupled with the widespread use of the affected service in enterprise environments
- The high availability of exploits to the public
- The apparent inadequacy of the patches released by Microsoft to fully remediate the threat
In this blog, we show the steps that security engineers can follow to check whether systems of interest remain vulnerable to known popular exploit PoCs (Proof of Concepts). We focus on the highest-impact cases associated with the RCE (Remote Code Execution) vulnerability, rather than exploits related to LPE (Local Privilege Escalation).
By showing what a successful attack looks like on the file system and at the network level, this blog can help you determine whether or not your systems remain vulnerable.
PrintNightmare RCE PoCs
By the time news of PrintNightmare hit all the major cybersecurity channels, there were already several RCE exploits available for everybody, including cybercriminals, to use. They were written in different programming languages and looked slightly different in network traffic. However, all of the RCE exploits require valid credentials from the vulnerable system, as well as the actual executable payload. The executables must be in the form of a DLL and available in a SMB share, accessible by the target host.
Here are the top popular PrintNightmare RCE PoCs and some technical peculiarities associated with them.
NB: Always exercise extreme caution when compiling and executing exploit PoC tools. Consider doing a code review for extra security. Please note that if the following steps do not reveal anything, it is not a guarantee that the tested systems are completely secure against this threat.
PrintNightmare Exploit PoC 1
[inaccessible – see link below]
Programming language: C++
Impact: RCE
External dependencies: No
At the time of blog publication, the author of our first exploit had already made its repository inaccessible. However, security specialists can still get access to the source code on the WebArchive: https://web.archive.org/web/*/https://github.com/afwu/PrintNightmare.
The exploit code is distributed as a self-contained Visual Studio solution, which takes seconds to build and start to use. The resulting file, by default, is named POC.exe. As command-line arguments, it accepts the details of the targeted system (IP address and valid credentials), and the path to the payload DLL.
An important note, the DriverStore path embedded in the source code: C:\Windows\System32\DriverStore\FileRepository\ntprint.inf_amd64_19a3fe50fa9a21b6\Amd64\UNIDRV.DLL is not universal and won’t work on all 64-bit systems:
The author(s) of other PoCs addressed this issue by either resolving the path dynamically, or letting the attacker specify it as a command-line argument.
Host Machine
Here is how the corresponding command line looks, where the 172.16.7.50 is the host machine, 172.16.7.52 is the victim machine and the test.dll is any clean file:
Here is the tool output if everything has gone as expected:
Target Machine
If the target machine is still vulnerable, the following activity can be seen in the file monitor (in this case, part of the Process Monitor by Sysinternals):
As we can see here, the affected system successfully read the payload DLL from the SMB share before loading it. We suggest using the filter by spoolsv.exe process name to quickly navigate through results.
Here is how the recorded network traffic will look (filtered by IP addresses):
PrintNightmare Exploit PoC 2
https://github.com/cube0x0/CVE-2021-1675
Programming language: Python
Impact: RCE
External dependencies: Yes, a custom Impacket toolset
Here, the PoC dynamically resolves the above-mentioned DriverStore path for the target machine, so this exploit is more universal. Apart from the actual exploit script, an impacket package is required to make it work, which can be found in another repository of the same author.
Host Machine
Here is the corresponding command line to execute it:
Normal tool output once executed:
Target Machine
If the target machine remains vulnerable, the following activity will be revealed in the Process Monitor running there:
Similar to the previous PoC, the vulnerable system was forced to obtain the payload DLL from the SMB share before loading it.
Here is a snippet of the corresponding network traffic:
PrintNightmare Exploit PoC 3
https://github.com/cube0x0/CVE-2021-1675/tree/main/SharpPrintNightmare
Programming language: C#
Impact: RCE
External dependencies: No
The author is the same as for the previous exploit, but this time the result PoC is a standalone executable written in C#, which is easier to distribute and use.
Host Machine
Here is the corresponding command line. As you can see, the DriverStore value is expected to be provided as an argument:
If everything is correct, the output will look like this:
Target Machine
If the target machine is vulnerable, the Process Monitor will reveal pretty much the same file system activity as in the previous two cases:
Here is an example of network traffic associated with this exploitation attempt:
Vulnerabilities Require Constant Vigilance and Swift Mitigation
Due to the complexity of modern systems, it’s inevitable that in the future there will continue to exploits in the wild for vulnerabilities without comprehensive patches. We urge security teams to stay alert to the news cycle, vendor notifications, government advisories, etc. for the latest information on vulnerabilities. And, be ready with the people, processes and technology to act quickly to mitigate such risks.
