Apple has issued a new wave of threat notifications warning users in 99 countries that they may have been targeted by mercenary spyware — the commercial-grade surveillance tooling sold to governments and private actors by vendors operating in the gray market for offensive cyber capability. The timing is notable: the alerts landed just as the Pall Mall Process, the UK- and France-led international initiative to establish norms around commercial intrusion tools, moves into final negotiations on usage guidelines.
For defenders, this is not an abstract policy story. Apple's threat notification program is one of the highest-fidelity signals in consumer security: Apple does not send these alerts lightly, and a notification means Apple's internal telemetry has identified targeting consistent with state-sponsored or mercenary spyware operations against a specific device or Apple ID. If your organization employs executives, journalists, lawyers, diplomats, activists, or anyone whose work intersects with sensitive geopolitical interests, you should assume some percentage of your user population may receive one of these notifications — and you need a runbook for what happens next.
This post lays out the technical context, detection opportunities for macOS/iOS fleets, and a concrete response workflow for when a user walks into the SOC holding a phone with an Apple threat notification on the lock screen.
Technical Analysis
What Apple's threat notifications actually mean
Apple's threat notification program alerts users via email, iMessage, and a banner at the top of their Apple ID account page (appleid.apple.com) when Apple detects activity consistent with mercenary spyware targeting. Apple intentionally does not disclose the specific indicators that trigger a notification — doing so would give spyware vendors a roadmap for evading detection. What we know from years of incident response on these cases:
- Notifications correlate strongly with confirmed infections by commercial spyware families (historically Pegasus-class tools) when independently validated by organizations like Citizen Lab and Amnesty International's Security Lab.
- Targeting is overwhelmingly zero-click — no user interaction required. The dominant delivery vectors have been iMessage (malformed attachments processed by the
imagentandIMTransferAgentdaemons), and less frequently web-based one-click chains via Safari/WebKit. - Exploitation chains are multi-stage: initial sandbox escape in the message-processing daemon, kernel-level privilege escalation, payload deployment, and aggressive anti-forensics including deletion of crash logs, diagnostic artifacts, and iMessage attachment remnants.
- Infections are typically memory-resident or non-persistent — many commercial implants do not survive a reboot, which is both a remediation lever and a forensics problem.
Why the Pall Mall Process context matters to defenders
The Pall Mall Process negotiations signal that the commercial spyware market is proliferating, not contracting. More vendors, more buyers, and weaker procurement controls mean targeting is expanding beyond the traditional dissident/journalist population into corporate espionage, legal proceedings, and executive targeting. Treat mercenary spyware as a board-level threat category if your organization operates in contested industries: energy, defense, legal, media, finance with sovereign exposure, and NGOs.
Exploitation status
These notifications reflect confirmed, active targeting in the wild — this is not theoretical. Apple's notification program only fires on detected activity. No CVE is associated with this specific notification wave in public reporting; mercenary spyware vendors burn chains of zero-days across iOS, and individual chains are often patched silently via iOS updates and Rapid Security Responses before public disclosure.
Who is at risk
- Individuals whose device or Apple ID received a notification (primary).
- High-risk-role employees: executives, journalists, counsel, government affairs, M&A teams, researchers working on sensitive topics.
- Any user running significantly outdated iOS versions — spyware vendors maintain n-day exploit inventories alongside zero-days, and unpatched devices are trivially exploitable with older chains.
Detection & Response
Endpoint visibility on iOS is structurally limited — there is no EDR for iPhone. However, most enterprises have macOS fleets managed through Defender for Endpoint, Jamf, or Velociraptor, and macOS shares the iMessage attack surface (the same daemons, the same attachment pipeline) with iOS. The detections below focus on the macOS observable surface and on fleet hygiene triage. For iOS devices themselves, forensic validation requires specialized tooling (Amnesty MVT, Mobile Verification Toolkit) rather than signature-based detection.
Sigma Rules
---
title: Suspicious Child Process Spawned by iMessage Daemons
description: Detects shell interpreters or script engines spawned by iMessage processing daemons on macOS, a pattern consistent with zero-click exploitation chains delivered via malicious iMessage attachments.
id: 3f8a2c71-9d4b-4e1a-b6c3-7a9f2e5d1c08
status: experimental
references:
- https://support.apple.com/en-us/102174
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.execution
- attack.t1059
logsource:
category: process_creation
product: macos
detection:
selection_parent:
ParentImage|endswith:
- '/imagent'
- '/IMTransferAgent'
- '/Messages'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/zsh'
- '/python'
- '/python3'
- '/osascript'
- '/curl'
- '/wget'
condition: selection_parent and selection_child
falsepositives:
- Rare; legitimate iMessage processing does not normally spawn shell interpreters
level: high
---
title: Deletion of macOS Diagnostic and Crash Report Artifacts
description: Detects bulk deletion of files under DiagnosticReports directories, an anti-forensics behavior observed in mercenary spyware cleanup routines seeking to remove evidence of exploitation crashes.
id: 8b1e4d92-5c6f-4a3b-9e7d-2f4a6c8e1b35
status: experimental
references:
- https://docs.mvt.re/en/latest/
- https://attack.mitre.org/techniques/T1070/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.defense_evasion
- attack.t1070.004
logsource:
category: process_creation
product: macos
detection:
selection_rm:
Image|endswith:
- '/rm'
- '/srm'
selection_path:
CommandLine|contains:
- '/Library/Logs/DiagnosticReports'
- 'DiagnosticReports/'
- '.panic'
- '.ips'
condition: selection_rm and selection_path
falsepositives:
- Legitimate user or admin cleanup of old crash logs; investigate scope and recency
level: medium
KQL (Microsoft Sentinel / Defender)
For organizations with Defender for Endpoint deployed on macOS, this query hunts for the zero-click child-process pattern across the managed fleet. The second pattern triages which managed Apple devices are significantly behind on OS version — your highest-risk population for n-day exploitation by commercial spyware.
// Hunt: shell/script engines spawned by iMessage daemons on macOS
DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where InitiatingProcessFileName in~ ("imagent", "IMTransferAgent", "Messages")
| where FileName in~ ("sh", "bash", "zsh", "python", "python3", "osascript", "curl", "wget")
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine, SHA256
| sort by TimeGenerated desc
;
// Fleet triage: macOS devices on outdated OS builds (n-day exposure surface)
DeviceInfo
| where OSPlatform startswith "macOS"
| summarize arg_max(TimeGenerated, *) by DeviceId
| project DeviceName, OSPlatform, OSVersion, OSBuild, LoggedOnUsers
| sort by OSBuild asc
Velociraptor VQL
For DFIR teams triaging a macOS device whose user received an Apple threat notification, this artifact hunts live process anomalies from iMessage daemons and enumerates recently modified persistence locations and iMessage attachment artifacts for collection.
-- Apple threat notification triage: anomalous iMessage child processes and recent persistence artifacts
LET procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(sh|bash|zsh|python|osascript|curl|wget)'
LET parents = SELECT Pid, Name FROM pslist()
SELECT P.Name AS ChildProcess,
P.Pid AS ChildPid,
P.CommandLine AS ChildCommandLine,
PAR.Name AS ParentProcess,
P.Username AS Username,
P.CreateTime AS CreateTime
FROM procs P
JOIN parents PAR ON P.Ppid = PAR.Pid
WHERE PAR.Name =~ '(?i)imagent|IMTransferAgent|Messages'
UNION ALL
SELECT FullPath AS ChildProcess,
Mtime AS ChildPid,
NULL AS ChildCommandLine,
'LaunchPersistence' AS ParentProcess,
NULL AS Username,
Mtime AS CreateTime
FROM glob(globs='/Library/LaunchAgents/*.plist,/Library/LaunchDaemons/*.plist,~/Library/LaunchAgents/*.plist')
WHERE Mtime > ago(days=30)
Remediation and Verification Script (Bash — macOS)
Run this on macOS endpoints for users who received a threat notification, or as a posture audit for your high-risk population. It verifies core security controls, enumerates unexpected configuration profiles (a known spyware/malware persistence vector on Apple platforms), and inventories recent persistence artifacts for review.
#!/bin/bash
# Apple threat notification triage - macOS posture and persistence audit
# Run as the affected user where possible; some checks require sudo.
echo "=== [1] System Integrity Protection status (must be 'enabled') ==="
csrutil status
echo "=== [2] macOS version and build - verify latest via: softwareupdate --list ==="
sw_vers
softwareupdate --list 2>/dev/null
echo "=== [3] Rapid Security Response status ==="
systemextensionsctl list 2>/dev/null | head -5
echo "=== [4] Configuration profiles - review EVERY entry; unexpected profiles are a red flag ==="
profiles list 2>/dev/null || echo "profiles command requires elevated privileges"
echo "=== [5] Persistence artifacts modified in last 30 days ==="
find /Library/LaunchAgents /Library/LaunchDaemons ~/Library/LaunchAgents -name "*.plist" -mtime -30 2>/dev/null
echo "=== [6] Recently modified iMessage attachments (potential delivery artifacts - PRESERVE, do not delete) ==="
find ~/Library/Messages/Attachments -mtime -30 -type f 2>/dev/null | head -50
echo "=== [7] Listening/unusual outbound connections ==="
lsof -i -nP 2>/dev/null | grep ESTABLISHED | grep -v -E "apple|icloud|itunes" | head -30
echo "=== Triage complete. Preserve output and device state before any remediation. ==="
Remediation
When a user reports an Apple threat notification, execute in this order:
1. Verify the notification is genuine. Apple's legitimate notifications appear at the top of appleid.apple.com after sign-in, and come from no-reply@apple.com addresses without links demanding action. Threat actors spoof these alerts precisely because they prompt panic clicks. Instruct users to verify by signing into their Apple ID directly — never through a link in the message. Reference: Apple's official guidance on threat notifications.
2. Preserve evidence before touching anything. Do not reboot, update, or factory reset before forensic capture. Commercial implants are frequently memory-resident; a reboot destroys the infection and with it your ability to determine dwell time, data accessed, and attribution. For high-risk users, engage a specialist: Amnesty International's MVT is the reference open-source toolkit for iOS spyware forensics, and the Access Now Digital Security Helpline provides 24/7 incident support for civil society targets.
3. Enable Lockdown Mode immediately. On the affected device: Settings > Privacy & Security > Lockdown Mode. Lockdown Mode blocks the dominant iMessage delivery vectors by disabling attachment previews and link previews, restricting complex web technologies in Safari, and blocking wired connections while locked. Apple's own engineering position is that Lockdown Mode breaks most known zero-click chains. There is no legitimate reason a targeted user should not have this enabled.
4. Update everything, including Rapid Security Responses. Ensure the device is on the latest iOS/macOS release with automatic updates and Rapid Security Responses enabled. Spyware vendors hold n-day inventories; an unpatched device is exploitable with commodity-grade chains.
5. Reboot as a containment lever — after forensics. Post-capture, regular reboots (many incident responders now recommend weekly for high-risk users) disrupt non-persistent implants. A factory reset removes known commercial infections, but understand the tradeoff: the actor knows the device and phone number, and reinfection attempts are common.
6. Rotate credentials from a clean device. Assume anything typed or received on the compromised device was observed. Rotate Apple ID password, and re-enroll MFA from a known-clean device.
7. Organizational escalation. If the targeted user is an employee, treat this as a security incident: log it, assess what data and conversations the device had access to, evaluate legal/regulatory notification obligations, and brief leadership. Consider whether the targeting indicates broader interest in your organization — one notified user often means others are being targeted silently.
8. Establish a standing policy. Organizations with high-risk staff should pre-authorize: dedicated devices for sensitive travel and communications, Lockdown Mode as a default for designated roles, a clear reporting channel for threat notifications, and a relationship with a DFIR provider capable of iOS spyware analysis before the first notification arrives.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.