ĢTV

This is some text inside of a div block.
Glitch effect

Critical Vuln.: PrintNightmare Exposes Windows Servers to RCE

Contributors:
Special thanks to our Contributors:
Glitch effectGlitch effectGlitch effect
Glitch banner

On June 29, ĢTV was made aware of (now termed , a critical remote code execution and local privilege escalation vulnerability dubbed “PrintNightmare.”

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, and released emergency patches, but the effectiveness of this security update is still under scrutiny.

have validated the new patch on Windows 21H1 Enterprise, and it has stopped local privilege escalation—however, this . This seemingly partial fix , but not yet covers privilege escalation. According to 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.

  • ұ-dzٹ󾱳
ұ-dzٹ󾱳cmdlet output
get hotfix
  • ٱ𳾾Դڴ
ٱ𳾾Դڴcommand output
ٱ𳾾Դڴcommand output
  • The HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint registry path was not present.

UPDATE July 02 @ 8:48am ET: , 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. ĢTV 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 , 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 (, ) 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 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. was brought to light by the team at , 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 ):

$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 
  • Check out Kevin Beaumont's 
  • Consider Lares'  if you're a Sysmon shop

Fellow researchers have also shared and to have better visibility on attacks weaponizing PrintNightmare.

What Is ĢTV 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  outside of the previously listed folders (doesn't appear to bypass the ACL technique or Olaf Hartung's )

Other security researchers, including Mimikatz author Benjamin Delpy, are observing  (some fully patched servers are  to a domain controller). We're also noticing that sometimes repeated successful exploitation attempts don't always get logged within  (Possible caching?)

The ĢTV 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 (,). Our team has reviewed the source code for each and confirmed both successfully Ի systems. We haven't experimented on all Windows operating systems, but  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 ĢTV partners have been compromised. Here's a filtered view of spoolsv.exe in ProcMon.

PrintNightmare 1

 Fetching the malicious DLL from attacker SMB share

PrintNightmare 2

Python PoC attempting to find temp destination for the malicious DLL

PrintNightmare 3


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  PowerShell snippet:

$logDeets = Get-LogProperties 'Microsoft-Windows-PrintService/Operational'$logDeets.Enabled = $trueSet-LogProperties -LogDetails $logDeets

Needless to say, lots of  going down. 😉

ĢTV 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. ĢTV 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.

Share

Sign Up for Blog Updates

Subscribe today and you’ll be the first to know when new content hits the blog.

By submitting this form, you accept our Privacy Policy
Oops! Something went wrong while submitting the form.
ĢTV at work
Response to Incidents
Response to Incidents