The call comes in some variation of the same way every time.

A client tells us their partner, current or estranged or former, has been reading their messages. Knows things they should not know. Turns up places the client never mentioned they would be. The client has done some Googling by this point and landed on articles about Pegasus, FlexiSPY, mSpy, or one of the dozens of commercial spyware products with names that sound like they belong in a Bond film. They are convinced one of those tools is running silently on their phone.

In the large majority of domestic cases we examine, that is not what happened. The real attack is simpler and cheaper, and in some ways worse, because it never has to touch the device at all.

The cost reality

Start with the surveillance tools clients are actually afraid of, because the numbers settle a lot of this quickly.

NSO Group's Pegasus, the tool that infected the phones of journalists and dissidents and made international headlines, costs somewhere around $650,000 USD for a license covering ten targets. That is the floor. Annual maintenance runs into the hundreds of thousands. NSO Group sells only to vetted government customers. A domestic abuser cannot buy Pegasus. A private investigator cannot buy Pegasus. Nobody reading this article can buy Pegasus.

Commercial stalkerware sits at the other end of the market. Products like FlexiSPY, Spynger or Hoverwatch run $30–$200 a month and are aimed at parents claiming to monitor children and at jealous partners willing to cross a criminal line. They require physical access to an unlocked device, and on iOS they typically need the device jailbroken to achieve the deep access their advertising claims. Installation leaves traces behind: modified system directories, unexpected certificate profiles, entries in the device's process list, elevated TCC privacy permissions granted to apps with no legitimate reason to hold them.

Cellebrite UFED, the same professional extraction tool we use at DRL, starts around $15,000 USD and requires specialized training. It is not a surveillance tool. It is a point-in-time extraction appliance and it does not run on devices continuously. Clients see it mentioned in news coverage and assume it represents some category of covert ongoing access.

When a device comes to us with domestic surveillance concerns, establishing whether any of these categories of tool are present is the first thing we do. On most devices, the answer is no. And that absence is itself a finding.

What the forensics showed

A recent case. A woman submitted her iPhone alleging that her estranged spouse had been reading her emails, iMessages and locked notes for years. She had changed her Wi-Fi password. Her router app still showed her phone connecting to the network hours later, then again in the middle of the night while she slept, and on one occasion while she was physically out of the house with the phone in her hand. She had seen the screen wake on its own one evening. She was certain the phone was compromised.

A full filesystem extraction showed the following.

No malware. No jailbreak. No MDM configuration profiles installed without her knowledge. No suspicious LaunchDaemons beyond the Cellebrite extraction agent we had placed there ourselves. We checked the TCC database, which is the iOS privacy permission log, and found elevated permissions on one app with a generic-looking bundle ID. It turned out to be a widely-distributed speed test application.

No unknown devices in her iCloud trust circle. We queried TrustedPeersHelper.db, a CoreData SQLite database recording every device ever enrolled as a trusted peer on an iCloud account, complete with hardware identifiers, serial numbers and timestamps. Every device in it was hers or her immediate family's. No third-party laptop, no burner phone, no unknown Mac. The attack never needed a trusted device.

The other party's email address in her Identity Services cache. iOS keeps a local status cache of iMessage addresses it has recently resolved. The spouse's email address was sitting in idstatuscache.plist, cross-referenceable with content in the SMS database.

Her own messages to a friend, in the SMS database, describing the access. She had written that the other party had obtained all her passwords and account credentials and had been reading her email and other communications, possibly for years.

That was the case. No spyware anywhere in it.

The actual attack: credential access

Apple's iCloud ecosystem is extraordinarily powerful. Share your Apple ID credentials with someone, or let them learn your password through observation or a shared device or a password manager they had access to, and from any browser on any machine they can:

None of that requires installing anything. None of it touches the device. None of it leaves forensic artifacts on the phone, because the access happens on Apple's servers. The phone's filesystem is clean because the phone was never the point of entry.

Which is why clients who buy a new device and assume they are safe often are not. The attack does not live on the hardware. It lives in the account.

The Wi-Fi anomalies were real

The router logs in this case were not fabricated. The anomalies genuinely happened. They just pointed somewhere other than where she thought.

Modern iPhones use a randomized private MAC address per Wi-Fi network, a network identifier unique to that device on that SSID. It is visible to anyone with access to the router's management app, which means anyone who had previously been on that router account would have seen it. Cloning a known MAC address onto another device and connecting to the same Wi-Fi is not technically difficult.

More decisive than that: we examined the phone's known-networks plist, the file storing every saved Wi-Fi network on the device with timestamps for when each one was added, and found that the home network credential was not saved to the phone until well after the anomalous connections were reported. The router app connections in the days beforehand predated the phone having that network's password at all. Her phone could not have been auto-connecting to a network it did not yet know.

Something else was connecting, using her MAC address.

The forensic evidence did not confirm spyware. It confirmed a pattern of access from external devices, alongside credential-level account access, and neither of those has anything to do with software installed on the phone.

What forensics can and cannot tell you

A full filesystem extraction gives us everything stored on the device. What it cannot give us is the server-side record of what happened on the account. Apple does not surface iCloud.com login history locally. The IP addresses, timestamps and session tokens from web logins to icloud.com live on Apple's servers, not on the phone.

So our recommendations in domestic surveillance cases almost always include:

  1. Apple Privacy Portal (privacy.apple.com). Apple's GDPR and privacy law data request mechanism lets a user request their own account activity logs, including trusted device history and sign-in locations. This is the appropriate first step.
  1. Apple Law Enforcement Portal. If there is a legal proceeding underway, counsel can submit a formal production order for iCloud account access logs including IP addresses and timestamps per access event. These are the server-side records that prove account takeover.
  1. Change Apple ID credentials immediately, from a device that has never been in the abuser's possession. Password change notifications go to all trusted devices, so if he controls a trusted device or session, he will be notified. The secure sequence is: remove trusted devices, then change the password, then sign out all sessions.
  1. Enable two-factor authentication with a phone number only you can access. A shared or observed 2FA number defeats the whole mechanism.

What this means for counsel

If you are representing a client in a family law or domestic abuse matter with a digital surveillance component, a properly scoped mobile forensic examination establishes:

What it cannot establish, absent a legal production order directed at Apple, is when and from where the iCloud account was accessed via web browser. The most damaging access often happened entirely offsite, on hardware that was never submitted for examination, against an account rather than a device.

Which is why the absence of malware on a phone is not exculpatory. In most domestic surveillance cases we examine, it is the expected finding, because the phone was never the target.

Data Rescue Labs performs iOS and Android forensic examinations for domestic abuse victims, family law counsel, and corporate clients. If your client alleges digital surveillance and you need a court-ready examination report, our Mobile Forensics and iCloud Forensics teams handle this work. Open a case for a privileged consult.