Rules from EXP DarkSword Exploit Framework Multi-Stage Exploitation and Malware Delivery Platform

Report Type

Threat Intelligence Assessment

Threat Category

Exploit Framework Activity
Multi-Stage Exploitation Chain
Client-Side Exploitation and Malware Delivery

Assessment Date

March 24, 2026

Primary Impact Domain

Endpoint Security (iOS / Mobile Platform)
Exploit Chain Execution and Detection Evasion
Device-Level Trust Boundaries and Telemetry Visibility

BLUF

‍S2 BLUF – Recommended Executive-Grade Summary

 The DarkSword exploit framework presents a material business risk by enabling full-chain device compromise that can lead to covert surveillance, credential theft, and exposure of sensitive or regulated data through downstream malware deployment. The technical cause is a multi-stage exploit chain that leverages vulnerability exploitation to achieve initial access, privilege escalation, and controlled payload delivery within targeted environments. Current threat posture indicates elevated operational risk because exploit chaining can limit early observable indicators and create a direct path from vulnerability exposure to malware delivery. Executive action should prioritize platform hardening, accelerated vulnerability remediation, and deployment of behavior-based detection across endpoint and network telemetry.

‍ ‍

S2A Executive Risk Translation

‍ ‍

If vulnerable platforms or applications remain exposed, DarkSword can achieve full device compromise and silently deliver malware, increasing the likelihood of undetected access to sensitive data, persistent surveillance, and sustained operational impact.

‍ ‍

S3 Why This Matters Now

DarkSword reflects the increasing use of exploit frameworks that combine multiple vulnerabilities into a single execution chain capable of bypassing platform security layers and exploit mitigation controls. These frameworks target mobile operating systems, device components, and application layers where remediation delays, software fragmentation, and exposure conditions create exploitable gaps. The ability to move directly from exploitation to payload delivery creates a compressed attack path from vulnerability exposure to persistent compromise with minimal detection opportunity.

‍ ‍S25 Ultra-Tuned Detection Engineering Rules

Implementation Integrity Statement
S25 is considered complete when each platform is written to its maximum truthful detection strength and real-world deployability constraints are embedded directly in the rule fields. Differences in platform visibility or telemetry depth do not constitute a framework failure when those constraints are explicitly documented and the rule remains threat-specific, phase-pure, and operationally honest.

Suricata

Deployment Status

Conditionally Deployable

Corroborating Only
Rule Name

DarkSword iOS Repeated Non-Approved DNS Burst Corroborator

Purpose

Provide low-noise network corroboration for suspected DarkSword exploit-trigger windows by identifying repeated DNS queries from iOS-managed traffic to non-approved destinations.
ATT&CK Technique
T1203 – Exploitation for Client Execution

Telemetry Dependency

Suricata DNS telemetry
Reliable iOS device attribution through subnet segmentation, NAC tagging, or equivalent source identity mapping
Maintained allowlists for Apple infrastructure, MDM services, enterprise proxy infrastructure, enterprise security tooling, and sanctioned mobile application dependencies
This rule is not deployable as intended in environments where iOS traffic cannot be distinguished from general user traffic.

Network activity in this rule is limited to immediate post-instability onset and is used strictly as Phase 1 corroboration, not as post-exploitation communication detection.

Tuning Explanation

This rule is intentionally constrained to a corroborating role because DarkSword Phase 1 activity is primarily device-side and WebKit-driven. It is tuned to remain low-noise by limiting scope to attributed iOS-managed traffic and excluding known benign mobile infrastructure. If iOS attribution or allowlist maturity is weak, the rule should be disabled or downgraded rather than broadened into a generic DNS burst analytic.

Detection Logic

Trigger when a single attributed iOS source performs six or more DNS queries to non-approved destinations within 120 seconds.

Operational Context

Use only as a low-confidence supporting signal that is correlated with repeated WebKit instability or abnormal post-crash behavior from the same device population. This rule must not be used as a standalone exploit detector or as a high-severity alert trigger.

var IOS_NETS [10.50.0.0/16,10.51.0.0/16]
var APPROVED_MOBILE_DESTS [17.0.0.0/8,52.96.0.0/12,13.107.6.0/24]

alert dns $IOS_NETS any -> !$APPROVED_MOBILE_DESTS any (
    msg:"CYBERDAX DarkSword iOS repeated non-approved DNS burst corroborator";
    dns.query;
    threshold:type both, track by_src, count 6, seconds 120;
    classtype:policy-violation;
    metadata:attack_target Mobile_Device, confidence Low, role Corroborating;
    sid:2542101;
    rev:9;
)
Deployment Status

Conditionally Deployable
Corroborating Only

Rule Name
DarkSword iOS Early TLS Session Burst Corroborator

Purpose

Identify tightly grouped outbound TLS session initiation from iOS-managed traffic during suspected exploit-trigger windows.

ATT&CK Technique
T1203 – Exploitation for Client Execution

Telemetry Dependency

Suricata TLS metadata
Reliable iOS device attribution through subnet segmentation, NAC tagging, or equivalent source identity mapping
Maintained allowlists for Apple, MDM, enterprise proxy, enterprise security tooling, and sanctioned mobile application infrastructure
This rule is not deployable as intended where mobile traffic cannot be attributed with reasonable confidence.

Tuning Explanation

This rule remains corroboration-only because benign iOS devices regularly generate TLS activity. It is tuned to reduce false positives by requiring grouped session onset and by excluding common benign destinations. If destination filtering and iOS attribution are not operationally mature, this rule should be disabled instead of being widened into a generic TLS burst detector.

Detection Logic
Trigger when the same attributed iOS source initiates three or more outbound TLS sessions to non-approved destinations within 180 seconds.

Operational Context

Use only alongside device-side instability analytics or same-device correlation in a SIEM. This rule is intended to strengthen confidence in a suspected exploit window, not to independently identify DarkSword exploitation.

alert tls $IOS_NETS any -> !$APPROVED_MOBILE_DESTS any (
    msg:"CYBERDAX DarkSword iOS TLS burst corroborator";
    flow:established,to_server;
    threshold:type both, track by_src, count 3, seconds 180;
    classtype:trojan-activity;
    sid:2542102;
    rev:9;
)

SentinelOne

Deployment Status

Conditionally Deployable

Rule Name

DarkSword Repeated WebKit Crash Threshold

Purpose

Detect exploit-trigger instability via repeated WebKit or Safari crash behavior on the same iOS device.

ATT&CK Technique
T1203 – Exploitation for Client Execution

Telemetry Dependency

Normalized iOS crash telemetry ingested into SentinelOne or a validated connected analytics pipeline
Stable device identifier
Normalized naming for MobileSafari, SafariViewService, or WebKit-linked crash context
This rule is not deployable in environments where SentinelOne does not actually receive normalized mobile crash telemetry.

Tuning Explanation

This rule is valid only where iOS crash telemetry is present and normalized. It is not acceptable to emulate this logic using desktop-oriented browser crash or generic process telemetry. Tuning relies on repeated crash behavior inside a five-minute interval and assumes lab, QA, and crash-test populations are tagged and excluded.

Detection Logic

Trigger when three or more WebKit- or Safari-linked crash events occur on the same device within five minutes.

Operational Context

Use only in environments with validated mobile crash ingestion. If the telemetry source is absent or inconsistent, mark the rule not deployable rather than degrading it into a generic browser-instability detector.

EventType = "MobileCrash"
AND (
  AppName RegExp "(?i)(MobileSafari|SafariViewService|WebKit)"
)
| group by DeviceId, bin(Time, 5m)
| where count() >= 3
AND NOT DeviceTag IN ("MobileQALab","CrashTest","MDMValidation")

Deployment Status

Conditionally Deployable

Rule Name

DarkSword Crash-to-Abnormal-Recovery Correlation

Purpose

Detect exploit progression by correlating repeated crash behavior with abnormal recovery behavior on the same iOS device.

ATT&CK Technique
T1203 – Exploitation for Client Execution

Telemetry Dependency

Normalized iOS crash telemetry
Normalized mobile abnormal recovery or execution-anomaly telemetry
Stable device identifier across both telemetry streams
This rule is not deployable in environments where post-crash anomaly telemetry is absent or unreliable.

Tuning Explanation

This rule remains Phase 1 pure because it focuses on exploit-trigger progression immediately following instability and does not depend on payload or communication telemetry. It is tuned to require both repeated crash behavior and one abnormal recovery-type event in the same bounded interval. If abnormal recovery telemetry is not present, this rule should not be forced into production as a partial substitute.

Detection Logic

Trigger when three or more WebKit- or Safari-linked crash events are followed by at least one abnormal recovery or execution-anomaly event on the same device within five minutes.

Operational Context

Use only where both crash telemetry and abnormal recovery telemetry are available from mobile sources and normalized to the same device identity. This is the higher-confidence SentinelOne Phase 1 analytic only in those environments.

(
  EventType = "MobileCrash"
  AND AppName RegExp "(?i)(WebKit|Safari)"
)
| group by DeviceId, bin(Time, 5m)
| where count() >= 3
| join (
    EventType = "MobileRecoveryAnomaly"
    | group by DeviceId, bin(Time, 5m)
) on DeviceId

Splunk

Deployment Status

Production-Deployable

Rule Name

DarkSword Repeated WebKit Instability (Time-Bound)

Purpose

Detect repeated exploit-trigger instability using precise timing correlation on the same iOS device.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

Normalized iOS crash logs
Stable device identifier
Normalized application or process naming for WebKit, MobileSafari, or Safari-linked crash context

Tuning Explanation

This is the low-confidence precursor analytic. It is tuned using a bounded interval derived from earliest and latest event timestamps rather than broad time bucketing, which reduces timing smear. It is intentionally lower severity and should be escalated only when same-device behavioral or network corroboration is present.

Detection Logic

Trigger when three or more WebKit- or Safari-linked crash events occur on the same device inside 300 seconds.

Operational Context

Use as the baseline Phase 1 detector where crash telemetry is stable, normalized, and tied to a trustworthy device identifier.

index=mobile_crash process="*WebKit*" OR process="*Safari*"
| stats count earliest(_time) as first latest(_time) as last by device_id
| where count >= 3 AND (last - first) <= 300

Deployment Status

Production-Deployable

Rule Name

DarkSword Instability + Recovery Correlation

Purpose

Detect exploit-trigger progression with higher confidence by correlating repeated WebKit instability with abnormal post-crash recovery behavior on the same device.

ATT&CK Technique

T1203 – Exploitation for Client Execution
Telemetry Dependency

Normalized iOS crash logs
Normalized abnormal recovery or execution-anomaly logs
Stable device identifier
Reasonably aligned timestamps across sources

Tuning Explanation

This is the preferred Splunk Phase 1 production analytic because it materially reduces false positives by requiring both repeated instability and same-device abnormal recovery. It stays Phase 1 pure and avoids reliance on later network or payload behavior. Operationally, it assumes time alignment and device normalization are already solved upstream.

Detection Logic

Trigger when three or more WebKit- or Safari-linked crash events and at least one abnormal recovery or execution anomaly occur on the same device within five minutes.

Operational Context

Use where crash telemetry and abnormal recovery telemetry are both available, normalized, and attributed to the same device. If device identity is weak or timestamps are materially delayed, this rule should be downgraded to hunt support.

(
  search index=mobile_crash (
      app_name="MobileSafari" OR
      app_name="SafariViewService" OR
      process_name="WebKit*" OR
      process_name="Safari*"
  )
  | stats count earliest(_time) as first_crash latest(_time) as last_crash by device_id
  | where count >= 3 AND (last_crash - first_crash) <= 300
)
| join type=inner device_id [
    search index=mobile_behavior event_type="abnormal_recovery"
    | stats earliest(_time) as anomaly_time by device_id
]
| where anomaly_time >= first_crash AND anomaly_time <= last_crash + 300

Deployment Status

Production-Deployable
Environment-Dependent on Same-Device Network Attribution

Rule Name

DarkSword Phase 1 Multi-Signal Convergence

Purpose

Detect high-confidence DarkSword exploit-trigger progression through same-device correlation of repeated WebKit instability, abnormal recovery behavior, and near-term first-seen outbound communication.

ATT&CK Technique

T1203 – Exploitation for Client Execution
T1071 – Application Layer Protocol

Telemetry Dependency

iOS crash telemetry
Abnormal recovery telemetry
DNS or TLS telemetry with first-seen destination enrichment
Reliable same-device attribution across crash, behavior, and network sources
This rule is not production-deployable as written where device-to-network normalization is weak or absent.

Tuning Explanation

This is the highest-confidence Phase 1 analytic in Group 1. It is intentionally conservative and requires three-signal convergence inside a bounded interval. It remains Phase 1 because it detects exploit-trigger progression and immediate corroboration rather than later payload behavior. If same-device network attribution is weak, the rule should be downgraded to hunt-only rather than loosened.

Detection Logic

Trigger when repeated WebKit instability, at least one abnormal recovery event, and at least one first-seen outbound communication event occur on the same device within five minutes of the initial instability sequence.

Operational Context

Use only where crash, device anomaly, and network telemetry are all available and normalized to the same device identity. This is the preferred high-confidence SOC detector for Phase 1 in Splunk-capable environments with mature mobile telemetry correlation.

(
  search index=mobile_crash (
      app_name="MobileSafari" OR
      app_name="SafariViewService" OR
      process_name="WebKit*" OR
      process_name="Safari*"
  )
  | stats count earliest(_time) as first_crash latest(_time) as last_crash by device_id
  | where count >= 3 AND (last_crash - first_crash) <= 300
)
| join type=inner device_id [
    search index=mobile_behavior event_type="abnormal_recovery"
    | stats earliest(_time) as anomaly_time by device_id
]
| join type=inner device_id [
    search index=mobile_network first_seen_dest="true"
    | stats earliest(_time) as network_time values(dest) as dests by device_id
]
| where anomaly_time >= first_crash AND anomaly_time <= last_crash + 300
| where network_time >= first_crash AND network_time <= last_crash + 300

Elastic

Deployment Status

Production-Deployable
Environment-Dependent on normalized mobile crash and abnormal recovery telemetry

Rule Name

DarkSword Repeated WebKit Instability Threshold

Purpose

Detect probable DarkSword exploit-trigger activity by identifying repeated WebKit- or Safari-linked crash behavior on the same iOS device inside a tightly bounded interval.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

Normalized iOS crash telemetry in Elastic
Stable device identifier
Normalized process or application naming for MobileSafari, SafariViewService, or WebKit-linked crash context
This rule is not deployable as intended if mobile crash telemetry is absent, poorly normalized, or not attributable to a stable device identity

Tuning Explanation

This rule is the low-confidence Elastic precursor detector for Phase 1. It is intentionally implemented as a threshold-style production analytic because that is operationally cleaner and more maintainable than forcing repeated-event logic into an overly rigid sequence. It should remain lower severity until corroborated by same-device abnormal recovery.

Detection Logic

Trigger when three or more WebKit- or Safari-linked crash or restart events occur on the same device within five minutes.

Operational Context

Use where iOS crash telemetry is centralized in Elastic and device identity is stable. If crash telemetry is incomplete, delayed, or inconsistently normalized, downgrade to hunt support rather than loosening thresholds.

System-Ready Code

rule_name: DarkSword Repeated WebKit Instability Threshold
rule_type: threshold
index:
  - mobile-crash-*
query: >
  event.dataset:"mobile.crash" AND
  (
    process.name:/WebKit.*/ OR
    process.name:/Safari.*/ OR
    app.name:("MobileSafari" OR "SafariViewService")
  )
threshold:
  field: device.id
  value: 3
time_window: 5m
severity: low
risk_score: 35

Deployment Status

Production-Deployable
Environment-Dependent on same-device abnormal recovery visibility

Rule Name

DarkSword Repeated Instability with Abnormal Recovery Correlation

Purpose

Detect likely DarkSword exploit-trigger progression by correlating repeated WebKit instability with abnormal recovery on the same iOS device.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

Normalized iOS crash telemetry
Normalized abnormal recovery telemetry from mobile sources using the canonical value abnormal_recovery

Stable same-device identity across both event classes
This rule is not deployable as intended where abnormal recovery telemetry is absent, not normalized, or cannot be mapped to the same device

Tuning Explanation

This is the preferred Elastic Phase 1 production analytic because it materially reduces false positives by requiring repeated instability plus abnormal same-device follow-on behavior. It stays phase-pure and does not depend on payload or communication events.

Detection Logic

Trigger when a repeated WebKit instability sequence is followed by abnormal recovery on the same device within five minutes.

Operational Context

Use only where crash telemetry and abnormal recovery telemetry are both available and same-device correlation is reliable. If abnormal recovery visibility is partial, retain medium severity and use analyst confirmation rather than broadening the rule.

System-Ready Code

sequence by device.id with maxspan=5m
  [any where event.dataset == "mobile.crash"
        and (
          process.name like "WebKit*" or
          process.name like "Safari*" or
          app.name in ("MobileSafari","SafariViewService")
        )]
  [any where event.dataset == "mobile.crash"
        and (
          process.name like "WebKit*" or
          process.name like "Safari*" or
          app.name in ("MobileSafari","SafariViewService")
        )]
  [any where event.dataset == "mobile.crash"
        and (
          process.name like "WebKit*" or
          process.name like "Safari*" or
          app.name in ("MobileSafari","SafariViewService")
        )]
  [any where event.dataset == "mobile.behavior"
        and event.action == "abnormal_recovery"]

QRadar

Deployment Status

Conditionally Deployable
Production-usable only where mobile crash telemetry and same-device CRE correlation are available

Rule Name

DarkSword Repeated WebKit Instability Building Block

Purpose

Create a QRadar building block for repeated WebKit- or Safari-linked instability on the same iOS device to support higher-confidence Phase 1 CRE correlation.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

Normalized mobile crash events in QRadar
Stable device identifier or equivalent asset identity
Normalized app or process naming for MobileSafari, SafariViewService, or WebKit-linked contexts
This rule is not deployable as intended where mobile crash telemetry is not ingested into QRadar

Tuning Explanation

This content is intentionally implemented as a building block rather than a final offense rule so it can drive same-device Phase 1 correlation. It is hardened by requiring repeated instability in a short interval and should not be used by itself as a final high-severity signal.

Detection Logic

Create a building block when three or more WebKit- or Safari-linked crash or restart events occur on the same device within five minutes.

Operational Context

Use as the foundational QRadar Phase 1 signal for later CRE correlation with abnormal recovery. Keep this at low or medium confidence until a second same-device signal is present.

System-Ready Code

Building Block Name:
BB: DarkSword Repeated WebKit Instability

BB Test:
when the event(s) were detected by one or more of the following log source type(s):
  Mobile Telemetry
and when the normalized event name is:
  Crash
or
  Restart
and when at least one of the following is true:
  processname ILIKE 'WebKit%'
  processname ILIKE 'Safari%'
  appname = 'MobileSafari'
  appname = 'SafariViewService'
and when at least 3 events are seen with the same deviceid in 5 minutes

Deployment Status

Conditionally Deployable
Production-usable only where abnormal recovery telemetry exists

Rule Name

DarkSword Instability-to-Abnormal-Recovery CRE Correlation

Purpose

Detect likely DarkSword exploit-trigger progression by correlating repeated WebKit instability with abnormal recovery on the same iOS device.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

QRadar building block for repeated instability
Normalized abnormal recovery telemetry using the canonical value abnormal_recovery
Reliable same-device identity across both signal classes
This rule is not deployable as intended where abnormal recovery events are not ingested or cannot be tied to the same device identity

Tuning Explanation

This rule stays Phase 1 pure and is stronger than crash-only logic because it requires a second same-device signal. It uses ordered CRE logic: instability first, abnormal recovery second, on the same device, inside five minutes.

Detection Logic

Raise a medium-severity offense when the repeated-instability building block is followed by abnormal recovery on the same device within five minutes.

Operational Context

Use as the higher-confidence QRadar Phase 1 analytic only where both crash and abnormal recovery events are available. If only crash telemetry exists, retain the building block and do not force offense creation.

System-Ready Code

CRE Rule Name:
DarkSword Instability-to-Abnormal-Recovery CRE Correlation

Rule Logic:
when BB: DarkSword Repeated WebKit Instability has matched
and then when an event is seen with:
  eventaction = 'abnormal_recovery'
on the same deviceid
within 5 minutes after the building block match

Response:
create offense
severity: medium
magnitude: medium

YARA

Deployment Status

Conditionally Deployable
Forensic or diagnostic artifact triage only

Rule Name

DarkSword iOS WebKit Diagnostic Bundle Triage

Purpose

Support forensic triage of exported iOS diagnostic or crash bundles by identifying WebKit- and Safari-linked diagnostic structures consistent with repeated Phase 1 instability on suspected DarkSword devices.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

Collected iOS crash logs, sysdiagnose bundles, mobile diagnostic exports, or forensic artifact packages
File-access workflow capable of scanning collected diagnostic artifacts with YARA
This rule is not deployable as a real-time detector and must not be presented as an inline exploit-prevention rule

Tuning Explanation

YARA is not a primary real-time detection platform for DarkSword Phase 1. This rule is acceptable only as forensic support content for already collected diagnostics. It is intentionally scoped to iOS WebKit and Safari diagnostic structures rather than generic crash text, which keeps it threat-relevant without overstating live-detection capability.

Detection Logic

Match diagnostic or crash artifacts containing WebKit- or Safari-linked indicators plus iOS crash-reporting metadata commonly present in sysdiagnose or exported diagnostic bundles.

Operational Context

Use during incident response, forensic review, or MDM-driven diagnostic collection when a device is already suspected. Do not use as a live detection substitute.

System-Ready Code

rule CYBERDAX_DarkSword_iOS_WebKit_Diagnostic_Bundle
{
    meta:
        description = "Identifies iOS WebKit/Safari diagnostic artifacts consistent with repeated Phase 1 instability"
        author = "CyberDax Detection Engineering"
        version = "1.2"
    strings:
        $a = "WebKit" ascii nocase
        $b = "MobileSafari" ascii nocase
        $c = "SafariViewService" ascii nocase
        $d = "CrashReporter Key" ascii nocase
        $e = "Exception Type" ascii nocase
        $f = "Termination Reason" ascii nocase
        $g = "Incident Identifier" ascii nocase
        $h = "Process:" ascii nocase
    condition:
        5 of ($a,$b,$c,$d,$e,$f,$g,$h)
}

Sigma

Deployment Status

Conditionally Deployable
Portable content only where mobile crash telemetry is normalized to Sigma-compatible fields and the backend supports correlation or threshold logic

Rule Name

DarkSword Repeated WebKit Instability on iOS

Purpose

Provide portable detection logic intended for backend-native conversion for repeated WebKit- or Safari-linked instability on the same iOS device.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

Normalized mobile crash events mapped into Sigma-compatible fields
Stable device identifier
App or process fields for WebKit- or Safari-linked contexts
Backend support for same-device repeated-event thresholds
This rule is not deployable as intended if the target backend cannot express same-device repetition inside a bounded interval

Tuning Explanation

This rule is the portable precursor detector for Phase 1. It is intentionally limited to repeated instability and should be converted only where iOS crash telemetry exists in a compatible schema and the backend can enforce “same device, three or more events, five-minute window” logic.

Detection Logic

Detect repeated WebKit- or Safari-linked crash or restart events on the same device within five minutes.

Operational Context

Use as portable content feeding backend-native detection engineering. Do not treat it as a single-event detector or final high-confidence rule without backend-supported aggregation.

System-Ready Code

title: DarkSword Repeated WebKit Instability on iOS
id: 9dd2d8ef-5f36-4e64-a2c1-darksword-ios-webkit-instability
status: experimental
logsource:
  category: mobile_crash
detection:
  selection_app:
    AppName|contains:
      - 'MobileSafari'
      - 'SafariViewService'
      - 'WebKit'
  selection_action:
    EventAction:
      - 'Crash'
      - 'Restart'
  condition: selection_app and selection_action
  timeframe: 5m
level: medium
tags:
  - attack.t1203
fields:
  - DeviceId
  - AppName
  - EventAction
correlation:
  type: event_count
  group-by:
    - DeviceId
  timespan: 5m
  condition:
    gte: 3
falsepositives:
  - Repeated crash loops during QA or device validation

Deployment Status

Conditionally Deployable
Portable content only where crash and abnormal recovery telemetry are both normalized with same-device correlation support

Rule Name

DarkSword WebKit Instability with Abnormal Recovery Correlation

Purpose

Provide portable Phase 1 content for higher-confidence DarkSword exploit-trigger progression by correlating repeated instability with abnormal recovery on the same device.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

Normalized mobile crash events
Normalized abnormal recovery telemetry using the canonical value abnormal_recovery
Stable device identity in Sigma-compatible fields
Backend support for same-device bounded correlation
This rule is not deployable as intended where post-crash anomaly telemetry is unavailable or cannot be correlated to the same device

Tuning Explanation

This rule is the portable equivalent of the higher-confidence crash-plus-recovery analytics used in backend-native platforms. It remains Phase 1 pure and should be converted only where both event classes are present and same-device identity is preserved.

Detection Logic

Detect repeated WebKit instability plus abnormal recovery on the same device inside five minutes.

Operational Context

Use as portable content for backend-native correlation logic where both crash and abnormal recovery telemetry exist. Do not collapse it into crash-only logic.

System-Ready Code

title: DarkSword WebKit Instability with Abnormal Recovery Correlation
id: c304a7a2-8d38-4f43-9d2b-darksword-ios-recovery-correlation

status: experimental
logsource:
  category: mobile
detection:
  selection_crash:
    AppName|contains:
      - 'MobileSafari'
      - 'SafariViewService'
      - 'WebKit'
    EventAction:
      - 'Crash'
      - 'Restart'
  selection_recovery:
    EventAction: 'abnormal_recovery'
  condition: selection_crash and selection_recovery
  timeframe: 5m
level: high
tags:
  - attack.t1203
fields:
  - DeviceId
  - AppName
  - EventAction
correlation:
  type: temporal
  group-by:
    - DeviceId
  timespan: 5m
falsepositives:
  - QA-driven repeated crash testing with abnormal recovery instrumentation

AWS

Deployment Status

Production-Deployable in environments where normalized mobile crash and abnormal recovery telemetry are centralized in AWS analytics and same-device identity is preserved across sources

Rule Name

DarkSword Repeated WebKit Instability Threshold

Purpose

Detect probable DarkSword exploit-trigger activity by identifying repeated WebKit- or Safari-linked crash behavior on the same iOS device inside a tightly bounded interval using AWS-native analytics.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

A normalized crash telemetry dataset containing:

·        device_id

·        event_time

·        app_name

·        process_name

The implementation example below uses mobile_crash_logs as a placeholder normalized source name. This rule is not deployable as intended if crash telemetry is absent, poorly normalized, or not attributable to a stable device_id.

Tuning Explanation

This is the low-confidence AWS precursor detector for Phase 1. It is tuned as a bounded same-device threshold analytic and should remain lower severity until corroborated by same-device abnormal recovery. It must not be widened into generic mobile crash detection. The SQL assumes upstream normalization into the required canonical fields.

Detection Logic

Trigger when three or more WebKit- or Safari-linked crash or restart events occur on the same device within five minutes.

Operational Context

Use where mobile crash telemetry is reliably centralized into AWS analytics and same-device attribution is preserved. If device_id integrity or timestamp normalization is weak, downgrade to hunt support rather than loosening thresholds.

System-Ready Code

WITH crash_windows AS (
  SELECT
    device_id,
    COUNT(*) AS crash_count,
    MIN(event_time) AS first_crash,
    MAX(event_time) AS last_crash
  FROM mobile_crash_logs
  WHERE
    app_name IN ('MobileSafari','SafariViewService')
    OR process_name LIKE 'WebKit%'
    OR process_name LIKE 'Safari%'
  GROUP BY device_id
  HAVING COUNT(*) >= 3
     AND date_diff('second', MIN(event_time), MAX(event_time)) <= 300
)
SELECT
  device_id,
  crash_count,
  first_crash,
  last_crash
FROM crash_windows;

Deployment Status

Production-Deployable in environments where normalized abnormal recovery telemetry is centralized in AWS analytics and same-device identity is preserved across crash and behavior sources

Rule Name

DarkSword Repeated Instability with Abnormal Recovery Correlation

Purpose

Detect likely DarkSword exploit-trigger progression by correlating repeated WebKit instability with abnormal recovery on the same iOS device in AWS-native analytics.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

A normalized crash telemetry dataset containing:

·        device_id

·        event_time

·        app_name

·        process_name

A normalized behavior telemetry dataset containing:

·        device_id

·        event_time

·        event_action

event_action must use the canonical normalized value abnormal_recovery. The implementation example below uses mobile_crash_logs and mobile_behavior_logs as placeholder normalized source names. This rule is not deployable as intended where abnormal recovery telemetry is absent, not normalized, or cannot be mapped to the same device_id.

Tuning Explanation

This is the preferred AWS Phase 1 production analytic because it materially reduces false positives by requiring repeated instability plus abnormal same-device follow-on behavior. It stays phase-pure and does not depend on payload or later communication behavior. Sequence order is explicit: abnormal recovery must occur after the instability window begins and within five minutes of the repeated-instability window closing.

Detection Logic

Trigger when a repeated WebKit instability window is established and an abnormal recovery event occurs on the same device after the first crash and within five minutes of the last crash.

Operational Context

Use only where crash telemetry and abnormal recovery telemetry are centralized and same-device correlation is reliable. If event_action is not normalized to abnormal_recovery, normalize upstream before deployment.

System-Ready Code

WITH crash_windows AS (
  SELECT
    device_id,
    COUNT(*) AS crash_count,
    MIN(event_time) AS first_crash,
    MAX(event_time) AS last_crash
  FROM mobile_crash_logs
  WHERE
    app_name IN ('MobileSafari','SafariViewService')
    OR process_name LIKE 'WebKit%'
    OR process_name LIKE 'Safari%'
  GROUP BY device_id
  HAVING COUNT(*) >= 3
     AND date_diff('second', MIN(event_time), MAX(event_time)) <= 300
),
recovery_events AS (
  SELECT
    device_id,
    event_time AS recovery_time
  FROM mobile_behavior_logs
  WHERE event_action = 'abnormal_recovery'
)
SELECT
  c.device_id,
  c.crash_count,
  c.first_crash,
  c.last_crash,
  MIN(r.recovery_time) AS recovery_time
FROM crash_windows c
JOIN recovery_events r
  ON c.device_id = r.device_id
WHERE r.recovery_time > c.first_crash
  AND r.recovery_time <= date_add('second', 300, c.last_crash)
GROUP BY c.device_id, c.crash_count, c.first_crash, c.last_crash;

Azure

Deployment Status

Production-Deployable in environments where normalized mobile crash and abnormal recovery telemetry are available in Sentinel or Log Analytics and same-device identity is preserved across sources

Rule Name

DarkSword Repeated WebKit Instability Threshold

Purpose

Detect probable DarkSword exploit-trigger activity by identifying repeated WebKit- or Safari-linked crash behavior on the same iOS device inside a tightly bounded interval using Azure-native analytics.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

A normalized crash telemetry table containing:

·        DeviceId

·        TimeGenerated

·        AppName

·        ProcessName

The implementation example below uses MobileCrashLogs as a placeholder normalized source name. This rule is not deployable as intended where mobile crash telemetry is not ingested into Azure analytics or cannot be tied to a stable DeviceId.

Tuning Explanation

This is the low-confidence Azure precursor detector for Phase 1. It is tuned as a bounded same-device threshold analytic and should remain lower severity until corroborated by same-device abnormal recovery. It must not be widened into generic mobile instability detection.

Detection Logic

Trigger when three or more WebKit- or Safari-linked crash or restart events occur on the same device within five minutes.

Operational Context

Use where mobile crash telemetry is present in Sentinel or Log Analytics and device identity is stable. If local schema differs, map fields to the canonical model before deployment.

System-Ready Code

MobileCrashLogs
| where AppName in ("MobileSafari","SafariViewService")
    or ProcessName startswith "WebKit"
    or ProcessName startswith "Safari"
| summarize CrashCount=count(), FirstCrash=min(TimeGenerated), LastCrash=max(TimeGenerated) by DeviceId
| where CrashCount >= 3 and datetime_diff('second', LastCrash, FirstCrash) <= 300

Deployment Status

Production-Deployable in environments where normalized abnormal recovery telemetry is available in Azure analytics and same-device identity is preserved across crash and behavior sources

Rule Name

DarkSword Repeated Instability with Abnormal Recovery Correlation

Purpose

Detect likely DarkSword exploit-trigger progression by correlating repeated WebKit instability with abnormal recovery on the same iOS device using Azure-native analytics.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

A normalized crash telemetry table containing:

·        DeviceId

·        TimeGenerated

·        AppName

·        ProcessName

A normalized behavior telemetry table containing:

·        DeviceId

·        TimeGenerated

·        EventAction

EventAction must use the canonical normalized value abnormal_recovery. The implementation example below uses MobileCrashLogs and MobileBehaviorLogs as placeholder normalized source names. This rule is not deployable as intended where abnormal recovery telemetry is absent, not normalized, or cannot be correlated to the same DeviceId.

Tuning Explanation

This is the preferred Azure Phase 1 production analytic because it materially reduces false positives by requiring repeated instability plus abnormal same-device follow-on behavior. It stays phase-pure and does not depend on later payload behavior. Sequence order is explicit: abnormal recovery must occur after the instability window begins and within five minutes of the last crash.

Detection Logic

Trigger when a repeated WebKit instability window is established and an abnormal recovery event occurs on the same device after the first crash and within five minutes of the last crash.

Operational Context

Use only where crash telemetry and abnormal recovery telemetry both exist in Azure analytics and same-device identity is reliable. If source telemetry uses different anomaly labels, normalize to abnormal_recovery before deployment.

System-Ready Code

let CrashWindows =
    MobileCrashLogs
    | where AppName in ("MobileSafari","SafariViewService")
        or ProcessName startswith "WebKit"
        or ProcessName startswith "Safari"
    | summarize CrashCount=count(), FirstCrash=min(TimeGenerated), LastCrash=max(TimeGenerated) by DeviceId
    | where CrashCount >= 3 and datetime_diff('second', LastCrash, FirstCrash) <= 300;
let RecoveryEvents =
    MobileBehaviorLogs
    | where EventAction == "abnormal_recovery"
    | project DeviceId, RecoveryTime=TimeGenerated;
CrashWindows
| join kind=inner RecoveryEvents on DeviceId
| where RecoveryTime > FirstCrash
| where RecoveryTime <= LastCrash + 5m

GCP

Deployment Status

Production-Deployable in environments where normalized mobile crash and abnormal recovery telemetry are centralized in BigQuery, Chronicle, or equivalent GCP analytics and same-device identity is preserved across sources

Rule Name

DarkSword Repeated WebKit Instability Threshold

Purpose

Detect probable DarkSword exploit-trigger activity by identifying repeated WebKit- or Safari-linked crash behavior on the same iOS device inside a tightly bounded interval using GCP-native analytics.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

A normalized crash telemetry dataset containing:

·        device_id

·        event_time

·        app_name

·        process_name

The implementation example below uses project.dataset.mobile_crash_logs as a placeholder normalized source name. This rule is not deployable as intended where mobile crash telemetry is absent or not attributable to a stable device_id.

Tuning Explanation

This is the low-confidence GCP precursor detector for Phase 1. It is tuned as a bounded same-device threshold analytic and should remain lower severity until corroborated by abnormal recovery. It must not be generalized into broad mobile instability detection.

Detection Logic

Trigger when three or more WebKit- or Safari-linked crash or restart events occur on the same device within five minutes.

Operational Context

Use where mobile crash telemetry is centralized into GCP and same-device identity is preserved. If local schema differs, map fields to the canonical model before deployment.

System-Ready Code

WITH crash_windows AS (
  SELECT
    device_id,
    COUNT(*) AS crash_count,
    MIN(event_time) AS first_crash,
    MAX(event_time) AS last_crash
  FROM `project.dataset.mobile_crash_logs`
  WHERE
    app_name IN ('MobileSafari','SafariViewService')
    OR process_name LIKE 'WebKit%'
    OR process_name LIKE 'Safari%'
  GROUP BY device_id
  HAVING crash_count >= 3
     AND TIMESTAMP_DIFF(MAX(event_time), MIN(event_time), SECOND) <= 300
)
SELECT
  device_id,
  crash_count,
  first_crash,
  last_crash
FROM crash_windows;

Deployment Status

Production-Deployable in environments where normalized abnormal recovery telemetry is centralized in GCP analytics and same-device identity is preserved across crash and behavior sources

Rule Name

DarkSword Repeated Instability with Abnormal Recovery Correlation

Purpose

Detect likely DarkSword exploit-trigger progression by correlating repeated WebKit instability with abnormal recovery on the same iOS device using GCP-native analytics.

ATT&CK Technique

T1203 – Exploitation for Client Execution

Telemetry Dependency

A normalized crash telemetry dataset containing:

·        device_id

·        event_time

·        app_name

·        process_name

A normalized behavior telemetry dataset containing:

·        device_id

·        event_time

·        event_action

event_action must use the canonical normalized value abnormal_recovery. The implementation example below uses project.dataset.mobile_crash_logs and project.dataset.mobile_behavior_logs as placeholder normalized source names. This rule is not deployable as intended where abnormal recovery telemetry is absent, not normalized, or cannot be correlated to the same device_id.

Tuning Explanation

This is the preferred GCP Phase 1 production analytic because it materially reduces false positives by requiring repeated instability plus abnormal same-device follow-on behavior. It stays phase-pure and does not depend on later payload or communication behavior. Sequence order is explicit: abnormal recovery must occur after the instability window begins and within five minutes of the last crash.

Detection Logic

Trigger when a repeated WebKit instability window is established and an abnormal recovery event occurs on the same device after the first crash and within five minutes of the last crash.

Operational Context

Use only where crash telemetry and abnormal recovery telemetry are both available in GCP analytics and same-device correlation is reliable. If source anomaly labels differ, normalize them to abnormal_recovery before deployment.

System-Ready Code

WITH crash_windows AS (
  SELECT
    device_id,
    COUNT(*) AS crash_count,
    MIN(event_time) AS first_crash,
    MAX(event_time) AS last_crash
  FROM `project.dataset.mobile_crash_logs`
  WHERE
    app_name IN ('MobileSafari','SafariViewService')
    OR process_name LIKE 'WebKit%'
    OR process_name LIKE 'Safari%'
  GROUP BY device_id
  HAVING crash_count >= 3
     AND TIMESTAMP_DIFF(MAX(event_time), MIN(event_time), SECOND) <= 300
),
recovery_events AS (
  SELECT
    device_id,
    event_time AS recovery_time
  FROM `project.dataset.mobile_behavior_logs`
  WHERE event_action = 'abnormal_recovery'
)
SELECT
  c.device_id,
  c.crash_count,
  c.first_crash,
  c.last_crash,
  MIN(r.recovery_time) AS recovery_time
FROM crash_windows c
JOIN recovery_events r
  ON c.device_id = r.device_id
WHERE r.recovery_time > c.first_crash
  AND r.recovery_time <= TIMESTAMP_ADD(c.last_crash, INTERVAL 5 MINUTE)
GROUP BY c.device_id, c.crash_count, c.first_crash, c.last_crash;

S26 Threat-to-Rule Traceability Matrix

Behavior 1

WebKit-driven client exploitation causing repeated crash or restart instability on the same device

ATT&CK Technique

T1203 – Exploitation for Client Execution
Exploitation of a client application (WebKit/Safari) resulting in repeated crash or restart behavior during exploit triggering.

Mapped Rules

·        DarkSword Repeated WebKit Crash Threshold

·        DarkSword Repeated WebKit Instability (Time-Bound)

·        DarkSword Repeated WebKit Instability Threshold

·        DarkSword Repeated WebKit Instability Building Block

·        DarkSword Repeated WebKit Instability on iOS

·        DarkSword Repeated WebKit Instability Threshold (AWS, Azure, GCP)

Primary Detection Signa

Repeated WebKit or Safari-linked crash or restart events exceeding normal device behavior within a bounded time window

Telemetry Dependency

·        Normalized iOS crash telemetry

·        Stable same-device identifier

·        Normalized WebKit or Safari-linked application or process naming

Coverage Disposition

Detected

Disposition Rationale

This is the foundational exploit-trigger signal and is directly represented across endpoint, SIEM, portable, and cloud-native rules. It is consistently detectable where crash telemetry is available and normalized.

Behavior 2

Exploit-trigger progression resulting in repeated instability followed by abnormal same-device recovery behavior

ATT&CK Technique

T1203 – Exploitation for Client Execution
Exploitation results in execution instability followed by abnormal recovery or execution-context anomaly behavior.

Mapped Rules

·        DarkSword Crash-to-Abnormal-Recovery Correlation

·        DarkSword Instability + Recovery Correlation

·        DarkSword Repeated Instability with Abnormal Recovery Correlation

·        DarkSword Instability-to-Abnormal-Recovery CRE Correlation

·        DarkSword WebKit Instability with Abnormal Recovery Correlation

·        DarkSword Repeated Instability with Abnormal Recovery Correlation (AWS, Azure, GCP)

Primary Detection Signal

Correlation of repeated WebKit instability events with a subsequent abnormal recovery event on the same device

Telemetry Dependency

·        Normalized iOS crash telemetry

·        Normalized anomaly telemetry mapped to abnormal_recovery

·        Stable same-device identity across crash and behavior sources

·        Time alignment between crash and recovery events

Coverage Disposition

Detected

Disposition Rationale

This is the highest-confidence Phase 1 exploit indicator and is directly implemented across all rule groups. Detection strength is high where abnormal recovery telemetry is available and normalized.

Behavior 3

Exploit-trigger window producing instability followed by immediate same-device outbound communication onset

ATT&CK Technique

T1203 – Exploitation for Client Execution
T1071 – Application Layer Protocol
Exploitation is followed by immediate application-layer communication consistent with exploit-trigger or staging behavior.

Mapped Rules

·        DarkSword iOS Repeated Non-Approved DNS Burst Corroborator

·        DarkSword iOS Early TLS Session Burst Corroborator

·        DarkSword Phase 1 Multi-Signal Convergence

Primary Detection Signal

Correlation of repeated instability with first-seen or non-approved outbound DNS or TLS communication within a bounded post-instability window

Telemetry Dependency

·        DNS telemetry

·        TLS telemetry

·        First-seen destination enrichment

·        Reliable same-device attribution between endpoint and network sources

·        Maintained allowlists for approved mobile infrastructure

·        IOS_NETS and APPROVED_MOBILE_DESTS variable integrity

Coverage Disposition

Partially Detected

Disposition Rationale

This behavior is strongly detectable in platforms with endpoint-to-network correlation (for example Splunk). In network-only systems, detection is explicitly corroborative. Because coverage is not uniform across platforms, Partially Detected is the correct classification.

Behavior 4

Network-only corroboration of a suspected exploit-trigger window from iOS-attributed traffic

ATT&CK Technique

T1203 – Exploitation for Client Execution
Network activity reflects exploit-trigger side effects but lacks direct endpoint confirmation.

Mapped Rules

·        DarkSword iOS Repeated Non-Approved DNS Burst Corroborator

·        DarkSword iOS Early TLS Session Burst Corroborator

Primary Detection Signal

Burst or deviation in outbound DNS or TLS communication to non-approved or first-seen destinations from iOS-attributed traffic

Telemetry Dependency

·        DNS or TLS metadata

·        Reliable iOS traffic attribution

·        Maintained allowlists for Apple, MDM, proxy, and sanctioned infrastructure

·        IOS_NETS and APPROVED_MOBILE_DESTS variable maintenance

Coverage Disposition

Partially Detected

Disposition Rationale

These rules are explicitly defined as corroborating-only detections and do not independently confirm exploitation. They support detection confidence when combined with endpoint signals.

Behavior 5

Portable detection of repeated instability and instability-to-recovery correlation in backend-converted environments

ATT&CK Technique

T1203 – Exploitation for Client Execution

Mapped Rules

·        DarkSword Repeated WebKit Instability on iOS

·        DarkSword WebKit Instability with Abnormal Recovery Correlation

Primary Detection Signal

Backend-converted detection of repeated instability and instability-to-recovery correlation using Sigma-derived logic

Telemetry Dependency

·        Normalized mobile crash telemetry in Sigma-compatible schema

·        Normalized anomaly telemetry mapped to abnormal_recovery

·        Backend support for aggregation or temporal correlation

·        Stable same-device identity in the target platform

Coverage Disposition

Partially Detected

Disposition Rationale

Detection capability depends on backend implementation and correlation support. Because the rule requires conversion and backend capability, coverage is conditional.

Behavior 6

Forensic confirmation of exploit-trigger instability through diagnostic artifact analysis

ATT&CK Technique

T1203 – Exploitation for Client Execution
Evidence of exploitation is derived from diagnostic artifacts rather than real-time telemetry.

Mapped Rules

·        DarkSword iOS WebKit Diagnostic Bundle Triage

Primary Detection Signal

Presence of WebKit or Safari-linked crash artifacts and diagnostic metadata in collected iOS forensic bundles

Telemetry Dependency

·        Sysdiagnose bundles or crash exports

·        Forensic collection workflow

·        YARA scanning capability

Coverage Disposition

Hunt Only

Disposition Rationale

This rule supports investigation and confirmation rather than real-time detection. It is correctly classified as Hunt Only.

Behavior 7

Cloud-native correlation of instability and abnormal recovery in centralized analytics environments

ATT&CK Technique

T1203 – Exploitation for Client Execution
Exploitation behavior is detected through centralized aggregation and correlation of device telemetry.

Mapped Rules

·        DarkSword Repeated Instability with Abnormal Recovery Correlation (AWS, Azure, GCP)

Primary Detection Signal

Correlation of repeated instability and abnormal recovery within centralized cloud analytics pipelines

Telemetry Dependency

·        Centralized crash telemetry

Centralized anomaly telemetry normalized to abnormal_recovery

·        Stable same-device identity across ingestion pipelines

·        Consistent timestamp normalization

Coverage Disposition

Detected

Disposition Rationale

Cloud platforms provide consistent and scalable correlation of the core exploit behavior when telemetry is properly centralized and normalized.

Coverage Integrity Note

This matrix applies strict rule-accountability discipline. Behaviors are marked Detected only where direct, deployable, behavior-aligned detection exists under stated telemetry conditions.

Behaviors dependent on:

·        corroboration-only signals

·        backend conversion requirements

·        forensic workflows

·        or incomplete same-device identity

are conservatively classified as Partially Detected or Hunt Only.

Detection limitations caused by missing telemetry (for example absence of abnormal recovery data or loss of same-device identity) are treated as environmental constraints, not separate attacker behaviors, and are reflected within the relevant behavior dispositions rather than modeled as standalone behaviors.