PrintNightmare for administrators: Trying to sum up the current knowledge for decision-making:

Copper Contributor

Hi guys,

I wrote this blog post in the hope of making it possible to make decisions on how to mitigate PrintNightmare, while waiting for an official patch from Microsoft.

I hope it's useful :)

10 Replies
Emergency Out-of-Band patches for #PrintNightmare are finally being rolled out.

But note:
1: Not all supported Windows versions have a patch yet, but they will come soon.

2: Currently, the fix only protects against Remote Code Execution, not against the Local Privilege Escalation bug.

So, keep Print Spooler disabled on all systems, that doesn't need it.

And keep the Group Policy:
Computer Configuration\Administrative Templates\Printers\Allow Print Spooler to accept client connections - Setting: Disabled
On systems that don't have to function as a print server.

@Martin Jeppesen 


You talk to yourself like me - we are both mad - welcome to the club :)


There are articles you need to read here and here.

I have two thirds of my Windows 10 machines with the patch installed although M365 security portal says otherwise. The patch bumps the Windows 10 version to 10.0.x.1083 so I know they are patched.


The second link has a key that can be activated to remove the remaining vulnerability so taking Thijs Lecomte work I modified his code to create a proactive remediation script (that I am still testing).





   Code sourced from here:
   Code copyright of THIJS LECOMTE

   Code modified from here :

   Detection script for Printnightmare KB5005010

   Code not used but under investigation.


$RegPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint"
$RegKey = "RestrictDriverInstallationToAdministrators"
$RegValue = 1

    if(!(Test-Path $RegPath -ErrorAction Stop)){
        Write-Host "Path doesn't exist"
        Exit 1
    $key = Get-ItemProperty -Path $RegPath | Select-Object -Property $RegKey -ErrorAction Stop
    if($key."$RegKey" -eq $RegValue){
        Write-Host "Key has correct value" 
        Exit 0
        Write-Host "Key has incorrect value or doesn't exist"
        Exit 1
    Write-Host "Key doesn't exist"
    Exit 1







   Code sourced from here:
   Code copyright of THIJS LECOMTE

   Code modified from here :

   Remediation script for Printnightmare KB5005010

   Code not used but under investigation


$RegPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint"
$RegKey = "RestrictDriverInstallationToAdministrators"
$RegValue = 1

if(!(Test-Path $RegPath -ErrorAction Stop)){
    New-Item $RegPath
    Write-Host "Created path"
    Set-ItemProperty -Path $RegPath -Name $RegKey -Value $RegValue
    Write-Host "Key has been set"

    Restart-Service -Name "Spooler" -force
    Write-Host "Spooler has been reset"
    Write-Error "Error setting key"



Since I am waiting on the M365 portal to determine the status of my machines and are not at this point looking at the Streaming API or the use of PowerBi (its a test tenant and I am trying to control costs.  I am going to wait another 12 hours before I upload the proactive remediation which will take another 24 hours in M365 portal to see the results (really annoying Microsoft).


Be warned I am a hobbyist and in training.  I am not responsible for a production environment.


If you have a DC and access to group policy you have more abilities than me.  I am pure Intune.


Any feedback is better than no feedback.



Leon Scott.


Hello Leon @braedachau ,


Ha ha, yes isn't it great to be mad :lol:


Yes, I'm actually about to update my blog post about the most recent discoveries.


However, I think you might have confused two things here.


KB5005010 describes how you can further enhance your security posture after applying the patch.

But it is not the one, that determines, whether the machine is still susceptible to Remote Code Execution attacks after the patch.


This is what KB5005010 is about:

  • Before the July patch, if you were in for example Print Operators group but not a local administrator, you could install unsigned drivers on a print server.
  • After the July patch, a Print Operator can only install signed drivers.
  • If you set the RestrictDriverInstallationToAdministrators reg value, Print Operators cannot even install signed drivers, only Administrators can.


What makes the machine still vulnerable to Remote Code Execution attacks even after installing the July patch is if the "NoWarningNoElevationOnInstall" value is set to 1 under the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint key


Which maps to this (vulnerable) GP configuration:

Computer Configuration\Administrative Templates\Printers\Point and Print Restrictions is enabled and has the setting:

Security Prompts:

When installing drivers for a new connection = Do NOT show warning and elevation prompt 


Have you put the latest cumulative update under the microscope yet?? ver 10.0.x.1110
I updated my code to reflect your advise. Found no systems with the key enabled.

I don't twitter.

In general it's always worth installing Patch Tuesday patches 8), and it seems that for some of the supported Windows versions this patch contains patches for PrintNightmare.

But this update isn't mentioned in MS's security advisory for CVE-2021-34527, so it doesn't seem to be important specifically for PrintNightmare.

I'd say that the patches from last week are the most important ones in combination with ensuring that Point and Print Restrictions are not configured in an insecure way.

My recommendations from the latest update of my blog post are:
* Disable Print Spooler service on any Windows device, that does not need to print.

* For devices, that need to do print jobs- like user workstations - but not to print on behalf of remote users: Set this in Group Policy Computer Configuration\Administrative Templates\Printers\Allow Print Spooler to accept client connections - Setting: Disabled
(Remember to restart the Print Spooler service for this mitigation to take effect!)

* If in any way possible: Apply the Microsoft patches and make sure Point and Print Restrictions are configured with the secure settings.

* If none of the above are options: You can consider the unofficial mitigations, like 0Patch or the “Deny-SYSTEM-in-ACL-mitigation”. But be careful not to cause outages or things breaking, especially regarding the “Deny-SYSTEM-in-ACL-mitigation”.

@Martin Jeppesen 

Yes, but the setting that poses a threat = is human error.
But organizations often delay the update - i encourage quick deployments!
Thank you for the interesting topic!

To be honest, I kind of feel, that Microsoft's statement is a bit of a low blow: "All reports we have investigated have relied on the changing of default registry setting related to Point and Print to an insecure configuration."

They are almost implying, that some customers have "hacked" their systems to an irresponsibly insecure state.

The fact is, that nowhere in the Group Policy help text for this GP setting does it state that the setting - which Microsoft has made available in Group Policy - is frowned upon, is bad security practice or at least explained the ramifications of setting this configuration.

You will even find Microsoft documents online, that will guide you step-by-step on how to set this this insecure configuration.

Also, many enterprises will have printers, that do not have Package Aware printer drivers and have therefore set up this policy in the insecure configuration simply to make things work for their users (and been guided on how to do it through Microsoft documentation).

I do feel, that Microsoft should be willing to take partly responsibility for this instead of just "washing their hands".