A client approached us with two concerns: a belief that someone had gained unauthorised remote access to their personal Android smartphone, and the unexplained disappearance of approximately 1,500 photographs from the device. The deletion was estimated to have taken place roughly four months prior to the examination, though no precise date was known.
The device was a current-generation Android flagship running a recent OS version, fully patched, with the manufacturer's enhanced security feature active at the time of the reported incident. No physical signs of tampering were present, and the device had not been rooted or modified.
"The most significant finding came not from a malware scanner, but from a single timestamp buried in the operating system's permission audit log."
We performed a non-destructive logical acquisition using open-source forensic tooling over an authenticated USB connection. The dataset was subsequently processed through the Mobile Verification Toolkit (MVT), cross-referenced against 11,209 unique indicators of compromise drawn from fourteen active threat intelligence feeds — covering commercial surveillance tools including Pegasus, Predator, Candiru, NoviSpy, RCS Lab, and others.
Where automated analysis was inconclusive, we performed manual review of system logs, application permission records, power cycle history, package installer provenance, and live device database queries. A second data collection session was conducted to obtain a fresh snapshot of the operating system's App Operations manager — a component not fully captured in the initial acquisition.
Throughout, we maintained a non-invasive posture. No device modifications were made, no warranty seals were broken, and the chain of custody was preserved for potential legal use.
Automated analysis returned a single detection flag. Manual review confirmed it was a false positive — a mass permission-rejection event triggered by the carrier during SIM provisioning, not a sign of compromise. No known spyware signatures, malicious packages, or unauthorised root binaries were present.
Manual analysis, however, surfaced several items that warranted closer attention:
The OS permission audit log recorded an active, foreground-state invocation of a screen mirroring accessibility service on a date falling within the estimated incident window. The device owner stated this feature was not in use. This discrepancy is the central unresolved finding of the case.
The screen mirroring feature was bound to a third-party cloud account registered on the device. Any computer signed into the same account would have been capable of initiating a session. The account's paired device history — held externally — was identified as the primary avenue for further investigation.
Process lifecycle records showed the screen mirroring application maintaining continuous background activity across multiple days, consistent with an active pairing continuously polling for connection opportunities rather than an idle, unpaired installation.
A system setting permitting the installation of applications from outside the official app store was active. No such sideloaded applications were identified, but the setting represents an elevated risk posture and was likely unknown to the device owner.
Crash log and security report sharing with the manufacturer had been disabled. While this can be a legitimate privacy preference, it also reduces the visibility of anomalous system behaviour — a configuration that benefits an actor seeking to avoid detection.
Several applications had been silently installed via the carrier's device management channel, outside of the user's direct control. All were verified clean against VirusTotal's 58-engine database. Their presence and permission scope were documented for completeness.
The pivotal piece of evidence was a single record extracted from the Android App Operations manager — a component of the OS that logs the most recent access event for each permission, per application, per process priority tier.
The record showed that a screen mirroring accessibility service had been invoked in a top-of-stack foreground state — meaning the feature was actively in use, not merely initialised in the background — on a specific date and time that falls within the period the device owner reported the photograph deletion.
Package com.[screen-mirroring-application]: ... BIND_ACCESSIBILITY_SERVICE (allow): null=[ Access: [top-s] [DATE REDACTED] 18:32:27.173 ← foreground, active use Access: [fg-s] [+71 days later] 20:05:30.527 Access: [bg-s] [+93 days later] 04:19:47.088 Access: [cch-s] [+93 days later] 12:55:37.859 ] ... /* AppOps stores only the most recent event per tier. Earlier events in the same tier are silently overwritten. The top-s record above is the last known active user session. */
The relative timestamp embedded in the raw record — expressing elapsed time since the OS captured the data — independently confirms the absolute date, providing a second verification path that does not rely on system clock accuracy alone.
Crucially, this artefact was not surfaced by the automated MVT scan. It required a second, targeted data collection and manual interpretation of the permission audit structure — a process that is only meaningful when the examiner understands what AppOps records and, equally importantly, what it does not.
Android AppOps is not an event log. It is a state table. For each permission and each process priority level, the OS retains exactly one record: the most recent access. Prior events in the same tier are permanently overwritten with no recoverable history.
This means we can establish with confidence that the screen mirroring service was actively invoked on the recorded date. We cannot establish from this record alone how many times the service was used prior to that date, how long any individual session lasted, or what was visible to the remote party during the session.
"The log gap is not a failure of the investigation — it is itself a finding. An actor who understands Android's log retention behaviour can act within a window of plausible deniability."
The photograph deletion could not be forensically attributed from device-side evidence. Android retains battery statistics, logcat, and rotation logs for only a few weeks. The estimated deletion date predates all available logs by approximately two months. The device's media database — which records deletion timestamps and the identity of the application that deleted each file — was inaccessible without a root-level extraction that would have voided the device's security hardware warranty.
This is a structural limitation of non-invasive Android forensics. Attribution of events older than the log retention window requires either cloud-side records (from the services involved) or a physical extraction authorised within a formal legal framework.
No commercial spyware was found. The device had not been rooted or physically modified. The most significant finding came from a component of the operating system that most users — and many security tools — do not examine: the App Operations audit table, accessible without any special privileges, requiring only the knowledge to look for it and the ability to interpret what it contains.
Screen mirroring, remote desktop, and co-browsing tools are increasingly bundled into mainstream operating systems and pre-installed applications. They are not malicious — but they create a persistent, low-friction pathway from your device to any computer signed into the same account. If you do not actively use these features, their accessibility service registrations should be reviewed and disabled.
A compromised or shared cloud account credential is functionally equivalent to physical access to your device where these features are active. Two-factor authentication, passkey adoption, and periodic review of paired devices are not optional hygiene — they are the primary control layer.
Automated scanners and antivirus tools are designed to detect known malicious software. They are not designed to assess whether a legitimate, digitally-signed application from a major software vendor has been used — legitimately or otherwise — to gain access to your device. These are different questions that require different methods.
Android devices do not retain system logs indefinitely. In most configurations, the actionable forensic window is four to six weeks. If you suspect your device has been compromised, the single most important action is to preserve the device in its current state and seek examination promptly. Every day of normal use overwrites potential evidence.