July 20, 2021

SAM Database Vulnerability: What We Know So Far

## What Happened?

On July 13, [Microsoft released](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-33757) 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](https://support.microsoft.com/en-us/topic/kb5004605-update-adds-aes-encryption-protections-to-the-ms-samr-protocol-for-cve-2021-33757-e4daa133-54aa-4a5d-a921-04bb50868fc2):

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 u/GossiTheDog).

This was confirmed for the latest version of Windows 10, according to Benjamin Delpy, creator of MimiKatz (Twitter user u/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.

It is unclear whether the patch KB5004605 is related to the new vulnerability, however it did impact MS-SAMR at that point in time.

## 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:WINDIRsystem32config | 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 for these actions. Below is an example for 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. (FYI, 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.

We’ve also published this on Blumira’s blog, which we will continue to update as we get more information: [https://www.blumira.com/sam-database-vulnerability/](https://www.blumira.com/sam-database-vulnerability/)

Leave a Reply

Your email address will not be published. Required fields are marked *

Note: By filling this form and submitting your commen, you acknowledge, agree and comply with our terms of service. In addition you acknowledge that you are willingly sharing your email address with AiOWikis and you might receive notification emails from AiOWikis for comment notifications. AiOWiksi guarantees that your email address WILL NOT be used for advertisement or email marketting purposes.

This site uses Akismet to reduce spam. Learn how your comment data is processed.