First coming to light as a local elevation of privilege vulnerability affecting pre-release versions of Windows 11 (Figure 1), subsequent investigations into the issue, namely sensitive registry hive files being accessible to all users when 'System Protection' is enabled, confirm that it also affects Windows 10.
Initially dubbed 'HiveNightmare' and 'SeriousSAM' by security researchers, CVE-2021-36934 has been assigned to this vulnerability although the CVSS score has yet to be determined.
Whilst there are no reports of this vulnerability being exploited in the wild, proof-of-concept (PoC) code has been released  and could allow a threat actor with local access to take advantage of the overly permissive access control list (ACL) rules to acquire sensitive data from the Windows registry.
In response to this vulnerability being publicized, Microsoft have launched an investigation  in addition to providing workarounds. It is not yet known if a patch will be released in due course.
Given the wide adoption of Windows 10 and the sensitivity of data stored within the registry, especially the Security Accounts Manager (SAM) registry hive which contains hashed credentials, the severity of this vulnerability is likely to be high.
Whilst requiring the threat actor to have local access to a target machine, this elevation of privilege vulnerability arises from non-administrator accounts, as defined by the
BUILTIN\Users group, having
RX (read and execute) access to the following sensitive registry hive files:
In normal circumstances, and regardless of access privilege, these files would still be inaccessible due to them being locked 'open'. That being said, the proof-of-concept (PoC) code and attack vector for this vulnerability takes advantage of the Windows 'System Protection' feature that allows any user to access a volume shadow copy (VSS) of the system volume and, in turn, gain access to unlocked versions of these sensitive files.
Analysis of currently available PoC code indicates that these registry hives can be accessed from the VSS via the following path (where
<FILE> is one of the three registry hive files):
Using a script, or specially crafted executable, to read and save this path to file would allow the threat actor to leverage the sensitive information contained within for multiple scenarios, such as:
- Extracting and brute-force attacking hashed credentials from the System Account Manager (SAM).
- Extracting stored credentials, such as from browsers and mail applications.
- Extracting encryption keys, such as those created by the Data Protection API (DPAPI).
As a consequence of these scenarios, a threat actor could easily elevate their privileges on the local machine and/or gain access to other devices within the victim network.
According to Microsoft, the following versions of Microsoft Windows are officially recognized as affected:
- Windows 10 version 1809 and newer (including Windows 11 Insider)
Based on our own limited testing, and anecdotal reports via Twitter, in practice the affected versions may vary across build numbers and update status, for example, the author's test installation running Windows 10 20H2 build 19042.1110 did not appear to be vulnerable.
Unexpected access attempts to the volume shadow copy data may be indicative of exploitation, especially in the following instances:
- Regardless of the Microsoft Windows 10 version installed, organizations should verify the file access permissions across their deployments via the output of the following command:
<FILE>is each of
- Vulnerable hosts can be determined by
BUILTIN\Users:(I)(RX)appearing in the output.
- As a workaround, organizations should consider following Microsoft's recommendation  to restrict access to
%WINDIR%\System32\configusing the following command:
icacls %WINDIR%\System32\config\ . /inheritance:e
- Having removed any erroneous permissions, all existing shadow copies should be deleted using the command:
vssadmin delete shadows /for=c:
- Should they be required, new volume shadow copies can be created after the previous two recommendations to reflect the updated file permissions.
- Consideration should also be given to monitoring sensitive file locations for unauthorized or unexpected access attempts, potentially acting as an early warning of nefarious activity.