Blumira Resources & Blog

SAM Database in Windows 10 (HiveNightmare) | Blumira

Written by Matthew Warner | Jul 20, 2021 5:04:11 PM

What Happened?

On July 13, Microsoft released CVE-2021-33757, which enabled AES encryption by default to the remote protocol connection for MS-SAMR to mitigate the downgrade to RC4, which exposed data through insecure encryption. Microsoft subsequently released a patch for the vulnerability, KB5004605, which made changes related to the MS-SAMR protocol. Microsoft stated in documentation for the patch: 

After installing the July 13, 2021 Windows updates or later Windows updates, Advanced Encryption Standard (AES) encryption will be the preferred method on Windows clients when using the legacy MS-SAMR protocol for password operations if AES encryption is supported by the SAM server.

On July 19, a vulnerability was discovered in Windows 10 that allows non-admins to access the Security Account Manager (SAM) database, which stores users’ passwords, according to Kevin Beaumont (Twitter user @GossiTheDog). Kevin Beaumont dubbed the vulnerability HiveNightmare aka SeriousSam.

This was confirmed for the latest version of Windows 10, according to Benjamin Delpy, creator of MimiKatz (Twitter user @gentilkiwi).

The SYSTEM hive was also exposed during Microsoft’s ACL change to Windows, which means that all credentials are exposed in their hashed form. 

How Bad is This?

The SYSTEM and SAM credential database files have been updated to include the Read ACL set for all Users for some versions of Windows. This means that any authenticated user has the capability to extract these cached credentials on the host and use them for offline cracking, or pass-the-hash depending on the environment configuration. This has only been identified on updated Windows 10 endpoints at this point, however, it is possible Windows Servers have been impacted. 

The following builds have been identified as impacted so far:

  • 1809 ISO-June21 – 20H2
  • 1909 ISO-June21 – 20H2
  • 20H2 ISO-orig – 21H1
  • 21H1 ISO-June21 – 11 Insider (Windows 11)

You can identify your build by looking at winver in Run (Win + R)

As of 7/20/21, this attack pattern has been proven and is a potential privilege escalation path for attackers. If a Computer or Domain Admin has recently logged into a host that was impacted by this change, their hashed credentials would be cached on the host in these files. This could potentially give an attacker full access to your environment without requiring escalation to Administrator to access these credentials.

What Should I Do?

We recommend that you wait for Microsoft to release remediation steps. In the meantime, you can do a few things:

  • Monitor for SAM access on the host itself to determine if an attacker is attempting to dump and escalate. 
  • Prepare to patch when Microsoft has released their fix or mitigation for this issue. This is the safest way to respond to this issue as Microsoft will need to unroll the ACL changes that they added.
  • If the machine is critical to your environment from a security perspective, reset ACLs back to default across the impacted folder. This action does come with some amount of risk, as you will be changing ACLs set by the Windows update. However, so far in our testing, it has not negatively impacted the host but that does not mean it won’t impact others’ machines depending on configuration.
    • From an Administrator Powershell command line
      Get-ChildItem -File -Force $env:WINDIR\system32\config | ForEach-Object { icacls $_.FullName /reset 

How To Detect

Blumira recommends monitoring for actions against the HKLM System, Security, and SAM databases on all systems. Due to this incorrect ACL change by Microsoft, it is now an even higher priority to monitor these actions. Below is an example of utilizing Sysmon to monitor for reg.exe actions against the System, Security, or SAM files. 

This may require some changes based on your SIEM, e.g., escaping slashes and regex match formatting. Blumira customers who utilize Sysmon will already have this rule deployed to their environments.

windows_log_source="Microsoft-Windows-Sysmon" AND process_name LIKE "%reg.exe%" AND REGEXP_CONTAINS(command,  "HKLM\\\\system|HKLM\\\\security|HKLM\\\\sam")

Blumira also recommends monitoring WMIC, Shadow-Copy, and any actions that would involve the instantiation of Mimikatz, which can all leverage this exposure.

Update 7/21/21 (courtesy of Reddit user u/eider96)

  • This has nothing to do with KB5004605
  • The RX access for BU\Users does not allow for direct access to these files as they are protected, they can only be accessed if previously VSS snapshot has been made with these files (which is default action given either File History or System Restore are enabled). Unprivileged users can leverage such snapshots and use the improper permissions to take out files from it. Administrator permissions are not required to read snapshot, they are directly accessible via \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy{$N} where {$N} is snapshot number. Administrators can list all snapshots using vssadmin list shadows.
  • The PS snippet provided is not meant to secure system alone. Also consider existing snapshots and either remove them or accept the risk and let them be overwritten as time goes on.
  • Because the files can be copied offline from VSS snapshot and then inspected manually or hive loaded on separate system, monitoring for actions against these hives is not guaranteed to provide any meaningful results in relation to this specific vulnerability – there is no reason to modify or load the hive online in order to extract cached credentials from recovered files.

Update 7/21/21 (courtesy of Reddit user u/Oscar_Geare):

Microsoft has released a CVE for this vulnerability. In the CVE they identify that it affects all versions 1809 and newer. Additionally there is a workaround available:

  • Restrict access to the contents of %windir%\system32\config

    • Open Command Prompt or Windows PowerShell as an administrator.

    • Run this command: icacls %windir%\system32\config\*.* /inheritance:e

  • Delete Volume Shadow Copy Service (VSS) shadow copies

    • Delete any System Restore points and Shadow volumes that existed prior to restricting access to %windir%\system32\config.

    • Create a new System Restore point (if desired).

Our comments (7/21/21):

Only delete shadow copies with some level of knowledge you do not need them. Validation of backups is ideal and you can use vssadmin list shadows to see most of your shadow copies.

Since Microsoft’s patching credibility has taken a big hit in the past few weeks, it’s not a bad idea to test the patch once implemented as well.

Update – Detections and Future Proofing (07/21/21 at 12:45 PM ET)

Since the ACL changes that occurred within the host poisoned the VSS, you can take some steps to secure a system. This includes deleting VSS snapshots once ACLs have been resolved — or at the least, protecting those VSS snapshots until they are patched and rolled over with new snapshots.

Blumira is currently testing and implementing three separate detections for this, one of which is more forward-looking to ensure visibility for hive files living inside of VSS. These detections either require Sysmon or for you to have defined advanced auditing on hosts using GPOs such as Blumira’s Logmira.

  • Identification of HiveNightmare runs based on hardcoded string patterns using Sysmon. This will be easy to avoid for many attackers but will identify the reuse of existing attacks.
    type='windows' AND windows_log_source='Microsoft-Windows-Sysmon' AND windows_event_id in (1,5,11) AND ((process_name LIKE '%HiveNightmare%') or (regexp_contains(target, '(?i)S.*haxx$')))

  • Identification of Powershell referring to sensitive Hive files within VSS using Script Block logging. This assumes your script block logs into the info column and uses the case insensitive (?i) flag. *Requires script block logging to be enabled for Powershell.*
    type='windows' AND windows_event_id=4104 AND REGEXP_CONTAINS(info, r'(?i)\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy\d{1,2}\\Windows\\System32\\config\\(system|security|sam)')

  • Identification of Read of sensitive Hive files by everyone on the host using SACLs that flow into VSS. This allows for a significant increase in visibility for any hive access in our testing thus far. This won’t change your existing VSS until another restoration point is recorded. *Requires object access GPO to be enabled (RE Logmira) and for the following Powershell to be run to enable this detection.*
    type='windows' AND windows_event_id=4663 AND REGEXP_CONTAINS(object_name, r'(?i)Device\\HarddiskVolumeShadowCopy\d\\Windows\\System32\\config\\(system|security|sam)')
    You will also need to run the following Powershell to enable the auditing SACL on the hive files which will then be adopted by VSS. This script adds the ReadData Success audit rule for Everyone, allowing broad future visibility into any users, permissioned or not, accessing the hive files.
    $files = @("C:\Windows\System32\config\system","C:\Windows\System32\config\sam","C:\Windows\System32\config\security")

  • Foreach ($file in $files){ $acl = Get-ACL $file; $auditRule = New-Object System.Security.AccessControl.FileSystemAuditRule("Everyone", "ReadData", "Success"); $ACL.SetAuditRule($auditRule); $acl | Set-Acl $file; Write-Host "Getting ACL for $file, Audit column should state Everyone Success ReadData"; Get-ACL $file -Audit | Format-List }

Additional Resources

Try Blumira For Free

Blumira can detect activity related to the HKLM System, Security, and SAM databases, as well as many other security incidents. 

Blumira’s free trial is easy to deploy; IT and security teams can start seeing immediate security value for their organizations.

Sign up for a free trial to start detecting and mitigating exposure related to Windows vulnerabilities:
View full post