FalconFlank: your EDR as a privilege-escalation attack path

What is actually known

The author is a researcher who goes by Chaotic Eclipse, Nightmare Eclipse, INFINITE NIGHTMARE and MSNightmare, the same person who has been shipping Windows zero-days for months. We wrote here about his MiniPlasma in May and about LegacyHive in July. The PoC is public on GitHub.

Hard facts from the repository and from the vendor:

• The PoC works on fully patched Windows 11 25H2 and Windows Server 2025 with Falcon in a Phase 3 (Optimal Protection) policy.
• The trigger is the feature that removes malicious macros from Microsoft Office files.
• Kevin Beaumont confirmed in public that the exploit works, as did several others from the same series.
• CrowdStrike is investigating and recommends turning off the “Microsoft Office File Suspicious Macro Removal” policy for Windows. Macro protection stays with Cloud Anti-malware for Microsoft Office Files. Support has a separate Tech Alert named FalconFlank.
• No CVE has been assigned. There is no patch.

Why a protective feature becomes an attack primitive

A remediation engine has to run with high privileges. It has to delete, move and rewrite files in places a standard user cannot touch. That is not a design mistake. It is a condition of the job.

The problem starts when a process running as SYSTEM writes a file to a path the user can influence. Windows already ships the tool for that: reparse points, junctions and symlinks. The attacker builds a directory tree in their profile, drops a document that will trigger remediation, and redirects the write to a location they could not write themselves.

In FalconFlank the target file is:

C:\Windows\System32\WindowsPowerShell\v1.0\bcrypt.dll

On a clean system that file does not exist. The real bcrypt.dll lives in System32. When Windows loads a library, though, it searches the application's own directory first, and powershell.exe lives in v1.0. So any PowerShell process that starts as SYSTEM (a scheduled task, a startup script, a management tool) will execute the planted library with those rights.

The whole trick is that the attacker does not need write access to System32. They need a process that has it, and a way to point that process at where to write. Falcon supplies both.

This is not one vendor's blunder

In recent weeks the same researcher published a series of exploits built on the same idea:

• ShieldBreak (CVE-2026-69414) in Microsoft Defender, where the cleaning engine writes a controlled library as C:\Windows\System32\phoneinfo.dll and SYSTEM execution arrives through the built-in Windows Error Reporting task. That is a bypass of the patch for CVE-2026-50656.
• HardBreacher in Kaspersky Endpoint Security 14.0.0.504.
• PrettyPrague in Avast, which dumps the SAM hive through a bug in the product sandbox. Gen Digital confirmed the issue and is working on a fix.

Before that came RedSun (Cloud Files API plus TieringEngineService), LegacyHive, where a standard user mounts an administrator's registry hive through the User Profile Service, and MiniPlasma, which revived a 2020-patched bug in the cldflt.sys driver. A different corridor each time, the same pattern: a privileged write plus a path the attacker controls.

Beaumont said it without wrapping: the security quality of the security products themselves is a wider problem than one vendor. Hard to argue. We usually tell clients that a security control reduces risk. This series is a reminder that a security control is also software, so it has bugs, and it gets installed on 100 percent of the machines in the company.

What this means for your risk

Reach. EDR sits on every endpoint, almost always under one shared policy. A bug in the agent is not one server. It is the whole fleet at once, with the same configuration.

Place in the attack chain. FalconFlank does not break in by itself. It fills the exact step that sits between phishing and real trouble. SYSTEM on a workstation means credentials in memory, protective controls switched off, lateral movement, and then the domain. Ransomware needs that step.

Detectability. The author wrote himself that CrowdStrike almost certainly has signatures for the published PoC, and that changing the library-loading technique is enough to slip them. Detecting one file is not a mitigation of the bug. It is a mitigation of one implementation.

And the most awkward part for a CISO: the recommended mitigation is to turn a protective feature off. You pay with protection against one threat to close another. That is a risk decision, not an operations ticket, and it should be written down somewhere with a date and a name.

What to do this week

• Turn off the “Microsoft Office File Suspicious Macro Removal” policy for Windows in the Falcon console, as the vendor recommends, and confirm that Cloud Anti-malware for Microsoft Office Files is on.
• Open the FalconFlank Tech Alert in the CrowdStrike support portal and assign someone to track it until a patch ships. Vendor advice on unpatched bugs changes day to day.
• Watch for that file under the path in the technical section. It is not there on a clean system, so any appearance is an alert by itself.
• Build a hunt for the sequence: a Falcon remediation event, then a new DLL written into a system directory or a child process running as SYSTEM.
• Watch Falcon exclusion changes. Adding an exclusion is one of the two ways the PoC author suggests for launching the exploit.
• Cut the problem at the source. Block macros in files from the internet with the Office policy (Block macros from running in Office files from the Internet). If remediation has nothing to clean, it has nothing to steer.
• Check whether other security agents in the environment are in the same wave. Kaspersky and Avast are already on the list.

A quick check for the planted library:

$p = "$env:SystemRoot\System32\WindowsPowerShell\v1.0\bcrypt.dll"
if (Test-Path $p) {
    Write-Warning "Plik nie powinien istnieć w tej lokalizacji."
    Get-Item $p | Select-Object FullName, CreationTime, LastWriteTime, Length
    Get-AuthenticodeSignature $p | Select-Object Status, SignerCertificate
} else {
    "OK: brak pliku w katalogu PowerShella."
}

An OK result means this one path is clean right now. It does not mean the vulnerability does not apply to you.