Mobile T1424 Process Discovery Guide

Mobile malware needs to know which apps are running so it can decide whether to infect fully, when to draw a fake login screen over a banking app, and whether a security tool is watching. MITRE ATT&CK for Mobile tracks this as T1424 Process Discovery, a Discovery (TA0032) technique on Android and iOS. Both platforms have closed the easy routes: ATT&CK notes that since Android 7 an app cannot list processes without elevated privileges, and that the iOS sysctl route was removed in later versions. So in practice the technique now shows up in two forms: root-level implants that read the process list directly, and Android trojans that use the Accessibility Service to learn which app is in the foreground. This guide is for mobile security engineers, app owners and SOC analysts. It extends our MITRE ATT&CK for Mobile Guide; the host version is T1057 Process Discovery.

Key takeaways

A process list on a current phone means privilege. ATT&CK notes that from Android 7 an app cannot list processes without elevated privileges, and that the iOS sysctl route was closed; a full process list in an implant's output points to elevated privileges, while Accessibility Service abuse gives foreground app detection without them.
Accessibility is the modern substitute. ATT&CK records SharkBot and CherryBlos using the Accessibility Service to see which app is in the foreground, the trigger for overlay and credential theft.
Two ATT&CK mitigations, both usable. M1006 Use Recent OS Version removes the old routes; M1002 Attestation detects rooted devices so MDM or your backend can act.
App owners can check from the server side. Play Integrity's opt-in app access risk verdict reports apps that could capture the screen, draw overlays or control the device.
Detection is in vetting and forensics. ATT&CK's DET0692 points to dynamic analysis of /proc access on Android and to MDM and network evidence on iOS.

What the technique covers

ATT&CK v20 describes adversaries getting information about running processes to understand the software on the device and to shape follow-on behaviour, including whether to fully infect the target. There are no sub-techniques.

Platform	Historical route (per ATT&CK)	Current state (per ATT&CK)	What attackers use now
Android	`ps` command or reading the `/proc` directory before Android 7	From Android 7, the kernel's `hidepid` mount option means no app can obtain the process list without abusing elevated privileges	Root exploits on old builds; the Accessibility Service for foreground app detection; `dumpsys` in older families such as WolfRAT
iOS	`sysctl` to list running processes	Removed in later iOS versions	Exploit-chain implants with kernel privileges, such as TriangleDB and LightSpy

How adversaries use it: real cases

Foreground detection for overlay fraud: ATT&CK records SharkBot (S1055) using Accessibility Services to detect which process is in the foreground, citing NCC Group, and CherryBlos (S1225) using the Accessibility Service to watch for a cryptocurrency wallet app launching, citing Trend Micro. Knowing the moment a banking or wallet app opens is what lets the trojan act. See the Android Banking Trojans Guide.
Selective infection: Agent Smith (S0440) checks whether a targeted application is running before infecting it, citing Check Point. WolfRAT (S0489) uses dumpsys to see if certain apps are running, citing Cisco Talos.
Classic process listing on Android: Anubis (S0422), Rotexy (S0411), HenBox (S0544) and GolfSpy (S0421) collect running process lists.
iOS implants with kernel access: during Operation Triangulation (C0054), ATT&CK records the actors obtaining a list of processes, and both TriangleDB (S1216) and Binary Validator (S1215) collecting them, citing Kaspersky. LightSpy (S1185) also collects running processes. YiSpecter (S0311), an older iOS family, collected running process information by abusing private APIs.

For commercial and state-linked implants see the Commercial Spyware Guide.

Prevention: what actually reduces it

Control	Android	iOS	Effect on T1424
M1006 Use Recent OS Version	Enforce a minimum API level; the Android Management API reports `OS_NOT_PERMITTED` when a device is below `minimumApiLevel`	MDM compliance on OS version and patch level	Removes `/proc` and `sysctl` routes and closes the exploits root-level implants need
M1002 Attestation	Play Integrity device verdicts (`MEETS_DEVICE_INTEGRITY`, `MEETS_STRONG_INTEGRITY`) checked on your server	MDM security and compliance queries; App Attest for your own app	ATT&CK: attestation can typically detect rooted devices, and MDM can act on a failed check
Accessibility control	Block sideloading on managed devices; Android's restricted settings can hold back sensitive settings for some newly installed apps until the user explicitly allows them	ATT&CK's iOS cases use kernel-level implants instead, so updates and Lockdown Mode for high-risk users carry the weight	Removes the foreground-detection substitute
App-side risk check	Play Integrity `appAccessRiskVerdict`	Your own app's runtime checks and server-side risk signals	Lets a banking or payments app react when risky apps are running

Play Integrity in practice: Google's documentation says the verdict should be evaluated on your backend, checking the requestHash or nonce first to prevent replay, then appRecognitionVerdict and appLicensingVerdict, then tiering by device integrity. Its app access risk verdict, which is opt-in, tells you whether apps are running that could capture the screen, display overlays or control the device, for example by misusing the accessibility permission. Google advises requesting it as close as possible to the action you want to protect, and not relying on Play Integrity as your only anti-abuse mechanism. See the Mobile App Attestation Guide.

Managed fleets: keep Google Play Protect on (Google documents a daily scan, install-time checks for apps from outside Google Play, and automatic removal of the most harmful apps) and block untrusted app sources through policy. See the Android Enterprise Security Guide and the iOS and iPadOS Enterprise Security Guide.

What to detect and where

App vetting (Android): ATT&CK's analytic looks for an app outside an allow-list opening /proc/ and listing it recursively on devices below the hidepid version, or reading /proc/<PID>/status or /proc/<PID>/cmdline. Add accessibility service declarations and dumpsys references to your vetting checks.
MDM state (iOS and Android): installed and managed application lists, device information, security info and profile lists, compared with your baseline.
Network evidence: Android Enterprise network logging (DnsEvent and ConnectEvent per package) and iOS Network Extension or per-app VPN flow data, to catch the beacon that follows discovery.
Attestation failures: treat a device that drops from MEETS_DEVICE_INTEGRITY or fails MDM compliance as a possible root-level compromise.
Forensics: for suspected implants on high-risk users, use the Mobile Verification Toolkit (MVT) with current indicators.

Where identity fits

Foreground detection exists to steal credentials and session tokens at the moment a user signs in. Two identity controls blunt it: phishing-resistant authentication that a fake overlay cannot capture, and server-side checks that bind a session to an attested app and device. If your mobile app holds long-lived refresh tokens or API keys, assume a root-level implant can read them and keep their lifetime short. See the Mobile Access Credentials Guide.

Measuring whether it works

OS floor compliance: percentage of managed devices at or above your minimum OS and patch level.
Accessibility exposure: number of non-allow-listed apps holding an enabled accessibility service on managed Android devices; target zero.
Attestation coverage: percentage of sensitive transactions in your app protected by a server-checked integrity verdict.
Integrity drop response: median time from an attestation or compliance failure to restricted access.

Common failure patterns

Granting accessibility to "helper" apps: users enable accessibility for a utility installed outside the store, which gives it the foreground signal and much more.
Checking integrity on the device only: a client-side check that a rooted device can patch out; Google's guidance is to evaluate verdicts on the server.
Treating a stale OS as low risk: devices below Android 7 still expose /proc, and old iOS builds carry the exploits implants use.
Single-tier enforcement: requiring the strongest device label for everything blocks legitimate users; Google recommends tiered responses.

Framework mapping

Framework	Reference	Why it applies
ATT&CK for Mobile v20	M1006 Use Recent OS Version; M1002 Attestation	Mitigations mapped to T1424
NIST SP 800-53 Rev 5	SI-2 Flaw Remediation; SI-3 Malicious Code Protection; SI-4 System Monitoring; CM-7 Least Functionality	Updates, app scanning, telemetry, removing unneeded capability such as sideloading
NIST CSF 2.0	PR.PS-02; DE.CM-09	Maintaining software and monitoring devices and runtime environments
OWASP MASVS	MASVS-RESILIENCE; MASVS-PLATFORM	For your own app: detect tampering and hostile environments, use platform interaction safely

Practitioner checklist

Set and enforce a minimum OS version and patch level on every managed platform.
Block untrusted app sources and keep Play Protect enabled on managed Android.
Inventory apps with enabled accessibility services and remove any without approval.
Add /proc access, dumpsys use and accessibility declarations to app vetting.
For your own mobile apps, check integrity verdicts on the server and opt in to the app access risk verdict for sensitive actions.
Act on attestation and compliance failures by restricting access, not just logging them.
Keep an MVT-based triage route ready for high-risk users.

Mobile T1424 Process Discovery: How Mobile Malware Watches Which Apps Run