CrowdStrike’s Own Clean-Up Feature Could Hand an Attacker SYSTEM
FalconFlank is a public proof of concept that turns a low-privilege Windows foothold into SYSTEM access by abusing a trusted CrowdStrike Falcon clean-up feature. The exploit does not begin with an exotic kernel flaw. It begins with a security control that is already allowed to modify suspicious Microsoft Office files with the highest local privileges.
That distinction matters. Endpoint security products need deep access to inspect, quarantine and repair files. FalconFlank shows what can happen when an attacker finds a way to steer one of those trusted remediation workflows towards a path they control.
The proof of concept was published on 3 September 2026 by a researcher using the names Chaotic Eclipse and MSNightmare. Security firm Vega says it independently reproduced the attack in a controlled lab, taking a standard Windows user to NT AUTHORITY\SYSTEM. CrowdStrike is investigating and has issued temporary guidance to customers. There is no CVE, no confirmed malicious exploitation and no public evidence that every Falcon configuration is affected.
FalconFlank turns clean-up into the escalation path
The attack targets Falcon’s Microsoft Office malicious-macro removal capability. In the relevant prevention-policy configuration, the sensor can create a scheduled task called MareBackup that runs as SYSTEM while it repairs a flagged document.
According to Vega’s analysis, FalconFlank prepares a fake directory tree in the user’s temporary folder and places a malicious file named bcrypt.dll inside it. The exploit then uses a file-locking race, an NTFS junction and a transacted write to redirect Falcon’s trusted operation towards the real PowerShell directory under System32.
When the SYSTEM-level task runs, PowerShell loads the attacker-controlled DLL. The proof of concept then uses a named pipe as a local command channel.
The important point is not the filename or the pipe name. Those are easy to change. The reusable primitive is that a low-privilege process can prepare attacker-controlled material and cause a trusted security component to carry it across a privilege boundary.
The exploit needs a specific Falcon setting
FalconFlank is not a drive-by attack against any Windows computer running CrowdStrike. The public proof of concept starts from an existing low-privilege user context on the endpoint. It also depends on Falcon’s Microsoft Office File Malicious Macro Removal Windows policy setting being enabled.
The researcher reported success on fully updated Windows 11 25H2 and Windows Server 2025 systems using Falcon’s Phase 3 Optimal Protection configuration. That is evidence for those tested conditions, not a complete affected-version list.
Vega’s reproduction strengthens the underlying claim, but important scope questions remain unanswered. CrowdStrike has not published a public affected-version matrix, a CVE or a fixed sensor release. There is also no verified report of FalconFlank being used in a real intrusion.
CrowdStrike’s temporary guidance is to disable the feature
In a statement reported by IntelFusions, CrowdStrike said it was actively investigating the claims and advised customers to disable the Microsoft Office File Suspicious Macro Removal Windows policy setting. The company said customers would remain protected through Cloud Anti-malware for Microsoft Office Files when prevention policies follow its recommended configuration.
The setting is found in the next-generation antivirus policy area under the option for cleaning infected Microsoft Office files. Administrators should follow CrowdStrike’s customer Tech Alert and support guidance rather than relying solely on third-party summaries, because the vendor’s position may change as the investigation develops.
Disabling the feature reduces the specific attack surface described by the proof of concept, but it should not be treated as a complete incident-response action. Organisations still need to look for evidence that the technique was attempted.
What defenders can hunt for now
Vega published five detection ideas after reproducing FalconFlank. Several focus on the original proof of concept’s obvious artefacts, including a named pipe called FALCONFLANK and temporary directories beginning with Flanker_. Those indicators can catch an unmodified copy, but an attacker can rename them.
The stronger hunts look for behaviour that is harder to remove from the chain:
- A DLL staged inside a temporary directory that imitates a protected Windows system path.
- A suspicious
bcrypt.dlloutside its normal location, especially when paired with local named-pipe activity. - A DLL write affecting the PowerShell installation directory outside expected Windows servicing.
- Execution of the
MareBackupscheduled task shortly after suspicious DLL staging. - Unexpected junction creation or transacted file activity involving a low-privilege process and a protected system directory.
Vega also notes a difficult visibility gap. In its lab, the final atomic overwrite into the protected path did not appear as a normal per-file-write event in Falcon telemetry. That means a hunt focused only on the final write may miss the chain. The staging directory, named pipe and SYSTEM task provide more durable pivots.
Why a local privilege escalation still matters
A local privilege escalation is not an initial-access method. An attacker first needs code execution or an interactive foothold as a low-privilege user. That prerequisite does not make the issue unimportant.
Phishing, stolen credentials, browser exploits and exposed remote-access services often leave an intruder inside a standard user session. SYSTEM access can then open the way to credential theft, security-control tampering, persistence and access to data belonging to other users or services on the endpoint.
The affected component also changes the defensive calculation. Falcon is supposed to be one of the most trusted processes on the device. Security teams may monitor its scheduled tasks and remediation actions less suspiciously than an unknown binary. BlackTree documented a related trust-boundary failure in ShieldBreak, where Microsoft Defender’s quarantine workflow became a route to SYSTEM. FalconFlank turns that same trust into part of the attack path.
The public PoC shortens the defender’s clock
The FalconFlank source code is public. Vega says anyone can rebuild it and alter the simple artefacts used by signature-based detections. A public proof of concept does not prove attackers are exploiting the issue, but it reduces the work needed to test and adapt the technique.
That creates an awkward interval for defenders. The vendor investigation is still developing, there is no CVE and there is no conventional patch bulletin to drive vulnerability-management tooling. Yet the exploit logic can already be studied and modified.
Organisations cannot wait for a scanner to produce a red CVE row. They need to identify whether the relevant Falcon setting is enabled, apply the temporary vendor guidance, deploy behavioural hunts and preserve telemetry that could show an attempted chain.
What Falcon customers should do
- Review CrowdStrike’s FalconFlank Tech Alert in the customer support portal for the latest vendor position.
- Disable the Microsoft Office File Suspicious Macro Removal Windows policy setting if CrowdStrike’s current guidance applies to your environment.
- Confirm that Cloud Anti-malware for Microsoft Office Files and the recommended prevention controls remain enabled.
- Hunt for FalconFlank’s published artefacts, then expand the hunt to junction abuse, DLL staging, named pipes and unexpected
MareBackupexecution. - Do not run the public exploit on production endpoints. Reproduction should be confined to an isolated lab with appropriate authorisation.
- Track CrowdStrike for an affected-version statement, a permanent fix and any change in exploitation status.
The bigger lesson is about trusted remediation
FalconFlank is still an evolving disclosure. The public evidence supports a specific, reproducible privilege-escalation chain under defined conditions. It does not support claims of a universal Falcon compromise or an active campaign.
What it does expose is a broader security-design problem. A remediation engine does not merely detect an attacker-controlled object. It opens, moves, rewrites and sometimes executes supporting processes around that object while holding privileges the user does not have. A recent WatchGuard Agent flaw exposed the same reversal at a network boundary: the trusted security agent became the privileged execution path.
That makes every path decision, file operation and scheduled task inside the clean-up pipeline part of the security boundary. The more authority a defensive tool has, the more carefully its own remediation logic must treat attacker-controlled input.
Frequently asked questions
Is FalconFlank being exploited in the wild?
No confirmed malicious exploitation has been publicly reported as of 5 September 2026. A public proof of concept exists and Vega says it reproduced the attack in a lab.
Does FalconFlank have a CVE?
No CVE had been assigned at the time of writing.
Does the attack work on every CrowdStrike Falcon endpoint?
No. The public proof of concept requires an existing low-privilege foothold and the relevant Microsoft Office malicious-macro removal setting. The full affected-version and configuration scope has not been published.
What is the immediate mitigation?
CrowdStrike has advised customers to disable the Microsoft Office File Suspicious Macro Removal Windows policy setting while it investigates. Customers should check the vendor’s Tech Alert for the latest guidance.
