Why antivirus cannot clear a phone: lessons from Operation Triangulation

Summary

• On 1 June 2023 Kaspersky reported that several iPhones on its own corporate network had been infected. The oldest traces it found dated from 2019. The campaign is known as Operation Triangulation.
• According to Kaspersky, the phones were infected through an iMessage attachment that needed no action from the owner, using four previously unknown flaws, one of which relied on a hardware feature that no public document describes. Apple's security notes confirm that two of the flaws may have been actively exploited and credit Kaspersky.
• A scanner that looks for known malware answers the question "is this a known threat?" The U.S. standards institute NIST says largely signature-based controls cannot keep up with malware tailored to one target. Kaspersky says modern iPhones cannot be inspected from the inside, so its team studied offline backups.
• What found the campaign was network monitoring and the examination of a backup against published indicators. The Amnesty International Security Lab's toolkit for that work says it is not intended for end-user self-assessment.
• An examiner can report which published indicators were present in the data examined. An examiner cannot certify that a phone is clean, and the device alone does not say who ran an attack.

What was reported

Kaspersky says it noticed suspicious traffic while monitoring its own corporate Wi-Fi network for mobile devices. The activity came from several iPhones. Because it is not possible to look inside a modern iPhone, the team made offline backups of the phones and examined them with the Mobile Verification Toolkit (MVT), an open-source forensic tool. Kaspersky published its first account on 1 June 2023 and says the oldest traces it found dated from 2019 and that the campaign was still running at the time of writing. That is about four years on devices that belonged to a company whose business is detecting malicious software.

The company later said the campaign targeted iOS up to version 16.2 and that, for the hardware step, it affected Apple chips from the A12 to the A16 generation. No source we cite names the attacker. Kaspersky has said it does not know how the attackers learned about the hardware feature they used.

Apple's own notes agree with the outline. The notes for iOS 16.5.1 (21 June 2023) list an integer overflow in the kernel, CVE-2023-32434, and say Apple is aware of a report that it may have been actively exploited against versions of iOS released before iOS 15.7. The notes for iOS 16.6 (24 July 2023) list a second kernel flaw, CVE-2023-38606, with similar wording for versions before iOS 15.7.1. Both credit Kaspersky researchers.

How the attack worked, as published

Figure 1 follows Kaspersky's published description at the level a reader needs to understand why detection is hard. It is a summary of the company's account, not a Lab finding, and it leaves out technical detail on purpose.

The lesson Kaspersky and others draw is about structure, not about one phone maker. A chain of unknown flaws, delivered without a click, can defeat protections that were each sound on their own. Apple has fixed the flaws named above in later releases. That closes this chain. The category of attack remains.

Why a scan cannot answer the question

A security app that compares what it can see against a list of known malicious files answers a narrow question. NIST's guide to malware incident handling, written for desktop and laptop computers in 2013, says antivirus detects malware primarily by looking for characteristics of known instances. It calls this highly effective for known malware and not so effective against highly customized, tailored malware. It also says that when attackers send a unique attack to each victim, largely signature-based controls such as antivirus cannot keep up. The guide's date and scope matter. It is not a study of phones. It does describe the same principle: a list-based tool needs the list to contain the threat.

Operation Triangulation adds three practical points. First, Kaspersky's own team could not inspect the iPhones from the inside and had to study backups. Second, according to Kaspersky the implant did not persist across a restart and the delivery message deleted itself, so the evidence was thin by design. Third, none of the Kaspersky pages we read says that its security products flagged the phones. What raised the alarm was monitoring of the network the phones used.

None of this makes a scan app useless. For the many commodity threats that are known and catalogued, such tools and prompt updates remain sensible. The point is narrower: a clean result from a scan answers "no known threat found by this tool", which is not the same as "this phone is clean". Figure 2 sets out the difference. It is the Lab's summary of the sources above, not a test of any product.

What an examination looks at

Backups and indicators. The Mobile Verification Toolkit was released by the Amnesty International Security Lab in July 2021 in the context of the Pegasus Project, which examined spyware sold to governments (see LAB-0019). It collects forensic traces from iOS and Android devices and checks them against published indicators of compromise. In July 2021 the Citizen Lab at the University of Toronto reviewed Amnesty's forensic methods and found its core methods sound. It also set out the limits of its own review: it saw a sample of the evidence and validated the method against four iTunes backups. For Triangulation, Kaspersky published indicators that fall in two groups. Some are in the network-usage records and attachment folders of a backup, and Kaspersky calls the most reliable ones. Others it treats as indicators only when several appear within minutes of each other.

The reboot log. In January 2024 Kaspersky described a small log on iPhones, Shutdown.log, that is part of a system diagnostic archive. If a process is still running when the phone restarts, the log notes its process path and time. In cases the company analyzed from 2021 and 2022, Pegasus infections left traces there. Kaspersky released scripts to read it. It also states the limits: the log only records entries when a restart happens, so a phone that was not restarted during the period of interest may show nothing, and the method does not detect all malware.

The network. Operation Triangulation began as a network observation. Where the people at risk work in an organization, the traffic of the networks their phones join is a second source of evidence that does not depend on the phone.

Skill. The toolkit's own README says that it is aimed at technical users, requires an understanding of digital forensics and command-line tools, and is not intended for end-user self-assessment. It also warns that public indicators alone are insufficient to determine that a device is clean and can give a false sense of security. That is why the work belongs to people who can say what an anomaly is and what it is not.

What an examiner can and cannot conclude

An examiner can say that named indicators were present or absent in a stated data set, from a stated source, at a stated software version, and whether the pattern matches a published campaign. If several of the weaker indicators appear together within minutes, that is a stronger statement than any one of them. The report should say which indicators were checked and which public lists they came from.

An examiner cannot say that a phone is clean. A restart can remove an implant that does not persist, a rolling log may have covered the period or not, and indicators exist only for campaigns that someone has already found. The Lab's earlier work makes the same point about empty results in general: a claim that nothing happened needs a store that could have recorded it (LAB-TR-0034), and a setting or key that is not found is not the same as one that is off (LAB-0005).

An examiner also cannot name the attacker from the device. None of the Kaspersky pages we read names the attacker, and the infrastructure and implant describe how a campaign worked, not who paid for it. If the question is "who", the answer needs other evidence and other people. If the question is "when", the earliest trace gives a lower bound on the infection, not its start.

What to do if the risk is real

Most people are not targets of campaigns like this one. Apple's own page on threat notifications says the vast majority of users will never be targeted. For those who might be, such as journalists, activists, lawyers and officials, four steps are well supported in public sources.

• Install updates promptly. The flaws in this case were fixed by updates, and Apple's notes name the versions.
• Consider Lockdown Mode. Apple describes it as an optional, extreme protection for the very small number of people who may be personally targeted. It blocks most message attachment types, some web technologies and some incoming FaceTime calls, and it blocks configuration profiles. It has a cost in convenience.
• Act on an Apple threat notification. Apple says these are high-confidence alerts that a user has been individually targeted, sent as a lock screen alert, an email, and a banner after signing in at account.apple.com, and that it never asks you to click a link in one. Apple recommends Lockdown Mode and expert help. It says that investigations can never achieve absolute certainty.
• Ask for expert help. Access Now's Digital Security Helpline is free for civil society, journalists and human rights defenders, answers around the clock and says it responds within two hours.

Lab guidance, which is our view and not a cited fact: if you intend to have a phone examined, keep it as it is. Do not reset it or restore it from a backup first, and do not delete messages or apps, because each of those changes the evidence an examiner would read.

What this article does not claim

Sources

Every number and claim, and where it comes from. Web pages were read on 2026-11-08. Statements that could not be sourced were left out, including a description of the hardware feature as known to few outside the chip's makers, which we could not find in Kaspersky's published account. LAB-TR-0034 is a Lab Technical Report available on this site, with no DOI yet.

Version history and corrections

Corrections log

No corrections have been published for this article. Corrections to any article are listed on Corrections, with the version they apply to.

Related