On June 29, Huntress was made aware of CVE-2021-1675 (now termed CVE-2021-34527), a critical remote code execution and local privilege escalation vulnerability dubbed “PrintNightmare.”
Microsoft released a patch on June 8 considering this vulnerability low in severity. On June 21, PrintNightmare was updated to critical severity as the potential for remote code execution was uncovered. The June 8 Microsoft patch did not successfully resolve the issue for CVE-2021-32547 PrintNightmare, but it did resolve CVE-2021-1675.
UPDATE July 07 @ 12pm ET: On July 6, Microsoft updated their advisory on CVE-2021-34527 and released emergency patches, but the effectiveness of this security update is still under scrutiny.
Members of our Huntress team have validated the new patch on Windows 21H1 Enterprise, and it has stopped local privilege escalation—however, this privilege escalation still succeeds on Windows Servers. This seemingly partial fix does look to prevent remote code execution, but not yet covers privilege escalation. According to Microsoft's latest updates on July 6, "Updates are not yet available for Windows 10 version 1607, Windows Server 2016, or Windows Server 2012. Security updates for these versions of Windows will be released soon."
So far, we have not seen a patch scenario that all-encompasses (1) preventing local privilege escalation, (2) preventing remote code execution and (3) allows printing.
UPDATE July 08 @ 10:18am ET: There have been requests for the technical information on the machine we had tested the patch on. On a Windows 10 21H1 Enterprise VM, it had stopped the Mimikatz implementation of local privilege escalation.
- Get-HotFix cmdlet output
- systeminfo command output
- The HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint registry path was not present.
UPDATE July 02 @ 8:48am ET: Microsoft has now termed PrintNightmare as CVE-2021-34527, what some of us originally considered as CVE-2021-1675. The threat is still real—just had a naming confusion. Strictly 1675 was addressed in the June 8 updates but 34527/PrintNightmare still goes without a patch.
This blog post hopes to raise awareness of this vulnerability, as this is a severe security flaw affecting an incredibly large number of Windows Servers.
Note: This is still breaking news and an emerging threat. Huntress will continue to update this blog with our observations and any indicators of compromise following post-exploitation activity if discovered.
As this develops, you can (and should) stay up-to-date with the latest security advisories, headlines and threat intelligence.
UPDATE June 30 @ 5:24pm ET: We have shared this in r/msp on Reddit, please check that thread for community input and other insights.
UPDATE June 30 @ 5:28pm ET: Added new detection information for ImageLoad and Microsoft's previous information citing the need to prune print queues if the Print Spooler service is disabled.
UPDATE June 30 @ 9:01pm ET: Included another option for temporary mitigation without hindering printing functionality from the Print Spooler service.
UPDATE July 01 @ 9:14am ET: Updated to better reflect guidance from our Reddit post with new intel.
UPDATE July 02 @ 8:48am ET: Updated to include the new Microsoft advisory for CVE-2021-34527.
What Does PrintNightmare Do?
PrintNightmare affects a native, built-in Windows service named “Print Spooler” that is enabled by default on Windows machines. In the past, Print Spooler has been targeted for other attacks and exploits, but it remains prevalent on modern operating systems. The purpose of Print Spooler is to manage printers or printer servers. Oftentimes, this is not a critical or business-essential service and can be disabled.
The impact of this attack vector lends to local privilege escalation and remote execution.
- Local privilege escalation means if a bad actor already has access to a compromised machine with a low privilege user account (oftentimes domain users), they can easily and immediately gain administrator or SYSTEM level rights to fully own the machine.
- Remote code execution means that this attack vector can be weaponized externally, from one separate computer to another. Not only does this offer an option for initial access—it readily enables lateral movement into other high-value systems (like a domain controller).
With these effects, threat actors with any non-administrator user and credential (password or NTLM hash) can rapidly gain full access to a domain controller and take over a whole domain.
This is a severe security flaw that affects an incredibly large number of Windows servers. Multiple proof-of-concept exploits have been released (Python, C++) and we've confirmed this vulnerability is trivial to exploit.
As this affects so many Windows servers, we strongly encourage you to take action.
What Should MSPs Do?
The June 8 patch from Microsoft does not fix this issue.
Currently, a temporary, band-aid solution is to disable the Print Spooler service.
Note: This may have other unwanted implications if your organization prints things to PDF before sending them in emails, like for payroll purposes or other use cases.
If disabling the Print Spooler service is appropriate for your organization, you can do this on a single machine with a few PowerShell commands:
Stop-Service -Name Spooler -Force Set-Service -Name Spooler -StartupType Disabled
With your RMM solution or PSRemoting, this can be fanned out to multiple hosts.
This can also be configured via Group Policy, under...
Policies/Windows Settings/Security Settings/System Services/Print Spooler
We advise you to monitor log entries in Microsoft-Windows-PrintService/Admin to find potential evidence of exploitation. Entries with error messages failing to load plug-in module DLLs could be an indicator, but if a threat actor packaged a legitimate DLL that Print Spooler would demand, this error is not logged.
For visibility on these logs, ensure that you have Microsoft-Windows-PrintService/Operational logging enabled.
UPDATE June 29 5:28pm ET: Organizations may not have logging for Print Service operations enabled and may have difficulty enabling them site-wide. If you cannot readily enable that logging, another option is to look for the use of ImageLoad (Event ID 7) with the `spoolsv.exe` process. Researchers have shared Sigma rules to help detect this.
Microsoft has shared previous information regarding the Print Spooler service and explains that disabling it does carry the trade-off between security and the ability to perform print pruning. Their note explains that “to mitigate the side-effects of disabling the print service, you can work to prune stale print queue objects either manually or with an automated script.”
UPDATE June 29 @ 9:01pm ET: Disabling the Print Spooler service and stopping printing altogether is certainly impractical for some businesses. While it is one option for a subpar band-aid fix, another option without disabling the service is restricting the access controls (ACLs) in the directory that the exploit uses to drop malicious DLLs. This method was brought to light by the team at TrueSec, and we, alongside the community, offer kudos and props for their efforts.
Changing the ACLs prevents rogue DLLs from being placed by the targeted print spooler service and still maintains the service functionality. Note: You will not be able to install/uninstall/make changes to your printer drivers while this ACL is in place, and some Citrix users have reported printing issues with this method.
PowerShell code to constrain the ACL is below:
$Path = "C:\Windows\System32\spool\drivers"$ACL = Get-Acl $Path$NewRule = New-Object System.Security.AccessControl.FileSystemAccessRule("System", "Modify", "ContainerInherit, ObjectInherit", "None", "Deny")$ACL.AddAccessRule($NewRule)Set-Acl $Path $ACL
Below is a video demonstration of this ACL in effect, preventing the proof of concept from dropping a malicious DLL.
To remove the ACL via PowerShell deployment (shoutout and kudos to community member u/bclimer in our Reddit thread):
$Path = "C:\Windows\System32\spool\drivers"$ACL = Get-Acl $Path$NewRule = New-Object System.Security.AccessControl.FileSystemAccessRule("System", "Modify", "ContainerInherit, ObjectInherit", "None", "Deny")$ACL.RemoveAccessRule($NewRule)Set-Acl $Path $ACL
For other technical details:
- Follow our live forensics thread in the comments of our Reddit thread
- Check out Kevin Beaumont's solid explainer blog
- Consider Lares' detection config if you're a Sysmon shop
Fellow researchers have also shared detection rules and techniques to have better visibility on attacks weaponizing PrintNightmare.
What Is Huntress Doing?
We've completed our first review and all 34,000+ networks are looking clean so far. We will continue to share if we see post-exploitation activity. We're also keeping a close eye on the ability to craft directory traversing payload paths outside of the previously listed folders (doesn't appear to bypass the ACL technique or Olaf Hartung's Defender for Endpoints KQL)
Other security researchers, including Mimikatz author Benjamin Delpy, are observing funky vulnerability behavior (some fully patched servers are not vulnerable until promoted to a domain controller). We're also noticing that sometimes repeated successful exploitation attempts don't always get logged within Microsoft-Windows-PrintService/Admin. (Possible caching?)
The Huntress agent specifically monitors for hacker activity indicated by the presence of persistence and persistent footholds, like backdoors or implants.
PrintNightmare on its own does not create a persistent foothold, but with the impact of privilege escalation and code execution, it offers the ability for later post-exploitation and persistence.
Two public PoCs have dropped on GitHub (Python, C++). Our team has reviewed the source code for each and confirmed both successfully exploit Server 2016 and Server 2019 systems. We haven't experimented on all Windows operating systems, but Microsoft's CVE announcement states Windows 7, 8, 8.1, 10 and Server 2008, 2008 R2, 2012, and 2012 R2 are impacted).
For those technical folks who want to follow along, our team is diving into the exploit's behaviors to help us determine if any Huntress partners have been compromised. Here's a filtered view of spoolsv.exe in ProcMon.
Fetching the malicious DLL from attacker SMB share
Python PoC attempting to find temp destination for the malicious DLL
Finds the malicious DLL (and executes it)
From this quick analysis, we learned there's a handful of directories we can monitor for dropped payloads:
- C:\Windows\System32\spool\drivers\x64\3\
- C:\Windows\System32\spool\drivers\x64\3\old
- C:\Windows\System32\spool\drivers\x64\3\new
Enabling the Microsoft-Windows-PrintService/Operational event log (disabled by default) and monitoring for event ID 316 yields solid detection results in our lab testing regardless of whether the exploit is successful. Fellow security researcher Jake Williams has seen the same success and recommended the following PowerShell snippet:
$logDeets = Get-LogProperties 'Microsoft-Windows-PrintService/Operational'$logDeets.Enabled = $trueSet-LogProperties -LogDetails $logDeets
Needless to say, lots of hunting going down. 😉
Huntress will remain on the lookout for updates and other threat intelligence as it develops and will continue to update this article.
Learn More: Research and Intelligence
The information security community stands on the shoulders of giants. That means the whole industry plays in concert to share knowledge, resources and understanding. Huntress has no intention of being your sole provider as there is a whole world of actionable information.
As this news develops, we encourage you to follow the research and intelligence from others in our industry and the information security community. It takes a village.
