The file at the centre of FalconFlank is called bcrypt.dll, and it is not a DLL. It is a Microsoft Word document of 93,696 bytes. Its own metadata, which is self reported and easily forged, says it was last saved in December 2015 by a user recorded as MXP, with its text in Cyrillic code page 1251. It carries the VBA streams and the AutoOpen entry point of a macro dropper. The exploit writes this file into a temporary folder and then waits.
It is there to be caught. The technique is built around Falcon noticing it.
FalconFlank is a proof of concept published to GitHub on 3 September by the account MSNightmare, which also goes by Chaotic Eclipse and Nightmare Eclipse. The repository ships C++ source, a Visual Studio project and a compiled Windows executable, and within hours of going up it had gathered more than 140 stars and 30 forks. The claim attached to it is that Falcon's cleanup of malicious Office macros can be redirected into writing inside C:\Windows\System32, a place no ordinary user account can touch. CrowdStrike has published no advisory, no CVE has been assigned, and there is nothing to patch. So we read the code rather than the README.
A document that wants to be found
Before it does anything else, the exploit builds a small replica of the operating system. Under the user's own temporary directory it creates a folder, then inside it one named WindowsPowerShell, then inside that one named v1.0. That is the exact shape of a real path present on every Windows machine, C:\Windows\System32\WindowsPowerShell\v1.0. Into the deepest folder it drops the 2015 Word document, under the filename bcrypt.dll.
The mismatch is the entire point. A scanner reading the contents sees a macro bearing Office document and flags it. Anything that later acts on the same file by name is handling what looks like a system library. The exploit needs both readings to be true at once.
It then takes an opportunistic lock on the file. An oplock is a Windows mechanism that lets a program ask to be told before anyone else touches a file it has cached, and it exists to keep caches coherent. Used this way it is a timing device, letting the exploit synchronise itself with the scan rather than race it blind.
The junction does the real work
In that window the exploit deletes the v1.0 folder and converts the WindowsPowerShell folder above it into a junction, a filesystem redirect that makes one directory silently stand in for another. It aims that redirect at the genuine article, \SystemRoot\System32\WindowsPowerShell, retrying in a tight loop until it lands.
Anything that then resumed work on the old path would be operating inside System32 without knowing it. That is the outcome the exploit is designed to produce. The remediation carries the sensor's privileges, and the user who set the trap has none of them.
What follows in the code is a write to C:\Windows\System32\WindowsPowerShell\v1.0\bcrypt.dll, opened through a Kernel Transaction Manager transaction and written through a mapped view of the file. The content written is a genuine 64 bit Windows DLL, carried in the same header file as the decoy document. The exploit then uses the Task Scheduler COM interface to start a built in Windows task called MareBackup, and waits on a named pipe for a signal back.
CrowdStrike's own documentation describes the write
The README names a setting called "Microsoft Office file malicious macro removal". CrowdStrike documents a matching control in its own Terraform provider, where the attribute microsoft_office_file_suspicious_macro_removal is described as one that "identifies potentially malicious macros in Microsoft Office files and, if prevention is enabled, either quarantines the file or removes the malicious macros before releasing the file back to the host".
Releasing the file back to the host means writing it. That documented phrase is what the exploit is built around: a privileged component that does not merely read a suspect file but rewrites it and puts it back where it found it. The second precondition the README names, Phase 3 Optimal Protection, is also CrowdStrike's own vocabulary, the final tier of the company's phased rollout guidance, where prevention settings are fully switched on. The configuration under attack is the recommended one, not a weakened one.
What the code does not prove
Here is the honest boundary of this analysis. We read the published source, extracted and identified both embedded payloads, and confirmed the vendor's own description of the feature. We did not run it. The researcher published a screenshot of his own attempt, showing a console that reports the exploit succeeded and a second window in which whoami returns nt authority\system. That is his demonstration rather than an independent reproduction, and a picture of a SYSTEM prompt cannot show what was protecting the machine at the time. Nobody else has published a reproduction, and CrowdStrike has not confirmed the behaviour. The code establishes what the exploit asks Falcon to do; it cannot establish what Falcon actually does. The researcher's own note that Falcon would already carry detections by release, and that a tester would need to add exclusions to try it, is a further reason to treat the working state of this as unsettled. Credible and unverified, in that order.
One detail in that screenshot is worth more than the administrator prompt it ends on. The exploit is run twice. The Release build exits with "Access is denied", and only the Debug build reports success. Debug builds run slower, and the chain turns on winning a race against the sensor, which is the likeliest explanation for the difference. It also means the single precompiled binary the repository ships, the one sitting in its x64\Release folder, is the build shown failing in its own author's screenshot.
The task it triggers is already known
MareBackup, the scheduled task at the end of the chain, is a standard Windows component under Application Experience that gathers application data and runs as SYSTEM. It is also a documented escalation route in its own right. The researcher known as itm4n published in May 2025 that the task's executable, CompatTelRunner.exe, launches PowerShell without giving an absolute path, so a writable folder sitting earlier in the system PATH than the real PowerShell directory yields SYSTEM.
FalconFlank is built so that it does not need that misconfiguration. It aims at the real PowerShell directory instead, which is what the earlier technique could not reach. If the planted library is loaded when the SYSTEM task starts PowerShell, the attacker inherits that privilege. That last conditional is ours rather than the source's, and it is the part we cannot test.
No patch, so watch the junctions
With no fix to apply, detection is the whole of the response. In rough order of value:
- Writes, replacements or deletions of a file at C:\Windows\System32\WindowsPowerShell\v1.0\bcrypt.dll. Check your own gold image first, then alert on that file appearing where your baseline says it should not. A Sysmon hunt for known Windows libraries loading from non-standard directories covers the moment it is loaded.
- A mount point reparse point set on a user writable directory, especially one whose subfolders mirror a System32 path. This is the actual pivot, and it is far harder for an attacker to avoid than the cosmetic details.
- A folder tree under a user's temporary directory that reproduces WindowsPowerShell\v1.0.
- An on demand start of \Microsoft\Windows\Application Experience\MareBackup, a task that normally runs to its own schedule rather than because somebody asked it to.
- Transacted file creation against a System32 path, which is rare in ordinary software.
- The named pipe FALCONFLANK. This one appears in every write up and is worth exactly one rule, because renaming it costs an attacker a single line.
Turning the macro removal setting off would remove the component under attack, and would also remove a control that strips live malicious macros out of documents. Against an unverified local escalation that already requires code execution on the host, that is a poor trade, and we would not make it. Monitor instead. Anyone minded to test the claim should build from source in an isolated lab and leave the precompiled executable alone, for the reason we set out when trojanised exploit code was used to steal credentials from researchers last month.
Five vendors, one idea
This is not an isolated result. Since June the same account has published proof of concept code against Microsoft Defender twice, against Windows profile services and BitLocker, and then against Kaspersky Endpoint Security, Nvidia and Avast. Those last three all landed within seven days of this one. We covered the Kaspersky, Nvidia and Avast releases on 31 August, when Kaspersky was the only one of the three vendors to say anything publicly. That release came with no warning to the company, and the Defender work reached the public the same way.
Microsoft has twice assigned this researcher a CVE, and the pair say more together than apart. RoguePlanet is CVE-2026-50656 and ShieldBreak is CVE-2026-69414, both rated 7.8, and both are elevation of privilege in the Microsoft Malware Protection Engine inside Defender. Microsoft patched RoguePlanet in July, which we covered at the time. Vendor analyses since have assessed ShieldBreak as a bypass of that same patch, and Microsoft's own record still says only that it is "working to provide a high quality security update that addresses this vulnerability". These are not two closed cases. They are one weakness, patched, bypassed, and still open.
That history is the best reason to take FalconFlank seriously, because ShieldBreak is the same shape. Published analyses of it describe Defender's own remediation being redirected into writing an attacker's DLL into System32 under the name phoneinfo.dll, with SYSTEM execution following from a built in Windows scheduled task. Change the product, the filename and the task, and that is the chain described above. Very little in FalconFlank is novel, and that is the point rather than a criticism: a near identical design against a different vendor has already been examined by others and given a number. The idea keeps working because security software runs at the highest privilege on the machine, it is obliged to handle files that attackers control, and the moment between judging a file malicious and acting on it is a window somebody can climb through.
That idea will not run short of targets. The question worth asking this week is not whether this particular exploit fires on a particular sensor build. It is how many other products, having just condemned a file, answer by writing a new one back to the same place.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.