Exploiting and Mitigating SeriousSAM / HiveNightmare

The Microsoft Patch Tuesday update on August 10, 2021 “addressed” SeriousSAM a.k.a. HiveNightmare (CVE-2021-36934). So it’s all fixed right? Not quite!

It turns out that the update is only a partial fix, as acknowledged by Microsoft’s advisory. Because of this, it is still possible to exploit the SeriousSAM vulnerability on patched systems under certain conditions.

In this blog post, I will first show how the SeriousSAM vulnerability can be exploited in its original form. Next, I will demonstrate how Microsoft’s defenses can be bypassed to exploit SeriousSAM even on systems that are fully-patched by Microsoft’s Patch Tuesday update. Finally, I will discuss mitigation measures. This information should hopefully be useful to both pentesters and defenders.

As a side note, throughout this blog post I will just refer to the vulnerability “SeriousSAM” for the sake of brevity, even though it is also known as “HiveNightmare” elsewhere.

What is SeriousSAM?

So let’s start with what SeriousSAM is. On July 19, 2021, security researcher Jonas Lyk discovered that recent versions of Windows 10 and 11 allowed regular users to read the Security Accounts Manager (SAM) file. This is bad since only administrators are supposed to be able to access the SAM file.

For those who may not be familiar, the SAM file on a Windows system stores the password hashes of all local users of that system. It is similar to /etc/master.passwd on BSD systems or /etc/shadow on Linux – but with one key difference: On UNIX, gaining access to the password hashes in the shadow file does not grant the attacker immediate access to the user accounts that those password hashes belong to. On Windows, they might!

The hashes in the SAM file are Windows NTLM hashes. They are different from UNIX password hashes in two ways:

1. They are not salted, meaning that two users who happen to use the same password will also have the same password hash
2. It is possible to use Pass-the-Hash attacks to gain access to the user with just the hash alone (no password cracking required)

The password hashes in the SAM file include the hash for the local administrator. Therefore, a threat actor with local user access who obtains the SAM file would be able to elevate their privilege to that of a local administrator on the compromised machine. From there, they can use it to perform further nefarious activities, such as:

• Compromising other machines in the network (lateral movement) either by using Pass-the-Hash or cracking the local administrator’s password (if shared/weak passwords are being used)
• Potentially compromising the entire Active Directory domain if they are able to dump the Domain Admin’s credentials from the LSASS process as the local administrator
• Attacking all compromised systems with ransomware

So even though SeriousSAM is classified as a “local vulnerability,” when it is abused along with other weak security practices, it can be used to carry out devastating attacks against a network.

I have good news and bad news…

The good news is, Windows places a persistent file-lock on the SAM file, so the threat actor would not be able to actually read it under normal circumstances even if they have read permissions on the file.

The bad news is, if the Windows system is set up to create volume shadows (similar to filesystem snapshots on BSD/Linux), a readable copy of the SAM file may still be present in the volume shadow copies. If the copy of the SAM file in the shadow copy is also readable, it can be read by the threat actor since it is not file-locked.

Exploiting SeriousSAM in its Original Form

Now I will show how SeriousSAM can be exploited when it was first discovered in its original form, that is before Patch Tuesday (August 10, 2021). The following commands and output are from an isolated Windows system that I have intentionally disconnected from the Internet to prevent it from receiving Windows updates, so it is still vulnerable to SeriousSAM.

The SAM file is located in the %windir%\system32\config directory, which is usually c:\windows\system32\config.

You can use the icacls command which displays or modifies discretionary access control lists (DACLs) on files.

Using a regular (non-administrator) user, check if you are able to read the SAM file:

icacls c:\windows\system32\config\sam

For example, here’s what the output looks like if C:\Windows\System32\config\sam is readable by regular users:

The BUILTIN\Users:(I)(RX) line in the output indicates that regular users can read the SAM file, thus this system is vulnerable to SeriousSAM. Conversely, if you see “Access denied”, that means the SAM file is not readable (but volume shadow copies could still be – more on this later!).

However, even if icacls.exe says the file is readable by regular users, attempting to copy the file will still fail:

C:\Users\testuser>copy C:\Windows\System32\config\sam sam.copy
C:\Windows\System32\config\sam
Access is denied.
        0 file(s) copied.

This is due to the persistent file-lock that Windows places on the SAM file.

Copying from the Shadows

As mentioned earlier, there is still a way to obtain the SAM file if the system has been set up to create volume shadows, since the volume shadow copies may contain a user-readable copy of the SAM file.

Even though the regular user (or a threat actor running in the context of the regular user) is not able to check if volume shadow copies exist, they can still guess the name of the volume shadow copies.

To see why this is the case, run the following as administrator, which shows all volume shadow copies on the system:

vssadmin list shadows

Here’s an example output:

C:\Windows\system32>vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Contents of shadow copy set ID: {f475d904-854b-4374-989c-a8751d07f214}
   Contained 1 shadow copies at creation time: 8/12/2021 6:00:31 AM
      Shadow Copy ID: {7a995a8d-8cfa-4de1-8b27-50b456869b39}
         Original Volume: (C:)\\?\Volume{9d757f23-3cac-48ff-95e6-0fd9f4380732}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
         Originating Machine: LAPTOP-RSLG7MF8
         Service Machine: LAPTOP-RSLG7MF8
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessibleWriters
         Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered

On this example system, there is one volume shadow copy called \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2. The names of the shadow copies are numbered sequentially, so the regular user can simply guess the names like \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2, \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3, and so forth.

For example, a regular user could try to run this icacls.exe command:

icacls \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\windows\system32\config\sam

Here’s what the output may look like:

Note how they are able to obtain the same output as if they ran it directly on the original SAM file. The icacls output also shows that the SAM file in the shadow copy is readable.

Even so, the SAM file still cannot be copied using the copy command:

C:\Users\testuser>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\windows\system32\config\sam sam.copy
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\windows\system32\config\sam
Access is denied.
        0 file(s) copied.

However, the SAM file can be copied via this PowerShell command that reads the file into standard input, and then redirects it to standard output and subsequently saves it to a new file:

powershell.exe -c "[Console]::OpenStandardInput().CopyTo([Console]::OpenStandardOutput())" < "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\System32\Config\SAM" > sam.copy

Here’s an example showing a regular user called testuser copying the SAM file from the volume shadow copy with PowerShell:

Note that even though the name of the vulnerability is “SeriousSAM”, the threat actor actually needs more than just the SAM file in order to decode it. The other file is C:\Windows\System32\config\SYSTEM, which typically has the same permissions as the SAM file. Copying this SYSTEM file is equally trivial:

The regular user (or a pentester or threat actor operating in the context of a regular user) now has access to the SAM and SYSTEM files. Since these files grant them the password hashes, including that of the local administrator, they can then use the hash to impersonate the local admin.

Exploiting SeriousSAM by Bypassing Defenses

Now that we’ve covered how SeriousSAM in its original form can be exploited, let’s talk about what Microsoft has done about SeriousSAM and how the defenses can still be bypassed..

On Patch Tuesday (August 10, 2021), Microsoft has “addressed” this vulnerability by changing the permission of the C:\Windows\System32\config\SAM file. For the demos in this section, I will switch to a different Windows system that has been patched.

As a result of the patch, the original icacls command no longer works:

What about volume shadow copies? It turns out that Microsoft did not make any changes to existing volume shadow copies that were created prior to Patch Tuesday. Therefore, a user-readable SAM file in an existing shadow copy would still be readable. However, they did make a change to Defender. Defender will now trigger alerts if users attempt to use icacls.exe to check the permissions of the SAM file in a volume shadow copy (note: it is not clear to me at what point in time in the past Defender was updated to do this).

So let’s see what happens when a regular user uses icacls.exe to read the permissions of the SAM file in a shadow copy:

It “worked,” but right after the icacls.exe command completed, Defender terminated the cmd.exe process since it was running an icacls.exe process that attempted to read the SAM permissions from a volume shadow copy. The threat was identified as “Win32/Vessam.A”:

Bypassing Defenses

At first glance, these defenses seem effective, but unfortunately they fall short in three ways.

First, even though the process was terminated, it was terminated “after the fact”; there is a short lag of a few seconds between the time the threat actor ran icacls.exe and the time Defender terminates the process. In that short timeframe, the threat actor or their malware could have already recorded the permissions of the SAM file. Nevertheless, an alert would still have triggered so this may not be the attack mode of choice for experienced threat actors.

Second, even though attempting to read the permissions of the SAM file in the volume shadow copy gets terminated, using icacls.exe on the SYSTEM file still works! Defender does not attempt to terminate this icacls.exe attempt at all.

For example:

As shown, I waited a full five minutes after icacls.exe has completed but Defender did not terminate cmd.exe, unlike earlier when I used icacls.exe on the SAM file. Since the SYSTEM file usually has the same permissions as the SAM file, the threat actor can assume that the SAM file has the same permissions as SYSTEM. And they can do this without triggering any Defender threat alert notifications.

Third, and most seriously, the threat actor can still copy the SAM and SYSTEM files from the volume shadow copies without triggering any Defender alerts:

As a result, the threat actor can simply guess the names of the shadow copies and attempt to copy the SAM and SYSTEM files directly.

Mitigations

Now that we have discussed exploitation, let’s talk about what we can do to mitigate against the SeriousSAM vulnerability.

1. Confirm that your SAM file is not readable by a regular user. The most obvious thing to do is to check if the root cause of the issue has been addressed, which is by confirming that the SAM file is not readable by a regular user. This is pretty straightforward; simply use a regular user account with no administrative privileges, and execute icacls.exe C:\Windows\System32\config. If you see “Access denied”, you’re good – but don’t forget to check the volume shadow copies which we will discuss next.

2. Inspect any volume shadow copies for readable SAM and SYSTEM files. If volume shadow copies are enabled, first check if there are any volume shadow copies by running vssadmin list shadows as administrator. If there are, run icacls \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyX\windows\system32\config\system (replace HarddiskVolumeShadowCopyX with the name of the shadow copy) to check if any of the shadow copies return BUILTIN\Users:(I)(RX). If there are, these need to be deleted – see Microsoft’s documentation on vssadmin delete shadows for details.

3. Don’t forget systems that are not regularly updated, like new computers and suspended virtual machines. Microsoft may have partially addressed the underlying vulnerability, but systems such as newly purchased computers and suspended virtual machines may not have received the patch. These systems need to be investigated as well.

4. Do not use shared local administrator passwords on multiple systems. This will help prevent a threat actor from reusing the credentials they obtained from a system that was compromised using SeriousSAM to log in to other systems in the network (lateral movement).

5. Do not allow the Domain Admin accounts to log in to workstations. When domain accounts log in to systems, they leave behind credentials in the LSASS process. A threat actor who has compromised the local administrator account on a workstation may have the ability to dump the credentials within LSASS process. If a Domain Admin has recently logged in to such a workstation, the threat actor may be able to obtain the credentials of the Domain Admin and use that to compromise the entire Active Directory domain.

Wrapping Things Up

The SeriousSAM / HiveNightmare vulnerability allows regular users, or threat actors operating in the context of a regular user, to read the SAM file which contains password hashes. This includes the password hash of the local administrator, which the threat actor can then use to impersonate the local administrator to potentially compromise other machines and perhaps even the entire AD domain.

Microsoft has applied defenses by modifying the permission of the SAM file; however, volume shadow copies are untouched. Therefore, administrators should examine the existing volume shadow copies to ensure that the SAM and SYSTEM files are not readable by regular users.

I hope you’ve found this blog post helpful. I hope to perform more research on similar security topics and present my results on this blog. If you would like to be notified of any new posts, please feel free to follow me on Twitter (@lteo) or subscribe to the RSS feed of this blog.