After the PrinterNightMare now follows the HiveNightmare. The access rights (ACLs) for the SAM database are set incorrectly in certain scenarios since Windows 10 version 1809. This allows any user to read the NTLM-hashed passwords, abuse them to extend privileges. The user can also read the Security Account Manager (SAM), SYSTEM, and SECURITY files in the Windows Registry.
Windows stores certain registry information in structure files called hives in the Windows folder C:\Windows\system32\config. Stored in this folder are a total of five files, SYSTEM, SECURITY, SAM, DEFAULT and SOFTWARE. The Security Account Manager (SAM) is a database where Windows stores user accounts and security descriptors for users on the local computer. For security reasons, only the system and administrators should have access to the relevant structure files.
With volume shadow copies enabled (standard in Windows), the case can arise that any user can gain read access to the SAM database and read its contents via the VSS shadow copies. The detour via the shadow files is necessary because the originals are opened by the system during operation and are thus locked. When a feature update is performed this occurs on Windows 10 from version 1809 up to the current 21H1 and on Windows 11. A quick test by the author on a test machine running Windows 10 21H1 with icacls running under a standard account confirmed this.
The Windows tool icacls witnesses the access rights of the executing user.
The RX flag shows that the normal user has read and execute access to the SAM file. If shadow copies are present, any user can read the contents of the SAM database with the hashed user passwords.
US-CERT has since issued a security alert summarizing the details. According to this the BUILTIN\Users group is assigned the read-execute (RX) permission to the following files as of Windows 10 1809, :
If volume shadow copies of the system drive are available, a non-privileged local user can use access to these files to do the following. For example:
Extracting and exploiting account password hashes with tools such as mimikatz for pass-the-hash attacks.
Find out the original Windows installation password
In order to decrypt all computer keys you must obtain DPAPI computer keys
Take over a local administrator’s computer account for a silver-ticket attack
Microsoft has now also published an initial description of the vulnerability with the identifier CVE-2021-36934. This confirms incorrect access rights in the Access Control Lists (ACLs) of several system files, including the Security Accounts Manager database (SAM).
Microsoft has not yet released any updates to fix the vulnerability. It is possible to delete or disable the shadow copies, but this would mean losing the ability to restore damaged hives. The US-CERT security alert suggests to revoke the access permissions for the Users group. This can be achieved by executing the following commands in an administrative command prompt.
icacls %windir%\system32\config\sam /remove “Users”.
icacls %windir%\system32\config\security /remove “Users”.
icacls %windir%\system32\config\system /remove “Users”.
Microsoft suggests to change the permissions via the directory:
icacls %windir%\system32\config. /inheritance:e
However, it would be better to adjust the access permissions in managed environments by means of group policy. If you want to find corresponding registry entries you must look under Computer configuration ->Policies ->Windows settings ->Security settings ->File system.
In addition, after executing the above commands, all VSS shadow copies of the system drive must be deleted – otherwise the information could still be read. However, there is a risk that the changed access rights could trigger follow-up problems.
The vulnerability naturally raises serious questions. Why was such a capital problem, which has existed since 2018, not uncovered by Microsoft during internal tests. The ACLs for the hives were set correctly prior to Windows 10 version 1809. There are indications that the security of Windows 10 suffers permanently due to the switch to Windows-as-a-Service (WaaS) and the compulsion to release feature updates every six months.