Mobile Malware Detection on Work Phones

Security teams that have solid detection on laptops often have close to none on phones. Mobile device management tells you which devices exist and how they are configured. It does not tell you which of them is under attack.

This guide covers why that gap exists and what to do about it, in the order the work should be tackled.

Why mobile malware is hard to detect

The sandbox prevents scanning

On iOS and Android, applications run in isolation and cannot read the files or memory of other applications. That design blocks most malware from spreading between apps, and it also blocks security software from doing what antivirus does on a laptop. No third-party app can scan the contents of another app, inspect the filesystem or watch processes it does not own. The desktop model of on-access file scanning has no equivalent on mobile.

MDM answers a different question

Mobile device management was built to configure devices and enforce policy rather than to detect threats. It will tell you which devices are enrolled, which operating system versions they run, whether a passcode is set and which managed apps are installed. It will not tell you that an installed app is exfiltrating contacts, that a user has just authenticated on a credential harvesting page, or that a device is talking to a command and control server. Knowing an app is present is not the same as knowing what it does.

The BYOD privacy boundary is deliberate

On personally owned devices the work profile exists specifically to keep the organisation out of the personal side. Google states plainly that the separation of work and personal apps means IT gets full control over work apps and data with no visibility into personal apps.

That boundary is correct for privacy and costly for detection, and the cost is measurable in timing. Verizon’s 2026 Data Breach Investigations Report found that among ransomware victims who had a prior credential or infostealer event, half saw that event occur within 95 days of the ransomware attack.

There is usually a window of weeks or months between the theft and the consequence, and whether anyone notices depends on being able to see the device where the credentials were taken. Attackers are not constrained by the boundary the organisation agreed to respect, so a phishing message arriving through personal WhatsApp can harvest corporate credentials that work perfectly well against corporate systems.

Attacks arrive through unmonitored channels

Email security gateways see corporate email. They do not see SMS, WhatsApp, Signal, LinkedIn messages, QR codes scanned from a poster, or links opened in a personal browser. On mobile those channels carry a large share of credential phishing, and most of it now lands outside the inbox entirely. The small screen hides the signals users are trained to look for, including the full URL and the sender’s real address.

Attackers have noticed that this works. Verizon’s 2026 report recorded a 40% rise in the success rate of mobile social engineering year on year, naming mobile devices among the fastest-growing targets. The same evasion logic drives phishing hidden inside QR codes, where the destination is an image that text-based scanning never reads. Phones also spend most of their time on mobile data or home wifi, so network controls sitting in the office never inspect that traffic.

Malware is built to survive app review

Attackers assume the store review process exists and design around it. A common pattern is a clean utility app that fetches its payload only after approval. Kaspersky’s researchers documented this in the second quarter of 2026, when a trojanised PDF reader distributed through Google Play showed users a fake update prompt in order to install the Anatsa banking malware.

Attackers also hide what the code does. The SparkCat crypto stealer, found in apps on both Google Play and the App Store, kept its malicious component encrypted so that nothing suspicious was visible to anyone reviewing it. Once running on an iPhone, it read text out of photos stored on the device, looking for saved recovery phrases.

Overlay attacks draw a fake login screen on top of a real banking or single sign-on app, leaving nothing on disk to find. Accessibility service abuse gives an app the ability to read screen content and simulate input, using one of several Android permissions that have entirely legitimate uses alongside their malicious ones. Volume compounds all of it: Google reported that Play Protect identified more than 27 million new malicious apps from outside Google Play in 2025, more than double the 13 million the year before, which is a large part of why installing apps from outside the official stores carries a different level of risk.

Users have no symptoms to report

On a laptop, an infection usually produces something the user notices. On a phone, the signs are heat, battery drain and slower performance, which people attribute to an ageing handset. Spyware is designed to produce no signs at all. Apple’s threat notification programme exists because mercenary spyware attacks are difficult to detect and prevent even for the platform vendor, with infection often requiring no interaction from the target.

How to improve malware detection for mobile

Step 1: Establish what you can currently see

Start with an honest inventory rather than a tooling decision. For each group of devices, record who owns it, whether it is enrolled, what data it can reach, and what your existing tools actually report. Separate four questions: which apps are installed, what those apps are doing, what the device is connecting to, and what the user is being sent. Most teams can answer the first and none of the rest. That gap is the scope of the work.

Step 2: Set the privacy boundary before you deploy anything

On personally owned devices, detection succeeds or fails on consent. Decide and document what will be monitored, what will not, who can see the data, and how long it is retained. Under GDPR this needs a lawful basis and, in most cases, a data protection impact assessment. Write it in language employees can read, and be specific about the personal side of the device. A programme that collects less and is trusted will get better coverage than one that collects more and gets resisted.

Step 3: Fix the configuration baseline

Detection is cheaper when there is less to detect. Set a minimum operating system version and enforce it through conditional access rather than through reminders. Restrict installation sources on corporate-owned devices. Ensure Google Play Protect stays enabled, which matters because Google’s enhanced fraud protection blocked 266 million risky sideloading attempts in 2025. Block enrolment of jailbroken or rooted devices, since those lose the platform protections the rest of your controls assume.

Step 4: Monitor the device’s network traffic

Since the platform prevents third-party software from scanning other apps, the practical detection surface on mobile is the connection rather than the file. Network traffic inspection performed on the device catches what file scanning cannot: connections to command and control infrastructure, credential harvesting pages opened from any app, and data leaving for destinations it should not reach. It works regardless of whether the phone is on the office network, home wifi or mobile data. This is the largest capability gap between a managed mobile estate and a monitored one.

Step 5: Watch permissions and behaviour, not just app names

Build alerting around the permissions malware needs in order to function:

• Accessibility services, which allow an app to read screen content and simulate input.
• Notification listener access, which lets an app read one-time passcodes as they arrive.
• Device administrator rights requested by an app with no management purpose.
• Draw over other apps, used for overlay attacks against banking and single sign-on screens.
• Installation from unknown sources, including any change to that setting.

Treat a request for any of these from an app outside your approved catalogue as an incident rather than a support ticket.

Step 6: Extend phishing detection to every channel

Most mobile compromise starts with a message rather than an app, so detection needs to cover SMS, messaging apps, QR codes, personal browsers and social platforms. Two behaviours deserve specific alerting: a user being walked through disabling a security control, and a user being talked into installing an app during a phone call. Google considered the second pattern common enough that Play Protect now cannot be switched off while a call is in progress.

Step 7: Route mobile alerts into the same queue as everything else

A mobile detection tool that emails a dashboard link to one administrator is not detection. Feed alerts into the SIEM, map them to your existing severity model, and name the team that owns triage. Define in advance what a confirmed mobile compromise triggers in your identity stack, because the credentials and session tokens taken from a phone are used against systems that have nothing to do with mobile.

Step 8: Write and rehearse the response playbook

Decide these points before you need them:

• How a device is isolated from corporate resources, and who authorises it.
• How sessions and tokens are revoked, given that infostealers capture live session tokens and bypass the login step.
• What evidence is preserved before any wipe, and whether a selective wipe destroys what you would need.
• How a BYOD device is handled when the organisation has no right to wipe the personal side.
• What happens when an employee receives an Apple threat notification, which warrants specialist help rather than a routine device reset.

Run the scenario at least once. The first time a team discovers it cannot revoke a session on a phone it does not own should not be during an incident.

Measuring whether it is working

Track a small set of numbers monthly: percentage of devices with work access covered by detection rather than just enrolled, percentage running a current operating system, phishing links blocked split by channel, sideloading and permission-change attempts flagged, and median time from alert to containment. Coverage is the one to watch first, since a capability deployed to 60% of the estate leaves the other 40% as the route in.

Corrata provides mobile threat defence for iOS and Android. See how detection and response works on employee devices.