The evidence that erases itself

A file that stopped keeping history

On 21 October 2025 the mobile security firm iVerify reported a quiet change in Apple’s iOS 26[S2]. The iPhone keeps a shutdown log inside its diagnostic data, and for years that log accumulated entries across restarts. Investigators used it to find traces of older Pegasus and Predator infections[S1].

In the first iOS 26 releases, iVerify said, the file was replaced at every restart instead. The history vanished each time the phone rebooted [S1][S2].

The log was never designed as evidence. That is the point. Housekeeping records can outlive an attacker’s cleanup precisely because the attacker is not thinking about them, and a change in the housekeeping can erase a long-standing source of evidence between one update and the next.

Apple's reversal, and what it did not repair

iVerify reported on 18 February 2026 that iOS 26.2, released on 12 December 2025, restored the earlier behavior, with new entries added to the file rather than replacing it [S1][S3]. Records lost on phones that had run the earlier 26.x builds were not recovered[S1].

Apple has not described the change as intentional, and iVerify framed it as either a design choice or a bug[S1]. Nothing in the public record supports a claim that Apple meant to hinder investigators.

iVerify added a second caution. Newer spyware largely avoids leaving this trace or wipes the file, so the log mainly helps with older cases[S1]. The episode is therefore less a story about one file than about a pattern: what a phone keeps can change with a software update, and an update can turn a recoverable history into a gap.

Implants that clean up after themselves

Google’s Threat Intelligence Group described three data-stealing programs delivered through an iPhone exploit chain it calls DarkSword, documented in March 2026. According to Google, all three delete crash reports connected to their activity, and one stages stolen data in temporary storage before sending it[S4]. Google describes a chain written entirely in JavaScript, started by a visit to a web page, with no mechanism for staying on the phone after a restart described[S4].

Kaspersky’s account of Operation Triangulation, an iMessage-delivered campaign disclosed in June 2023, shows the same habit earlier. The exploit message and attachment were removed after use. Kaspersky said the strongest indicator left behind was traces of a deprecated backup-related process, not the file itself, and that the oldest traces dated to 2019[S6].

On 8 October 2026 iVerify reported a DarkSword variant, found during an August examination of a customer’s phone, that it says logs less and injects fewer processes than the original[S10]. That is one firm’s observation. We have not seen it confirmed independently.

Implants that do not stay

Google Project Zero’s 2019 teardown of an iPhone implant delivered by compromised websites found one that did not survive a restart[S7]. It asked its server for commands every 60 seconds, uploaded location up to once a minute over plain HTTP, and gave the owner no visual sign[S7]. Restarting the phone would have ended it, although data already sent stayed sent.

Implants that watch for the examiner

In December 2025 Google described an implant it calls PREYHUNTER, tied in its report to a commercial surveillance vendor it names Intellexa[S5]. A watcher component, Google says, ends the infection if it detects signs of analysis: developer mode, hooking tools, a custom root certificate or proxy, security apps or certain regional settings[S5].

The implication is ours, not Google’s. If tooling sits on a phone when an implant checks, the implant may leave early, so a clean result after tools arrive is weaker than the same result before.

Our assessment: the short life of evidence on both platforms

Apple’s App Privacy Report lists when apps used the camera, microphone, location, photos and contacts over the past seven days. It needs iOS 15.2 or later and is off until the owner turns it on[S8]. A phone whose owner never enabled it holds no such history.

Android offers fewer comparable records. In the 2021 Pegasus Project, Amnesty’s Security Lab examined 67 phones; 37 showed traces and 30 were inconclusive, and Amnesty said Android phones did not log the information it needed[S9]. That was five years ago and platforms have changed. The lesson has not: what a phone keeps is a property of the platform and its settings, not a constant.

Two features of that result shape how we read any finding. The list behind the project held more than 50,000 numbers, and Amnesty stressed that a number on the list is not proof of infection[S9]. And the phones examined were those whose owners volunteered them, some already replaced, so the sample says little about how common infection is. It says a great deal about how often a careful examination ends without an answer.

What this means for the numbers

The public statistics on mobile compromise are thin for exactly this reason. We found no public median dwell time or detection delay for mobile compromise. The nearest figures describe single cases, such as Operation Triangulation’s traces from 2019 to 2023[S6], or enterprise networks, which are not phones. Any claim of how often phones are compromised, or for how long, should be read with that gap in mind.

What the Lab is watching

Three developments will tell us whether the evidence window is narrowing.

First, whether diagnostic retention stays stable across Apple’s next releases. The shutdown log changed once without a published explanation[S1], and Apple’s release index shows a steady cadence of point releases through 2026[S3]. Each release is a chance for another quiet change.

Second, whether other researchers corroborate the smaller-footprint DarkSword variant[S10]. A trend toward less logging by implants would shrink the evidence further, but one vendor’s report is not a trend.

Third, whether the self-aborting behavior Google describes[S5] appears in other families. In the sources we reviewed, it is documented in a single implant. We treat it as a design idea attackers have shown they can build, not as a measured prevalence.

What this means for examiners

If a phone may have been targeted, or a client’s older phone may hold history, do not update, reset or restart it as a first step. A restart ended the 2019 implant and, on early iOS 26 builds, overwrote the shutdown log, so a restart is a one-way step. Keep the device powered and in its current state, record the iOS version and the date, and have it examined before it is changed.

For a phone at active risk, preserving and patching pull in opposite directions. Decide that trade with a specialist, not by default. A record Apple overwrote cannot be rebuilt, and nothing in this article changes that.

What we could not confirm

We could not independently confirm the iVerify variant report[S10]. We also did not find any statement from Apple explaining the shutdown log change.