Symptoms of compromise on a mobile device, where the tooling is thinner

Why this matters

Mobile compromise is harder to see than desktop compromise, because the platforms deliberately hide the machinery. There is no process list, no startup folder, no registry, and on one platform no meaningful scanner. A technician has far fewer instruments here and has to reason from behaviour.

The compensating advantage is that the platforms are more locked down, so compromise usually requires either the user installing something or the user granting something unusual — and both leave traces in places you can look. That is what this lesson covers: the small number of places worth checking, and why the rebuild decision is easier here than on a desktop.

The lesson

High data or battery use with no application to explain it

The two measurable resources on a phone are data and battery, and unexplained consumption of either is the most useful signal available.

Data. Both platforms report data used per application. Look for:

• An application using significant data that has no reason to — a torch, a calculator, a wallpaper application.
• System or "unattributed" usage that is large and constant.
• Usage continuing overnight with nothing running.

Battery, as covered in the performance lesson, with the same caveat: the application at the top of the list is usually the one used most, and the anomaly is an application consuming battery in the background with no screen time.

What the honest alternatives are, because they are more likely:

• A cloud backup uploading photos for the first time.
• A streaming application downloading over cellular because the setting was changed.
• A device on poor signal, where the radio works harder for everything.
• A degraded battery, which makes every draw look worse.

So the signal is not "high usage" but usage with no plausible owner, sustained, and preferably confirmed a second way — by a change in behaviour after force-stopping a suspect, or by a mobile plan's own usage figures.

Escalate to the full check in this lesson when the pattern survives those explanations.

Applications installed that nobody installed, and where they came from

Applications nobody installed have a small number of origins, and each has a different implication.

• Bundled by the manufacturer or carrier. Common on Android, often unwanted, and not a compromise. Recognisable because they were there from the first day.
• Installed by a management profile, on a work device. Expected, and worth confirming rather than removing.
• Installed from the store by the user, forgotten, or installed accidentally from an advertisement. The store's own purchase history distinguishes these, and it is the first place to look because it shows what the account has ever installed.
• Sideloaded, which is the concerning category. Installed from a file, a link, a third-party store, or by someone with physical access to the device.

How to tell: on Android, the application's information page names its source, and settings show which applications are permitted to install other applications — a permission that should be granted to nothing unexpected. On iOS, sideloading generally requires an enterprise or developer profile, so checking the device's profiles covers it.

The physical-access case deserves naming. Commercial "monitoring" applications are installed by somebody with the device in their hands and the passcode, and they hide their icon. The signals are an unexplained profile, an unexplained device administrator, an accessibility service that should not be there, and battery and data use with no owner. This is a situation with a safety dimension as well as a technical one, and the right posture is to be careful and factual rather than dramatic.

Profiles, device administrators and accessibility permissions as persistence

Persistence on a phone lives in three places, and they are the three to check.

Configuration profiles (iOS) and work profiles (Android). A profile can install applications, set a VPN, install a root certificate, configure mail, and restrict the device. An unexplained profile is the single strongest finding available on iOS, and it is two taps away in the device's settings.

Device administrators (Android). An application with device administrator rights can lock the device, change the passcode, and — the point — resist uninstallation, because removal requires revoking the right first. An application that cannot be uninstalled is usually a device administrator, not a fault.

Accessibility services. This is the most abused permission on Android. It exists so that assistive software can read the screen and act on the user's behalf, which means an application granted it can read everything displayed and tap anything — including entering a banking application and moving money. An accessibility service granted to an application that has no accessibility purpose is a serious finding.

Two more worth checking:

• Installed root certificates, which allow traffic interception.
• VPN configurations the user did not create, which route everything through somebody else.

The check, in order: profiles; device administrators; accessibility services; VPN; certificates; then the store's installation history. Five minutes, and between them they cover essentially every route a mobile compromise persists through.

Leaked personal files, and the account rather than the device being the breach

On mobile more than anywhere else, the breach is usually the account rather than the device.

Photos, messages, contacts and documents sync to a cloud account. Anyone who can sign in to that account has them, from anywhere, without touching the phone. So when a user reports that their private photos have appeared somewhere:

• The device is often fine. Examining it can be a complete waste of the hours that matter.
• The account is where to look: recent sign-in activity, devices signed in, connected applications, recovery details, and whether anyone else has ever had the password.
• The most common actual cause is a password known to someone close to the user, or reused from a service that was breached. It is not usually anything technical.

What to do, in the order that helps: change the account password from a clean device, sign out all sessions, check and remove unrecognised devices, check recovery email and phone, check connected applications, and enable a second factor if there is not one.

That is the same sequence as the desktop credentials lesson, because it is the same problem.

And the part that is not technical: where the likely explanation is somebody with legitimate physical access, the situation may involve personal safety, and changing the password may itself be visible to that person. The right response is to be careful, to avoid speculating about who, and to point towards proper support rather than to conduct an investigation. A technician's job here is to secure the account and to be trustworthy about it.

Why a factory reset is a more reasonable answer here than on a desktop

On a desktop, rebuilding is a day's work and is resisted for that reason. On a phone it is an hour, which changes the calculation completely.

Why a reset is reasonable here:

• The platforms make restoring painless: a backup or a cloud account returns the device to a usable state in an hour, mostly unattended.
• The diagnostic tools are so limited that establishing cleanliness by inspection is genuinely hard, whereas a reset is definitive for anything living in the user partition.
• Most mobile compromise is in installed applications, profiles and granted permissions — all of which a reset removes completely.

How to do it so it works:

• Do not restore from a backup made after the compromise began, or the problem returns with the restore. Set up as new where the timeline is unclear.
• Deal with the account first, using the previous section, because restoring into a compromised account restores the compromise.
• Follow the provisioning lesson's order: confirm the account credentials, confirm the backup, move authenticators, then reset.
• Reinstall applications deliberately rather than restoring the whole application set, so whatever arrived does not come back.

The exception that still means escalate: a device belonging to an organisation, one that handled regulated data, or one where the compromise looks targeted. A reset destroys the evidence, and in those cases the evidence is the thing that matters — which is the chain-of-custody point the last domain of this course sets out.