ShieldBreak: When Microsoft Patches a Zero-Day and the Researcher Patches the Patch

Category: Vulnerability Research | Windows Security | Zero-Day Analysis  •  Published: August 12, 2026

---

Table of Contents

1. What Just Happened
2. Who Is Nightmare-Eclipse?
3. What Makes ShieldBreak Different From RoguePlanet
4. The Six Windows Features That Combine to Produce the Exploit
5. Eight-Stage Attack Chain, Explained
6. Why Microsoft's July Patch Didn't Work
7. Current Detection Posture
8. What Defenders Should Actually Do
9. MITRE ATT&CK Mapping
10. IOC Reference
11. The Bigger Picture
12. References

---

1. What Just Happened

On July 9, 2026, Microsoft shipped an out-of-cycle Defender engine update (version 1.1.26060.3008) specifically targeting CVE-2026-50656 — the vulnerability underlying RoguePlanet, a local privilege escalation exploit that had been running unpatched since June. That patch took about five weeks to land. The researcher who published RoguePlanet took about a month to beat it.

On August 11, 2026, a new repository appeared on GitHub under the MSNightmare handle. The repository is called ShieldBreak. It does not exploit a new bug. It walks directly through the patch Microsoft built to close RoguePlanet, on fully patched Windows 11 25H2 and Windows Server 2025, at a reported success rate of 100%.

This is the tenth tool from the NightmareEclipse cluster in nineteen weeks. It is the first time in the campaign that the researcher has cycled back to defeat a patch built specifically to stop them. The PoC is publicly available. No CVE has been assigned. No patch exists.

---

2. Who Is Nightmare-Eclipse?

The real identity behind the persona has not been independently confirmed. The researcher operates under three aliases — Nightmare-Eclipse, Chaotic Eclipse, and Dead Eclipse — with GitHub releases shipping under MSNightmare. Security journalists at Krebs on Security and The Register have reported that a LinkedIn profile tied to the persona shows Microsoft security employment from September 2022 to June 2025, suggesting a former-insider dispute rather than an outside researcher's grievance. The researcher has not confirmed this. Other outlets treat it as an unverified circulating rumor.

What is verifiable is the public record: ten working exploits targeting Windows Defender, BitLocker, or the User Profile Service, released over nineteen weeks beginning April 3, 2026, none of them coordinated with Microsoft before publication. The stated motivation is specific — revoked portal access, dismissed bug reports, bounties refused on confirmed findings. The researcher frames the releases as a response to what they describe as defamation by MSRC.

The track record matters for evaluating the threat level of new releases. Three earlier tools in this cluster — BlueHammer, RedSun, and UnDefend — have been confirmed in real-world attack chains by Huntress researchers. When the tenth tool in a series drops publicly, the baseline assumption should not be "this might get picked up." It already has an audience.

Tool	CVE	Patch Status	Notes
BlueHammer	CVE-2026-33825	Patched April 14, 2026	Added to CISA KEV. Confirmed real-world exploitation.
RedSun	CVE-2026-41091	Patched May 21, 2026 (out-of-band)	Added to CISA KEV. Confirmed exploitation.
UnDefend	CVE-2026-45498	Patched May 21, 2026 (out-of-band)	Added to CISA KEV.
YellowKey	CVE-2026-45585	Patched June 9, 2026
GreenPlasma	CVE-2026-45586	Patched June 9, 2026
MiniPlasma	CVE-2020-17103 (researcher-attributed)	Patched June 9, 2026	Re-exploitation of incomplete 2020 fix.
RoguePlanet	CVE-2026-50656	Patched July 9, 2026	PoC public June 10, 2026.
GreatXML	—	Unpatched
LegacyHive	—	Unpatched	User Profile Service, July 2026.
ShieldBreak	No CVE assigned	No patch available	Full bypass of the RoguePlanet patch. PoC public August 11, 2026.

---

3. What Makes ShieldBreak Different From RoguePlanet

RoguePlanet was the seventh release in this cluster. ShieldBreak is the tenth. On the surface, both are local privilege escalation exploits that elevate a standard user to NT AUTHORITY\SYSTEM through Defender's own remediation pipeline. Beyond that, the mechanics diverge significantly.

RoguePlanet used NTFS junction swaps and opportunistic locks to redirect Defender's quarantine artifact into attacker-controlled space, then triggered WER's QueueReporting scheduled task to execute the injected payload. The exploit was reliable in lab conditions but described by the researcher as "hit or miss" in production due to timing variability in the underlying race condition. Microsoft's July patch targeted the NTFS junction layer where the redirect operated.

ShieldBreak does not touch NTFS junctions. The entire redirect has moved to the NT Object Manager namespace — a layer the July patch does not reach. Instead of junctions, the exploit uses a shadow directory mechanism to atomically flip how a path resolves without touching the filesystem at all. The race condition that plagued RoguePlanet is replaced with priority-class scheduling and a CLFS log file lock that pauses Defender mid-remediation at a deterministic point. Result: 100% reported success on patched Windows 11 25H2 and Windows Server 2025.

The payload delivery is also new. RoguePlanet delivered a copy of its own binary through Defender's quarantine write. ShieldBreak uses the Cloud Filter API to switch delivered content mid-operation — serving EICAR test content on the first hydration request, then swapping to Warden.dll on a forced restart hydration. The final payload lands at C:\Windows\System32\phoneinfo.dll, a path that does not exist in any supported Windows version and whose presence is therefore an unambiguous indicator of compromise.

---

4. The Six Windows Features That Combine to Produce the Exploit

ShieldBreak is not a memory safety bug. Nothing overflows. Nothing corrupts. Six legitimate, documented Windows features are assembled in a specific sequence that produces a result none of them were designed to allow.

Cloud Filter API (CfApi). The infrastructure backing OneDrive Files On-Demand. ShieldBreak registers a fake sync provider named "Flubber" and creates a placeholder file called BERLIN. When the placeholder is read, the registered callback controls what content is served. First read: EICAR zip. Forced second read via CF_OPERATION_TYPE_RESTART_HYDRATION: Warden.dll. Defender's own remediation write is what delivers the DLL to System32 — the callback is just deciding what that write contains.

NT Object Manager shadow directories. The NtCreateDirectoryObjectEx API creates a shadow directory that overlays a target directory. Lookups check the shadow's own namespace first and fall through to the target's entries if nothing matches. This produces an atomic, filesystem-invisible path redirect that operates below the NTFS layer entirely.

NT Object Manager symbolic links. NtCreateSymbolicLinkObject places targeted redirects within the shadow directory structure. When the shadow's link is deleted, the target's link becomes visible — same path string, different resolution. Defender never sees a path change because there is no path change at the string level.

CLFS device namespace routing. A symbolic link targeting the \CLFS\??\ Object Manager prefix forces the CLFS driver to create a predictable .BLF log file in the working directory. The exploit locks this file exclusively using LockFileEx, pausing Defender's remediation at a controlled point and holding the redirect chain stable while the final namespace construction completes.

Fabricated WER crash report. A structurally valid Report.wer file planted in C:\ProgramData\Microsoft\Windows\WER\ReportQueue\. Format validation passes. When the QueueReporting scheduled task processes it, wermgr.exe executes as SYSTEM and loads phoneinfo.dll from System32 as a known dependency — independent of anything in the report itself.

WER QueueReporting scheduled task. Present on every standard Windows installation. Runs as SYSTEM. Can be triggered by any unprivileged user through the Task Scheduler COM interface. ShieldBreak uses it the same way RoguePlanet did. It is the SYSTEM-level execution primitive at the end of the chain.

---

5. Eight-Stage Attack Chain, Explained

Stage 1: Initialization

The exploit checks that phoneinfo.dll does not already exist in System32. The process sets itself to HIGH_PRIORITY_CLASS with THREAD_PRIORITY_TIME_CRITICAL — this is how ShieldBreak eliminates RoguePlanet's timing variability. A named pipe \\.\pipe\SHIELDBREAK is created and held open for the process lifetime. The elevated payload connects back through it to signal success.

A working directory C:\ShieldBreak_<GUID> is created with the hidden attribute and an Everyone SID full-control ACL. The Everyone ACL is required so that Defender's SYSTEM-level service can write into the directory during remediation.

Detection note: The named pipe SHIELDBREAK is a stable, observable artifact for the entire exploit duration. High-confidence indicator against the published PoC.

Stage 2: Cloud Provider Registration and Placeholder

The fake cloud sync provider "Flubber" (GUID {B196E670-59C7-4D41-9637-C62D80541321}) is registered on the working directory using the same Cloud Filter API that backs OneDrive. A placeholder file named BERLIN is created inside with its advertised size set to the embedded zip resource.

The fetch-data callback controls hydration output via a counter initialized to 1:

• Counter = 1: Serves the embedded EICAR zip (bait that triggers Defender detection), then advances counter to 2
• Counter = 2: Serves Warden.dll (the payload)

The first hydration — delivering EICAR to disk — happens before Defender is invoked. Subsequent reads by Defender during scanning do not fire the callback again because the file is already fully hydrated. The second hydration is forced later via CF_OPERATION_TYPE_RESTART_HYDRATION, which dehydrates the placeholder, resets its size metadata to match Warden.dll, and triggers a fresh callback. Counter is at 2. The callback serves the DLL.

Stage 3: Object Manager Namespace Construction

Two object directories are created in \BaseNamedObjects\Restricted\:

• Target: WD_TARGET_<GUID>
• Shadow: WD_SHADOW_<GUID>, created with the target's handle as its ShadowDirectoryHandle

Two symbolic links named WD_SCAN are placed in these directories:

• In the shadow: points to \??\C:\ShieldBreak_<GUID> (working directory directly)
• In the target: points to \CLFS\??\C:\ShieldBreak_<GUID> (same path, via CLFS namespace prefix)

Because the shadow overlays the target, the shadow's WD_SCAN link wins. The target's is hidden. When the shadow's link is deleted later, the target's becomes visible — same path name, different resolution, no filesystem change, no path string change visible to any external process.

The scan target passed to Defender:
\\.\globalroot\BaseNamedObjects\Restricted\WD_SHADOW_<GUID>\WD_SCAN\BERLIN

Stage 4: ADS Preparation

BERLIN is opened via the direct working directory path. Under the registered hydration policy, accessing the dehydrated placeholder triggers the first callback — EICAR zip content is served and written to disk. The file is now hydrated.

ntdll.dll is then copied to an NTFS Alternate Data Stream on the placeholder (BERLIN:stream). This ADS is a pinning mechanism: after Warden.dll lands at phoneinfo.dll, the exploit maps phoneinfo.dll:stream as an executable image section (PAGE_EXECUTE_READ | SEC_IMAGE), which prevents Windows from deleting a file backing an active image mapping.

The restart hydration parameters are staged here but not fired — deferred until the namespace manipulation and CLFS lock are in place.

Stage 5: Defender Scan and CLFS Log Capture

A worker thread loads MpClient.dll directly, opens its RPC interface, and triggers a resource scan of the BERLIN placeholder through the globalroot path. Because the placeholder is already hydrated with EICAR, Defender reads it from disk without firing the callback. Detection happens. Defender enters remediation.

The main thread monitors the working directory with ReadDirectoryChangesW:

• First FILE_ACTION_ADDED: Defender has created a remediation artifact. The exploit immediately deletes the shadow directory's WD_SCAN link. Path resolution now falls through to the target's link, routing through the CLFS namespace prefix.
• Second FILE_ACTION_ADDED: CLFS has created a log file in the working directory. The exploit captures its filename.

Stage 6: CLFS Lock and Final Redirect

The CLFS log file is exclusively byte-range locked over the maximum range. Defender pauses mid-remediation.

With Defender paused, the final redirect is constructed:

1. A new WD_SCAN object directory is created inside the shadow directory (occupying the name freed when the prior link was deleted in Stage 5)
2. Inside it, a symbolic link is created whose name matches the CLFS log filename minus its extension and whose target is the UNC loopback path \\??\UNC\127.0.0.1\C$\Windows\System32\phoneinfo.dll

When Defender resumes and resolves the CLFS log through the Object Manager namespace, it hits the new directory, matches the filename symlink, and resolves through SMB loopback to phoneinfo.dll in System32.

Stage 7: Payload Delivery and File Pinning

The staged restart hydration fires. The placeholder's advertised size changes to match Warden.dll. Full re-hydration is forced. The callback serves Warden.dll. Through the redirect chain, that content lands at C:\Windows\System32\phoneinfo.dll under Defender's SYSTEM token.

The exploit pins the payload: phoneinfo.dll:stream is mapped as a SEC_IMAGE section. Windows will not delete a file backing an active image mapping. Defender's remediation pipeline is released cleanly.

Stage 8: WER Task Execution and Shell Delivery

A WER report directory is created at:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Kernel_c0000000_A_B_C-C-D-E-<GUID>

A structurally valid Report.wer is written into it, crafted to pass WER format validation. The QueueReporting scheduled task is triggered via Task Scheduler COM from the unprivileged process. The task runs as SYSTEM, processes the fabricated report, and loads phoneinfo.dll from System32 as a known dependency.

Warden.dll is now executing as SYSTEM. It connects back through the SHIELDBREAK pipe. The orchestrator's blocking ConnectNamedPipe unblocks. The exploit prints "Exploit succeeded."

---

6. Why Microsoft's July Patch Didn't Work

Microsoft's fix for CVE-2026-50656 addressed the NTFS junction layer — the junction-based redirect that RoguePlanet used to steer Defender's quarantine artifact into attacker-controlled space. That was the right fix for the tool it was patching.

ShieldBreak does not use NTFS junctions. The entire redirect operates through the NT Object Manager namespace, using shadow directories and symbolic links to flip path resolution atomically and invisibly at a layer the July patch does not instrument. The core vulnerability — the gap between when Defender creates a remediation artifact and when it validates where that artifact actually landed — was not closed at the root. The July patch closed one instance of that gap at one layer. ShieldBreak found the same gap expressed through different plumbing at a different layer.

A root-cause fix requires a change to how Defender validates path integrity across its quarantine workflow at the file handle level, not at the path string level. That is an architectural change.

---

7. Current Detection Posture

The Defender signatures Exploit:Win32/NghtMrShldBrk.BB and Trojan:Win32/Bearfoos.B!ml flag the compiled sample. Minor source modifications defeat them. The behavioral chain is undetected by static means and survives recompilation without additional changes.

There is no patch. The PoC is public. Hash-based and signature-based detection of the compiled binary has the same limitation it always does in this cluster: it is accurate until someone recompiles, which is trivial.

---

8. What Defenders Should Actually Do

No patch exists. Detection has to be behavioral. The following signals are organized from most reliable to most environment-dependent.

High-Confidence PoC-Specific Signals

These accurately detect the published PoC and are trivially defeated by anyone adapting the technique. Worth running now; do not treat them as durable detections.

• Named pipe \\.\pipe\SHIELDBREAK created by a non-SYSTEM process
• Cloud sync root registration with provider name "Flubber" or GUID {B196E670-59C7-4D41-9637-C62D80541321}
• Working directory at the root of C: matching C:\ShieldBreak_<GUID> with hidden attribute and an Everyone SID full-control ACL. Root-of-C directories with Everyone full-control ACLs have essentially no legitimate equivalent.
• Placeholder file named BERLIN inside a Cloud Files sync root

Technique-Level Behavioral Signals (survive recompilation)

• phoneinfo.dll appearing in C:\Windows\System32\. This file does not ship with any supported Windows version. Its presence is confirmed compromise. Alert on file creation events at this path and do not wait for execution.
• CfRegisterSyncRoot called by processes outside of known cloud sync software (OneDrive, Dropbox, Box, iCloud). This signal appeared in BlueHammer and RedSun coverage and should already be in your stack. A sync root registered on a directory at the root of C: from an unsigned binary is high-signal.
• Object Manager symbolic links or directories created under \BaseNamedObjects\Restricted by user-mode processes. The WD_TARGET_ and WD_SHADOW_ naming pattern is PoC-specific; any symlink creation in this namespace from non-system processes is uncommon. Baseline against your environment before alerting.
• MpClient.dll loaded by processes outside the Defender service tree. ShieldBreak, RoguePlanet, RedSun, and BlueHammer all load this library at runtime and call its exports directly. Any process loading it that is not MsMpEng.exe, MpCmdRun.exe, or another Defender component should be flagged. Applies across the entire NightmareEclipse cluster.
• WER report directories or Report.wer files written under C:\ProgramData\Microsoft\Windows\WER\ReportQueue\ by non-WER processes. Standard users can write to this path. A user-mode process writing a Report.wer directly is a strong signal.
• QueueReporting scheduled task triggered via Task Scheduler COM from a non-SYSTEM, non-WER process.

Composite Signal (Highest Confidence)

No legitimate software performs this combination: Cloud Filter sync root registration + Object Manager namespace activity + MpClient.dll load + WER ReportQueue write + QueueReporting task trigger. Any two or more of these from the same process tree within a short window should generate a high-severity alert. The composite signal survives recompilation and actor adaptation in a way individual indicators do not.

---

9. MITRE ATT&CK Mapping

Technique ID	Technique Name	How ShieldBreak Uses It
T1068	Exploitation for Privilege Escalation	Core exploit: standard user to NT AUTHORITY\SYSTEM through Defender's remediation pipeline, no kernel bug required
T1574.010	Hijack Execution Flow: Services File Permissions Weakness	Warden.dll delivered to System32 via Defender's SYSTEM-token write, then loaded by WER task
T1053.005	Scheduled Task/Job: Scheduled Task	WER QueueReporting (SYSTEM) triggered via Task Scheduler COM by unprivileged user
T1055	Process Injection	Warden.dll executes as SYSTEM, connects back to orchestrator via named pipe
T1036.005	Masquerading: Match Legitimate Name or Location	Payload delivered to C:\Windows\System32\phoneinfo.dll via UNC loopback redirect
T1480	Execution Guardrails	Pre-check for phoneinfo.dll existence gates execution; priority-class scheduling enforces reliable timing
T1187	Forced Authentication	UNC loopback path (127.0.0.1\C$) routes payload delivery through SMB loopback
T1562.001	Impair Defenses: Disable or Modify Tools	Defender's own remediation pipeline is the delivery mechanism; no external injection needed

---

10. IOC Reference

Indicator	Type	Notes
\\.\pipe\SHIELDBREAK	Named Pipe	PoC-specific; rename defeats this indicator
C:\ShieldBreak_<GUID> at root of C:, hidden, Everyone SID full control	File Path Pattern	Unusual ACL at root of C: is the durable signal component
Cloud sync provider "Flubber", GUID {B196E670-59C7-4D41-9637-C62D80541321}	Registry/CfApi	PoC-specific; trivially changed
Placeholder file BERLIN inside Cloud Files sync root	File	PoC-specific
C:\Windows\System32\phoneinfo.dll	File	Does not exist in any legitimate Windows install. Confirmed IOC. Alert on creation.
Exploit:Win32/NghtMrShldBrk.BB	Defender Signature	Compiled sample only; does not survive recompilation
Trojan:Win32/Bearfoos.B!ml	Defender Signature	Compiled sample only
hxxps[://]github[.]com/MSNightmare/ShieldBreak	PoC URL	Defanged
git.projectnightcrawler[.]dev/NightmareEclipse	Mirror	Defanged
git.churchofmalware[.]org/Nightmare_Eclipse	Mirror	Defanged
deadeclipse666[.]blogspot[.]com	Researcher Blog	PGP-signed posts; tracks new releases

File hashes (Warden.dll):

Algorithm	Hash
MD5	ff5b18a59cc71ea4274239463bf1d9d2
SHA-1	c60b42ce019d8e727e08e75690128f28583d8900
SHA-256	691857f3f28049a7e33f5767d4e4eb3d739e1aa76c2a43c8cccadf871cfa7c1a
SHA3-256	96167fa28329360740d5cd0c72ef57090045a4e7079b404223e80c2d08b192f9

These hashes identify the specific compiled release. A recompile changes all of them. Treat as a record of what was observed, not a durable detection control.

---

11. The Bigger Picture

Ten tools in nineteen weeks. The pace alone is notable. But the more significant development with ShieldBreak is the feedback loop it establishes: Microsoft patches an exploit from this cluster, and within roughly a month, the researcher delivers a full bypass of that specific patch at higher reliability than the original. That is not coincidental timing. It is a deliberate, calibrated response.

The architectural consistency is intentional. All ten tools target the intersection of Microsoft Defender, Windows namespace and filesystem behavior, scheduled task infrastructure, and Windows security internals. This is not breadth — it is depth. The researcher has mapped a family of related design assumptions in a specific attack surface and is working through them methodically.

Each patch informs the next exploit. The April 2026 fix for BlueHammer did not end the campaign — it told the researcher what Microsoft had visibility into. The mid-May Defender engine update that broke RoguePlanet's original remote code execution path resulted in three weeks of rebuilding on a different primitive. ShieldBreak is the same dynamic applied to a shipped patch rather than an engine update.

Public release is not an accident. Every tool in this cluster dropped without coordinated disclosure. Three of them appeared in real-world attack chains within weeks of release. When a working LPE PoC goes public, the question is not whether it will be used by attackers — it is how quickly.

The patch gap is the actual problem. Closing individual expressions of the vulnerability while leaving the underlying architectural gap accessible gives the researcher raw material for the next release. ShieldBreak is the second demonstration of that dynamic; it will likely not be the last.

Behavioral detection against the TTPs described above is the primary and only reliable defensive control until a root-cause patch addressing the Object Manager redirect path and the CfApi restart hydration primitive is available.

---

12. References

• Primary Technical Analysis: Reegun Jayapaul and Rahul Ramesh, Cyderes Howler Cell — "ShieldBreak: The Windows Zero-Day That Breaks Microsoft's Own RoguePlanet Fix," August 12, 2026.
• Cyderes Howler Cell — RoguePlanet (CVE-2026-50656)
• Cyderes Howler Cell — LegacyHive
• Cyderes Howler Cell — GreatXML
• Cyderes Howler Cell — RedSun (CVE-2026-41091)
• Cyderes Howler Cell — BlueHammer (CVE-2026-33825)
• PoC repository (defanged): hxxps[://]github[.]com/MSNightmare/ShieldBreak

---

Tags: Windows Zero-Day, Privilege Escalation, Microsoft Defender, LPE, Cloud Filter API, NT Object Manager, CLFS, WER Scheduled Task, Nightmare-Eclipse, MSNightmare, ShieldBreak, CVE-2026-50656, Patch Bypass, Windows 11, Vulnerability Research, Zero-Day Exploit, Defender Remediation, Threat Intelligence

Status of api.ipify.org — Part 2: 2026 Verdict Update

Hunt. Analyze. Respond. Repeat. ∞

Edison NewWorld — Real samples. Raw analysis. No vendor spin.

THREAT//INTEL Verdict Update IOC Retrospective Part 2 of 2

Malware Analysis · Nine Years Later

Status of api.ipify.org — Part 2
Did the 2026 Verdict Change?

In 2017 I called api.ipify.org clean but abused. Nine years, a Suricata rule, a Splunk detection, a wave of sandbox verdicts, and one GitHub Actions false-alarm later — I went back and checked whether that verdict still holds.

newWorld · Follow-up to the August 2017 original · 2026 Update

Verdict: Still Not Malicious — Confidence Increased

01 / Recap: The 2017 Call

Clean Service, Abused Purpose

Back in August 2017 I wrote a post asking a simple question: is api.ipify.org malicious or not. The answer then was straightforward. api.ipify.org is a legitimate public IP lookup API. It kept showing up in malware traffic, so I dug into VirusTotal, cross-checked the URLs and files calling it, and concluded the domain itself was clean — malware was abusing a benign service, not the other way around.

That article kept climbing in views for years. Enough that it deserves a real follow-up instead of one verdict left standing untested forever. So I pulled fresh data — sandbox reports, detection rulesets, vendor research, and one live incident — and checked whether 2026 tells a different story.

Original 2017 Finding

api.ipify.org never hosted malware, never served payloads. Samples called it for exactly one reason: to fetch the infected machine's public IP address. The service was innocent; the traffic pattern around it was the tell.

02 / Nine Years, Five Data Points

What Actually Changed Since 2017

The core fact hasn't moved. What changed is how much better documented, and how much more institutionalized, the abuse pattern has become.

01

A named detection rule now exists

Proofpoint's Emerging Threats ruleset carries ET POLICY External IP Lookup api.ipify.org, categorized as "Device Retrieving External IP Address Detected." Pure policy signature — fires on the pattern, not on maliciousness.

02

Splunk built SIEM content around it

A Cisco NVM-based detection watches api.ipify.org alongside ipinfo.io, icanhazip.com, checkip.amazonaws.com and others — explicitly described as recurring in post-exploitation frameworks, stealer malware, and advanced threat actor campaigns.

03

Sandboxes now tag it directly

ANY.RUN reports on api.ipify.org connections come back tagged evasion, verdict "Malicious activity" — a behavioral read, not an infrastructure one, but it lands as a red flag on the dashboard regardless.

04

The scale is now quantified

SANS research (analyst Jay Yanza, via IronNet) found api.ipify.org used as a third-party IP lookup in 205 of 7,747 unique malicious file hashes examined — with other lookup services combined exceeding 2,000 hits.

05

Even trusted infrastructure trips the alarm

In November 2024, StepSecurity's Harden-Runner flagged a wave of GitHub Actions runners across multiple customers calling api.ipify.org with no prior baseline. Traced back to GitHub's own infrastructure — benign, but a live demonstration of why the policy rule exists.

03 / A Legitimate Extension, An Undocumented Call

The Chrome Extension Case

IronNet's writeup includes a good illustration of why this domain keeps landing on watchlists even when nothing is wrong. Researchers traced an undocumented outbound connection in a PCAP back to a completely legitimate, widely-used Chrome extension quietly calling api.ipify.org. The vendor's own engineering team had to be looped in to confirm it was expected behavior — they didn't know either.

"External IP lookups, while not inherently bad, can be indications of anomalous or even malicious activity. Organizations should be aware of network behavior and permissions — both expected and unexpected." — IronNet, Investigating Undocumented Netcomms From a Legitimate Chrome Extension

That's the same conclusion the 2017 post reached, just with a better citation trail behind it now.

04 / Why Malware Keeps Calling It

The Motive Hasn't Changed — Just the Documentation

Three consistent reasons show up across the research for why malware families keep reaching out to services like this one:

• Sandbox and geofencing checks — comparing the returned public IP against known cloud/sandbox ranges, or against a target region, before deciding whether to detonate.
• C2 confirmation and beaconing — using the external IP as part of victim fingerprinting, or confirming live internet egress before continuing.
• Evasion of network-based attribution — detecting NAT, VPN, or proxy layers that need to be worked around.

None of it requires the API to do anything malicious. It just has to return an IP address reliably — which is exactly what it was built to do.

---

05 / Updated Verdict

So — Is It Malicious in 2026?

No. Same answer as 2017.

VirusTotal's community detections on the domain remain clean. OTX and other threat intel platforms list it as an observed indicator inside campaigns, not as malicious infrastructure in its own right. Functionally it's still exactly what it says on the tin — a single-purpose IP address API, no authentication, no payload delivery, no history of hosting anything harmful.

Assessment

What changed is confidence, not conclusion. In 2017 this took manual VirusTotal digging to establish. In 2026 it's baked into commercial detection rulesets and sandbox verdicts as a matter of course. The service is still innocent; the surrounding tooling has simply caught up to what was already true.

Signal Source	Verdict on api.ipify.org itself	Status
VirusTotal community detections	No malicious infrastructure flags	CLEAN
OTX / threat intel platforms	Listed as observed IOC in campaigns	CONTEXTUAL
ANY.RUN sandbox tagging	Behavioral "evasion" tag on connection pattern	BEHAVIORAL
ET POLICY / Suricata	Policy signature, not malicious signature	MONITORED
Splunk / Cisco NVM content	Named in stealer & post-exploitation detection logic	MONITORED

06 / Recommendations

For Defenders Running These Rules Today

1. Don't blocklist the domain outright. Legitimate software, browser extensions, and CI/CD infrastructure all use it — you'll break things that have nothing to do with an incident.
2. Treat unexpected calls as worth a second look. An undocumented request to any IP-lookup service from a non-browser process — especially one with no reason to check its own public IP — deserves triage.
3. Use it as telemetry, not a verdict. A hit on this domain alone is not proof of infection. It's one data point in a chain that should include the calling process, its parent, and what happens right after the IP comes back.
4. Start from the existing rulesets. Pull the ET POLICY signature and the Cisco NVM/Splunk detection logic referenced above as a baseline, then tune the exclusion list to your own known-good processes.

Operational Risk

The November 2024 GitHub Actions incident is the cautionary example here: a completely benign explanation still needed a full investigation before anyone could rule out compromise. Treat every hit with the same discipline, regardless of how likely it is to be nothing.

07 / Conclusion

Nine years on, the mist from the original title is still the same mist: the service was never the problem. It's what gets built on top of it that matters.

That part hasn't changed, and honestly, I don't expect it to.

Part 1 of this series: Status of api.ipify.org - is it malicious or non malicious? (2017)

Sources referenced: Proofpoint Emerging Threats ruleset · Splunk Security Content (Cisco NVM detection) · ANY.RUN sandbox reports · IronNet, "Investigating Undocumented Netcomms From Legitimate Chrome Extension" (2023) · StepSecurity, "Harden-Runner Detects Anomalous Traffic to api.ipify.org" (Nov 2024) · SANS research via Jay Yanza

THREAT//INTEL · Verdict Update Edison NewWorld — Hunt. Analyze. Respond. Repeat. ∞

fast16 & The MARINTEK False Positive | Threat Intelligence

THREAT//INTEL APT Analysis Reverse Engineering False Positive Watch

Threat Intelligence · June 2026

The fast16 Mystery
and the MARINTEK False Positive

A 2005 state-grade sabotage framework predates Stuxnet by five years — and its YARA signatures are now flagging legitimate Norwegian marine engineering software. Researcher Snorre Fagerland explains why.

Snorre Fagerland · LinkedIn Research Note Based on SentinelLABS findings by Vitaly Kamluk & JAGS June 22, 2026

---

01 / Background: What Is fast16?

In April 2026, SentinelLABS researchers Vitaly Kamluk and Juan Andrés Guerrero-Saade published a landmark analysis of a previously undocumented cyber sabotage framework they named fast16. Dating to 2005, it predates Stuxnet by at least five years and stands as the earliest known example of state-grade software designed to silently corrupt physical-world calculations.

Key Finding

The name fast16 appears in the Shadow Brokers' 2017 leak of NSA's "Territorial Dispute" deconfliction signatures, with an unusual operator note: "fast16 *** Nothing to see here – carry on ***"

The framework consists of two core components. svcmgmt.exe is a Lua-powered wormable carrier, compiled August 2005, that spreads itself across network shares and installs the payload. fast16.sys is a kernel-mode filesystem driver that intercepts executable reads and patches code in memory in real time — corrupting high-precision floating-point calculations without ever touching the file on disk.

JUNE – AUGUST 2005

fast16.sys and svcmgmt.exe compiled. Kernel driver and Lua-powered carrier built with Intel compiler. SCCS/RCS markers suggest Unix-era developers.

~2010

Stuxnet discovered. Previously considered the first ICS sabotage operation. fast16 predates it by five years.

APRIL 2017

Shadow Brokers leak includes drv_list.txt with a fast16 entry and the "Nothing to see here" deconfliction note.

APRIL 23, 2026

SentinelLABS publishes full analysis. Three patch target candidates identified: LS-DYNA 970, PKPM, and MOHID.

JUNE 2026

Snorre Fagerland flags a fourth YARA hit — MARINTEK A/S's marine performance analysis DLL — and raises the question: real target or false positive?

02 / How the Sabotage Works

The genius — and the danger — of fast16 is that it never modifies a file on disk. The kernel driver inserts itself above every active filesystem device (NTFS, FAT, network shares) and intercepts read operations. When a qualifying executable is loaded into memory, the driver applies a rule-driven patch engine containing 101 patterns before the code ever reaches the CPU.

Target Selection: Intel Compiler Fingerprinting

A file qualifies for patching only if two conditions are met: the filename ends in .EXE, and immediately after the last PE section header there is a printable ASCII string beginning with Intel. This is a compiler metadata artifact left by the Intel C/C++ compiler — the same toolchain used by LS-DYNA, PKPM, and MOHID. It is a remarkably precise targeting mechanism for 2005.

The Floating-Point Corruption Block

Most of the 101 patch rules deal with code flow manipulation — standard injection technique. But one injected block stands apart: a large sequence of x87 FPU instructions that scales values in internal numeric arrays. Without knowing the exact target binary, the precise effect cannot be determined. But the intent is unambiguous: to produce subtly wrong numerical results in physical-world simulations.

Sabotage Vector

Because the wormable carrier deploys the same driver to every reachable network host, an independent verification run on another machine on the same network would produce the same corrupted output — eliminating the most obvious cross-check.

03 / The Three Confirmed Target Candidates

SentinelLABS ran the patching engine's byte patterns as YARA rules against large, era-appropriate software corpora. Only a handful of files matched two or more patterns — and they clustered into three distinct suites:

Software	Domain	Significance	Status
LS-DYNA 970	Structural / crash simulation	Cited in IAEA reporting on Iran's AMAD nuclear weapons program — used to model explosive lens implosion dynamics	High Confidence
PKPM Suite	Chinese civil engineering CAD	Dominant structural design platform across China; SATWE engine handles full tridimensional analysis	High Confidence
MOHID	Marine hydrodynamics	Portuguese open-source water modeling; used for coastal, oil spill, and sediment transport simulations	Needs More Research

The combination of LS-DYNA and PKPM as targets carries significant geopolitical weight. LS-DYNA's documented role in Iran's suspected nuclear warhead design work — specifically for simulating the precisely shaped conventional explosive lenses required for an implosion-type device — places fast16 squarely in the domain of counter-proliferation operations.

04 / Enter Snorre Fagerland: A Possible Fourth Hit

Norwegian malware analyst and reverse engineer Snorre Fagerland — known for deep work on ICS/SCADA threats and targeted attack research — posted a notable observation on LinkedIn following the SentinelLABS publication. He had run the clean_fast16_patchtarget YARA rule against a DLL from the files of MARINTEK A/S, the Norwegian Marine Technology Research Institute (now part of SINTEF Ocean, Trondheim).

Filename MTRepGenDLL.dll
Description MARINTEK Report Generator DLL
Product Dynamic Link Library for Analysis of Performance Tests
Copyright © MARINTEK A/S
Version 2, 0, 21, 0
SHA-256 abb70fd400f4ab9fe27e8a1b3aa937db8fb88aea59c9ebc8ce645cd59f0cc2f2

The YARA rule fired. Two patterns matched inside the function _TIMESERIES_ANALYSIS_JNI_mp_TIMESERIES_ANALYSIS. One of those matching patterns is rule $el36:

$el36 = { 75 18 8D 35 ?? ?? ?? ?? 56 8D 3D }

This is the exact byte sequence visible in Fagerland's IDA Pro screenshot, highlighted in orange — a push [ebp+OMEGA] / lea esi, WMAX_RSP sequence in the middle of a dense signal processing argument-setup block.

"I have no idea whether this is a real hit or a false positive. The byte strings that are used by Fast16 to decide whether the file is of interest are... not hugely accurate. As an old signature pro I think FPs are possible."

— Snorre Fagerland, LinkedIn

05 / False Positive Analysis

Why the Match Is Structurally Weak

The clean_fast16_patchtarget YARA rule requires any 2 of ~45 patterns to fire — a deliberately low threshold chosen to maximize research coverage rather than detection precision. Rule $el36, the matching pattern in question, is only 10 bytes long with wildcard bytes at positions 4–7. In 32-bit x86 calling convention code, the sequence lea reg, [var] / push reg repeating across multiple arguments is extremely common in any compiled C code that passes multiple pointer arguments to a function.

What the IDA Screenshot Shows

The surrounding context in Fagerland's IDA view is unambiguous scientific computing: operands named WMAX_RSP, WMIN_RSP, OMEGA, TZERO, RESPONSE, DT, NBR_SAMPLES, NSTEPS, NWSP, N_FFT_SEQ — textbook time-series spectral analysis parameters. The function calls _TS_ANALYSIS_mp_TS_SPEC and is followed by fdiv, fld, fstp, fcomp floating-point instructions. This is consistent with marine vessel performance analysis: computing response amplitude operators, frequency-domain spectra, and fatigue loads from sea trial data.

The Intel Compiler Criterion Likely Fails

The actual fast16 kernel driver only patches executables compiled with the Intel C/C++ compiler, checked by reading compiler metadata embedded after the last PE section header. MTRepGenDLL.dll would need to carry that Intel compiler signature to be targeted at runtime. This is a separate and harder condition than the YARA byte match — it acts as a natural pre-filter the driver applies before any pattern matching begins.

Criterion	MARINTEK DLL	Verdict
YARA pattern match (2+ rules)	Yes — $el36 + one other	Inconclusive
Intel compiler metadata after last PE section	Unknown / likely absent	Probably FP
Matching pattern length & specificity	10 bytes with wildcards — very short	Probably FP
Code context (surrounding disassembly)	Pure DSP / signal processing math	Probably FP
Geopolitical/sector fit	Norwegian marine research — no proliferation nexus	Probably FP
Import table anomalies	Not reported; none visible	Probably FP

Assessment

This is almost certainly a false positive. The YARA rule was designed for broad community research hunting, not operational detection. The MARINTEK DLL matches on short, common x86 patterns that appear naturally in any 32-bit scientific computing DLL from the 2000s era.

06 / Why the Norwegian Context Matters

Snorre Fagerland's nationality is not incidental here. MARINTEK A/S is a well-known Norwegian institution — its Trondheim-based marine technology labs have been central to North Sea offshore engineering and ship performance research for decades. A Norwegian analyst immediately recognizes this as a domestic research organization with no plausible connection to the geopolitical targets fast16 appears to have been aimed at.

This local knowledge is precisely what gives Fagerland's observation weight. A non-Norwegian analyst scanning the same YARA hit might have flagged it as suspicious without the institutional context to dismiss it confidently. His post is a responsible, community-minded act of signature quality control — the kind of signal the research community needs to tune detection rules before they cause incident responders to chase phantoms.

Operational Risk

Any organization in offshore engineering, naval architecture, or coastal simulation that uses similar 32-bit scientific DLLs compiled in the 2000–2015 era may see false positives from the clean_fast16_patchtarget rule. This is especially relevant in OT/ICS environments where alert fatigue or incorrect attribution could have real operational consequences.

07 / Recommendations for Defenders

If you are running the SentinelLABS fast16 YARA rules in your environment, consider the following before acting on a hit from clean_fast16_patchtarget:

Step 1 — Check the Intel Compiler Marker

Parse the PE file. After the last section header (IMAGE_SECTION_HEADER array), check for a printable ASCII string beginning with Intel. If absent, the file would not have been targeted by the actual fast16 driver at runtime — strong evidence of a false positive.

Step 2 — Examine the Import Table

Legitimate scientific DLLs import math, memory, and OS APIs. Suspicious imports for a calculation DLL include network functions (WSAConnect, InternetOpen), process injection APIs (VirtualAllocEx, WriteProcessMemory), or crypto primitives outside expected contexts.

Step 3 — Disassemble the Matching Region

Open the file in IDA Pro or Ghidra. Navigate to the matching byte pattern. If the surrounding code is dense floating-point math with named scientific operands — spectral analysis, fluid dynamics, structural loads — that is a false positive signature, not malware.

Step 4 — Check Section Entropy

Packed or encrypted sections have high entropy (>7.0). A legitimate engineering DLL should have normal section entropy. High entropy in a code section warrants deeper investigation regardless of the YARA result.

Step 5 — Apply Geopolitical Context

fast16's confirmed and suspected targets are all directly relevant to nuclear weapons development or Chinese civil infrastructure. A Norwegian marine performance DLL, a Dutch offshore simulation suite, or an academic fluid dynamics package have no plausible place in that target set.

08 / Conclusion

fast16 is a genuinely remarkable piece of history — a 2005 state-grade sabotage framework whose kernel-level floating-point corruption predates every well-known ICS attack. Its discovery forces a re-evaluation of when sophisticated cyber sabotage became operational, and its appearance in the Shadow Brokers leak raises questions about provenance and use that the research community is still working through.

Snorre Fagerland's observation about MARINTEK's MTRepGenDLL.dll is a necessary counterweight to that excitement. Good threat intelligence is not just about finding new malware — it is about ensuring the signatures and rules that follow do not create noise that degrades incident response. The clean_fast16_patchtarget rule, by design, casts a wide net. Analysts acting on its results need to apply the full chain of analysis before drawing conclusions.

In this case, the weight of evidence is clear: the MARINTEK hit is a false positive, produced by short, common x86 patterns in legitimate engineering code. The real targets of fast16 remain those identified by SentinelLABS — and understanding exactly what was being sabotaged, and where, is the research question that still deserves the community's attention.

Reference

Kamluk, V. & Guerrero-Saade, J.A. (2026). fast16 | Mystery Shadow Brokers Reference Reveals High-Precision Software Sabotage 5 Years Before Stuxnet. SentinelLABS. April 23, 2026.

THREAT//INTEL · Analysis based on public SentinelLABS research & Snorre Fagerland's LinkedIn observation June 22, 2026