Update: No longer considered a zero-day, keep reading for the fix.
Two days ago, I wrote an article about a malicious driver that Microsoft had digitally signed. In that article, I said, "it's not a matter of if we'll be covering another security event blog, but when." Well, apparently, the answer to that question is today, two days later...
Here We Go Again
Printers have been responsible for their fair share of issues recently. Whether they're being exploited or crashing systems, printers seem to be a vulnerable spot in a world that is becoming less dependent on them as we transition to digital formats. Fortunately, Microsoft takes these issues seriously and is usually swift with a solution. Unfortunately, this time around, we've got an exploit and a proof of concept that was posted publicly by a security firm believing the exploit had already been patched. Spoiler alert, it hasn't.
Aptly named PrintNightmare, this new exploit, which was believed to have been resolved with Windows June 8th patches, is, in fact, a new exploit. Systems with the Print Spooler service enabled are vulnerable to be exploited.
How Bad Is It?
That depends. If you work for a paperless organization and you've already disabled the Print Spooler service, then grab yourself a latte and relax; your work here is done. If you live in the real world like the rest of us, then you've probably got some work to do. Considering that a threat actor could use this exploit to perform local privilege escalation and remote code execution, the sooner you get to work, the better.
You may have already guessed this, but the short-term solution is to stop and disable the Print Spooler service. Crazy, right?
Before you go disabling the service across your entire organization, there are a couple of things to consider. First, to take advantage of the exploit, the actor must have an authenticated user's credentials. It doesn't matter if those credentials belong to a standard or administrative user. While this provides some level of comfort, keep in mind that obtaining credentials is not a very difficult task. In fact, with dark web forums hosting and selling lists of credentials, a threat actor could honestly just purchase compromised credentials. You may have users in your environment who have already had their credentials compromised and don't even know it.
The second thing to consider is where a threat actor could do the most harm. While any compromised system is a big no-no, a compromised domain controller is a much bigger no-no. If nothing else, the current recommendation is to stop and disable the Print Spooler service on domain controllers and other high-risk systems.
This has now officially been patched with out-of-band update KB5005010. After the release there was a lot of information published that stated it was not fully protected. We sifted through all the information and it looks like most are protected, but those that are using Point and Print may still be at risk. Luckily, it is easy to track those that need a little extra love. Point and print is set up through Group Policy at Computer Configuration/Policies/Administrative Templates/Printers. You can set these to the secure options by editing Point and Print Restrictions and set both to Show Warning and Elevation Prompt
This should take care of everything, but with everything that has gone into this one, let’s go into how we can track if we are secure, and how we can fix it if the Group Policy does not do it. In PDQ Inventory Click on Scan Profiles and select New. Select Registry for the type and put “SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\” without the quotes in the Include Pattern window.
Scan your environment with this and it will find a registry entry in that location, but we are only concerned about the bad entries. For this, we will build a dynamic collection that looks for either NoWarningNoElevationOnInstall or UpdatePromptSettings that has a value of one. Every machine that shows up in this collection is not fully secured. If you set the Group Policy up top these should remediate themselves over time, but to be more proactive all we need to do is build a Deploy Package to reset those values to 0 and run it against the Collection. Below is the PowerShell that will make these changes.
To make sure that your collection has updated, set the package to scan with your new registry scan after deployment. Every machine that was successful will be removed from the collection and you can have some peace of mind that you can re-enable the print scanner and be safe.
Finding Computers With Print Spooler Enabled With PDQ Inventory
Before we begin disabling the Print Spooler service, let's first make sure that we find all the computers that have the service running. With PDQ Inventory, we'll create a PowerShell scanner that will scan our machines for the service.
In PDQ Inventory, click New Scanner > PowerShell
Name the scanner
Add this script
The New Scan Profile window will open. Give the scan profile a name
Now that the scan profile has been created, we can run the scanner against the computers in PDQ Inventory.
Right-click All Computers
Click Scan Collection > "Your New Scan Profile"
Once the scan finishes, double-click on a computer to open up the properties
Select the PowerShell menu option
Select the correct scan profile to view the results
Now that we've collected that data, we can create a dynamic collection of all the computers with the service enabled.
In PDQ Inventory, click New Dynamic Collection
Give your collection a name
Add the following filters and click OK
"New Scan Profile Name" > StartType > Contains > Automatic
"New Scan Profile Name" > Status > Contains > Running
Keep in mind that this is only returning the computers that are in PDQ Inventory. If you have servers and other computers that are not in PDQ Inventory, you will need to manually check those.
Stopping & Disabling Print Spooler
Now that we've found the computers with the service running and enabled, here are a few methods of stopping and disabling the service. Keep in mind that disabling the service will also mean your users won't be able to print. Also, PDQ Inventory's auto reports and print preview rely on the Print Spooler service, and will also cease to function.
The first and probably the most common way to stop and disable the service is through the services app.
In the Windows search bar, type Services
Click on the Services App
Locate the Print Spooler service
Right-click on the service and click Properties
Click Stop under the service status
Change the startup type to Disabled
If PowerShell is more your style, we've got you covered.
That's all there is to it. Run that on your system, and it will stop and disable the Print Spooler service. If you want to deploy this script to multiple machines, you can create a custom package in PDQ Deploy with a PowerShell step and deploy it to as many targets as you need.
In PDQ Deploy, click New Package
Name your package
Click New Step > PowerShell
Copy the above script into the PowerShell window
With the package created, you can deploy it to as many targets as needed.
Another effective way to disable the Print Spooler service is with a GPO.
Open Group Policy Management
Right-click on the OU you want to assign the GPO to and click Create a GPO in this domain, and Link it here…
Name your GPO Disable Spooler Service and click OK
Right-click on your new GPO and select Edit
Navigate to Computer Configuration > Windows Settings > Security Settings > System Services
Double-click on Print Spooler
Select Define this policy setting
Select Disabled and click Apply and OK
These security events are becoming frequent enough that I'm starting to get some serious deja vu vibes. Hopefully, Microsoft releases a patch for this zero-day soon because I know disabling the Print Spooler service isn't the most attractive option for many users. However, if you don't need the Print Spooler enabled on your domain controllers or other high-risk systems, you may just want to have it permanently disabled since it's not the first time it's been exploited.