How to protect your system from the SeriousSAM vulnerability in Windows

Microsoft just can't seem to catch a break. If you’ve been anywhere near a screen over the past month, then you've probably seen the numerous vulnerabilities afflicting Windows systems as of late. From the Print Spooler fiasco, aka "PrintNightmare," to IIS and PowerShell vulnerabilities, the steady stream of exploits seems unending. 

If, on the other hand, this is all news to you, then it’s time to get you up to speed on the newest risk your system could face--and what you can do about it. 

CVE-2021-36934, aka SeriousSAM

This new vulnerability, CVE-2021-36934, aka SeriousSAM, aka HiveNightmare, grants low-privileged users access to the sensitive registry database files located in the C:\Windows\system32\config folder. You may be wondering what a user has to do to take advantage of the vulnerability. Unfortunately, they don't have to do anything. It seems that standard users have been granted permissions to this folder since Windows 10 version 1809, which was released in October, 2018.

The Risk

The very thin silver lining here is that in order to take advantage of this vulnerability, an attacker would first need to have the ability to execute code on the vulnerable system. However, keep in mind that gaining access to a system isn't very difficult with spear-phishing attacks.

Once the attacker has access to a vulnerable system, they have access to these sensitive files, which contain the hashed passwords for all accounts on the machine. However, because these are systems files that are always in use, an attacker won't be able to manipulate these files directly. Instead, an attacker can get around this by accessing the Windows shadow volume copies. In short, once the attacker has access to these files, they can easily obtain elevated account credentials.

As per Microsoft:

"An attacker who successfully exploited this vulnerability could run arbitrary code with SYSTEM privileges. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights."

The Workaround

While we await an official patch from Microsoft, they have given us a workaround that they recommend implementing on vulnerable systems. The first step of the workaround is to restrict access to the %windir%\system32\config folder by enabling inheritance on all the files contained in the config folder. Here is the ICACLS command:

The last step of the workaround is to delete the vulnerable shadow copies. Be aware that deleting the shadow copies could impact restore point operations, including restoring data with third-party backup applications.

Implementing the Workaround with PDQ Inventory & PDQ Deploy

The first thing we want to do is identify all of our vulnerable devices. We can create a PowerShell scanner and a dynamic collection in PDQ Inventory to take care of that.

Creating the PowerShell scanner:

1. Click New
2. In PDQ Inventory, click Scan Profiles

3. Enter a name for the scan profile. I've used the name "SeriousSAM."
4. Click Add > PowerShell

5. Give the PowerShell scanner a name. I've used the same name as the scan profile.
6. Here is the code we will use. You can either select Script and add it directly to the scanner or save it to a file and point to it, which is what I have done.

7. Click OK

8. Click OK to close the Scan Profile window.

Now that we have our PowerShell scanner created, we can run it against the computers in PDQ Inventory and create a dynamic collection.

1. Right-click on All Computers and click Scan Collection > "New PowerShell Scanner Name"

2. Double-click on a computer to open up the computer details window

3. Click on PowerShell in the navigation pane options

4. Click the drop-down menu button and select the PowerShell scanner

5. The results of the scan will be displayed. If you scroll to the right, you will see the AccessToString, which will display the ACL information that we'll use to build our dynamic collection.

6. Now that we have this information, close the computer details window and click New Dynamic Collection

7. Name the collection (I'm continuing to use the name SeriousSAM)

8. Add the following filter All > PowerShell (SeriousSam) > AccessToString > Contains > BUILTIN\Users Allow ReadAndExecute

9. Note that there are two spaces between "Allow" and "ReadAndExecute" since that is how the data is returned with the PowerShell scanner. If you don't add two spaces, the filter will not work and won't return any computers.

10. Click OK

11. The new collection should now start to populate with the vulnerable computers

Now that we have identified the vulnerable machines, we can build a package in PDQ Deploy that will enable inheritance, fix the permissions issue, and delete the shadow copies.

1. In PDQ Deploy, click New Package

2. Give the package a name, then click New Step > Command

3. Enter the command provided by Microsoft

4. Click New Step > Command to add a second Command step. This step will be used to delete the shadow copies.

5. Add the following command

6. Add success code 1 to the Success Codes field in case there are no shadow copies to delete

7. Click New Step > Scan

8. Select the scan profile you created for this vulnerability

9. When you are done, click Save and close the package window

With our package created, we'll now deploy it to the SeriousSAM dynamic collection.

1. Right-click on the newly created package and select Deploy Once

2. Click Choose Targets > PDQ Inventory > Collection

3. Verify that everything looks okay and click Deploy Now

4. The computers from the collection will be added automatically to the deploy window

5. Click on the dynamic collection you created earlier and click OK

Once the deployment finishes, you should see the computers being removed from the SeriousSAM dynamic collection.

Final Thoughts on the Big Fix

Again, I feel it's worth mentioning that deleting the shadow copies will impact your restore point options, so do not take this fix lightly. If you do not delete the shadow copies, however, you will still be vulnerable to exploitation. The price we pay for security is high indeed.