PrintNightmare: 0-Day Exploit for Windows Domain Server Print Spooler

UPDATED 7/2/21: We’ve included additional guidance for mitigating this exploit as well as a method for detection.

For your security, please take this notice seriously.

A new 0-day exploit, dubbed PrintNightmare, has been discovered in the wild that is allowing attackers to gain access to Windows Domain Controllers (DC) and execute remote code.

Yes, authentication is still needed by the attacker, but this is not a deterrent because anyone with access to the print spooler (read: anyone who can print from the network) is at risk. Once the attacker has access, they can use this exploit to escalate privileges to full SYSTEM access from a Domain User account and execute remote code on the network.

Here are the steps to mitigate this vulnerability on your network:

  1. Before you do anything else, apply the patch Microsoft sent out, it may not fix it completely, but it does help in lessening the attack surface.
  2. Disable print Spooling Service
    via Powershell
    Single Machine (Small Organizaitons)
    Powershell snippet
    Stop-Service -Name Spooler -Force
    Set-Service -Name Spooler -StartupType Disabled
    Can also be configured under: Policies/Windows Settings/Security Settings/System Services/Print Spooler
    or if Disabling Printer Spool service isn’t practical for your environment you can utilize this ACL:
    Powershell Snippet:
    $Path = “C:\Windows\System32\spool\drivers”
    $ACL = Get-Acl $Path
    $NewRule = New-Object System.Security.AccessControl.FileSystemAccessRule(“System”, “Modify”, “ContainerInherit, ObjectInherit”, “None”, “Deny”)
    Set-Acl $Path $ACL
    This will prevent any new/rogue DLLs from being added and still allow for relatively normal functionality. Be Advised: While this ACL is active NO CHANGES can be made to print drivers
    Here is the Powershell command to REMOVE the ACL:
    $Path = “C:\Windows\System32\spool\drivers”
    $ACL = Get-Acl $Path
    $NewRule = New-Object System.Security.AccessControl.FileSystemAccessRule(“System”, “Modify”, “ContainerInherit, ObjectInherit”, “None”, “Deny”)
    Set-Acl $Path $ACL
  3. This vulnerability requires an authenticated user, so ensuring that all privileged users are using MFA is a compensating control that can reduce the risk.
  4. There are known PoCs floating in the wild and are actively being shared by others that can be used as an attack method.
  5. After applying the patch from Microsoft, if HKLM\SOFTWARE\Policies\Microsoft\WindowsNT\Printers\PointAndPrint\NoElevationOnInstall is 1, then the system is still vulnerable.

Alternatively, another workaround is to remove authenticated users from Pre-Windows 2000 Compatible Access as discovered by Dirk-jan.

Ensure the “Anonymous Logon” and “Everyone” groups are not members of the “Pre-Windows 2000 Compatible Access group”. (By default, these groups are not included in current Windows versions.), in addition ensure that ‘Authenticated Users’ are also not a member as shown in the screenshot below there should be no members:


If in doubt as to how to do this, the following steps can be taken:

  1. Open “Active Directory Users and Computers” (available from various menus or run “dsa.msc”).
  2. Expand the domain being reviewed in the left pane and select the “Builtin” container.
  3. Double-click on the “Pre-Windows 2000 Compatible Access” group in the right pane.
  4. Select the “Members” tab.
  5. If the “Anonymous Logon”, “Authenticated Users” or “Everyone” groups are members, select each and click “Remove”.

Options for Easier Detection:

  1. Enable the Microsoft-Windows-PrintService/Operational Logging (disabled by default). This will allow for monitoring of entries in Microsoft-Windows-PrintService/Admin and Event ID: 316
  2. PowerShell snippet:
  3. $logDeets = Get-LogProperties ‘Microsoft-Windows-PrintService/Operational’
  4. $logDeets.Enabled = $true
  5. Set-LogProperties -LogDetails $logDeets
  6. ​​​​​​​You can scan for all vulnerable assets with QID 91772 if you have Qualys Vulnerability Manager

You can read more about this PrintNightmare 0-day exploit here.

As always, feel free to reach out to us if you have any questions and please feel free to share this post with other colleagues and organizations who might be at risk.

Stay safe!