This is the story of how all non-admin users can read the registry — and so elevate privileges and access sensitive credential information — on various flavours of Windows 10. It appears this vulnerability has existed for years, and nobody noticed. In this post I made an exploit to test it.
Press F to pay respects to MSRC (it’s not their fault)
Recently, Jonas tweeted something interesting. What Jonas didn’t realise at the time is Windows 10 also has the same behavior when System Protection aka Shadow Volumes is enabled, which should be the default in a majority of cases.
This is caused by BUILTIN\Users having read access to c:\Windows\System32\config\SAM.
It shouldn’t. That breaks a security barrier, as the SAM is a sensitive registry hive, and BUILTIN\Users include non-administrators.
That folder also has other sensitive registry hives — for example SYSTEM, SECURITY etc — which BUILTIN\Users can access.
This has since become CVE-2021–36934.
Creating an exploit
Normally you cannot access the SAM (or other registry hive files) as they’re in use. To get around this, I used CreateFile to access the device path to the VSC snapshot — used in recovery situations — in a slightly hacky way:
hFile = CreateFile(TEXT(“\\\\?\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy1\\Windows\\System32\\config\\SAM”),GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
The exploit is here:
aka SeriousSam. Exploit allowing you to read any registry hives as non-admin. An exploit for HiveNightmare, discovered…
Direct link to compiled binary: https://github.com/GossiTheDog/HiveNightmare/raw/master/Release/HiveNightmare.exe
When run, it creates a copy of SAM, SECURITY and SYSTEM files in the working folder, accessible to the logged in, non-admin user.
Here’s a video of how to use my exploit to reach remote code execution as SYSTEM on endpoints:
Microsoft have provided mitigations in their security guide: Security Update Guide — Loading — Microsoft
And an article on removing VSC: KB5005357- Delete Volume Shadow Copies (microsoft.com)
Here is a PowerShell script, which can be deployed via SCCM, to fix the ACL and remove the VSC:
HiveNightmare/Mitigation.ps1 at master · GossiTheDog/HiveNightmare (github.com)
Here is a blog on how to deploy our mitigation in Microsoft Endpoint Manager:
Mitigate HiveNightmare with MEM | The Collective
It’s been only three weeks since the PrintNightmare debacle, which introduced several zero-days into the world of…
Your EDR tools should have logic to look for SAM files being accessed, it it worth asking your EDR vendors for confirmation and detection names.
In the mean time, here are some custom detections:
Microsoft Defender for Endpoint
ThreatHunting/CVE-2021–36934-HiveNightmare-Defender.ahq at master · GossiTheDog/ThreatHunting (github.com)
M365 Defender query link
Mcafee EDR block rule
ThreatHunting/CVE-2021–36934-HiveNightmare-Mcafee at master · GossiTheDog/ThreatHunting (github.com)
ThreatHunting/CVE-2021–36934-HiveNightmare-Sentinel-Events at master · GossiTheDog/ThreatHunting (github.com)
All Windows 10 releases through the last 3 years. US-CERT pen the issue as starting in 2018. Microsoft’s MSRC advisory says all Windows 10 versions since 1809.
One thing of note, when you do certain actions it creates a system recovery point (for example, installing 7-zip did on my gaming PC) which appears to play a factor.
There’s no patches, it’s a zero day.
As with all things security, don’t panic. It’s just another vulnerability. There’s also still an outstanding an unpatched Print Spooler zero day.
… and have you finished July’s patching? Really?
My take — ask your EDR vendors for detection, chill, and keep up the fight.
Also, yes, Microsoft really need to look at resourcing on MSRC and Windows OS engineering. Microsoft can’t boast about being a $10bn security company while watching their own products burn down. I mean, they can — but they shouldn’t.