A practical look at how the public FalconFlank PoC turns a low-privileged Windows user into SYSTEM - and where AZT Full Prevent stops the chain.
FalconFlank is a public local-privilege-escalation PoC targeting CrowdStrike Falcon on Windows. The attack starts with an ordinary local user, abuses Falcon's Microsoft Office malicious-macro remediation path, redirects a privileged file operation into the Windows PowerShell directory, plants a fake bcrypt.dll, and then triggers a built-in scheduled task so the attacker-controlled DLL executes with SYSTEM privileges. As of September 9, 2026, there is no word of a CrowdStrike patch to this high-risk vulnerability. However, with AZT installed on the same endpoint in Full Prevent mode, the chain is stopped at multiple deterministic trust boundaries - beginning with the FalconFlank launcher itself rendering the attack inert. ARIA AZT keeps your Falcon deployments safe from this type of attack so that you don’t have to turn off critical features. [1][2]
FalconFlank succeeds by turning a trusted security product's privileged remediation capability into a way to place and execute attacker-controlled binary code. AZT does not need to understand the exploit logic. It enforces a simpler rule: untrusted executable code does not run, untrusted PE/DLL content is not allowed to be written or loaded, and a protected process cannot simply become SYSTEM. In a normal Full Prevent posture, NO TRUST stops the public PoC first; WRITE BUFFER and IMAGE LOAD provide additional hard stops if the launcher is deliberately allowed for deeper testing.
Figure 1. Public FalconFlank privilege-escalation path and the points where AZT Full Prevent blocks the untrusted launcher, payload staging, DLL loading, and SYSTEM transition.
FalconFlank was publicly released by researcher MSNightmare in early September 2026 as a proof of concept for local privilege escalation against CrowdStrike Falcon. Truesec reports that the PoC works on fully updated Windows 11 25H2 and Windows Server 2025 systems when Falcon is configured with the Microsoft Office malicious-macro removal feature enabled. Truesec recommended disabling the affected macro-remediation setting while remediation proceeds. [1][2]
This is not a remote attack. The attacker already needs local code execution as a normal user. The important security failure is what happens next: a low-privileged process manipulates filesystem objects and a race condition so a security product operating with higher privileges performs a file action the attacker could not perform directly. The attacker then uses a planted DLL and a privileged scheduled-task execution path to reach NT AUTHORITY\SYSTEM. [2][3]
The public source code shows a chain built from ordinary Windows features - temporary directories, reparse points, oplocks, transacted file I/O, DLL search behavior, and Task Scheduler. None of those features is malicious by itself. The exploit succeeds by arranging them so a privileged Falcon remediation operation and a later SYSTEM task act on attacker-controlled filesystem state.
The attack starts locally. The researcher describes the PoC as working from a non-administrative context on supported Windows systems with the relevant Falcon prevention setting enabled. FalconFlank.exe is a custom proof-of-concept executable, not a Windows component and not part of CrowdStrike Falcon. [1][2]
This is AZT's earliest and strongest stop point. In Full Prevent mode, a FalconFlank.exe that does not already carry a valid TrustID is denied by NO_TRUST before the exploit can create its working directory, manipulate reparse points, or stage its DLL.
If the launcher is deliberately allowed for testing, FalconFlank creates a uniquely named directory under
%TEMP% using the pattern Flanker_<GUID>. Inside that directory it builds a WindowsPowerShell\v1.0 structure and creates a file named bcrypt.dll. The PoC also prepares a mount-point reparse target that points toward the real \SystemRoot\System32\WindowsPowerShell directory. [2]
FalconFlank places an oplock on the fake bcrypt.dll and waits for the targeted remediation path to interact with the file. That synchronization gives the exploit a narrow window to change the filesystem underneath the privileged operation. The code then removes and redirects parts of the temporary path using a mount-point reparse operation so an action that began against the attacker-controlled directory resolves into the protected Windows PowerShell directory under System32. [2][3]
An analogy is useful: imagine asking a trusted courier to deliver a package to Room A. While the courier is walking down the hall, the attacker changes the sign on Room A so the door now opens into a locked server room. The courier still believes it is completing the approved delivery, but the destination has changed underneath it.
The public code defines its target as C:\Windows\System32\WindowsPowerShell\v1.0\bcrypt.dll. It opens the target through a Kernel Transaction Manager transaction, creates a file mapping, copies the embedded FlankerDll bytes into the mapped file, and commits the transaction. In other words, the PoC does not merely manipulate metadata - it stages a real PE/DLL payload in the directory from which the later privileged process will search for bcrypt.dll. [2]
If the launcher has been allowed so testing reaches this stage, WRITE_BUF provides the next strong enforcement point. The embedded bcrypt.dll is executable PE content. In Full Prevent mode, AZT blocks untrusted executable content in the write buffer before the malicious DLL can be successfully staged for later execution.
After the DLL is staged, FalconFlank uses the Windows Task Scheduler COM interface. The source code connects to the \Microsoft\Windows\Application Experience task folder, obtains the built-in MareBackup task, and runs it. The PoC then waits on a named pipe while the privileged task executes. [2]
The attack relies on DLL search behavior: a privileged process started through this path can load the attacker-controlled bcrypt.dll from the PowerShell application directory before falling back to the legitimate system copy. Public reporting describes the end result as a command shell running with SYSTEM privileges. [3][4]
Even if the fake DLL reaches disk, IMAGE_LOAD blocks an executable image that does not have a valid TrustID when the privileged process attempts to load it. This is a particularly important defense because it prevents a trusted SYSTEM process from inheriting trust for an attacker-controlled DLL simply because the DLL is placed in a trusted-looking Windows path.
FalconFlank by name, wait for a CVE, or decide that the reparse-point sequence looks suspicious. The PoC eventually needs attacker-controlled binary code to launch, be written, be loaded, and produce SYSTEM execution. AZT places deterministic trust decisions at each of those points. 3.1 Stop 1: NO TRUST blocks FalconFlank.exe Under the stated Full Prevent posture, this is the expected first stop. FalconFlank.exe is a standalone custom executable. If it lacks an AZT TrustID, NO_TRUST denies execution before the PoC begins.
NO_TRUST: Blocks FalconFlank.exe when it has no valid TrustID.
Result: No temporary staging tree, no reparse race, no malicious DLL write, and no privilege escalation. For most production deployments, the story should end here.
Security teams may intentionally trust the launcher in a laboratory so they can observe deeper controls. FalconFlank contains an embedded PE DLL and writes those bytes as bcrypt.dll. WRITE_BUF is the strongest second-stage control because it evaluates executable content as it is being written, rather than trusting the process performing the write or the destination path.
WRITE_BUF: Blocks the untrusted PE/DLL content before it is successfully written to the target path.
Result: The scheduled task has no attacker-controlled bcrypt.dll to load.
If the payload is already present on disk, IMAGE_LOAD provides another independent stop. The privileged scheduled-task path does not make the DLL trusted. When the fake bcrypt.dll is selected for loading, AZT checks the executable image itself.
IMAGE_LOAD: Blocks the untrusted DLL image when a process attempts to load it.
Result: The attacker-controlled code never executes inside the privileged context.
The PoC's objective is not merely file placement; it is local elevation to NT AUTHORITY\SYSTEM. AZT's PRIV_ESC control adds another enforcement point at the privilege boundary. For FalconFlank, this is best treated as additional protection after the stronger and earlier NO_TRUST, WRITE_BUF, and IMAGE_LOAD controls.
PRIV_ESC: Blocks an attempt to raise the protected execution context to SYSTEM privileges.
Result: The attacker does not obtain a SYSTEM shell or equivalent SYSTEM process.
FalconFlank is a good example of a confused-deputy problem. CrowdStrike Falcon legitimately needs elevated rights to remediate malicious Office content. The exploit manipulates filesystem state so that a privileged remediation action helps place attacker-controlled content where the low-privileged user could not normally write it. [1][3]
That means a traditional question such as "Is the process trusted?" is not enough. A trusted security process can still be tricked into handling untrusted executable content. AZT's value is that it follows the trust decision to the executable bytes themselves.
The fake bcrypt.dll is aimed at a Windows System32 PowerShell directory - exactly the kind of location many people instinctively associate with trusted operating-system code. AZT does not assume that a file is safe because of its filename or directory. The DLL still needs a valid TrustID, and its executable content remains subject to write and image-load enforcement.
FalconFlank has to complete a long chain correctly: launch the PoC, prepare the filesystem, win the timing window, stage the DLL, trigger the task, load the DLL, and reach SYSTEM. AZT does not need every countermeasure to fire. It only needs one hard trust decision to fail the attack.
FalconFlank demonstrates an uncomfortable security reality: a trusted endpoint-security product can become part of a privilege-escalation path when an attacker finds a way to redirect its privileged remediation activity. The public PoC begins as a low-privileged local user and ends with SYSTEM by combining filesystem race techniques, a planted DLL, and a privileged Windows scheduled task. [1][2][3]
AZT changes that outcome by enforcing trust on the executable code that makes the exploit useful. In Full Prevent mode, NO_TRUST stops the public launcher before the attack begins. If the launcher is deliberately allowed, WRITE_BUF stops the embedded malicious DLL from being staged. If the DLL reaches disk,
IMAGE_LOAD stops it from being loaded into the privileged execution path. PRIV_ESC adds another barrier at the final SYSTEM transition.
Sources
[1] Truesec, "Privilege Escalation Vulnerability in Falcon Crowdstrike," September 4, 2026. https://www.truesec.com/hub/blog/privilege-escalation-vulnerability-in-falcon-crowdstrike
[2] MSNightmare, "FalconFlank - Crowdstrike Falcon 0day Privilege Escalation Vulnerability," GitHub repository and FalconFlank.cpp, September 2026. https://github.com/MSNightmare/FalconFlank
[3] IntelFusions, "FalconFlank: Falcon macro remediation LPE," September 2026. https://www.intelfusions.com/news/falconflank-falcon-macro-remediation-lpe
[4] BleepingComputer, "New CrowdStrike FalconFlank zero-day grants SYSTEM privileges," September 4, 2026.
https://www.bleepingcomputer.com/news/security/new-crowdstrike-falconflank-zero-day-grants-system-privileges/