FILEPublic
FILE

FUZZBUNCH Toolkit Bundles EternalBlue and DarkPulsar in Single APT40 Package

A 19-file FUZZBUNCH/ShadowBrokers toolkit attributed to APT40 pairs the EternalBlue SMB exploit with fragmented DarkPulsar kernel backdoor components, Tor-routed C2, and anti-debugging measures across 11 of 19 samples. The toolkit's modular architecture — spanning components built across five years of development — delivers exploitation and persistent access in a single deployable package. A 2019 repackaging of the bundle, disguised as a Windows diagnostics file, confirms active operational use two years after the original ShadowBrokers public release.

Jun 1, 2026, 01:53 (UTC+9)Last seenJun 1, 2026Severity61ByCTX TeamActorAPT40MudcarpIOC19

EternalBlue and DarkPulsar, Bundled Together: Inside the FUZZBUNCH Toolkit's Modular Kill Chain

Nineteen files. One deployable directory tree. A complete offensive capability spanning SMB exploitation, kernel-level persistence, Tor-routed command-and-control, and a Python orchestration layer — all assembled from components whose PE compile timestamps span more than a decade of development. The FUZZBUNCH/ShadowBrokers toolkit now attributed in CTX Team's tracking to APT40, with healthcare flagged as the targeted sector, is not a collection of loosely related tools. It is an engineered system, and the engineering choices embedded in its architecture — particularly the deliberate fragmentation of DarkPulsar kernel backdoor code across four separate DLLs — tell a more operationally significant story than any single binary in the set.

The pairing of EternalBlue (MS17-010) with persistent DarkPulsar kernel implant components inside a single FUZZBUNCH directory tree is the central analytical signal: exploitation and long-term access are bundled together, not staged separately. An operator deploying this toolkit does not need to return to deliver a persistence payload after gaining a foothold — the foothold and the persistence mechanism arrive in the same package.

The EternalBlue Launcher: Highest-Detected File, Richest Rule Coverage

The entry point into the kill chain is eternalblue-2.2.0.exe (SHA-256: 85b936960fbe5100c170b777e1647ce9f0f01e3ab9742dfc23f37cb0825b30b5), the sole Win32 EXE in the set and the highest-detected file in the catalog at 67 of 76 engines. Its meaningful name — recorded across multiple submission paths as FUZZBUNCH-1-master/specials/Eternalblue-2.2.0.exe — places it unambiguously within the FUZZBUNCH framework directory tree. Sandbox Zenbox names the family ETERNALBLUE with confidence 56, and four of six sandbox environments return a malicious verdict.

The YARA rule INDICATOR_TOOL_EXP_EternalBlue, authored by ditekSHen and sourced from the public detection repository at github.com/ditekshen/detection, fires twice on this binary — a double hit that reflects the presence of multiple distinct EternalBlue exploitation artifacts within the same executable [T1190]. The IDS rule MALWARE-CNC DNS Fast Flux attempt fires during execution, a Snort registered-user ruleset signature rated high severity, indicating that the exploit phase also initiates network reconnaissance activity consistent with lateral movement preparation [T1018].

The binary carries the detect-debug-environment, long-sleeps, checks-disk-space, and spreader tags — a combination that signals deliberate anti-analysis engineering. The IDS rule ET INFO EXE IsDebuggerPresent (Used in Malware Anti-Debugging) fires on this sample, confirming the presence of IsDebuggerPresent API calls [T1027]. Its PE compile timestamp reads 2013-05-28, placing it in a third distinct build era from the 2008-era PEiD-packed DLLs and the 2012-02-28-timestamped DarkPulsar components discussed below — a detail that underscores the toolkit's multi-generational assembly.

The .text section entropy for the EternalBlue launcher sits at 6.6, consistent with compiled code rather than heavy packing, and the binary carries an imphash of 43ab0829235f0f3299a0baee637645e2. Five engines that might be expected to flag this binary — APEX, Acronis, Avast-Mobile, Trapmine, and tehtris — are still missing from the detection set, a gap that matters operationally in environments where endpoint coverage is uneven.

DarkPulsar Fragmented Across Four DLLs: The win_darkpulsar_auto Cohort

The persistence layer of the toolkit is where the architectural sophistication becomes most visible. Four DLLs from the FUZZBUNCH library tree — cnli-1.dll (SHA-256: db0831e19a4e3a736ea7498dadc2d6702342f75fd8f7fbae1894ee2e9738c2b4), ucl.dll (f0df80978b3a563077def7ba919e2f49e5883d24176e6b3371a8eef1efe2b06a), posh-0.dll (cde45f7ff05f52b7215e4b0ea1f2f42ad9b42031e16a3be9772aa09e014bacdb), and exma-1.dll (15292172a83f2e7f07114693ab92753ed32311dfba7d54fe36cc7229136874d9) — all match the Malpedia-sourced YARA rule win_darkpulsar_auto, authored by Felix Bilstein via the yara-signator project at malpedia.caad.fkie.fraunhofer.de [T1547].

This is not incidental overlap. The cohort analysis confirms that DarkPulsar kernel backdoor code is deliberately distributed across multiple modular components rather than consolidated into a single binary. Each of the four DLLs carries a distinct imphash — a482b407319dc74133dc3d7a0212f626 for cnli-1.dll, 33ac1cb1711de5488c50eafd916d2ad2 for ucl.dll, 3238dd5467a491407079286b75fed933 for posh-0.dll, and 38335bfed05954b26590a75c4458da60 for exma-1.dll — meaning no two components share an import-table fingerprint. A signature-based detection workflow that catches one component will not automatically surface the others.

The build provenance of the DarkPulsar quartet points to a common compilation environment: all four carry PE timestamps of 2012-02-28, a date that distinguishes them from both the 2008-era PEiD-packed DLLs and the 2013-era EternalBlue launcher. The .text section entropy for cnli-1.dll reads 6.54, and for ucl.dll 6.71 — both consistent with compiled, moderately complex code. The sandbox picture for these components is mixed: cnli-1.dll draws 2 of 5 malicious verdicts (NSFOCUS POMA and Lastline both flag it as a trojan), while ucl.dll draws 1 of 4. The detection ratios cluster between 55 and 63 of 77 engines — strong community consensus, but with a persistent tail of engines that miss each component individually.

Two of the four DarkPulsar DLLs — cnli-1.dll and exma-1.dll — also trigger the Snort registered-user IDS rule TAG_LOG_PKT, a network-level signature that co-fires exclusively on this pair within the toolkit. The analyst cohort significance entry for this IDS rule binding notes that these two components generate distinctive packet-level traffic patterns during implant operation. The implication is that even without known C2 IP addresses, network perimeter sensors running the Snort registered-user ruleset may be able to detect DarkPulsar implant activity through traffic pattern anomalies rather than endpoint indicators alone.

The cnli-1.dll dossier narrative states directly: "Named rules: 1 YARA rule hits (e.g. win_darkpulsar_auto); 1 IDS rule hits (e.g. TAG_LOG_PKT)" — a dual-layer detection signal that links the kernel backdoor code to observable network behavior.

Two Build Pipelines, One Toolkit: The PEiD Packer Cohort and Timestamp Archaeology

Separate from the 2012-era DarkPulsar quartet, five DLLs in the toolkit share a PEiD packer signature and carry PE compile timestamps clustered on 2008-09-18 and 2008-09-19: adfw.dll (c51bce247bee4a6f4cd2d7d45483b5b1d9b53f8cc0e04fb4f4221283e356959d), posh.dll (47e16f7db53d9adf24d193ff4d523b1bc7ae59ff8520cfa012365bdb947c96f9), riar.dll (55039ab48c0916a38f1ceee08ba9f9cf5f292064cf3ee6631f22becde5e74b2d), exma.dll (c977ac10aa3d2250a1af39630f532184a5185f505bcd5f03ea7083a3a701a969), and trch.dll (06c031f0d905cdeb0d9c172c27ae0c2d25bbf0d08db27a4aa98ec540a15306e7).

The PEiD packer cohort represents a distinct older build pipeline. The dossier for adfw.dll records: "Build provenance: packed (PEiD); imphash 715742f34145…" — and the same packer annotation appears across all five members. Their PE section entropy values are notably lower than the DarkPulsar quartet: adfw.dll's .text section reads 5.98, posh.dll's reads 6.09, and exma.dll's reads 5.75. The packing adds an obfuscation layer without dramatically elevating entropy, suggesting a packer configuration tuned for stealth rather than compression.

The coexistence of 2008-era PEiD-packed components alongside 2012-era DarkPulsar DLLs and a 2013-era EternalBlue launcher in a single deployable package is itself an operational signal. The toolkit was not built in a single development sprint — it was assembled from components produced across at least five years of tooling development, then integrated into the FUZZBUNCH framework. This multi-era assembly pattern is consistent with a mature development organization that maintains and updates a modular offensive toolkit over time rather than rebuilding from scratch for each campaign.

The five PEiD-packed DLLs range in size from 6 KB (posh.dll and exma.dll) to 48 KB (trch.dll), all unsigned. Detection ratios for this cohort cluster between 59 and 60 of 77 engines — slightly below the DarkPulsar quartet, which is consistent with the additional obfuscation layer the packer provides. The detect-debug-environment tag appears on four of the five, and spreader tags appear on posh.dll and exma.dll, indicating that even the older 2008-era components carry active lateral movement capability [T1570].

The C2 Architecture: Tor Routing, OpenSSL Encryption, and Base64 Obfuscation

The command-and-control design of the toolkit is layered across three components that form a coherent anonymization stack. riar.dll (55039ab48c0916a38f1ceee08ba9f9cf5f292064cf3ee6631f22becde5e74b2d) carries the via-tor tag — the only file in the set so tagged — indicating this component is designed to route traffic through the Tor anonymization network [T1090.003]. It is also a member of the PEiD packer cohort, with a PE timestamp of 2008-09-19, placing its build origin in the same 2008-era pipeline as adfw.dll and posh.dll.

The cryptographic layer is provided by libeay32.dll (5f30aa2fe338191b972705412b8043b0a134cdb287d754771fc225f2309e82ee), the largest file in the DLL set at 882 KB. Its signing metadata identifies it as version 0.9.8r of The OpenSSL Toolkit — a 2012-era build of OpenSSL embedded directly within the FUZZBUNCH library tree at FUZZBUNCH-1-master/lib/x86-Windows/libeay32.dll. The .text section of libeay32.dll registers entropy at 6.72, and the .reloc section at 6.44 — elevated values consistent with the dense, optimized code characteristic of a cryptographic library.

Both libeay32.dll and the transport component trfo-0.dll (a4c460b27d03daf7828f6b6db87e0ff3ee851fdb1b8654b0a778b4c34953a3dc) match the YARA rule susp_b64_enc, authored by RussianPanda and sourced from github.com/RussianPanda95/Malware-Rules-IOCs. The cohort significance entry for this binding notes that base64 encoding appears at the cryptographic and transport layer, suggesting configuration data or beacon content is obfuscated at rest within these components [T1027]. The trfo-0.dll dossier records: "Named rules: 1 YARA rule hits (e.g. susp_b64_enc)" — and the same rule fires on libeay32.dll, binding the two components into a detectable pair.

The practical consequence of this C2 architecture is that traditional IP-based blocking is insufficient against an implant that routes through Tor. Current evidence is too thin to confirm the actual C2 endpoints, but the Tor-routing capability embedded in riar.dll means that endpoint-level detection of the DarkPulsar implant components, rather than network-perimeter blocking of C2 addresses, is the operative detection surface. The susp_b64_enc YARA rule provides a host-level signature that fires on both the cryptographic and transport components simultaneously, offering a detection opportunity that does not depend on C2 IP knowledge.

The trfo-0.dll carries a PE timestamp of 2009-02-18, placing it between the 2008-era PEiD cohort and the 2012-era DarkPulsar quartet — another data point in the multi-era assembly picture. Its detection ratio of 56 of 76 engines is the lowest among the PE32 DLLs in the set, with APEX, Acronis, Avast-Mobile, Bkav, ClamAV, and SentinelOne among the engines still missing.

The FUZZBUNCH Python Controller and the Repackaged ZIP: Two Outliers That Define the Operational Envelope

Two files in the set stand apart from the PE32 DLL cluster and together define the operational envelope of the toolkit's deployment lifecycle.

The Python controller pytrch.py (45b3b5442fd6e7fa9c2d8591710b231a260d8fae75e7d3748b83c7d5aa507355) is the only script in the set and the weakest-evidenced sample by detection metrics: 35 of 76 engines flag it, and its single sandbox run — Zenbox — returns a clean verdict with confidence 99. Its meaningful name is YANGBEN/pytrch.py, and its alt names span both FUZZBUNCH-1-master/lib/x64-Windows/pytrch.py and FUZZBUNCH-1-master/lib/x86-Windows/pytrch.py, confirming it serves as the FUZZBUNCH post-exploitation framework controller across both x86 and x64 Windows targets [T1059.006]. The threat label trojan.python/equationdrug is consistent with its role as the orchestration layer that directs DLL payload delivery after EternalBlue establishes the initial foothold.

The low detection ratio and clean sandbox verdict are not anomalies — they are expected characteristics of script-based tooling. Dynamic analysis environments that detonate PE32 executables reliably will often return inconclusive results for Python scripts that require a specific runtime context, interpreter version, or framework dependency to execute their malicious logic. The 20 engines that miss pytrch.py include APEX, AVG, Acronis, Alibaba, Avast, ClamAV, and SentinelOne — a broader miss list than any PE32 DLL in the set. It was first seen on 2017-05-08, three weeks after the 2017-04-14 batch of DLL components, suggesting it was submitted separately from the initial leak artifacts.

The second outlier is the ZIP bundle Diagnostics.zip (8e03f05ecd08cb78f37ccd92c48cd9d357c438112b85bd154e8261c19e38a56e), at 3,341 KB the largest file in the set. Its operational significance lies not in its contents — which span 47 DLLs, 2 EXEs, 1 Python script, 1 PYC, and 1 PYD file, with child timestamps ranging from 2017-04-14 to 2019-03-14 — but in its submission metadata. First seen on 2019-07-07, two full years after the individual component batch, the ZIP was submitted under the alternate name C:\Windows\NetworkDistribution\Diagnostics.txt. The .txt extension applied to a ZIP archive, staged in the NetworkDistribution directory under C:\Windows\, is a deliberate disguise: the file is masquerading as a diagnostics text file in a directory path that mimics legitimate Windows network infrastructure components.

Sandbox Zenbox names the family ETERNALBLUE for this bundle with confidence 60, and 57 of 76 engines flag it — but 19 engines still miss, including Microsoft, CrowdStrike, Cylance, and Paloalto. The 2019 first-seen date is the most operationally significant fact about this artifact: it demonstrates that the toolkit was actively repackaged and deployed at least two years after the original ShadowBrokers public release, with the disguised filename indicating deliberate staging on compromised Windows hosts rather than archival storage.

Anti-Debugging as a Design Philosophy: 11 of 19 Samples

The anti-analysis engineering embedded in this toolkit is not a feature of individual components — it is a design philosophy applied consistently across the set. The detect-debug-environment tag appears on 11 of 19 samples, spanning the EternalBlue launcher, the DarkPulsar quartet, the PEiD-packed cohort, the OpenSSL library, and the ZIP bundle. The IDS rule ET INFO EXE IsDebuggerPresent (Used in Malware Anti-Debugging), from the Proofpoint Emerging Threats Open ruleset, fires on the EternalBlue launcher during execution — confirming that IsDebuggerPresent API calls are present in the binary's execution path, not merely in its import table [T1027].

The long-sleeps tag appears on both the EternalBlue launcher and the ZIP bundle, a technique that delays malicious behavior long enough to exhaust sandbox timeout windows. The checks-disk-space tag on the EternalBlue launcher suggests environment validation — a check that can distinguish a real target host (with substantial disk usage) from a sandbox VM (often configured with minimal storage). Together, these behavioral signals paint a picture of toolkit components engineered to fail gracefully in analysis environments while executing reliably on production targets.

Five samples carry the spreader tag — the EternalBlue launcher, cnli-1.dll, pcreposix-0.dll, posh.dll, and exma.dll — indicating that lateral movement capability is distributed across both the exploit delivery layer and the post-exploitation DLL components. The IDS rule MALWARE-CNC DNS Fast Flux attempt firing on the EternalBlue launcher during execution adds a network-level dimension to this lateral movement picture: the exploit phase appears to initiate DNS-based network reconnaissance consistent with fast-flux infrastructure probing [T1018].

One anomalous signal in the anti-analysis picture warrants explicit hedging. pcre-0.dll (17d6dde8a6715b9311734cb557b76160a22e340785b3950eae23aae67b0af6a8) is the only sample in the set that matches the YARA rule RedOctoberPluginFileInfo, from the RussianAPT ruleset authored by Intezer Analyze and sourced from github.com/intezer/yara-rules. This rule is associated with a separate APT campaign. The single anomalous YARA hit on pcre-0.dll may indicate code reuse between toolsets, a shared underlying code library, or a false positive — and should not be treated as confirmed attribution evidence without additional corroborating analysis. pcre-0.dll is otherwise labeled consistently as trojan.shadowbrokers/equation, and it shares no cohort linkages with other samples in the set.

The Repackaging Signal and What It Means for Healthcare Environments

The upstream feed attributes this toolkit to APT40, also tracked under the aliases Mudcarp, Bronze Mohawk, TEMP.Periscope, Leviathan, Gadolinium, Gingham Typhoon, and Kryptonite Panda, with espionage listed as the stated motivation and healthcare as the targeted sector. The feed-level attribution carries medium confidence in CTX Team's assessment. All 19 samples are labeled consistently as Equation Group or ShadowBrokers-origin tooling — this does not itself establish APT40 authorship of these binaries. The toolkit's origin in the Equation Group / ShadowBrokers leak is not in dispute; what the feed attribution suggests is secondary use of that leaked tooling by a Chinese state-aligned actor, a pattern that warrants independent verification before being treated as confirmed.

The "Lucifer" family name appearing in the feed-level metadata does not align with the per-file labels, which consistently identify the toolkit as Equation/ShadowBrokers across all 19 samples. CTX Team assesses this as a feed-level tagging artifact and does not treat it as a confirmed family designation for these binaries.

What can be established with high confidence is the continued operational deployment of ShadowBrokers-origin tooling well beyond the 2017 public release window. The 2019-07-07 first-seen date for the Diagnostics.zip bundle, staged as C:\Windows\NetworkDistribution\Diagnostics.txt, is direct evidence of active repackaging and deployment two years after the original leak. Multiple DLLs in the set carry last-seen dates of 2026-05-25, indicating ongoing submission activity through the present period — consistent with continued operational use rather than archival interest.

Healthcare environments are the explicitly tagged target sector. The operational envelope of this toolkit maps directly onto the vulnerabilities that characterize healthcare IT infrastructure: unpatched Windows systems running legacy SMB configurations, medical device networks with limited EDR coverage, and clinical data systems where patch cycles are constrained by regulatory and operational continuity requirements. EternalBlue (MS17-010) remains exploitable against unpatched Windows hosts years after the patch was issued — and the healthcare sector's historically slower patch adoption rate means the exploit's operational utility has not expired in this environment.

The DarkPulsar kernel implant's deliberate fragmentation across cnli-1.dll, ucl.dll, posh-0.dll, and exma-1.dll — each with a distinct imphash, each matching win_darkpulsar_auto — is the architectural feature with the most direct consequence for remediation workflows. An incident responder who identifies and removes the EternalBlue launcher without hunting for the full win_darkpulsar_auto cohort will leave persistent kernel-level access in place. The four DLLs are small — ranging from 10 KB to 57 KB — and their individual detection ratios, while strong in aggregate (55 to 63 of 77 engines), leave a tail of missing engines that includes SentinelOne, Trapmine, and tehtris across multiple members of the cohort.

The Snort TAG_LOG_PKT IDS rule binding cnli-1.dll and exma-1.dll to a shared network traffic pattern offers a detection pathway that operates independently of endpoint coverage gaps: organizations running the Snort registered-user ruleset at their network perimeter may be able to identify DarkPulsar implant activity through traffic anomalies even when endpoint agents miss the individual DLL components.

Leaked Nation-State Tooling as a Persistent Threat: The Longer Analytical Arc

The analytical significance of this toolkit extends beyond the specific files in the set. The FUZZBUNCH/ShadowBrokers toolkit represents a documented case of nation-state offensive tooling — originally developed by the Equation Group and publicly released in 2017 — remaining operationally active and actively repackaged years after its public disclosure. The 2019 Diagnostics.zip bundle is not a historical artifact; it is evidence of an operator who, two years after the leak, assembled 56 components into a single deployable package, disguised it as a Windows diagnostics file, and staged it on a compromised host.

The toolkit's design philosophy — modular DLL components with distinct imphashes, anti-debugging checks across 11 of 19 samples, Tor-routed C2 via riar.dll, OpenSSL-encrypted traffic via libeay32.dll v0.9.8r, and base64-obfuscated configuration data in both the cryptographic and transport layers — reflects a level of operational engineering that does not degrade simply because the source code became public. The techniques embedded in these components [T1190, T1059.006, T1547, T1027, T1090.003] remain effective against the target environments for which they were designed, and the modular architecture means that individual component updates can refresh the toolkit without rebuilding the entire framework.

If the feed-level attribution to APT40 is confirmed through additional analysis, the operational picture becomes analytically significant at a policy level: a Chinese state-aligned actor operationalizing leaked NSA capabilities against civilian healthcare infrastructure represents a specific and documented form of offensive tool proliferation — one where the original developer's tradecraft is repurposed by a geopolitical competitor against a sector that the original developer's own government has designated as critical infrastructure. That thread is worth pulling as additional samples surface, particularly if new variants of the DarkPulsar DLL components emerge with updated imphashes that break the current win_darkpulsar_auto YARA cohort binding. The fragmentation architecture that makes DarkPulsar difficult to remediate also makes it relatively straightforward to update: replacing one of the four DLLs with a recompiled variant would break that component's individual detection while leaving the others intact — a rotation strategy that the modular design appears to have been built to support.

Indicators of compromise19 indicators

Files

(19)
Source: CTX Threat Intelligence