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!

Mitigation

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!

--
Bojan
@bojanz
INFIGO IS