Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1424: Process Discovery

Adversaries may attempt to get information about running processes on a device. Information obtained could be used to gain an understanding of common software/applications running on devices within a network. Adversaries may use the information from Process Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.

Recent Android security enhancements have made it more difficult to obtain a list of running processes. On Android 7 and later, there is no way for an application to obtain the process list without abusing elevated privileges. This is due to the Android kernel utilizing the `hidepid` mount feature. Prior to Android 7, applications could utilize the `ps` command or examine the `/proc` directory on the device.[1]

In iOS, applications have previously been able to use the `sysctl` command to obtain a list of running processes. This functionality has been removed in later iOS versions.

MobileT1424TechniqueObject v2.1 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Process Discovery on mobile devices is reconnaissance: malware or an implant tries to learn what is running so it can decide whether to continue, change behavior, or perform follow-on actions. For security leaders, the business issue is not the process list itself; it is that this behavior can help mobile threats adapt to the device environment, including whether the device is worth fully infecting or what actions to attempt next.

Executive priority

Prioritize this as a mobile security readiness and fleet hygiene question. Leaders should ask whether enterprise Android and iOS devices are kept on recent OS versions, whether attestation gates access to enterprise resources, and whether SOC/IR teams can investigate suspicious mobile discovery activity when a high-risk device is involved. The supplied ATT&CK relationships connect this technique to multiple Android and iOS malware/software entries and Operation Triangulation, so it is material for mobile threat intelligence, executive device protection, and incident scoping, but the object does not establish current exposure in any specific environment.

Technical view

ATT&CK describes Process Discovery for Android and iOS. On Android versions before 7, applications could use the `ps` command or inspect `/proc`; Android 7 and later made process listing unavailable to normal applications through the kernel `hidepid` mount feature unless elevated privileges are abused. On iOS, applications previously used `sysctl` for process listing, but that functionality was removed in later iOS versions. Detection content is not provided in the technique object, but relationship DET0692 indicates an ATT&CK detection strategy exists. SOC and IR teams should validate whether mobile security tooling can surface process-enumeration attempts, abnormal privilege context, device OS version, app provenance, and attestation status.

Likely telemetry

  • Mobile device OS version and patch/version inventory for Android and iOS fleets
  • Remote attestation results and device compliance status where available
  • Mobile EDR/MDM or forensic telemetry showing suspicious process enumeration behavior
  • Android evidence of attempted `ps` execution or `/proc` inspection on older devices, where such telemetry is available
  • Android evidence suggesting elevated privilege abuse when process listing is observed on Android 7 or later

Detection direction

  • Do not assume coverage because official detection text is not provided; map local controls against DET0692 and test what mobile telemetry is actually collected.
  • Tune analysis by OS version: process-list access on Android 7+ is more suspicious if observed because normal applications should not obtain it without elevated privileges; older Android versions have different baseline behavior.
  • For iOS, account for OS-version differences because ATT&CK notes that prior `sysctl` process-list functionality was removed in later versions.
  • Correlate process discovery with other suspicious mobile behaviors, app installation context, device compliance failures, and related threat intelligence rather than treating a single enumeration signal as conclusive.
  • Expect visibility gaps on unmanaged BYOD, privacy-restricted mobile platforms, and devices without mobile EDR, forensic acquisition, or attestation telemetry.

Mitigation priorities

  • Keep mobile devices on recent OS versions; ATT&CK mitigation M1006 emphasizes that newer mobile OS versions include security architecture improvements that may block observed techniques.
  • Use remote attestation where available and prevent devices that fail attestation from accessing enterprise resources, consistent with ATT&CK mitigation M1002.
  • Use OS-version and attestation evidence as compliance and incident-response decision points for access to enterprise data.
  • For high-risk users or sensitive workflows, validate that mobile monitoring and IR procedures can distinguish normal platform behavior from suspicious discovery attempts.
Analyst notes and limits

Relationship context shows use by Operation Triangulation and multiple software entries including YiSpecter, Rotexy, GolfSpy, Anubis, Agent Smith, WolfRAT, HenBox, SharkBot, LightSpy, Binary Validator, TriangleDB, and CherryBlos. This supports treating the technique as a recurring mobile discovery behavior across Android and iOS contexts, not as proof of any specific campaign or actor in the local environment.

The ATT&CK object lists no tactic and provides no official detection text. The practical value of this technique depends heavily on OS version, device management state, attestation availability, and the organization’s mobile telemetry. This summary does not claim active exploitation, attribution, or guaranteed detection coverage.

Official MITRE ATT&CK definition

Process Discovery

Adversaries may attempt to get information about running processes on a device. Information obtained could be used to gain an understanding of common software/applications running on devices within a network. Adversaries may use the information from Process Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.

Recent Android security enhancements have made it more difficult to obtain a list of running processes. On Android 7 and later, there is no way for an application to obtain the process list without abusing elevated privileges. This is due to the Android kernel utilizing the `hidepid` mount feature. Prior to Android 7, applications could utilize the `ps` command or examine the `/proc` directory on the device.[1]

In iOS, applications have previously been able to use the `sysctl` command to obtain a list of running processes. This functionality has been removed in later iOS versions.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Associated objects

Groups, software, and campaigns

Malware Mobile

S1225: CherryBlos

CherryBlos is an Android malware that steals credentials and redirects cryptocurrency to adversary-controlled wallets. CherryBlos was labelled Robot 999 in its first appearance in April 2023; since then, various aliases have been used, including GPTalk, Happy Miner, and SynthNet. The threat actors behind CherryBlos uploaded the malware to different Google Play regions, such as Malaysia, Vietnam, Indonesia, Philippines, Uganda, and Mexico.[1]

Android
Malware Mobile

S1055: SharkBot

SharkBot is a banking malware, first discovered in October 2021, that tries to initiate money transfers directly from compromised devices by abusing Accessibility Services.[1]

Android
Malware Mobile

S0422: Anubis

Anubis is Android malware that was originally used for cyber espionage, and has been retooled as a banking trojan.[1]

Android
Malware Mobile

S0311: YiSpecter

YiSpecter is a family of iOS and Android malware, first detected in November 2014, targeting users in mainland China and Taiwan. YiSpecter abuses private APIs in iOS to infect both jailbroken and non-jailbroken devices.[1]

AndroidiOS
Malware Mobile

S0440: Agent Smith

Agent Smith is mobile malware that generates financial gain by replacing legitimate applications on devices with malicious versions that include fraudulent ads. As of July 2019 Agent Smith had infected around 25 million devices, primarily targeting India though effects had been observed in other Asian countries as well as Saudi Arabia, the United Kingdom, and the United States.[1]

Android
Malware Mobile

S1185: LightSpy

First observed in 2018, LightSpy is a modular malware family that initially targeted iOS devices in Southern Asia before expanding to Android and macOS platforms. It consists of a downloader, a main executable that manages network communications, and functionality-specific modules, typically implemented as `.dylib` files (iOS, macOS) or `.apk` files (Android). LightSpy can collect VoIP call recordings, SMS messages, and credential stores, which are then exfiltrated to a command and control (C2) server.[1]

AndroidWindowsiOS
Malware Mobile

S0544: HenBox

HenBox is Android malware that attempts to only execute on Xiaomi devices running the MIUI operating system. HenBox has primarily been used to target Uyghurs, a minority Turkic ethnic group.[1]

Android
Malware Mobile

S0411: Rotexy

Rotexy is an Android banking malware that has evolved over several years. It was originally an SMS spyware Trojan first spotted in October 2014, and since then has evolved to contain more features, including ransomware functionality.[1]

Android
Malware Mobile

S1215: Binary Validator

Binary Validator is a Mach-O binary file used during Operation Triangulation.[1] Binary Validator first collects information about the device, such as the device's phone number and a list of installed applications, before the deployment of the TriangleDB implant. After the actions are completed and the data is collected, Binary Validator encrypts and sends the data to the C2 server, and in turn, the C2 server sends the TriangleDB implant.

iOS
Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
2.1
Created
Modified
Raw hash
54de9c3140c35357...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.1 Current bundle 54de9c3140c3…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Android-SELinuxChanges

    Various. (2016, March 31). Overly restrictive SELinux filesystem permissions in Android N. Retrieved December 21, 2016.

    Open source URL
  2. [2]
    mitre-attack T1424
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.