This week, PrintNightmare – Microsoft’s Print Spooler vulnerability (CVE-2021-34527) was upgraded from a ‘Low’ criticality to a ‘Critical’ criticality.
This is due to a Proof of Concept published on GitHub, which attackers could potentially leverage for gaining access to Domain Controllers.
As we reported earlier, Microsoft already released a patch in June 2021, but it wasn’t enough to stop exploits. Attackers can still use Print Spooler when connecting remotely. You can find all you need to know about this vulnerability in this article and how you can mitigate it (and you can).
Print Spooler in a nutshell: Print Spooler is Microsoft’s service for managing and monitoring files printing. This service is among Microsoft’s oldest and has had minimal maintenance updates since it was released.
Every Microsoft machine (servers and endpoints) has this feature enabled by default.
PrintNightmare vulnerability: As soon as an attacker gains limited user access to a network, he will be able to connect (directly or remotely) to the Print Spooler. Since the Print Spooler has direct access to the kernel, the attacker can use it to gain access to the operating system, run remote code with system privileges, and ultimately attack the Domain Controller.
Your best option when it comes to mitigating the PrintNightmare vulnerability is to disable the Print Spooler on every server and/or sensitive workstation (such as administrators’ workstations, direct internet-facing workstations, and non-printing workstations).
This is what Dvir Goren’s, hardening expert and CTO at CalCom Software Solutions, suggests as your first move towards mitigation.
Follow these steps to disable the Print Spooler service on Windows 10: Open Start. Search for PowerShell, right-click on it and select the Run as administrator. Type the command and press Enter: Stop-Service -Name Spooler -Force Use this command to prevent the service from starting back up again during restart: Set-Service -Name Spooler -StartupType Disabled
According to Dvir’s experience, 90% of servers do not require Print Spooler. It is the default configuration for most of them, so it is usually enabled. As a result, disabling it can solve 90% of your problem and have little impact on production.
In large and complex infrastructures, it can be challenging to locate where Print Spooler is used.
Here are a few examples where Print Spooler is required: When using Citrix services, Fax servers, Any application requiring virtual or physical printing of PDFs, XPSs, etc. Billing services and wage applications, for example.
Here are a few examples when Print Spooler is not needed but enabled by default: Domain Controller and Active Directory – the main risk in this vulnerability can be neutralized by practicing basic cyber hygiene. It makes no sense to have Print Spooler enabled in DCs and AD servers. Member servers such as SQL, File System, and Exchange servers. Machines that do not require printing.
A few other hardening steps suggested by Dvir for machines dependent on Print Spooler include: Replace the vulnerable Print Spooler protocol with a non-Microsoft service. By changing ‘Allow Print Spooler to accept client connections’, you can restrict users’ and drivers’ access to the Print Spooler to groups that must use it. Disable Print Spooler caller in Pre-Windows 2000 compatibility group. Make sure that Point and Print is not configured to No Warning – check registry key SOFTWARE/Policies/Microsoft/Windows NT/Printers/PointAndPrint/NoElevationOnInstall for DWORD value 1 and change it to 0. Turn off EnableLUA – check registry key SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLUA for DWORD value 0 and change it to 1.
Here’s what you need to do next to ensure your organization is secure: Identify where Print Spooler is being used on your network. Map your network to find the machines that must use Print Spooler. Disable Print Spooler on machines that do not use it. For machines that require Print Spooler – configure them in a way to minimize its attack surface.
Beside this, to find potential evidence of exploitation, you should also monitor Microsoft-Windows-PrintService/Admin log entries. There might be entries with error messages that indicate Print Spooler can’t load plug-in module DLLs, although this can also happen if an attacker packaged a legitimate DLL that Print Spooler demands.
The final recommendation from Dvir is to implement these recommendations through hardening automation tools. Without automation, you will spend countless hours attempting to harden manually and may end up vulnerable or causing systems to go down
After choosing your course of action, a Hardening automation tool will discover where Print Spooler is enabled, where they are actually used, and disable or reconfigure them automatically.
Found this article interesting? Follow THN on Facebook, Twitter and LinkedIn to read more exclusive content we post.