arrow_back All posts

FalconFlank: privilege escalation through CrowdStrike Falcon's macro remediation

A published PoC turns Falcon's SYSTEM-level macro cleanup into an arbitrary write via a junction and an oplock race, dropping a DLL into System32. Root cause, mechanism and detection.

·9 min read

Security agents run as SYSTEM and touch files that ordinary users control. That combination is a recurring privilege-escalation surface, and FalconFlank — a proof-of-concept dropped on GitHub in September 2026 without coordinated disclosure — is a clean example. It abuses the CrowdStrike Falcon sensor’s feature that strips malicious macros from Microsoft Office files, redirecting that privileged file operation so a low-privileged user lands a DLL inside C:\Windows\System32 and executes code as SYSTEM.

This post analyses the mechanism from a defender’s point of view: what the root cause is, how the race is won, and — the part that matters for a SOC — how to detect it. It is based on the public PoC, reproduced in a lab. It is not an operating guide, and it deliberately omits the weaponised code and any evasion technique.

Overview

Attribute Value
Class Local privilege escalation (LPE), user → SYSTEM
Target CrowdStrike Falcon Sensor, “Microsoft Office file malicious macro removal”
Bug class TOCTOU / link-following in a privileged file operation
Primitives Directory junction (reparse point), oplock, transacted NTFS
Payload sink C:\Windows\System32\WindowsPowerShell\v1.0\bcrypt.dll
Execution Scheduled task \Microsoft\Windows\Application Experience\MareBackup (runs as SYSTEM)
Confirmed on Windows 11 25H2, Windows Server 2025, Falcon Phase 3 “Optimal” protection
Disclosed 2026-09-03, uncoordinated full disclosure, no CVE assigned
Status No patch; CrowdStrike investigating, official workaround only

1. The bug class: remediation as a privileged primitive

When an EDR or antivirus quarantines, deletes or “cleans” a file, a SYSTEM-level component performs a file operation against a path an unprivileged user chose. If that component does not

  • impersonate the requesting user for the operation, and
  • open the target while refusing to follow reparse points,

then the user can substitute a junction at the last moment and steer the SYSTEM write or delete somewhere they could never reach on their own. The result is an arbitrary create/write/delete as SYSTEM, which is one of the most reliable stepping stones to full compromise. AV and EDR products have shipped this bug repeatedly; FalconFlank is the same pattern applied to Falcon’s in-place macro cleanup.

Falcon’s feature is helpful by design: when it sees an Office document carrying a malicious macro, the sensor removes the macro from the file in place, rather than blocking or deleting the whole document. That “modify the user’s file, as SYSTEM” action is exactly the privileged primitive the exploit hijacks.

2. Mechanism

The exploit starts as a standard user and needs only a writable temp directory and the ability to make Falcon act.

  1. Bait. It writes an Office file containing a macro that Falcon classifies as malicious into an attacker-controlled directory under %TEMP%\Flanker_<GUID>\. This guarantees the sensor will come and operate on a path the attacker owns.
  2. Widen the window. File-system TOCTOU races are usually too fast to win by luck, so the exploit takes an opportunistic lock (oplock) on the file the sensor will touch. When the sensor opens it, the OS stalls that access and signals the exploit, which now controls the timing of the race.
  3. Swap the path. During that stall, the exploit turns its directory into a junction (an NTFS reparse point set with FSCTL_SET_REPARSE_POINT_EX) so the path the sensor believes points at the quarantined file now resolves into \SystemRoot\System32\WindowsPowerShell\v1.0\. Because the sensor opened the path without refusing reparse points, its privileged operation follows the junction out of the sandbox and into System32.
  4. Land the DLL. Combined with a transacted-NTFS handle (CreateFileTransacted), the redirected SYSTEM operation is used to place an attacker-controlled bcrypt.dll into the PowerShell directory. That directory is on the DLL search path of binaries launched from it, and bcrypt.dll is a name those binaries import — a classic phantom/search-order DLL sink.
  5. Detonate as SYSTEM. The exploit then triggers the built-in scheduled task \Microsoft\Windows\Application Experience\MareBackup through the Task Scheduler COM API (ITaskService → IRegisteredTask::Run). That task runs as SYSTEM, loads the planted bcrypt.dll from the poisoned directory, and the attacker’s code executes with SYSTEM privileges.

The named pipe \\.\pipe\FALCONFLANK also appears in the PoC, used for the exploit’s own synchronisation.

Why each primitive is there

  • Junction — redirects a file path the attacker controls into a protected location. No admin rights are needed to create one.
  • Oplock — converts an unwinnable microsecond race into a controlled, deterministic swap by pausing the sensor mid-operation.
  • Transacted NTFS — lets the write land atomically, so the sensor sees a consistent file while the attacker swaps the underlying target.
  • bcrypt.dll in WindowsPowerShell\v1.0\ — a DLL name and directory that a SYSTEM-context binary will load, turning an arbitrary-write into code execution.
  • MareBackup scheduled task — a ready-made, on-demand SYSTEM execution context that the standard user is allowed to start.

3. Detection opportunities

Each stage of the chain leaves a signal. The most specific ones are the DLL sink and the junction.

  • Writes to C:\Windows\System32\WindowsPowerShell\v1.0\bcrypt.dll. bcrypt.dll is a system DLL that loads from System32 proper; a copy appearing in the PowerShell v1.0 subdirectory should essentially never happen on a healthy host. Alert on any create/write of bcrypt.dll (or other core DLL names) under an application subdirectory.
  • Phantom DLL loads. A bcrypt.dll loaded from ...\WindowsPowerShell\v1.0\ rather than from System32 is a high-fidelity indicator, whether or not you caught the write. (Sysmon Event ID 7, image-load, filtered to unexpected paths for known system DLL names.)
  • Junctions from user-writable paths into System32. A reparse point created under %TEMP% or a user profile that resolves into C:\Windows\System32\... is rare and suspicious. Watch for FSCTL_SET_REPARSE_POINT activity and directories like %TEMP%\Flanker_*.
  • On-demand start of MareBackup by a non-SYSTEM process. MareBackup is a maintenance task; a standard-user process invoking it through the Task Scheduler COM interface, especially right after a macro-remediation event, is anomalous. Correlate Task Scheduler operational logs (Event IDs 100/200) with the triggering process.
  • Oplock + rapid create/rename/delete races around a file the sensor is remediating. Harder to alert on directly, but the sequence “Falcon remediation event → junction creation → System32 DLL write → SYSTEM task run” within seconds is a strong composite rule.
  • Named pipe \\.\pipe\FALCONFLANK in the public PoC. A trivial string IOC that any obfuscated or renamed variant will change, so treat it as a tripwire, not a control.

The durable detections are the behavioural ones — DLL landing in System32 and the phantom load — because they survive renaming and repacking of the tool.

4. Mitigation

There is no patch. FalconFlank was dropped without coordinated disclosure and, at the time of writing, CrowdStrike is still investigating. Its official guidance is a configuration workaround, not a fix:

“We are actively investigating these claims and advise customers to disable the Microsoft Office File Suspicious Macro Removal Windows policy setting. Customers remain protected through the Cloud Anti-malware for Microsoft Office Files settings.” — CrowdStrike

  • Apply the vendor workaround. Disable the Microsoft Office File Suspicious Macro Removal Windows policy setting. Macro protection is retained through the Cloud Anti-malware for Microsoft Office Files setting, which does the inspection in the cloud rather than through the local privileged remediation this exploit abuses. CrowdStrike has posted a FalconFlank Tech Alert in the support portal for authenticated customers.
  • What an eventual sensor fix has to do. The defect is in the remediation code, so a real fix has to close the link-following race: impersonate the requesting user for the file operation, open the target with FILE_FLAG_OPEN_REPARSE_POINT so junctions are not followed, and re-validate the final resolved path before writing. Until the sensor ships that, the workaround above is the only control that removes the vulnerable code path.
  • Harden the DLL sink. Where it is feasible, monitor or restrict writes of core DLL names into System32 application subdirectories; legitimate software rarely does this.
  • Watch privileged scheduled tasks. Treat on-demand execution of built-in SYSTEM tasks by unprivileged processes as an escalation signal across the estate, not just for this exploit.
  • Assume the primitive recurs. Any SYSTEM-level “clean the user’s file” behaviour — in EDR, AV, backup agents or updaters — is worth reviewing for the same link-following weakness.

5. Disclosure and status

FalconFlank was published on 3 September 2026 by a researcher who goes by Nightmare Eclipse (also Chaotic Eclipse, Infinite Nightmare, and MSNightmare on GitHub), known for a run of Microsoft zero-days over the preceding months. It was an uncoordinated full-disclosure release: proof-of-concept code straight to a public repository, no CVE assigned, and no advance notice to CrowdStrike. The drop was covered by The Hacker News, BleepingComputer and The Register (linked below).

The researcher expected the sensor to flag the PoC on sight — in their words, “by the time I drop this Crowdstrike would already have detections for it” — and noted that testing it would require exclusions or an obfuscated build. For a defender that framing is reassuring rather than alarming: signature detection of the sample is easy to sidestep, but the behavioural chain in section 3 is not. A repacked or renamed variant still has to plant a DLL in System32 and trigger a SYSTEM task, so that is where detection belongs — not on the surface of any one sample.

6. MITRE ATT&CK

Tactic Technique
Privilege Escalation T1548 Abuse Elevation Control Mechanism
Privilege Escalation / Persistence T1053.005 Scheduled Task/Job
Defense Evasion T1574.001 Hijack Execution Flow: DLL Search Order Hijacking
Defense Evasion T1211 Exploitation for Defense Evasion (abusing the security product)
Execution T1106 Native API

7. References