Zero-Click Smartphone Spyware: Evidence, Triage and Hardening

01 / Field notes

Executive Summary

Zero-click spyware exploits software behavior without requiring the victim to tap a malicious link or approve an installation. That makes ordinary advice about avoiding suspicious links incomplete for this threat. It does not mean every warm phone, dropped call or fast-draining battery is evidence of spyware. Those symptoms have many routine explanations.

The right response depends on the evidence and the person's risk. A verified vendor threat notification, a known targeting context or forensic findings deserve more weight than a vague performance change. Someone handling sensitive sources, political work or high-value investigations may reasonably choose stronger protections even without a confirmed compromise. An everyday reader should still keep software updated and accounts secure without assuming that a sophisticated surveillance operation is present.

Apple describes mercenary spyware as highly targeted and recommends additional protections for people at risk. Its threat-notification guidance provides ways to verify a notice through the account itself. Navigate to the account service independently rather than following a surprising message that asks for credentials or payment. [1]

This guide explains a defensive triage process for a device you own or whose owner has explicitly consented. It is not a remote diagnosis, a replacement for a qualified forensic examiner or a claim that OneMoreLock extracted evidence from a real victim. The proposed exercises use an ordinary spare device and synthetic data. No exploitation or spyware installation is required.

The main priorities are to reduce ongoing exposure, preserve useful information and avoid making the situation harder to investigate. Those priorities can conflict. A reset may reduce some immediate risks while destroying evidence; leaving a suspected device connected may preserve normal state while allowing further exposure. A qualified responder can help choose an approach based on the person's safety and the available facts.

02 / Field notes

Prerequisites / Lab Setup

For learning, use a spare supported phone with test accounts, synthetic messages and a clear recovery path. Record the model, operating-system build, security patch level and backup configuration. Keep it separate from sensitive personal accounts. The exercise is to understand available records and protection settings, not to simulate an attack on somebody else's phone.

Prepare a trusted computer with enough encrypted storage for backups and analysis results. Phone records can include intimate communications, location information and other people's data. Decide who may access the material, where it will be stored and when it will be deleted. Consent to inspect a device should include an explanation of what might be collected.

For a real concern, first record a timeline using a separate trusted device: when a notification arrived, relevant travel or targeting events, unusual account changes and what actions have already been taken. Preserve the original wording and timestamps of a vendor notice. Avoid posting private identifiers or complete backup files to a public forum.

If there is an immediate personal-safety concern, safety takes priority over a perfect forensic process. Use a trusted alternative communication method and appropriate local support. Do not continue sensitive conversations on a device you reasonably believe may be monitored simply to preserve a clean experiment.

03 / Field notes

Technical Analysis

What does a zero-click attack actually exploit?

Modern phones process incoming content before a user deliberately opens it. Messaging, media parsing and other services have complex code paths. A vulnerability in one of those paths can sometimes be reached without the visible action people associate with phishing. A complete compromise may involve several linked vulnerabilities and privilege boundaries rather than one magical message.

That description should not become an excuse for fatalism. Software vendors reduce attack surface, isolate components and patch discovered flaws. A historical exploit against one version does not establish that the same chain works against a current fully updated device. Always identify the affected versions and the date of the evidence when discussing a named case.

What did BLASTPASS establish?

Citizen Lab's September 2023 BLASTPASS report documented a zero-click exploit chain involving malicious image content in PassKit attachments delivered through iMessage. The researchers connected it with Pegasus spyware and identified related Apple CVEs. This is a dated, documented case of a specific chain, not a newly discovered 2026 exploit or a test performed for this guide. [2]

Its relevance is architectural: content-processing paths that appear passive can still be attack surfaces. The correct defensive conclusion is to follow current vendor updates and risk-specific hardening advice, not to assume a visible suspicious message will always be available to delete. An attacker may exploit processing that occurs before a person sees anything useful.

Avoid turning incident examples into product rankings. Different platforms expose different evidence and receive different research attention. Counting public reports does not produce a reliable probability that a particular person's phone is compromised. Device support, update behavior, account security and the user's actual threat context are more actionable inputs.

Which indicators deserve attention?

Treat indicators as evidence with context. A domain, process name or unusual database record can support an investigation when it matches a documented campaign and appears in a meaningful timeline. The same string in an unrelated context may mean little. A finding needs interpretation, not just a red label from a tool.

Write down alternative explanations. A crash may follow an ordinary app bug. Network traffic may belong to a legitimate service. A suspicious timestamp may be affected by timezone conversion. Good analysis tries to disprove its first interpretation as well as support it. That discipline protects the owner from both missed threats and unnecessary alarm.

What can Mobile Verification Toolkit tell you?

MVT supports processing mobile forensic material and comparing it with known indicators. Its own documentation explicitly warns that public indicators cannot establish that a device is clean and that the tool is not intended for unsupported end-user self-assessment. Those limits belong beside any results, not in a footnote removed from the final report. [3]

For a learning exercise, inspect the structure of output from a consented synthetic backup. Learn which records were actually available, which modules ran and which errors occurred. A report with missing acquisition data should not be described as a full-device examination. Different operating systems, versions and backup methods expose different artifacts.

The project's indicator documentation describes using STIX files and recording the indicator set used for analysis. Preserve the acquisition date, tool version and indicator version with the result. A later re-analysis with updated indicators may produce different findings even when the underlying backup is unchanged. [4]

Do not upload an unredacted phone backup to an unknown “spyware detector.” The backup itself may be more sensitive than the symptom that started the investigation. A trustworthy responder should explain collection, access, retention and reporting before asking for the data.

How should evidence be preserved?

Keep an acquisition log that records who collected the material, with whose consent, using which method and at what time. Compute a cryptographic hash of exported files where appropriate, store originals securely and analyze working copies. A hash helps detect later changes; it does not prove the acquisition was complete or the source was trustworthy.

This simple example operates on a local evidence file selected by its owner. It computes a SHA-256 digest without interpreting the phone's contents. Use an actual authorized file path in a controlled environment and keep the resulting record private when it identifies sensitive evidence.

function sha256File(string $path): string
{
    if (!stream_is_local($path) || !is_file($path) || !is_readable($path)) {
        throw new RuntimeException('Choose a readable local evidence file');
    }
    $digest = hash_file('sha256', $path);
    if ($digest === false) {
        throw new RuntimeException('Could not hash evidence file');
    }
    return $digest;
}

Document every state-changing action. Updating, rebooting, disconnecting accounts and resetting the device can all affect what remains available. None is automatically wrong; the point is to make the decision deliberate and reconstructable. If a responder recommends an urgent change, record the reason and time rather than delaying necessary protection for paperwork.

What does Lockdown Mode change on an iPhone?

Apple's Lockdown Mode is intended for people facing sophisticated targeted threats. It restricts selected features and interactions to reduce attack surface, with usability trade-offs. Review Apple's current description on each supported device and enable the protection consistently across the devices relevant to your work. It is a risk-reduction feature, not a forensic verdict. [5]

Do not treat an enabled setting as permission to ignore updates or account hygiene. Keep the operating system current, review trusted devices and protect the account used to recover or synchronize data. A separate account compromise may expose information without exploiting the phone in the way a zero-click headline describes.

Before enabling stronger restrictions for a dependent family member or colleague, explain what normal behavior may change and how to obtain help. A protection that silently breaks a necessary workflow may be disabled later without review. Test critical communications and accessibility needs through the supported configuration.

What should Android users review?

Check the device manufacturer's supported update period and the actual installed security patch level. Android devices vary in hardware, vendor software and update delivery; “Android” alone is not a precise test environment. Replace unsupported devices used for sensitive work when a supported upgrade path is unavailable.

Google's Android Advanced Protection Mode, introduced with Android 16, groups stronger device protections for at-risk users. Availability and specific behavior depend on the device and software. Review the current supported settings rather than assuming a menu path or feature set is identical on every phone. [6]

Keep app installation and account access under review. Remove unused apps, scrutinize powerful permissions and avoid granting accessibility or device-administration privileges without a clear need. Those checks address common access paths; they do not prove the absence of an advanced exploit. A balanced defense handles ordinary risks while preserving a plan for exceptional ones.

04 / Field notes

Mitigation / Defense

For routine protection, keep supported devices and apps updated, use a strong device passcode and secure the associated cloud account with appropriate MFA or passkeys. Review account recovery and trusted devices periodically. Make encrypted backups you can actually restore, and avoid keeping the only recovery method on the same phone you may lose.

If the concern is targeted spyware, use a trusted alternative device for sensitive communication and seek a qualified incident responder. A verified vendor notice or credible targeting context warrants more than an online symptom checklist. Share a concise timeline and the actions already taken so the responder does not have to reconstruct the first hours from memory.

A reset may be part of a response, but it should not be sold as a universal proof of safety. Account access, reinfection risk, unsupported software and restored configuration all need consideration. Similarly, a new phone is not enough if the attacker still controls the account used to set it up.

The most useful final report separates what was observed, what is inferred and what remains unknown. State the acquisition limits and the indicators examined. Explain the protective steps in language the owner can follow. Honest uncertainty is more useful than either a dramatic diagnosis based on battery behavior or a confident all-clear based on one scanner's output.

05 / Field notes

References

Drafted with AI assistance; no independent credential verification is claimed. Sources checked in October 2026. BLASTPASS is identified as a 2023 case. The triage workflow and hashing function are original defensive guidance; no victim-device examination, spyware deployment or clean-device certification is claimed.

1. Apple Threat Notifications and Mercenary Spyware ↗Apple · accessed 2026-10-21
2. BLASTPASS: iPhone Zero-Click Exploit Captured in the Wild ↗Citizen Lab · accessed 2026-10-21
3. Mobile Verification Toolkit: Introduction and Limitations ↗MVT Project · accessed 2026-10-21
4. Mobile Verification Toolkit: Indicators of Compromise ↗MVT Project · accessed 2026-10-21
5. About Lockdown Mode ↗Apple · accessed 2026-10-21
6. Android Advanced Protection Mode ↗Google · accessed 2026-10-21

Questions readers ask