Skip to main content

DarkSword and the LLM Question: What Every Outlet Mentioned but Nobody Wrote About

· 24 min read
Dhayabaran V
Dhayabaran V
Barrack AI

On March 18, 2026, Lookout, Google's Threat Intelligence Group (GTIG), and iVerify published coordinated research disclosing DarkSword, a full-chain iOS exploit kit targeting iPhones running iOS 18.4 through 18.7. Within 48 hours, every major cybersecurity outlet covered the story. They covered the six CVEs, the three zero-days, the exploit chain walkthrough, the 270 million affected devices, the threat actor attribution, and the Coruna connection. But buried inside nearly every article was a finding that none of them turned into its own piece: indicators of LLM-assisted code inside a mass-deployed iOS exploit kit.

Seven separate outlets mentioned it. CyberScoop, BleepingComputer, Dark Reading, PBX Science, Lookout (the primary source), Infosectoday, and FoneArena all referenced some version of the finding. Not one published a standalone analysis. Every outlet treated it as a bullet point inside a broader DarkSword explainer. Notably, Help Net Security and The Hacker News covered DarkSword without mentioning the LLM angle at all.

This is that standalone analysis.

What follows is a precise, source-attributed breakdown of what Lookout actually found, what Google GTIG and iVerify did and did not say, how this compares to every prior documented case of LLM-assisted malware, and what it means for the mobile threat landscape. Every claim is sourced. Every qualifier is preserved. Where the evidence is circumstantial, we say so.

Table of Contents​

What DarkSword is (brief context)​

DarkSword is a JavaScript-based iOS exploit kit that chains six vulnerabilities (CVE-2025-31277, CVE-2025-43529, CVE-2026-20700, CVE-2025-14174, CVE-2025-43510, CVE-2025-43520) to achieve full device compromise. Three of these were zero-days when first exploited. The kit targets iPhones running iOS 18.4 through 18.7 and was first detected in November 2025 by Lookout researchers investigating the Coruna exploit kit's infrastructure.

Google GTIG identified three distinct threat actor groups using DarkSword: UNC6353 (suspected Russian, targeting Ukraine via watering hole attacks), UNC6748 (targeting Saudi Arabia via a fake Snapchat website), and PARS Defense (a Turkish commercial surveillance vendor targeting Turkey and Malaysia). Each group deployed different payloads: GHOSTBLADE, GHOSTKNIFE, and GHOSTSABER respectively.

iVerify estimated that approximately 14.2% of active iPhones, around 221 million devices running iOS 18.4 through 18.6.2, remain vulnerable. When including all iOS 18 versions, that figure rises to roughly 270 million devices.

The technical exploitation details, CVE walkthrough, and threat actor attribution have been covered exhaustively by Lookout, Google GTIG, iVerify, and others. This piece does not rehash that ground. It focuses on the finding that every outlet mentioned but none analyzed.

What Lookout found: the LLM indicators​

Of the three research teams involved in the coordinated disclosure, only Lookout identified LLM-assistance indicators. Their published report contains four specific passages referencing LLM or AI, each carefully qualified.

The first addresses the DarkSword File Receiver, a server-side component hosted at sqwas.shapelie[.]com on ports 8881 and 8882. Lookout noted indicators suggesting this infrastructure component was created with LLM assistance, citing specific artifacts: a folder emoji in the heading and a checkmark symbol.

The second and third passages appear together in the UNC6353 threat actor analysis section. Lookout stated that no attempts were made to obfuscate the exploit chain or implant code. They noted the presence of numerous comments and log messages in the JavaScript code. Their assessment: analysis of patterns suggests that LLMs were used in the creation of at least some of the implant code.

Lookout then offered a direct interpretation and an alternative: it appears probable that UNC6353 lacks first-hand experience with mobile exploits and may have relied on AI support to add functionality to purchased tooling. Alternatively, this code may have been added prior to the threat actor's acquisition of the tooling.

The fourth passage appears in Lookout's conclusion, where they note that groups purchasing exploit kits can customize them for their specific purposes, possibly with the help of AI.

The specific indicators Lookout cites for LLM involvement are: a folder emoji in the File Receiver heading, a checkmark symbol in the same heading, numerous comments and log messages throughout the JavaScript code, and pattern analysis of the implant code itself.

The qualifying language matters. Lookout uses "indicators" (not proof), "suggests" (not confirms), "appears probable" (not certain), "at least some" (scoped to a portion of the codebase), and "possibly" (hedged). They immediately offer an alternative explanation for every claim they make. This is deliberate precision from a research team that knows their finding will be scrutinized.

These indicators are consistent with LLM-generated output but are not exclusively attributable to it. Folder emojis, checkmark symbols, explanatory comments, and unobfuscated JavaScript are also consistent with code written by a developer who writes clean documented code, or code written for demonstration purposes, or code that was simply never stripped before deployment. No code fingerprinting, model attribution, or prompt artifact analysis has been published by any of the three research teams.

What GTIG and iVerify did not say​

This section matters as much as the previous one.

Google GTIG's published blog post contains zero mentions of LLM, AI, or artificial intelligence. GTIG noted that GHOSTBLADE (the payload deployed by UNC6353) had debug logging and comments in the code, but drew no AI or LLM inference from this observation. GTIG's analysis focused entirely on technical exploitation, vulnerability mechanics, and threat actor attribution.

iVerify's published blog post also contains zero LLM or AI claims. iVerify documented the same code characteristics that Lookout cited: the JavaScript was not obfuscated, it contained original variable names, and it featured comments left by the exploit authors. iVerify also noted that the entire chain contains verbose logging and commentary on how to use exploits and implants. But iVerify attributed these characteristics to typical exploit development practices, not to AI assistance.

This is not a contradiction between the research teams. Lookout performed a specific pattern analysis that led them to an LLM-assistance assessment. GTIG and iVerify observed the same surface-level code characteristics (comments, lack of obfuscation) but did not perform or publish the same pattern analysis. It is worth noting, however, that of the three teams, only one reached the LLM conclusion.

The developer-operator split and language mismatch​

Three separate evidence threads support the conclusion that DarkSword's developer and its operators are different entities. This distinction is directly relevant to the LLM finding because it determines who used the LLM: the developer who built the toolkit, or the operator who customized it after purchase.

GTIG provided the structural evidence. Their blog distinguishes throughout between "the DarkSword developers" and the three operator groups. GTIG assessed that each actor built their delivery mechanisms on a base set of logic from the DarkSword developers and made tweaks to fit their own needs. GTIG also assessed that GHOSTBLADE was likely developed by the DarkSword developers, based on consistency in coding styles and tight integration with the library code. This is notably distinct from how GHOSTKNIFE and GHOSTSABER leveraged those same libraries.

Lookout stated that, as with Coruna, it appears likely that the threat actor gained access to an exploit and post-exploitation toolkit built by a third party. They also noted that the use of BaseHTTPServer together with the HTML content served by the File Receiver endpoint indicates that server-side code may have been included in the sale of DarkSword for demonstration purposes.

The language mismatch provides supporting evidence. iVerify reported that early stages of the exploit (assets/index.html and /widget.js) contained comments written in Russian, while all further stages contained comments written in English. GTIG identified a specific Russian comment in UNC6353's loader. The exploit codebase itself used English variable names and deployment instructions.

Rocky Cole, iVerify's co-founder, told CyberScoop directly: DarkSword is hosted on the same command-and-control infrastructure as Coruna, but is an entirely separate kit made by entirely separate people.

This developer-operator split is what makes Lookout's alternative explanation analytically honest. When Lookout says the LLM-patterned code "may have been added prior to the threat actor's acquisition of the tooling," they are acknowledging that the developer, not UNC6353, may have been the one using the LLM. The evidence does not definitively resolve which entity introduced the LLM-assisted code.

The obfuscation gradient across operators​

One of the most analytically revealing details in the coordinated disclosure is how three different operators handled the same exploit kit's code hygiene. This gradient provides indirect supporting evidence for Lookout's LLM-related assessment.

UNC6353, the suspected Russian group targeting Ukraine, deployed DarkSword with what Lookout described as a complete lack of obfuscation. No JavaScript obfuscation, no HTML obfuscation, no infrastructure naming obfuscation. The server-side component was labeled "Dark sword file receiver" in plain text. Justin Albrecht, Lookout's global director of mobile threat intelligence, told CyberScoop that experienced Russian threat actors like APT29 would be expected to have better OPSEC.

PARS Defense, the Turkish commercial surveillance vendor, deployed the same exploit kit with significant obfuscation. GTIG noted that PARS Defense applied obfuscation to the exploit loader and some exploit stages, used ECDH and AES encryption between server and victim, and implemented version-specific exploit selection based on detected iOS version.

UNC6748, targeting Saudi Arabia, fell between the two: basic obfuscation initially, with anti-debugging and additional obfuscation added in updates through November 2025.

This gradient directly supports one of Lookout's two hypotheses. The operator (UNC6353) that shows the strongest indicators of LLM-assisted customization also shows the weakest operational security. Lookout wrote that UNC6353 may not have access to strong engineering resources or, alternatively, is not concerned with taking appropriate OPSEC measures. This is precisely the scenario where LLM assistance would provide the most value: an operator with ambition beyond their technical capability using AI to bridge the gap.

Prior art: LLM-assisted malware before DarkSword​

Before DarkSword, no documented case of LLM-assisted malware involved mass-scale deployment against mobile devices. Every prior case was either experimental, desktop-only, limited in scope, or assessed as operationally ineffective.

PROMPTSTEAL (June 2025, Google GTIG): A Python data miner used by APT28/FROZENLAKE against Ukraine. It queried Qwen2.5-Coder via the Hugging Face API to generate Windows commands at runtime. GTIG described it as their first observation of malware querying an LLM in live operations. It targeted desktop systems, not mobile devices, and was limited in scale.

PROMPTFLUX (June 2025, Google GTIG): An experimental VBScript dropper that attempted to use Google Gemini 1.5 Flash for self-modification. GTIG stated that the current state of this malware does not demonstrate an ability to compromise a victim network or device. It remained in development and testing.

Netskope Threat Labs (November 2025): Published a lab feasibility study testing GPT-3.5-Turbo and GPT-4 integration with malware. Their conclusion: LLM-powered malware was too unreliable and ineffective for operational deployment. The code generated by GPT-4 and GPT-3.5-Turbo had low success rates for virtualization evasion, with Netskope characterizing this as a significant hurdle to full automation of the malware lifecycle.

Palo Alto Unit 42 (March 2026): Analyzed malware samples incorporating OpenAI GPT-3.5-Turbo API calls. Their finding: none of these calls positively impact the malware's operation, and they add noise. Unit 42 stated they are not aware of any examples in the wild of locally executed agentic attack flows.

HP Wolf Security (September 2024): Identified what they characterized as significant evidence of GenAI-written malware in the wild, specifically an AsyncRAT campaign. This was desktop-only and limited in scale.

Anthropic Claude abuse cases (August to November 2025): Multiple incidents including a cybercriminal who used Claude Code for data extortion across 17 organizations. Anthropic described one case involving a Chinese state-sponsored group as the first documented AI-orchestrated cyberattack at scale. These were targeted operations, not mass mobile exploitation.

Every single one of these cases operated on desktop platforms, targeted limited victim sets, or was assessed by researchers as experimental and operationally unreliable. None involved mobile devices. None involved a professional-grade exploit kit chaining zero-day vulnerabilities. None reached the deployment scale of DarkSword.

Why DarkSword is different from everything before it​

DarkSword is not "LLM-powered malware" in the way that PROMPTSTEAL or PROMPTFLUX are. Those samples query LLMs at runtime. DarkSword does not call out to any AI service during execution. The distinction is important.

What Lookout identified is different: indicators suggesting that LLMs were used during the development and customization phase. The AI assistance, if Lookout's assessment is accurate, was applied to the code before deployment, not during it. This is the difference between a tool that uses AI and a tool that was built with AI assistance.

That difference does not diminish the significance. It may increase it.

Prior LLM-assisted malware was experimental. PROMPTFLUX could not compromise a victim. Netskope concluded LLM integration was unreliable. Unit 42 found that LLM API calls added noise without operational benefit. The malware ecosystem's experiments with AI had, up to this point, produced results that researchers consistently described as immature and ineffective.

DarkSword is a six-vulnerability, three-zero-day, full-chain iOS exploit kit that achieves sandbox escape, kernel privilege escalation, and complete data exfiltration without leaving persistent traces. It was deployed across four countries by three distinct threat actor groups, including at least one suspected state-sponsored entity. It targets potentially hundreds of millions of devices.

If Lookout's assessment is correct that LLM assistance was used in its development or customization, DarkSword represents a qualitative shift. Not because AI made the exploit chain possible (the core vulnerabilities and exploit development were produced by a technically sophisticated developer, as evidenced by the developer-operator split). But because AI may have enabled operators without mobile exploit experience to customize and deploy a professional-grade toolkit they could not have modified on their own.

That is the scenario Lookout describes when they assess that UNC6353 appears to lack first-hand experience with mobile exploits and may have relied on AI support to add additional functionality to purchased tooling.

The secondary market thesis​

The LLM finding does not exist in isolation. It sits inside a broader structural shift that Lookout, iVerify, and GTIG each documented from different angles.

Lookout was the most direct. They stated that the discoveries of DarkSword and previously Coruna prove that a second-hand market exists for such exploits, one that enables groups with more limited resources and motives other than highly targeted espionage to acquire top-of-the-line exploits. They described a secondary market for technically sophisticated exploit chains in which unscrupulous sellers are willing to serve buyers with no concerns for how the tools will be used.

Lookout also assessed that UNC6353 has access to a supply of high-quality iOS exploit chains likely developed for tier-1 commercial surveillance vendors (CSVs), and that some exploits appear to have been zero-days when first deployed. This indicates, according to Lookout, that UNC6353 is likely well funded and may have connections to exploit brokers such as Matrix LLC / Operation Zero.

Matthias Frielingsdorf, iVerify's co-founder, told Dark Reading that the share of users running legacy iOS versions is large enough for threat actors to target and support a thriving secondary market for n-day exploits. He stated that iVerify predicted this exact scenario and that it is coming to pass.

The LLM angle connects to this market thesis at a specific point. If professional-grade exploit kits are being sold on a secondary market to operators who lack the technical sophistication to use them, LLMs become the missing piece that makes the transaction viable. The operator does not need to understand iOS sandbox escape internals. They need to understand how to prompt an LLM to customize the kit for their target set. CyberScoop reported that Albrecht described this as a development that effectively lowers the barrier to entry for deploying advanced mobile exploits, even among state-sponsored actors.

A note on the dual-kit claim: CyberScoop reported that Lookout observed LLM usage in both Coruna and DarkSword. BleepingComputer independently confirmed this, noting that LLM indicators are "particularly visible in the case of DarkSword." This dual-kit claim does not appear in Lookout's published blog post. It was evidently communicated during media briefings. We include it here attributed to the journalist reporting, not to Lookout's published research.

What this means​

DarkSword does not prove that AI is creating unstoppable super-malware. The exploit chain's sophistication comes from the developer, not from AI. The six CVEs, the sandbox escape, the kernel privilege escalation: these are the product of expert vulnerability research, not LLM prompting.

What DarkSword does represent, if Lookout's assessment holds, is the first documented instance where LLM-assistance indicators appear in a mass-deployed, professional-grade mobile exploit kit. Every prior case of LLM-assisted malware was experimental, desktop-only, limited in scale, or assessed as operationally ineffective. DarkSword is none of those things.

The security implications are specific and practical. The secondary exploit market that Lookout and iVerify describe is real and documented. If LLMs lower the customization barrier for operators purchasing exploit kits, the pool of actors capable of deploying iOS zero-day chains expands. Not because AI makes exploits, but because AI makes purchased exploits usable by actors who could not otherwise customize them.

GTIG noted that they assess it is likely that additional commercial surveillance vendors and threat actors have acquired and are using DarkSword in campaigns not yet documented by researchers. If LLM-assisted customization is part of that adoption curve, the pace of proliferation may accelerate.

For now, the evidence is what it is: a single research team's carefully hedged assessment based on circumstantial indicators. That assessment has not been contradicted by the other two research teams, but it has not been independently corroborated either. The responsible framing is that Lookout identified indicators suggesting LLM assistance. Not more, not less.

The fact that eight outlets mentioned this finding and none wrote the analysis does not make the finding stronger. But it does suggest that the security journalism ecosystem treated a potentially significant shift as a footnote. Whether that assessment proves correct will depend on what researchers find in DarkSword campaigns that have not yet been documented, and whether future exploit kit disclosures reveal similar LLM-assistance patterns.

Update your iPhone. iOS 26.3.1 patches all six DarkSword CVEs. If you are on iOS 18, update to 18.7.6 at minimum. High-risk users should enable Lockdown Mode.

FAQ​

What is DarkSword?​

DarkSword is a JavaScript-based full-chain iOS exploit kit targeting iPhones running iOS 18.4 through 18.7. It chains six vulnerabilities, three of which were zero-days, to achieve full device compromise. It was disclosed on March 18, 2026 by Lookout, Google GTIG, and iVerify in a coordinated publication.

Did DarkSword use AI or LLM-generated code?​

Lookout identified indicators suggesting LLM assistance was used in the creation of at least some of DarkSword's implant code. The specific indicators include emoji markers in code headings, numerous explanatory comments, log messages, and unobfuscated JavaScript. Lookout uses qualifying language: "suggests," "appears probable," "at least some." They also note that the code may have been added before the operator acquired the toolkit. Google GTIG and iVerify did not make any LLM claims in their published reports.

Is DarkSword the first malware to use LLM-assisted code?​

No. Prior documented cases include PROMPTSTEAL, PROMPTFLUX, and samples analyzed by Netskope Threat Labs and Palo Alto Unit 42. However, all prior cases were either experimental, desktop-only, limited in scale, or assessed as operationally ineffective. DarkSword is the first documented case where researchers identified LLM-assistance indicators in a mass-deployed, professional-grade mobile exploit kit affecting potentially hundreds of millions of devices.

How many devices are affected by DarkSword?​

iVerify estimated that approximately 14.2% of active iPhones (around 221 million devices) running iOS 18.4 through 18.6.2 are vulnerable. When including all iOS 18 versions, the figure rises to approximately 270 million devices. These figures measure the blast radius of the exploit chain itself, not the LLM-assisted customization specifically.

Who is behind DarkSword?​

Google GTIG identified three distinct threat actor groups using DarkSword: UNC6353 (suspected Russian, targeting Ukraine), UNC6748 (targeting Saudi Arabia), and PARS Defense (a Turkish commercial surveillance vendor, targeting Turkey and Malaysia). The developer of DarkSword appears to be a separate entity from all three operators.

What CVEs does DarkSword exploit?​

DarkSword chains six CVEs: CVE-2025-31277 and CVE-2025-43529 (JavaScriptCore memory corruption), CVE-2026-20700 (dyld PAC bypass), CVE-2025-14174 (ANGLE memory corruption), CVE-2025-43510 (kernel memory management), and CVE-2025-43520 (kernel memory corruption). Three of these (CVE-2025-43529, CVE-2026-20700, CVE-2025-14174) were zero-days when first deployed.

How do I protect my iPhone from DarkSword?​

Update to iOS 26.3.1, the latest release, which patches all six DarkSword CVEs. If you are on iOS 18, update to iOS 18.7.6 at minimum. High-risk users such as journalists, activists, and government officials should enable Lockdown Mode, available since iOS 16. iVerify is offering its iVerify Basic app for free until May 2026, which includes DarkSword threat hunting capability.

What is the connection between DarkSword and Coruna?​

DarkSword was discovered by Lookout while investigating Coruna's infrastructure. Both exploit kits were deployed by UNC6353 against Ukrainian targets and share command-and-control infrastructure. However, Rocky Cole of iVerify told CyberScoop that DarkSword is an entirely separate kit made by entirely separate people. CyberScoop and BleepingComputer reported that Lookout observed LLM usage in both kits, though this dual-kit claim does not appear in Lookout's published blog.

Is the evidence that DarkSword used LLMs conclusive?​

No. The evidence is circumstantial. Lookout identified indicators consistent with LLM-generated output: emoji markers, explanatory comments, unobfuscated code, and pattern analysis. These indicators are also consistent with code written by a junior developer or code that was not cleaned before deployment. Lookout explicitly offers an alternative explanation: the LLM-patterned code may have been added by the developer before the operator acquired the toolkit. No code fingerprinting, model attribution, or prompt artifact analysis has been published by any of the three research teams.

Last updated: March 20, 2026

Sources: Lookout | Google GTIG | iVerify | CyberScoop | BleepingComputer | Dark Reading | PBX Science | Infosectoday | FoneArena

At Barrack AI, we provide GPU cloud infrastructure for AI and ML workloads. If you are running security research, threat analysis, or any compute-intensive workload, explore our H100, H200, and B200 GPU instances with per-minute billing and zero egress fees.