Summer of SAM - incorrect permissions on Windows 10/11 hives

Published: 2021-07-20
Last Updated: 2021-07-20 11:35:28 UTC
by Bojan Zdrnja (Version: 1)
10 comment(s)

If you opened Twitter today you were probably flooded with news about the latest security issue with Windows. For those that have ISC as their home page (yay!) the issue is the following: apparently starting with Windows 10 1809 (hey, that’s a version from 2018) Microsoft messed up permissions on the SAM and SYSTEM hives which became readable for any user on the system.

This can be easily checked on your system with the icacls utility, as shown above for my test Windows:

As you can see here, the BUILTIN\Users group has (RX) permission which stands for read and execute access; (I) says it’s inherited.
What does this mean? Well, since the SAM and SYSTEM hives are really important, by reading them we can retrieve hashes of all local accounts on the system. And by having the hash of a local administrator we have Local Privilege Escalation being served to us on a silver (pun intended) plate.

The only issue here is how do we read those files: when Windows are running, the access to the files is locked and even though we have read permission, we won’t be able to read them.

As two great researchers found (@jonasLyk and @gentilkiwi), we can actually abuse Volume Shadow Copy to read the files. VSS will allow us to bypass the file being locked, and since we have legitimate read access, there’s nothing preventing us from reading the file.

VSS is a feature that is enabled automatically on Windows and that allows us to restore previous copies in case something got messed up during installation of a new application or patch, for example. If your system disk is greater than 128 GB, it will be enabled automatically!

Now, as a standard user (without local administrator privileges), one cannot check what VSS copies exist, so let’s see what can be done.
First, if you do have local administrator privileges, you can check VSS status either through the GUI (System Properties -> System Protection), or by executing the vssadmin command (through an elevated command prompt) – both examples shown below:

As shown above, I have one VSS with the path of \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1. And due to incorrect permissions set on the SYSTEM and SAM hives, I can now simply try to copy these files from the VSS. While the built-in copy command will not work, there are other ways to do this - @gentilkiwi used Mimikatz (of course ?), and below is a simple C program compiled that literally takes one argument and copies the file to destination (thanks to my colleague @filip_dragovic for help):

Notice that the builtin copy command failed.

What if you don’t know which VSS copy you have? Don’t worry – Windows actually increments the number at the end, so just brute force them!
With the SYSTEM and SAM hives in your possession you can dump password hashes of other local users, possible machine hashes and all sorts of other things. Summer of SAM indeed!


To be honest – I’m not sure what’s the best way to mitigate this currently, apart from disabling/removing VSS copies. Keep in mind that the permission on the hives will still be wrong, but at least a non-privileged user will not be able to easily fetch these files due to them being locked by Windows as the system is running.

We’ll be keeping an eye on this, of course, if you have any additional information let us know!


Keywords: sam permission hive
10 comment(s)


Can you share the copy script Filip made?
[quote=comment#44078]Can you share the copy script Filip made?[/quote]

Sure - it's here:
Just compile it and off you go.
Does this effect any server versions for Microsoft or only Win10/11?
[quote=comment#44082]Does this effect any server versions for Microsoft or only Win10/11?[/quote]

Luckily servers are not affected, only Win10/11.
My Win10 21H1 (OS build 19043.1110) does not seem have this issue, but is not on a Domain (if that makes a difference).
Our testing shows you can mitigate it by running "icalcs %windir%\system32\config\*.* /inheritance:e" and then delete your old VSS copies with "vssadmin delete shadows /all /quiet". New VSS copies moving forward will not have the permission issue.
How can we check on a mass scale if our systems are vulnerable? Also what would be the registry settings to modify via Group Policy to make the changes, again on a mass scale?
This is now CVE-2021-36934 and Microsoft has suggested a workaround:
[quote=comment#44080][quote=comment#44078]Can you share the copy script Filip made?[/quote]

Sure - it's here:
Just compile it and off you go.[/quote]

It has been removed by pastebin.

Would you please post the code here in the chat?


Diary Archives