HiveNightmare; from Domain User to domain wide ransomware.

7 min readJul 30, 2021

TL;DR all this is on Google. I just put various ideas together to show how an attacker could get from Domain User to deploying ransomware domain wide by using HiveNightmare, aka SeriousSAM.

Background

In previous articles we went over Mimikatz style attacks, which allow an attacker to dump credentials given local admin access to a domain workstation. HiveNightmare, aka SeriousSAM, is fundamentally different as it does not require local admin credentials. For some reason Microsoft allows Builtin\Users to read the registry’s location, and has been since Windows 10 1809.

Researchers recently realized this means that users can dump the Security Account Manager (SAM) database and wrote code to do exactly that.

Prerequisites for this attack:

Domain User access
Domain workstation access
Windows domain default settings
HiveNightmare, or custom code that will evade Windows Defender

By default Domain Users are members of the Builtin\Users group on domain workstations.

This means that Domain Users can simply run the executable HiveNightmare (available from https://github.com/GossiTheDog/HiveNightmare/raw/master/Release/HiveNightmare.exe).

For simplicities sake I am using the C:\Temp folder for HiveNightmare. I already made an exception for this folder in Windows Defender during previous labs. To its credit Defender will flag Rubeus, Mimikatz, parts of BloodHound, and other tools used for security testing. It will also flag HiveNightmare.

HiveNightmare creates three files in the current directory. Simply move these files offline to a Kali system to view them. Secretsdump.py is included in the Impacket framework and works well on SAM dumps.

python3 /home/kali/Downloads/impacket-master/examples/secretsdump.py -system SYSTEM-2021-06-02 -security SECURITY-2021-06-02 -sam SAM-2021-06-02 LOCAL

Mscash aka mscache:

Note the ‘cached domain logon information’. I had to research that a bit as most courses only talk about LM, NTLM, NetNTLM, and NetNTLMv2. Most sources out there state that you need SYSTEM access to grab a mscache hash, which was true up until HiveNightmare became known. Again, any Domain User can get this by default.

The good news is that mscache is actually a pretty robust hash. It takes much longer to crack than NTLM and an attacker will need a good wordlist and some luck to have success. The other piece of good news is that pass the hash (PTH) does not work with mscache.

The bad news is that if your privileged users are not using 2FA and they pick passwords that are likely to be in a wordlist given well known permutations like tacking 12 on to the end in December then an attacker might very well have success with this attack.

I used the same wordlist I used in the lab on brute forcing SID 500. SID 500 does not lock out, no matter what your Group Policy lockout is set to. Hence that attack is crude, but it can work given the same conditions as this attack. Hashcat ran a wordlist with 14,344,392 entries and cracked the mscache in about 35 minutes on my VM. Obviously given some graphics cards in a dedicated setup it would be much quicker.

The hashcat syntax for mscache:

hashcat -m2100 '$DCC2$10240#Administrator#9e8ceeb2ba5c625d24ff2b1e3b90f5bc' /home/kali/Downloads/rockyou.txt --force --potfile-disable

Post exploitation:

I was on Kali running hashcat, so I ended up diving head first down a rabbit hole of using these credentials from Kali against the domain. PSExec does not work in an up to date, fully patched Windows domain as Windows Defender will immediately block it. One can smbclient into the domain controller (DC) using the creds with the intention of uploading a msfvenom payload and then wmiexec into the DC and run the payload to gain a Meterpreter shell … but Windows Defender will immediately delete the msfvenom payload.

One can dump all the credentials from the DC using secretsdump.py. This is also called DCSync or DCShadow on Google, as it essentially uses the stolen privileges to imitate another DC and tell the real DC that it needs to sync AD.

python3 /home/kali/Downloads/impacket-master/examples/secretsdump.py -just-dc Administrator:ParamountDefenses\!@192.168.0.110

Those who have done this before know that at this point an attacker has everything they need to generate an infamous Golden Ticket.

However that’s all a sidenote here. The attacker already has a Domain Admin’s plaintext password at this point. They could use Evil-winrm to remote in to a domain workstation via the CLI or rdesktop if they want a nice GUI. We covered using Evil-winrm and rdesktop from Kali here.

The end result of all this, we have seen this before:

An attacker who has an initial foothold and manages to grab elevated privileges can simply create or modify a GPO. This may not sound like a big deal at first, but remember that GPOs can be used to push an executable or script to every single system on the domain. In this day and age that means ransomware. In fact, this is exactly what the Colonial Pipeline attackers did. Quoting from https://www.areteir.com/darkside-ransomware-caviar-taste-on-your-big-game-budget/

“We observed Darkside payload (e.g., azure_agent.exe.exe) staged on the domain controller in a network-shareable folder (e.g., C:\Windows\IME\azure), followed by the establishment of a scheduled task (e.g., \Windows\SYSVOL\domain\Policies\{L0NGMGU1D}\User\Preferences\ScheduledTasks) set with Group Policy and instructing hosts to obtain and execute the payload. This resulted in a fully automated enterprise-wide deployment less than 24 hours after data was exfiltrated.”

For simplicities sake, I simply did a RunAs from the compromised domain workstation and used the credentials gained from HiveNightmare and hashcat to run the Group Policy Management Console (GPMC). Obviously I am not going to push ransomware, even in the lab, so I just used a PowerShell script that creates a text file on everybody’s desktop domain wide that warns that it could have been ransomware.

New-Item -Path C:\Users\Public\Desktop -ItemType File -Name test.txt
Add-Content -Path C:\Users\Public\Desktop\test.txt -Value "$(Get-Date) - This could have been ransomware!"

An experienced attacker would have the ransomware payload all ready to go and know exactly how to deploy it once they gained privileges. They would also probably use a scheduled task. The only part of this that would take time for them is cracking the mscache in hashcat. They might make it from Domain User to domain wide ransomware deployment within an hour.

Mitigations:

HiveNightmare, aka SeriousSAM, is labeled CVE-2021–36934 with a CVSS of 7.8. Microsoft has not released a patch yet. They have published guidance which will mitigate by fixing the underlying issue, that is take read access away from Builtin\Users. Microsoft’s guidance is here: CVE-2021–36934 — Security Update Guide — Microsoft — Windows Elevation of Privilege Vulnerability

Of course, if your organization is already following good security practices then the impact of HiveNightmare is limited. In this lab our attacker only met with success because a Domain Admin had used the compromised workstation and the Domain Admin had a weak password. 2FA, limiting Domain Admins to using Privileged Access Workstations (PAWs), strong passwords, LAPS, all these should be practice already. For the truly paranoid there is an administration tactic that will keep all privileged domain user’s credentials off the workstations by utilizing LAPS.

Additionally, as long as you test if first to ensure you won’t break anything, one can simply push a PowerShell script via GPO to take read access away from Builtin\Users. It is also necessary to delete the old shadow copies after doing so, otherwise an attacker could still read those. I simply put the below *.ps1 in a Startup Script GPO for workstations.

#Microsoft recommend method to remove Builtin\User read access
icacls $env:windir\system32\config\*.* /inheritance:e
#Remove old shadow copies since users would have read access to those
vssadmin delete shadows /for=c: /Quiet

Windows Server is not affected by this oversight by Microsoft, so there is no need to push the script to their OU. Of course Domain Users should not be allowed interactive login privileges to DCs anyway.