Part 1 · assessment and mitigation recommendations · published v1.0 · 14 October 2026
A phone compromise exposes confidential work
SC09 · Executives · legal teams · civil society · sensitive roles
What really happened
Citizen Lab reported BLASTPASS on 7 September 2023 after finding an actively exploited zero-click iPhone chain delivering Pegasus spyware to a civil-society employee’s device. The researchers reported associated Apple fixes.
Citizen Lab · original BLASTPASS investigation
Evidence limit: This is a documented exploitation case, but it does not imply that every unusual phone symptom is spyware or that a clean scan excludes compromise. This package does not reproduce the exploit.
The question for the client
Are sensitive mobile users adequately protected, and could we preserve and assess evidence if compromise were suspected?
Business impact: Loss of confidential communications and business intelligence, personal exposure and unreliable incident decisions if evidence is lost.
- Systems involved
- Mobile OS, messaging, device management, account sessions, backups and forensic evidence.
- Where people fit
- Sensitive roles face distinctive exposure; device owners, IT and investigators need an evidence-preserving reporting process. Zero-click compromise does not require a user mistake.
How a similar risk could develop here
Proposed client threat model, not a reconstruction of undocumented incident details.
Target a vulnerable device or identity → gain access without or with user interaction → access communications/data → persist until detected or remediated.
Each route depends on several controls. If one stage is blocked, later checks can only continue as a separately authorised, clearly labelled assumed-compromise test. Do not claim an end-to-end attack succeeded merely because a downstream test identity was supplied.
Referenced attack-vector guides
Approval is specific, never inherited from the guide. Check the client, campaign, individual person/asset, method, channel, time window and risk ceiling. Deny overrides allow; absent, expired or withdrawn permission blocks the action. LOW/MED/HIGH describe proposed test impact, not permission or finding severity.
Read the approval rules.
Assessment playbook · Part 1
Start with G01 scope and Target Management, G02 intelligence gathering where needed, and G03 tool/resource preflight. Each selected vector receives its own scoped invocation record.
SC09-S01LOW · proposed test impact1. Review device and account posture
Check approved inventory, support/update status, account protection and reporting arrangements.
- Why this is needed
- It tests a barrier in the route above and helps answer: Are sensitive mobile users adequately protected, and could we preserve and assess evidence if compromise were suspected?
- Vector / method
- Tools and guides
- Device-management and identity consoles · client/operator supplied
- Repository input
- control-matrix.csv · RES-011 · published assessment resource; pin its version/hash in the case record.
- Output
- Posture and coverage report; attach evidence, target ID, vector version and approval revision.
- Measure
- Required protections evidenced / applicable selected protections. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Recommend supported updates, appropriate account protection and a usable reporting route. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC09-S02MED · proposed test impact2. Validate sample evidence handling
Acquire a consented supported sample, record hashes and timestamps, and analyse a working copy using validated tools.
- Why this is needed
- It tests a barrier in the route above and helps answer: Are sensitive mobile users adequately protected, and could we preserve and assess evidence if compromise were suspected?
- Vector / method
- Tools and guides
- Repository input
- evidence-register.csv · RES-015 · published assessment resource; pin its version/hash in the case record.
- Output
- Forensic process results; attach evidence, target ID, vector version and approval revision.
- Measure
- Evidence items with verified custody / acquired items; supported checks completed. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Correct custody, acquisition or supported-analysis gaps; label unsupported platforms and inconclusive results. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC09-S03LOW · proposed test impact3. Interpret and recommend
Review indicator matches and alternatives with confidence statements and scope limits.
- Why this is needed
- It tests a barrier in the route above and helps answer: Are sensitive mobile users adequately protected, and could we preserve and assess evidence if compromise were suspected?
- Vector / method
- Tools and guides
- Timesketch · native service; handoff is not automatic execution
- Qualified case reviewer · client/operator supplied
- Repository input
- findings.csv · RES-016 · published assessment resource; pin its version/hash in the case record.
- Output
- Qualified findings and protection recommendations; attach evidence, target ID, vector version and approval revision.
- Measure
- Conclusions traceable to evidence / proposed conclusions. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Seek evidence that distinguishes alternative explanations and propose proportionate device/account protection. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
Use one step-result record per case and G06 reporting for the client deliverable. The report must explain successes, failures, uncertainty, prohibitions and coverage limits.
Recommendations to reduce the risk
Reduce the likelihood: Keep platforms supported and updated, protect identities and select stronger device protections for roles whose threat profile warrants them.
Reduce the impact if it happens: Minimise unnecessary sensitive data on devices, make incident reporting timely and preserve evidence for a proportionate response.
How to verify improvement later: repeat the failed control case and a permitted/clean comparison using the same agreed measure; compare conditions and evidence. A better test pass rate alone is not a quantified reduction in business risk.
End of Part 1: evidence-backed findings and mitigation recommendations. The implementation action plan, allocated work, commercial service packaging and costs are deliberately deferred.
Supporting TenguProtect capabilities
Baseline from the 13 October operational audit. This does not claim the complete service is ready or that permissions are already enforced across every agent.
| Capability | Observed readiness | Remaining gap |
|---|
| Mobile-device review and forensic readiness | Partial; no current saved MVT result evidence | Prove a consented sample-backup acquisition, hash manifest, MVT analysis and report. Validate Android separately; do not extrapolate from an iOS executable. |
| Incident investigation and timeline analysis | Bounded analyst review available; new-case delivery unproven | Prove a fresh isolated case import/export, permissions, timezone handling and retention. Existing corpus activity is not proof of a new client workflow. |