From a U.S. Defense Contractor to Chinese Crypto Thieves

An iPhone cyberweapon reportedly developed in part at L3Harris’s Trenchant division ended up in Chinese criminal campaigns targeting cryptocurrency wallets. Coruna, a kit for breaking into iPhones, was being used to hunt wallet secrets. A stolen recovery phrase could give the thief control of a victim’s bitcoin or other cryptocurrency.

How it passed between those users remains unresolved. What emerged at the criminal end of the trade, however, is available to inspect. I followed exploit files captured from an Italian nail-products website into public packages containing a reseller dashboard, a commission-rate field, an imitation Apple login page, and parsers for stolen wallet data. Integration and support were advertised for 5,000 USDT.

Parts of those packages matched the capture byte for byte. The code shows how circulating exploit material was being assembled into a business: assign devices to reseller accounts, collect their files, extract wallet secrets, and offer help finishing the integration. The capture does not establish a completed theft from a particular wallet or identify every handoff along the way.

The supplied Coruna-v2 dashboard includes reseller management (代理商管理) alongside collection, channels, and commands. Its displayed counters are part of the repository screenshot, not a measurement of this campaign. Original screenshot.

A shop website with two exploit routes

The investigation began with an archive containing group.html and three scripts from estrosa[.]it. The landing page selected between two exploit frameworks using the browser’s reported iOS version. One branch closely matched Coruna, an older iOS kit. The other matched a modified DarkSword chain.

The files sat under /js/analystic/assets/js/, a directory name resembling an analytics component. Passive urlscan records put the same path and kit on at least nine websites, with captures beginning October 12, 2026; the two most recent, both French small-business sites, appeared in scans on October 21 while this article was being prepared. Those records establish a deployment footprint. They do not establish when the sites were first compromised or how their ordinary pages sent visitors to the landing page. The complete site list is in the IOC dump at the end.

The landing page is a stager: it chooses which loader to fetch, and that loader selects the exploit stages. The two branches lead to different payloads. DarkSword includes a SpringBoard implant in the recovered code. Coruna reaches a native stager whose final core payload was not captured.

The delivery website serves the stages. The separate backend at btrf36[.]cc receives the landing page’s site beacon at /hx; the DarkSword implant polls /beacon and uses reporting and upload routes including /result, /aa, /uu, and /qq. Shared infrastructure does not make the two branches the same implant. Coruna’s later core and its behavior remain outside this capture.

The retained acquisition contains 54 response bodies, including the named exploit stages, encrypted configuration, and native payloads. For this article I inspected those files and public comparison repositories statically. I did not run the exploits or contact their infrastructure.

L3 bought the businesses that became Trenchant

The history spans a corporate acquisition, an insider theft, public exploit research, and later retail packaging. Select a date to read its evidence and limits; the line orders records without asserting how the code changed hands.

L3’s 2018 quarterly report records the Azimuth and Linchpin acquisition and their renaming as Trenchant: $200 million before acquired cash, approximately $185 million net, plus up to $31 million tied to later sales.

L3 described the acquisition as strengthening its command, intelligence, surveillance, and related capabilities. Its preliminary accounting assigned $98 million to intangible assets, principally technology and customer relationships. These were businesses with products, customers, and sales targets, acquired as part of a defense contractor’s growth strategy.

L3 and Harris completed their merger on June 29, 2019, forming L3Harris Technologies.

The subsequent criminal case against Trenchant’s former general manager, Peter Williams, describes how that product business operated. Exploit software could be sold as a complete product or as component subsets, with updated versions distributed to customers. Access was restricted, and contracts limited use and redistribution. The customers were trusted governments. Those details appear in the statement of offense Williams signed.

In October 2024, the company learned that one of its protected components was being offered by another vendor. Its own embedded vendor data helped establish the match. Williams oversaw the internal inquiry. He also had super-user access to the company’s protected products and network records. He did not disclose his own theft to the investigator or his employers, according to the same court document.

Prosecutors said Williams stole at least eight exploit components between April 2022 and August 2025. Intended exclusively for the U.S. government and selected allies, they were sold to a Russian broker under agreements covering both initial delivery and follow-on support.

Before sentencing, Williams described professional pressure and anxiety in a February 5 letter to Judge Loren L. AliKhan. He accepted responsibility for his decisions and acknowledged that those pressures did not excuse them. His attorney’s sentencing memorandum called the episode “an unfortunate period of extraordinarily poor judgment exacerbated by severe job stress and exhaustion.”

A cropped phrase from page 1 of Williams’s letter, dated February 5, 2026 and filed February 10 as Document 23-1. Read the full two-page letter.

The Treasury Department identified the broker as Operation Zero and said it resold the stolen tools to at least one unauthorized user. Treasury’s account establishes an onward sale beyond the initial theft. It does not identify that user as the operator of the files I examined.

Where Coruna enters the record

Google Threat Intelligence Group documented Coruna’s movement during 2025 from a surveillance-vendor customer’s targeted operation to suspected Russian espionage and then financially motivated activity from China. Google explicitly left the mechanism of that proliferation unresolved.

The Williams case provides a documented example of restricted exploit components escaping into a resale market. The Coruna reporting describes a kit moving between very different users. The available evidence does not establish that Williams’s sales caused Coruna’s spread. Filling that gap would turn two supported accounts into an unsupported chain of custody.

DarkSword has its own published exploit-chain analysis; its presence beside Coruna does not give every component the same origin. Public repositories preserved material from both kits and added deployment tools. In the retained history, scripts for serving payloads were followed by packages with an administrative application and database.

By July, a repository called DarkSword-PROV2 advertised a full version and technical support. An August repository from the same organization, Coruna-v2, offered integration and adaptation for one iOS version at a stated price of 5,000 USDT. Both carried authorized-research disclaimers.

The supplied DarkSword-PROV2 panel turns collection and tasking into buttons. The visible rows say “waiting to execute” (等待执行), and the exploitation status says “waiting for exploitation” (等待利用). These are interface claims and queued jobs, not verified results. Original screenshot.

The seller was advertising help integrating circulating exploit material into a usable system. The README establishes an asking price; I found no transaction record tying the seller to this deployment. Connecting the retail package to the shop-site files still required a byte comparison.

The recovered exploits and their CVEs

The capture preserves both exploit branches, including 13 older JavaScript modules and the newer browser, sandbox, and privilege-escalation stages. The table distinguishes a recovered artifact from its vulnerability assignment. Published association means the mapping comes from public lineage or module-role comparisons; inferred adds mechanism evidence from this capture. Neither means I ran the exploit successfully. Target iOS ranges are published module ranges unless labeled as captured profiles; they are not device compatibility tests.

CVE assignments come from GTIG’s Coruna table and DarkSword analysis, checked against the retained files and public counterparts. The older module IDs also agree with littlelailo’s Coruna analysis. The integrated worker’s strongest local match is to WebKit’s DFG store-barrier fix. Several sandbox and native-stage assignments still lack that level of verification; missing CVEs are not evidence of new zero-days.

The generic RCE file names 18.4/18.4.1 but lacks matching RCE profiles. Both RCE files contain an 18.1.1 record; the loader selects the integrated worker for that version, and both downstream sandbox tables lack its profile. Neither path establishes a working full chain. The 18.7 range comes from published DarkSword research; this capture’s listed profiles stop at 18.6.2.

The configuration matched exactly

The strongest match was a 2,192-byte configuration recovered by decoding the captured Coruna data. The retail repository carried an identical file under its payload tree. Their SHA-256 digest was:

1c690a980611a4fd8ab3681c871b9b131061511b0c1b9bc30189caa08fe1bced

The retail tree also contained matching payload content and the same salt used to derive resource names. This was a connection through actual bytes and configuration, beyond the reuse of a family name or a familiar directory structure.

But the configuration was not exclusive to the retailer. I independently checked two other retained public Coruna trees and found the captured encrypted configuration there too, unchanged. Public availability makes copying an entirely plausible explanation for the overlap.

There was a smaller DarkSword match as well: an 85-byte placeholder module shared by the captured deployment and DarkSword-PROV2. That exact match is reproducible, but a tiny shared placeholder says little about the identity of whoever deployed the surrounding chain.

The October deployment could have used the retail package, another copy of the same material, or a common upstream source. The files do not choose among those explanations. They do let us inspect the surrounding retail software as a concrete example of how this exploit material was being packaged.

The panel divides the work among resellers

In the retained Coruna-v2 source, an Agent is an account in the management application. Its database record includes max_devices and commission_rate, alongside contact details and two-factor authentication settings. Devices and traffic channels carry an agent_id. Channel records have their own identifiers, API keys, and landing-template associations.

The relationships continue into the request handlers. The reseller device view filters records by the signed-in account. Its collection view joins uploaded files to devices assigned to that account. Other handlers return its channels, pending commands, and activity counts.

The channel editor packages delivery as an embed: choose a template, generate code, copy it into a page. This supplied example uses a localhost address and an Apple ID login template. It does not establish how visitors reached the October shop-site landing page. Original screenshot.

The source models a division of access: one service can hold records for multiple resellers while presenting each with their assigned devices and collected material. The commission field indicates an intended commercial relationship, although I found no basis here for claiming commissions were paid or automatically settled.

The wallet section lists collected files by wallet category, groups them by application, and includes parsing paths for recovery phrases, private keys, and addresses. A recovery phrase can restore control of a cryptocurrency wallet; extracting it is a much more specific objective than collecting generic device telemetry.

The supplied wallet view makes the intended output explicit: recovery phrases, private keys, addresses, and an associated device. All six wallet counters are zero and the table is empty. Original screenshot.

These are source-level capabilities; I did not launch the panel. Censys separately documented combined Coruna/DarkSword distribution and a reseller model in another captured platform.

Collection is organized around wallets, with broader reach

The captured DarkSword branch contains a large agent intended to run inside SpringBoard, the iOS process responsible for the home-screen interface. Its structure overlaps the P7 variant previously described by iVerify. That is a lineage assessment based on code, not an attribution of this campaign to the operators in that report.

The automatic path checks 37 wallet bundle identifiers. Wallet recognition and an inventory acknowledgment gate some uploads; Notes and heavy keychain processing have different rules.

The companion privilege-stage code leaves heavy keychain processing enabled even without a wallet hit. Its selection rules include authentication, browser, mail, and other account material as well as wallet-related entries.

The pipeline also depends on coordination between separate pieces of code. One writes an early .wallet marker and a later .done marker; another waits for them. In the captured source, a failure after the early marker can leave the agent waiting for final completion while continuing to beacon. Seeing that traffic would not, by itself, prove collection finished or that normal command dispatch had begun.

The debug log’s completion message was misleading

The retail repository included a debug transcript, internally dated August 8. It named the same configuration and a payload container present in this investigation.

The transcript records five attempts to obtain a task port for another process. Each returns 5, with no usable port. The code’s diagnostic interprets those failures as a sandbox denial and stops that attempt. It then records that remote injection was skipped because the target task port was unavailable.

The next status message says, in translation, that the injection layer is complete.

Payload downloading and container assembly continue afterward. Those later steps do not turn the skipped injection into a successful one. The transcript establishes what its author recorded, including those payload names and the failed attempt. Its internal timestamp is not an independently verified event date, and it is not a device capture I made.

That is also why I would not use the committed database’s user-agent strings to announce support for a newer iOS release. The strings are stored claims about clients. They do not demonstrate an exploit running on those versions.

The October files’ version tables extend beyond A12 devices, but some routes have gaps between the selected profile and the metadata required by later stages. A version label in a menu, table, or log is not an end-to-end compatibility test.

The missing core

This investigation does not establish a new iOS vulnerability, a successful infection of a shop visitor, or a new operator identity.

The captured Coruna branch includes a native loader designed to fetch an encrypted configuration, download and verify more code, and inject it into another process. It also contains code to monitor the downloaded component and attempt recovery after failure. The server’s actual configuration, core payload, and app modules remain unobserved.

IOC dump

Indicators below come from this investigation’s captures and passive records; domains are defanged. The list is current as of October 21, 2026, and the delivery-site footprint was still growing when this was published.

• Delivery sites, by first passive capture: sielmann[.]de (Oct 12), mebel[.]store (Oct 13), tihsa[.]com and alpinstore[.]com (Oct 14), interdistribution[.]ca (Oct 15), estrosa[.]it and sweeper-engine[.]com (Oct 19), jardinmarket[.]com and acaris[.]fr (Oct 21)
• Kit path: /js/analystic/assets/js/ (one site uses /img/analystic/assets/js/); redirect target /404.html; disabled-by-default debug endpoint /log.html
• C2: btrf36[.]cc → 47[.]76[.]30[.]227 (Alibaba, Hong Kong). Landing beacon /hx; implant routes /beacon, /result, /aa, /uu, /qq, /heartbeat
• Landing and stage filenames: group.html; initial scripts a8c3f01e6b47d295.js, b8def7dab9dd9ad8.js, 49554fde7424c31c.js; newer initial modules e1105852cab6ef49.js, 455b474ef0843d25.js, 8150b44e89f06890.js, a13e3e4525e28ff8.js; deeper stages 717d3ef037488de5.js, e698499e769d1643.js, e0e65d55905b9342.js; encrypted configuration 7a7d99099b035b2c6512b6ebeeea6df1ede70fbb.min.js
• Landing set SHA-256: 2af55f5c00efad5e4d7547ca5153285db8a5d9e885d09d11fe85243faf8a11cf (group.html), 19380347b2cb20a40469a6de4ebbf6fcfddff551e9f5d5ecd657f2957d82042a (beacon), d86a69137cda7c4e6caab58ccf66eb59a6f68282b2e10fcd186a7b8c5af3b710 (loader), e9b106745a31d7ad4095dd87cf8f915cf600f929b6930b9ff3534826c649f803 (module framework)
• Newer-chain SHA-256: 5856c2c59ffcbe6b82f49ec94517463dc764cfe43333a7313c49a11c1c7934de (18.6 worker), 37efaa4237a28a4be411d40de80b2935be5b8c4e6731ee1f858c609142a87445 (85-byte placeholder), df86db89f7f965fc117d4c14b722d3d02f1d1de5c6ec216bb59fcf2736374caa (default worker), 3196034ef1196c9151395859019674e14e3c06e3fdbf230c7e0d0c5f6211824a (default RCE module), 9c7f86f2b82df171a09f096afcd8fa5b6b24f0b643aae765ad17ecf80dadb196 (memory-primitives stage), 6db7114ed9e8a89a75d11930d348ebd6c3bd52572238191c3116b100e8963a98 (GPU escape), da3fe94ac1ffe0ae01adfab6d5e6cd58933e93853c4b6e664f76ca468981bb02 (kernel stage with SpringBoard agent)
• Configuration hashes: c46f10963abb667af65d53e9b1d867ae8f8e0243de5ca45dd5ead3931dd61056 (raw encrypted config as served), 1c690a980611a4fd8ab3681c871b9b131061511b0c1b9bc30189caa08fe1bced (decoded, as cited above), 33d60d42472a83d0d2cf4ee6640c615313c29b18ce1e8ab06e41f4bba558a34b (original sample zip)
• Browser storage markers: sessionStorage['_x_nav'] (eight-second re-entry throttle), localStorage['_x_done'] (per-origin completion marker), _x_ok; ?force=1 bypasses these guards
• Build markers: resource-name salt cecd08aa6ff548c2 (truncated-SHA256 naming for the older branch’s modules), PE_BUILD = 20260914-aks40, and an unsubstituted {{LPE_64BITE}} template token in the GPU-escape stage
• On-device artifacts, from MyCERT’s August advisory for the same chain: /tmp/pe_worker_trace.log, /var/mobile/Media/PostLogs.txt, RemoteLog.log, ios_disk_scan.txt

Related infrastructure, from passive sources; roles unverified:

• hjih9[.]com / tlslfc[.]cc — a Google-indexed kit directory replaced by a scam page mid-campaign; parkpeark[.]xyz — the August lure domain from MyCERT advisory MA-1480.082026
• Same-provider cluster around the C2 box: webim/xinim/ujkwl/adminemsd[.]blgim168168[.]com, blg88888[.]com, turtlesoup[.]cloud, lai09[.]top, luke616[.]xyz
• March leaked-campaign hosts, from the captured-ITW repositories: kit host static[.]cdncounter[.]net, implant C2 sqwas[.]shapelie[.]com (ports 8881/8882)

I am deliberately not publishing a small set of indicators that appear to belong to infrastructure still being staged: releasing them now would tell the operators what is watched and prompt rotation before defenders benefit. They will be added once they rotate or are otherwise reported.