New exploits and long intrusions
Researchers publicly released a Windows Defender local‑privilege‑escalation exploit called 'BlueHammer', giving low‑privilege users a path to SYSTEM access via proof‑of‑concept code. Separately, Mandiant disclosed a long‑running VMware vSphere intrusion named BRICKSTORM that persisted in ESXi for 393 days, underscoring the need for ESXi hardening. Together these incidents show the dual threat: fast‑moving exploit code in the wild and long, stealthy persistence in infrastructure. ( )
Windows has a built-in ladder of trust, and the top rung is called SYSTEM, which is the account the operating system itself uses to read anything and change anything. A local privilege escalation bug is a flaw that lets a normal user climb that ladder without being an administrator first. (bleepingcomputer.com) Microsoft Defender is the antivirus that ships with Windows, and it updates itself with high privileges because malware would tamper with it if it did not. That update path is exactly where a new exploit called BlueHammer tries to slip in. (github.com, bleepingcomputer.com) BlueHammer was published on GitHub on April 3, 2026 by a researcher using the aliases Chaotic Eclipse and Nightmare-Eclipse after a dispute over disclosure with the Microsoft Security Response Center. BleepingComputer reported on April 6 that Microsoft had not released a patch, which makes it a zero-day by Microsoft’s own definition. (github.com, bleepingcomputer.com, microsoft.com) The bug is not a remote break-in by itself, because the attacker already needs a low-privilege account on the machine. The danger is what happens next: Will Dormann told BleepingComputer the exploit can expose the Security Account Manager database, which stores local password hashes, and that path can end in a SYSTEM shell. (bleepingcomputer.com) The trick behind BlueHammer is a race condition, which is like changing the destination label on a package between the moment the courier checks it and the moment the courier delivers it. Independent analysis says the proof-of-concept abuses Defender’s signature update process, swaps file paths at just the right moment, and redirects a privileged read toward a Volume Shadow Copy of the Security Account Manager file. (github.com, shield53.com) At the other end of the story is VMware vSphere, the software many companies use to run fleets of virtual machines on one physical server. Its core layer is the ESXi hypervisor, which sits underneath the guest operating systems the way an apartment building’s boiler room sits underneath every tenant. (cloud.google.com) Mandiant says attackers tied to BRICKSTORM have been hiding in that layer, not by breaking a new VMware bug, but by exploiting weak identity design, weak security architecture, and poor visibility in the control plane. In its September 24, 2025 write-up, Mandiant said these intrusions stayed undetected for 393 days on average. (cloud.google.com, cloud.google.com) That number is so high because many appliance-style systems do not run standard endpoint detection and response tools, which are the agents companies usually install on laptops and servers to watch for suspicious behavior. Mandiant said BRICKSTORM operators chose appliances and virtualization systems specifically because they generate little security telemetry and sit outside normal monitoring. (cloud.google.com) Mandiant’s April 2, 2026 defender guide says a compromise of the vCenter Server Appliance can hand an attacker administrative control over every managed ESXi host and every virtual machine attached to it. That turns one quiet foothold in the control plane into control over an entire virtual estate. (cloud.google.com) Put together, these two cases show the same problem from opposite directions. BlueHammer is the fast version, where public exploit code can turn a small foothold into full local control in days, and BRICKSTORM is the slow version, where attackers sit under the operating systems for more than a year because almost nobody is looking there. (bleepingcomputer.com, cloud.google.com, cloud.google.com) The immediate response is different in each case, but both start with the same rule: do not trust defaults. Windows teams need to watch for a Microsoft fix and restrict who gets local access, while vSphere teams need to harden vCenter and ESXi, review privileged identities, and hunt the virtualization layer itself instead of assuming the guest machines tell the whole story. (bleepingcomputer.com, cloud.google.com)
