Security Brief: PrintNightmare

July 2, 2021

PrintNightmare Vulnerability

We have just become aware of a significant exploit with Windows machines out in the wild. This exploit, PrintNightmare takes advantage of the print spooler service in Windows and allows local privilege escalation.

Priority:

This exploit should be considered critical in terms of establishing a remediation and/or workaround plan. It is recommended that you remediate or institute a workaround within 24-48 hours via an emergency change.

The Vulnerability:

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.

The Remediation:

The June 8^th patch initially for this does not work and no patch is available at this time.

The Workaround:

There are a couple of workarounds that one can do to help protect against the exploit until a patch is made available via Microsoft:

Workaround 1:

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.

Workaround 2:

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
To remove the ACL via PowerShell deployment:
- $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