DarkSword iOS Exploit Kit: Full-Chain Takeover & 3 Zero-Days in the Wild
Just caught the GTIG report on the new 'DarkSword' exploit kit, and it's a nightmare scenario for iOS security. It looks like multiple commercial surveillance vendors—and likely some state-sponsored actors—have been actively using this since at least November 2025.
The kit chains together six vulnerabilities, including three zero-days, to achieve a full device takeover. While specific CVEs are still being assigned (expect CVE-2026-xxxx identifiers shortly), the architecture implies a sophisticated attack vector:
- Initial RCE: Likely targeting WebKit rendering engines.
- Sandbox Escape: Breaking out of the application container.
- Kernel Privilege Escalation: Bypassing Pointer Authentication Codes (PAC) to gain root.
Standard MDM solutions often miss these kernel-level implants. If you're investigating a compromised device, you usually have to rely on low-level forensics. I've been parsing sysdiagnose logs to look for artifacts of the initial staging process. Here is a quick script to scan for suspicious configuration profiles often used for persistence:
import plistlib
import os
import glob
def scan_ios_profiles(backup_path):
# Recursively find mobileconfig files in a backup dump
profiles = glob.glob(f"{backup_path}/**/*.mobileconfig", recursive=True)
suspicious_indicators = ['RootCertificate', 'com.apple.system', 'VPN']
for profile_path in profiles:
with open(profile_path, 'rb') as f:
try:
data = plistlib.load(f)
data_str = str(data)
if any(indicator in data_str for indicator in suspicious_indicators):
# Check for unusual signing or identifiers
if 'PayloadIdentifier' in data and not 'apple.com' in data['PayloadIdentifier']:
print(f"[!] Suspicious profile found: {profile_path}")
except (ExpatError, ValueError) as e:
continue
# Usage: scan_ios_profiles('/path/to/device/backup')
Given that this is a 'for-hire' surveillance tool, it's highly targeted. However, the proliferation of the exploit kit is concerning. Is anyone else seeing anomalies in their mobile fleet, or are we all just enabling Lockdown Mode and hoping for the best?
We rolled out mandatory Lockdown Mode to all executives immediately after the IOCs dropped. It breaks some link previews and calendar invites, but it's currently the only reliable defense against WebKit exploits of this caliber.
Regarding your script: sophisticated actors like this often patch the kernel to hide files from glob. You might want to compare the filesystem dump against the official OS manifest to catch hidden discrepancies.
This reminds me of the FORCEDENTRY chain a few years back. The escalation speed is terrifying—we went from disclosure to active exploitation in months.
For detection, don't forget to check the Baseband logs. Sometimes the exploit attempts leave residual errors in the cellular modem logs before the kernel payload succeeds. It's a long shot, but it's a good indicator of compromise (IoC) when nothing else shows up.
With six exploits chained, traditional signatures will lag behind. We should pivot to behavioral anomalies in MDM telemetry. Specifically, watch for rapid process execution following iMessage receipt, a common vector for these kits.
You can hunt for suspicious parent-child process relationships with this KQL query:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "imservice"
| where FileName !~ "assetsd"
Has anyone successfully decrypted the payload to identify the C2 callback domains?
Agreed on the telemetry focus, Pete. Complementing that, we should inspect sysdiagnose logs for pre-exploitation WebKit instability. These zero-days often leave residual memory corruption artifacts before the final payload executes. If you're aggregating logs via your SIEM or macOS server, try hunting for specific crash indicators:
find /var/log -name "*.ips" -exec grep -l "WebKit" {} \; | xargs grep "EXC_BAD_ACCESS"
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access