cfreg.ProviderName = L"IHATEMICROSOFT"; That’s line 1469 of FunnyApp.cpp, the working proof-of-concept for CVE-2026-33825. To exploit BlueHammer, Nightmare-Eclipse’s code registers a fake Cloud Files sync provider — the same Windows feature that backs OneDrive — under that name. The name is editorial. The mechanism it exposes is architectural. This post is a line-by-line walk of the code, because most of the public analysis of BlueHammer describes what the vulnerability is without explaining how the two weapons inside the PoC relate to each other, and the relationship is the point. I’ve covered RedSun on this blog already. BlueHammer is described as a reimplementation in a different language, and technically that’s not wrong — both bugs live in the same component and the same fundamental problem. But “reimplementation” undersells how different the attack surface is. RedSun goes through Cloud Files + mount point reparse at the filesystem layer. BlueHammer goes through Defender’s definition update RPC endpoint and the NT object manager namespace. They share a class. They don’t share a technique. The patch that closes one does not obviously close the other. The Two Weapons FunnyApp.cpp contains two independent exploitation paths. I’m going to call them by the functions that carry them: the oplock path and FreezeVSS . They are not alternatives. They run sequentially in the exploit, and understanding why requires understanding what each one freezes and when. The oplock path exploits a TOCTOU in Defender’s remediation step. The FreezeVSS path uses the Cloud Files API to hold Defender suspended while the oplock path completes its redirect. You need both. The oplock gives you the window; the freeze makes the window wide enough. Neither path requires admin. Neither path requires any Windows privilege beyond what a standard user session provides. The whole exploit runs from a temporary directory the attacker creates under %TEMP% . When wmain checks IsRunningAsLocalSystem() at startup and finds the answer is no, the fun begins. Weapon One: The Oplock Race The first thing the code does is create a UUID-named working directory under %TEMP% , then write a file named foo.exe into it: char eicar [] = "*H+H$!ELIF-TSET-SURIVITNA-DRADNATS-RACIE$}7)CC7)^P(45XZP \\ 4[PA@ % P!O5X" ; rev (eicar); The EICAR test string is stored reversed in the binary and reversed at runtime — a minimal obfuscation against static analysis of the binary itself. The write lands in foo.exe , and then the code opens a handle to trigger Defender’s real-time protection: trigger = CreateFile (eicarfilepath, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL , OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL ); This is the gun. Not the bullet. The EICAR file is bait — its purpose is to make Defender want to remediate something. Before it does, the exploit has already requested a batch oplock on a different file entirely: hlock = CreateFile (rstmgr, GENERIC_READ | SYNCHRONIZE, NULL , NULL , OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL ); DeviceIoControl (hlock, FSCTL_REQUEST_BATCH_OPLOCK, NULL , NULL , NULL , NULL , NULL , & ovd ); rstmgr is %windir%\System32\RstrtMgr.dll — the Restart Manager DLL. Defender, when it identifies a threat and prepares to remediate it, calls the Restart Manager to check whether any processes have the malicious file locked open. That check requires opening RstrtMgr.dll . The batch oplock is sitting on that path. The moment Defender tries to open it, the kernel signals the oplock to the attacker and suspends Defender’s open call until the attacker releases. That suspension is the TOCTOU window. The attacker requested it before the EICAR file was visible to Defender. Defender finds the threat, begins remediation, tries to open the Restart Manager DLL, and blocks. The attacker gets the signal: GetOverlappedResult (hlock, & ovd , & nwf , TRUE ); printf ( "Oplock triggered. \n " ); Now it has an indefinite window to manipulate the filesystem while Defender is frozen mid-operation. What it does with that window is the second weapon. Weapon Two: The Object Manager Redirect I want to be precise about what kind of symlink BlueHammer uses, because this is where most descriptions of the exploit get imprecise. The exploit does not create an NTFS symbolic link. It creates an NT object manager symbolic link, using NtCreateSymbolicLinkObject — a kernel API that operates on the NT object namespace, which is a completely separate namespace from the filesystem. The NT object namespace sits below the filesystem in the Windows I/O stack. When a user-mode process opens a path like C:\foo\bar , the kernel expands that through the object namespace — \?? is a per-session alias for \DosDevices\ , and named objects like directories, events, and symlinks can all live in the namespace tree at \Sessions\<n>\BaseNamedObjects\ . A symlink in the object namespace redirects path resolution before the filesystem driver ever sees the path. The exp...