Executive summary
- Open directories on five hosts exposed the full DarkSword/Coruna iOS exploit-and-harvest platform, from the C2 delivery server to the per-wallet theft modules. The infrastructure was still in use at triage time.
- The platform runs a commercial exploitation-as-a-service operation. A copy of the production server recovered 11 victim recovery phrases, 179 device loot directories, and a 75-account control-plane roster.
- A separate China-based operator is running the same kit in the wild against its own C2, distinct from every other tracked DarkSword actor.
- The operator is developing a seventh CVE for the DarkSword toolkit targeting iOS 26, but the chain is mid-development and not yet deployed, so this is not a zero day.
Key judgments
- We assess with high confidence that this cluster is the same DarkSword/Coruna kit Google Threat Intelligence Group (GTIG) documented as adopted by multiple threat actors since late 2025. The Coruna payload module hash
1334417664270db20af705f422878c53c8378203is byte-identical across the185.189.45[.]40capture, the43.134.165[.]205DS-Fusion bundle, the156.239.230[.]120C2 platform, and the production-server capture. - The open directories were live at triage time:
166.88.95[.]90recorded two real Chinese iOS devices polling a beacon page every three seconds for hours on2026-09-06, and156.239.230[.]120was polling a device on2026-09-15. - The platform runs a Chinese-speaking exploitation-as-a-service operation, distinct from the six DarkSword operators documented publicly before this cluster. The admin panel exposes an agent/reseller model, and a copy of the production server recovered 11 victim recovery phrases, 179 device loot directories, and a 75-account control-plane roster.
- The kit’s purpose is wallet theft. Eighteen injection modules, one per targeted crypto wallet app, get pushed into running wallet processes by a SpringBoard coordinator; the implant also mines photos and Notes for BIP39 recovery phrases. A third delivery chain on the production server (
gooll, iOS 13.0 through 17.2.1) carries a self-adaptive kernel stage that fingerprints the device at runtime and never names its vulnerabilities. - A separate China-based operator is already running the same kit in the wild against its own C2 at
hxxps://66ds[.]lol, including a 19th wallet target (BitKeep) not in the open-directory set. The operator behind it sits on Tencent and Shenyang hosting, tied to the operator through a unique self-signed certificate authority. - The operator is developing a seventh CVE for the DarkSword toolkit targeting iOS 26 (
CVE-2026-31001, a JavaScriptCore type confusion), but the chain is mid-development and not yet deployed, so this is not a zero day.
Background: DarkSword and Coruna
DarkSword is an exploit chain for iOS that Google Threat Intelligence Group (GTIG) first documented publicly in March 2026. The chain attacks WebKit and JavaScriptCore to gain code execution, escapes the browser sandbox, escalates to kernel privileges, and injects into SpringBoard, the iOS process that manages app launch and the foreground display. GTIG assessed that the chain is a commercial product that spread from its first customer through a second-hand market to financially motivated operators, and documented it adopted by multiple threat actors since late 2025.
Coruna is the companion payload kit the same ecosystem distributes. Its stages run inside the victim’s browser session after DarkSword’s exploit stages land, and its wallet-harvesting modules steal crypto recovery phrases, balances, and keystore data from iOS apps. Operators run DarkSword and Coruna together against their own C2 infrastructure. Public reporting, including our July 2026 writeup on DarkSword panel sprawl, covered the panels and exploit chains; what has not been documented until now is the delivery infrastructure behind them. That is what the five open directories in this report expose.
The open directory cluster
Five hosts carrying DarkSword/Coruna deployment directories surfaced through an internal open-directory index that archives listings found by Internet scanning, between 2026-09-15 and 2026-09-17. None of the five had been documented before.
| Host | Port | Contents | Role |
43.134.165[.]205 | 9999 | DS-Fusion-v1.0-release tarball with coruna/payloads/<module-id>/ tree | Packaged distribution bundle |
166.88.95[.]90 | 9999 | /client/client/ implant kit, beacon backups, c2_results.jsonl, reports.jsonl | Operational C2 with live telemetry |
23.148.212[.]237 | 8888 | /darksword-merged/, /darksword-analysis/, /batch-compare/ | Operator analysis workspace |
47.102.192[.]23 | 9876 | coruna-waterhole/ Stage1/Stage2 JS + per-victim payload dirs | Coruna staging host |
156.239.230[.]120 | 8080 | Full C2 platform: exploit_server.py, FastAPI admin panel, darksword.db | Live agent-equipped C2 platform |
43.134.165[.]205:9999: the DS-Fusion v1.0 bundle. This host serves a single release tarball named DS-Fusion v1.0, the operator’s own label. The name reads as “DarkSword Fusion”: a fused package of the exploit chains, DarkSword’s included, alongside the Coruna payload tree. Its payload directory is byte-identical to the 185.189.45[.]40 full capture, so the dylibs are not new samples. The bundle is the first evidence of the kit distributed as one packaged release rather than the separate chains documented by GTIG.
166.88.95[.]90: operational beacon and victim telemetry. This host ran an active beacon with backups dated 2026-09-03: a 31-command polling implant covering shell execution, JavaScript evaluation, file and keychain dumps, contacts, SMS, photos, screenshots, camera capture, persistence installs, and self-destruction, with autoharvest modules for WhatsApp, Telegram, WeChat, browsers, and crypto wallets. Both backups carry a hxxp://YOUR_C2_HOST:8082 placeholder the operator never swapped before backing up.
The reports.jsonl file (4,690 lines, all from 2026-09-06 between 16:08 and 19:33 UTC) records fingerprint-report telemetry from the watering hole channel. A watering hole is a malicious web page, styled as ordinary content, that victims are lured to visit so the exploit code embedded in it can attack their browsers; the implant reports fingerprint data back to the C2 server each time it checks in. Two real devices, each keeping the same browser and session identifier, polled the beacon page every three seconds for hours:
| Victim IP | Network (Censys) | iOS | Reports | Window (UTC) |
183.154.173[.]30 | CHINANET, Hangzhou, China | 16.3.1 | 1,940 | 16:24 to 18:31 |
182.239.114[.]223 | China Mobile, Hong Kong | 16.1 | 2,749 | 16:24 to 19:33 |
All victim traffic carries the zh-CN language header and iPhone, Safari user-agent strings. The victims’ iOS versions (16.1 and 16.3.1) fall within the range Coruna’s stages cover. The chart’s flat cadence is the beacon’s 3-second poll loop running continuously: the implant runs inside the victim’s browser tab while the tab stays open on the watering hole page, and each poll is the implant checking in. The Evoxt Japan hosting, Cambodian test IP, and China-Mobile-Hong-Kong victim match the Asia-Pacific hosting profile of the operator cluster we tracked through panel body hashes in July 2026.
23.148.212[.]237: the operator’s analysis workspace. This host exposes darksword-merged/, darksword-analysis/, and batch-compare/ directories. The rce_worker_26.js and kernel_priv_26.js files, plus mos0027 stages, show the operator is developing exploit chains for iOS 26, a version the patched 18.x kit does not cover. The development lead is CVE-2026-31001, a JavaScriptCore bug not documented in any public reporting before this report, so the work targets an unpatched, previously unknown bug rather than a known one. The chain is unfinished, so it is a development lead, not a deployed zero day. This host is a developer workstation; it does not serve payloads.
47.102.192[.]23: Coruna staging. This host carries coruna-waterhole/ with Stage1 and Stage2 JavaScript and per-victim payload directories, consistent with the group.html loader model documented on the French-speaking operator.
The full C2 platform on 156.239.230[.]120
The fifth host exposes the entire C2 platform in an open directory on port 8080, confirmed live by Censys at scan time. Port 80 serves a Chinese-language watering hole landing page titled 点击下方按钮进入 (“Click the button below to enter”) with a button leading to group.html and the operator’s Telegram sales contact tg：@v66db in an <h1>.
The delivery server script (exploit_server.py, 2,595 lines) auto-registers devices on first hit, serves per-channel landing pages, dispatches exploit-result reports, and serves pending commands. The admin panel is a FastAPI application backed by a darksword.db database with routers for agents, devices, commands, exfiltration, and wallets. The panel exposes the agent/reseller model (commission_rate, max_devices quotas, per-agent channels), a 60-plus command whitelist with per-command two-factor confirmation, per-category exfiltration download endpoints, and a parser that scans exfiltrated files for BIP39 mnemonics and wallet addresses. The panel’s CORS allowlist names an IP that connects it to a separate operator panel, described in the next section: 154.217.250[.]206 (AS400619 AROSSCLOUD INC., Redondo Beach CA; Censys historical scans show it serving a “C2 Control Panel” page on ports 80 and 888).
The server script searches for exploit modules under Chinese-named developer directories that translate as “reference, cannot be on GitHub / Coruna original” and “Coruna-main: preparing to modify the C2”. This operator is running a locally modified Coruna tree. The 23.148.212[.]237 analysis workspace shows the same pattern.
The triage initially flagged an exfil directory as real victim browser data. Both files in it are tiny (87 and 62 bytes): one is a device heartbeat cookie and the other is a JSON stub with only a device ID. These are post-exploit stage reports from an operator test device; they contain no harvested victim content. The examined files contain no evidence of real victim data exfiltration.
The production-server capture
The package we obtained carries the full production infrastructure of a DarkSword/Coruna operator between 2026-09-15 and 2026-09-17. It presents itself as the output of a written-authorized red-team exercise against the operator. We do not credit that description: no such engagement is evident in the package, and the label was used to get AI assistants to help process the exfiltrated material despite their restrictions. Beyond the fact that it is a copy of the operator’s production infrastructure, the package does not explain how it was obtained. Three links tie it to the same ecosystem: 202.146.222[.]253 was already tracked as a DarkSword admin panel and the package identifies it as the operator’s old production server, the Coruna payload module hash is byte-identical to the one in the other captures, and the package carries the same Chinese-language panels, agent/reseller commissions, and wallet-harvesting dylibs as the operator cluster we tracked in July 2026.
The live production server (112.213.108[.]85, hostname hdios[.]cn) runs a Chinese hosting-panel stack and hosts the C2 behind nginx Basic auth plus a panel token. Its webroot carries the full kit: client/, coruna/, darksword/, gooll/, plasma/, profiles/, variants/, and sync/ directories, plus the six-CVE exploit registry and the vchain/ iOS 26 staging modules. Metadata-only victim telemetry from the production panel shows:
- 11 victim recovery phrases (12-word BIP39 mnemonics) extracted over the panel API, covering TronLink, Bitget, Bitpie, Trust, Phantom, and imToken.
- 87+ on-chain addresses on the panel (118+ in the iOS database history) and 179 device loot directories.
- 18 wallet-targeting dylibs in
variants/set0, matching the 18 modules documented in this report. - A 75-account control-plane roster with agents, commission rates, and device quotas.
- An asset audit that found about 0.3 TRX in directly sweepable on-chain funds; any remaining value sits in derivation paths of the 11 seeds that the audit did not derive.
The production server’s exploit registry lists the six tracked CVEs plus two not previously documented in public reporting on DarkSword: CVE-2025-24201 (a WebKit sandbox escape alternative for iOS below 18.3.2) and CVE-2025-31200 (a CoreAudio zero-click claim, unverified on device). The registry also shows the iOS 26 modules are on-disk staging only.
The vchain/ directory carries the iOS 26 exploit modules the operator is developing. Two of them document a new CVE not present in the six-CVE 18.x chain: CVE-2026-31001, a JavaScriptCore type confusion in which garbage collection relocates a memory block while just-in-time-compiled code keeps a stale pointer to its type descriptor, letting a later cast mistake one object type for another. The companion kernel-privilege and sandbox-escape scripts are one-byte placeholders, so those stages are not yet written. The operator’s build scripts flag an explicit self-test failure until each exploit step (reading or writing kernel memory, escaping the sandbox) is verified working. This is a seventh CVE for the DarkSword toolkit and a forward-looking lead; the operator has not fielded it.
The C2 control panel fleet (154.217.250[.]206 and 14.128.47[.]81)
We assess with moderate confidence that the 154.217.250[.]206 IP referenced in the 156.239.230[.]120 operator’s admin/.env CORS list is itself a DarkSword operator panel. Censys historical scans (2026-08-25 through 2026-08-27) show it serving an HTTP page titled “C2 Control Panel” on ports 80 and 888; the host did not respond in any later scan.
The page body carries the version banner “C2 PANEL v3.0”, a Chinese login form, a hidden Telegram contact link (hxxps://t.me/YATA0000), and the group name 幽灵集团 (“Ghost/Phantom Group”). The body hash 864d68e64618d6bfc26d75d6f780ae0b7bfed3698cc8333818ed32519e560d1f is unique to this host. The IP sits on AS400619 (AROSSCLOUD INC., Redondo Beach CA.
Forward DNS points at four hostnames: three ccwu[.]cc subdomains and wumian[.]cc.cd. These resolve to IPs on AS152194 (CTG Server Limited / Ansheng Network Technology, Hong Kong) serving Chinese-language management panels titled 领冠科技安卓设备管理 (“Lingguan Technology Android Device Management”) and 全新一代星核系统 (“Next-Generation Star Core System”).
A second panel host, 14.128.47[.]81 (AS152194 CTG Server Limited, Hong Kong), serves the same 幽灵集团 group name on port 443 but with a different body hash and without the “C2 PANEL v3.0” banner or Telegram link. Fourteen hosts across Censys carry the “C2 Control Panel” title in total; the 154.217.250[.]206 and 14.128.47[.]81 builds are two distinct deployments of the same group-named panel software.
The exploit chain and payload set
After the exploit chain achieves kernel read/write and injects into SpringBoard, the kit fetches and loads a staged payload chain. Reverse engineering of the downloaded binaries documents three layers: the bootstrap.dylib stage-0 beacon, the stage2.dylib plasma controller, and the core_v6.dylib plasma_core implant, which in turn drives the SpringBoard coordinator and the wallet modules.
The payload set breaks down as:
- Eleven GHOST exploit payloads from the
185.189.45[.]40:8080directory. These are native Mach-O exploit stages with no wallet-theft functionality: unlike the 18 wallet modules, they contain no wallet-app targeting, no recovery-phrase extraction, and none of the shared C2 framework strings the wallet modules carry. They link Apple private frameworks and target five distinct iOS-internal services (ARKit face tracking, the Safari JavaScript bridge, Safari data records, privilege escalation, and a WebKit exception handler). The Safari data-records type was new: it matched none of the four GHOST signatures documented before this report and required a fifth. - A staging chain of three dylib families and a JavaScript/WebAssembly stage that runs after the GHOST stages: filesystem patching, device profiling and stage decryption, privilege escalation signed with a spoofed Apple identifier, and in-page exploit execution.
- The
core_v6.dylibimplant (1.3 MB), the central coordinator. It injects wallet modules into running app processes, steals BIP39 seed phrases from photos and Notes (only checksum-valid phrases are exfiltrated), exfiltrates the address book, pulls daily config from the C2 with a domain-generation fallback, and self-updates. A production build (core_a5.dylib) drops the hardcoded lab deploy host. - A SpringBoard coordinator (
future-destroy.htm, a Mach-O binary disguised with a.htmextension) that watches for target wallet apps launching and triggers injection of the matching module, throttled at three seconds per bundle. - Eighteen wallet injection modules, each targeting a specific crypto wallet app (Bitpie, Coinbase, Exodus, imToken, MetaMask, Phantom, Trust Wallet, Uniswap, OKEx, and nine others). All 18 share one C2 framework: a hardcoded AES key, domain-generation seeds, five exfiltration endpoints split by data type, a spoofed Safari user agent, and disabled TLS validation. They carry the same embedded build date.
Detection
One signature set of 44 YARA rules covers the full DarkSword/Coruna binary surface: 27 targeting the wallet modules and shared framework (plus BitKeep and the four plugin modules), 3 covering the coordinator and implant layers, and 17 covering the exploit chains, including the five GHOST signatures (one new in this report), four staging-payload signatures, two gooll kernel signatures, and the five Google Threat Intelligence Group-published GHOSTBLADE, GHOSTKNIFE, and GHOSTSABER signatures.
A false-positive sweep across several thousand legitimate macOS binaries returned zero matches. Combined coverage is 347 of 347 unique Mach-O binaries in the sample set, 1,442 matched files in total: every wallet module, framework binary, wild build, GHOST exploit payload, and staging payload matches at least one signature. Decryption work on the production mirror recovered the locally available modules of the kit’s third delivery chain.
The gooll chain: payload decryption (iOS 13.0-17.2.1)
A third chain directory (gooll/) on the hdios[.]cn production server targets iOS 13.0 through 17.2.1 (gooll.html targets iOS <18 only; iOS >=18 is redirected to the DarkSword fork under /ios18/frame.html). We decrypted the chain’s manifest and all locally available payload modules.
The 19 modules are 14 exploit-stage bundles plus 4 utility containers, plus the manifest itself. Each bundle contains 2 to 7 entries: Mach-O dylibs named by stage, a config blob naming the injection target process (SpringBoard or powerd), a metadata blob, and where present raw ARM64 shellcode. The stages cover daemon enumeration, a JavaScriptCore loader with anti-virtual-device checks, a WebContent exploit with C2 check-in, kernel privilege escalation, and post-exploitation framework loading. Seven distinct kernel-stage builds exist, one per exploit variant, and a separate powerd-targeted pair provides an escalation path for when SpringBoard injection is unavailable.
No CVE references appear in any decrypted binary or the loader JS. Exploit targets are identified only by the victim services they touch, consistent with a closed-source commercial kit that does not advertise which bugs it uses.
The gooll kernel stage: what makes it different
The gooll chain contains seven kernel-stage builds, one per exploit variant. We reversed the largest of them (entry1_type0x09.dylib, 284 KB), renaming and commenting ~60 functions. It is an iOS 13-17.2 kernel exploitation library that adapts itself to the device it runs on (rather than shipping fixed addresses per device), and its design is what separates the gooll chain from older DarkSword versions:
- Runtime fingerprinting instead of offset tables. Older DarkSword chains carried per-device offset tables: precomputed memory addresses for each known device and iOS build, shipped in the binary. This stage carries none of those tables. Instead it fingerprints its targets at runtime (reads the XNU kernel build number, scans driver byte patterns, checks which IOKit services exist) and picks its exploitation path from what it finds. The strings in the binary never name a CVE, so the vulnerabilities it uses cannot be identified from the binary alone.
- Layered fallback. Memory access fans out to five independent backends; a lower layer’s failure falls through to the next, so a partial patch of one path does not break the chain.
- Two Page Protection Layer bypasses. PPL is the iOS 17 mitigation that made kernel read/write from userspace largely obsolete. The stage defeats it two ways: an older page-table forgery approach and a newer write method aware of error-correcting memory.
- Self-verifying writes. Every kernel-memory-write routine verifies itself by writing, re-reading, and comparing against the expected bytes.
The kernel stage targets iOS 13 through 17.2 only. Its XNU build gates match the DarkSword 18.x chain’s build table, which is evidence the two chains share a developer. Nothing in the gooll chain targets iOS 26.
Polymorphic variant engine and PHP distribution layer
The 154.219.127[.]147 open directory exposes the server-side delivery infrastructure: a small set of PHP files and a polymorphic variant registry (manifest.json) that together serve victims mutated binaries. The registry defines five variant sets: five hash-distinct copies of the same kit, built by mutating every file against a shared baseline so each copy carries different hashes.
Three access-control gates stand between victims and the payload directories: a signed token valid for five minutes and bound to the requesting IP, a fingerprint window that requires the requesting IP to have visited the watering hole landing page in the last 10 minutes, and a user-agent check matching the iOS daemon identities the implant spoofs. Every download URL carries a freshly signed token, so a leaked URL is useless within minutes.
The variant registry defines five variant sets. Each holds 25 files: the core dylibs, the stage-2 controller, the SpringBoard coordinator, the 18 wallet modules, the WebClip and NotNotify plugins, and the BitKeep module disguised as aware_retreat.css. The manifest records both the mutated hash a victim receives and the baseline hash it was built from, so no delivered binary matches a known baseline hash, and daily_render.php rewrites each URL with the active set’s hash and size. The 7z archives in the directory are build-time artifacts packed with a build-time password not present in any exposed file; all plaintext content they protect is available unencrypted in sync/, variants/set*/, and details/.
Wild builds and the 66ds[.]lol operator
A sweep of a historical malware repository matched 22 wallet-module samples collected from infections in the wild, which we call wild builds to distinguish them from the operator builds recovered from the open directories. All 22 share a hardcoded C2 at hxxps://66ds[.]lol (Cloudflare-fronted), on infrastructure entirely separate from the hdios[.]cn / fc.rsqqq[.]top / 199.30.90[.]154 cluster. None of the production sync/ modules from the 154.219.127[.]147 open directory contain 66ds[.]lol; all 22 wild builds do.
The 22 wild builds cover 10 wallet targets plus WhatsApp and telephony, with multiple arch and build variants per target. Two are BitKeep wallet modules, making BitKeep a 19th wallet target beyond the 18 in the open-directory set. A dedicated BitKeep signature catches them.
Every wild build is the production code with one functional string changed: the DGA fallback hxxps://backup%u[.]fit is replaced by the hardcoded hxxps://66ds[.]lol. The operator did not modify the DGA seeds, the AES key, the class names, or any wallet-specific logic, and did not run the builds through the variant engine, so the shared framework strings are intact in every wild build.
The operator behind Cloudflare
66ds[.]lol is Cloudflare-fronted. The served certificate’s organization field, IPLCZ Test Lab, pivots to the origin server behind the CDN: 101.35.158[.]183 (AS45090 Tencent, geolocated to Shanghai). That origin presents a private self-signed root CA that no other host on the Internet presents: a Censys search on either the issuer distinguished name (Codex iOS Isolated Lab Root CA 2026) or the organization field returns only this one host.
The origin’s 30-day forward-DNS history resolves to 14 hostnames, the operator’s IPLCZ Test Lab front: twelve iplcz[.]cn subdomains plus two auxiliary domains (a TikTok API proxy and an image service). The subdomain naming indicates the operator fronts an AI-services reseller alongside the iOS research lab.
The origin’s :9443 certificate leaks two management hostnames, g.northlab[.]cn and manager.g.northlab[.]cn, tying the operator to the northlab[.]cn domain. We call this the operator’s lab domain because their own certificate names it one: the self-signed root CA is Codex iOS Isolated Lab Root CA 2026 with organization IPLCZ Test Lab, and what the domain carries fits a test and management environment rather than victim-facing infrastructure (a Winmail mail server, a SecWorld VPN gateway, an app host; no payload serving). That domain resolves across two Shenyang (Liaoning) networks on China Unicom (218.25.85[.]177, 218.25.85[.]178) and China Telecom (59.46.4[.]117, 59.46.4[.]119), carrying mail and lab hosts. The combined Tencent (origin) and Shenyang (mail and lab) footprint places this operator in China, distinct from every other tracked DarkSword actor.
Infrastructure and IOCs
Open-directory cluster hosts
| IP | Port | Hosting | First seen |
43.134.165[.]205 | 9999 | Tencent Cloud | 2026-09-15 |
166.88.95[.]90 | 9999 | Evoxt (Japan) | 2026-09-15 |
23.148.212[.]237 | 8888 | (unknown) | 2026-09-15 |
47.102.192[.]23 | 9876 | Alibaba Cloud | 2026-09-15 |
156.239.230[.]120 | 8080, 80 | (unknown) | 2026-09-16 |
Red-team capture infrastructure (live as of 2026-09-17)
| IP | Hostname | Role | Domain |
112.213.108[.]85 | VM-NJb8T5qJl6 | Live production | hdios[.]cn |
154.18.187[.]160 | SG-B20702-I | Backup delivery stack | fc.rsqqq[.]top |
202.146.222[.]253 | C202609121655717 | Old production (migrated 2026-09-14) | i.131422[.]com |
203.91.77[.]253 | (unknown) | Operator work machine | st.onlinefc[.]top |
Wild-build C2 (repository sweep 2026-09-23)
| Domain | IP | Role |
66ds[.]lol | Cloudflare-fronted (AS13335) | Wild-build wallet module C2 (22 samples) |
66ds[.]lol (origin) | 101.35.158[.]183 (AS45090 Tencent, geolocated Shanghai) | Origin behind Cloudflare; private CA Codex iOS Isolated Lab Root CA 2026 (O=IPLCZ Test Lab) seen on no other host in Censys |
iplcz[.]cn | 101.35.158[.]183 | IPLCZ Test Lab parent; 12 subdomains in origin forward-DNS history |
northlab[.]cn | 218.25.85[.]177, 218.25.85[.]178 (AS4837 China Unicom), 59.46.4[.]117, 59.46.4[.]119 (AS4134 China Telecom) | Operator lab domain (leaked through origin :9443 cert SANs g.northlab[.]cn, manager.g.northlab[.]cn); Shenyang mail and lab cluster |
Payload hashes
| File | SHA-256 | Role |
bootstrap.dylib | c391bce7b09a0ea263e4b2c1d1bde0327c180723fa3299b006485429564c61ee | Stage-0 beacon |
stage2.dylib | 8973e80ab494c02463d4123f76fc5e2dca2ea2c097317d246323d75c1f2eb791 | Plasma stage-2 controller |
core_v6.dylib | a50c4da5c92636b2b1f170cdce3bd967a213886a8df5656cf3519214fcecfac5 | plasma_core implant (lab-force) |
core_a5.dylib | 54a4166ab33ffe02b41de9c943e783d20129b6cc22f56b7fe7d564fd02bde006 | plasma_core implant (production) |
future-destroy.htm | 7ff5bb16cd5f8c92bc4fec72bba162662f202af075418db5000a1b4f81489fc2 | SpringBoard injection coordinator |
wallet01 through wallet18 | 18 theft modules, one per targeted wallet app | |
wallet19 (BitKeep) | 19th wallet target (wild-build only; install name libbitDylib.dylib) |
The full per-sample hash list (347 binaries: these framework binaries, the 18 wallet modules, the GHOST and staging payloads, and the wild builds) ships with the companion payload analysis.
Hardcoded secrets
| Secret | Value | Use |
| AES key | Ek8pl31K2yeHgQwy | Shared exfil channel encryption |
| DGA seeds | UNDEFINED_DEPLOYMENT_SEED, UNDEFINED_REPORTING_SEED | Wallet module deployment and reporting DGA |
| 7z config password | c73dfcfd60a0c7ebcc03352d433349bc | 7z fallback transport password (build-time password differs) |
| Plasma DGA seeds | 09d0b8d58a71653cd1c89c64c866f2e6, 2d2aebba0bf3d7d694194a7ab93b0a96 | plasma_core deployment and reporting pools |
| Fallback C2 (plasma) | hxxp://199.30.90[.]154:18090 | Hardcoded lab deploy host |
Device-side persistence
- LaunchDaemon:
/Library/LaunchDaemons/com.apple.ds.agent.plist(labelcom.apple.ds.agent) - IPC channels:
/tmp/nb_cmd(commands),/tmp/nb_result(results) - Cookies:
ds_uuid,ds_done,coruna-lab-session
Operator profile and attribution
We assess with moderate confidence that the open-directory cluster and the 156.239.230[.]120 platform are run by a Chinese-speaking operator distinct from the six DarkSword operators documented publicly before this cluster: UNC6353 (Ukraine), UNC6748 (Saudi Arabia), PARS Defense (Turkey/Malaysia), a GitHub-dump clone, the Atlantic Council spearphishing actor, and a French-speaking operator running an earlier Coruna deployment.
The evidence is the Chinese-language operator tooling (参考不能参与github/coruna原版, 关键词雷达运营后台), the zh-CN panel markup, the Asia-Pacific hosting concentration, the .cn and .top domain choices, and the Telegram contact @v66db on the landing page. The operator is running a locally modified Coruna tree with active development on iOS 26 chains, which suggests access to source code rather than a binary redistribution. The agent/reseller model on the admin panel and the 75-account roster from the production-server capture indicate a commercial exploitation-as-a-service operation.
We cannot attribute the cluster to a named actor. The reuse of the public DarkSword kit is consistent with the proliferation pattern GTIG documented, in which the exploit chain spread from a commercial customer through a second-hand market to financially motivated actors.
Disruption and monitoring
The operators’ single-staging-host design is the weak point: closing port 9999 on 166.88.95[.]90 and port 8080 on 156.239.230[.]120 would deny the operator their C2 and telemetry, and taking down the single staging host behind the AWS-impersonation domains from the July 2026 cluster would drop 29 of 34 dominant-build domains at once. Domains churn faster than hosting, so track the staging hosts and the panel signatures instead of individual domains.
The iOS 26 development work on 23.148.212[.]237 is the lead to watch. The 18.x chains are patched in iOS 18.7.3 and 26.3, so the operator needs a working iOS 26 chain to reach patched devices. The staging scripts on that host are not fielded. The signature set and the known-sample hash list run continuously against a cloud-hosted historical malware corpus.
Scope and method
All open-directory content was discovered through an internal open-directory index, and payload binaries were downloaded from the operator C2 servers and analyzed statically. Every claim about binary behavior is supported by decompiled code, string evidence, or network artifacts. Victim IP geolocation and ASN data come from Censys host documents. We treat the production-server capture package as sensitive: all credential, SSH-key, and mnemonic material stays offline, and we do not redistribute it. IOCs are defanged in this report.
Caveats
- The production-server package labels itself a red-team exercise output; that label is a pretext and no engagement is evident in the package. We do not know how the package was obtained.
154.219.127[.]147is the staging host in the production-server package and154.219.127[.]94is its egress. Exclude both from operator IOC lists.- The iOS 26 modules have placeholder offsets and unverified profiles. Do not report 26.x as a live capability.
- The
CVE-2025-31200CoreAudio zero-click is a capability claim in the production registry, unverified on device. Treat it as a claim only.
References
- Google Threat Intelligence Group, “The Proliferation of DarkSword: iOS Exploit Chain Adopted by Multiple Threat Actors,” 2026-03-18. https://cloud.google.com/blog/topics/threat-intelligence/darksword-ios-exploit-chain/
- Malfors (@MalforsHQ), post reporting a targeted campaign delivering DarkSword RCE (GHOSTBLADE) through fake Atlantic Council “discussion invitation” emails, with IOCs
siekeltd[.]comandescofiringbijou[.]com(payload and C2), 2026-03-27. https://x.com/MalforsHQ/status/2037293707351765450 - Aidan Holland, Censys, “DarkSword’s Panel Sprawl: How One Body Hash Unravels a Six-Panel, Two-Codebase Operator Cluster,” 2026-07-31. https://censys.com/blog/darkswords-panel-sprawl/
