AN1804: Analytic 1804
Defender observes an app/package attempting to enumerate running processes by triggering restricted process visibility mechanisms (e.g., repeated queries for running tasks/services, rapid iteration over process identifiers, or access attempts against /proc entries) that are atypical for its declared function and occur without an associated user-facing diagnostic workflow. The detection relies on correlating (1) OS/API calls or shell/system utility execution indicative of process listing or /proc traversal, (2) app privilege context (root, debug build, device owner/profile owner, accessibility/IME status), (3) background execution state, and (4) optional follow-on behaviors consistent with automated discovery (short bursts of local IPC probes, network beacons immediately after enumeration, or rapid targeting of specific high-value package/process names). The analytic should describe what is observable: repeated enumeration signals + privilege context + timing relationship, not the adversary’s intent.
Analyst context for executives and security teams
AN1804 is an Android mobile detection analytic for spotting apps that appear to enumerate running processes or traverse /proc in ways that do not match their declared function or a visible diagnostic workflow. For leaders, the value is not that this proves compromise; it is an early-warning signal that an app may be performing automated discovery of the local device environment, which can matter for mobile fleet trust, incident triage, and validation of mobile telemetry coverage.
Executive priority
Prioritize this analytic where Android devices support sensitive workflows, privileged apps, device-owner/profile-owner controls, accessibility/IME-enabled apps, debug builds, or rooted devices. The business decision is whether the organization can distinguish legitimate diagnostics and administration from unusual background process discovery. This supports mobile security readiness, incident response scoping, and compliance evidence that mobile monitoring is based on observable behavior rather than assumptions about app intent.
Technical view
Validate whether Android telemetry can correlate repeated process-enumeration signals with app/package identity, privilege context, and timing. The supplied analytic focuses on observable patterns: repeated queries for running tasks or services, rapid iteration over process identifiers, attempted access to /proc entries, shell or system utility execution associated with process listing, background execution state, and optional follow-on behavior such as short bursts of local IPC probes, network beacons after enumeration, or rapid targeting of high-value package/process names. Because no ATT&CK tactic or relationship context is supplied, treat this as a detection strategy for suspicious Android discovery-like behavior, not as proof of a specific intrusion phase or adversary objective.
Likely telemetry
- Android app/package identity and declared function or expected role
- OS/API call traces related to running tasks, running services, process identifiers, or /proc access
- Shell or system utility execution telemetry associated with process listing or /proc traversal
- App privilege context, including root, debug build, device owner/profile owner, accessibility service, or IME status where available
- Foreground/background execution state and timing of enumeration activity
Detection direction
- Correlate repeated enumeration behavior with privilege context and background state rather than alerting on a single process-query event.
- Tune against legitimate diagnostic, device management, accessibility, IME, developer, or troubleshooting workflows that may enumerate processes with user-facing purpose.
- Look for short time-window patterns: bursts of process or /proc access followed by IPC probes, network activity, or targeting of specific packages/processes.
- Preserve app/package attribution so SOC and IR teams can distinguish platform services, sanctioned management tools, and third-party apps.
- Document telemetry gaps, especially where Android versions, privacy restrictions, EDR/MDM limits, or non-rooted devices reduce visibility into API calls, /proc access, or shell execution.
Mitigation priorities
- First, inventory which Android devices, app classes, and privilege contexts are in scope for monitoring, especially rooted/debug/device-owner/profile-owner/accessibility/IME cases.
- Restrict unnecessary privileged app states and review apps that require accessibility, IME, device-owner/profile-owner, debug, or root-equivalent capabilities.
- Establish allowlists or expected-behavior baselines for legitimate diagnostic and management tools before operationalizing alerts.
- Use mobile device management and app governance processes to investigate or remove apps that perform unexplained background enumeration inconsistent with their business purpose.
- Feed confirmed findings into incident response playbooks so responders can collect app metadata, timing, privilege context, and follow-on activity before making containment decisions.
Analyst notes and limits
The ATT&CK object is a mobile Android detection analytic, not a full technique entry. Its strongest decision value is helping teams validate whether they can observe and correlate suspicious process-enumeration behavior on Android. The analytic explicitly cautions that detections should describe observable repeated enumeration signals, privilege context, and timing relationships, not infer adversary intent.
No official detection text, tactics, ATT&CK relationships, aliases, labels, or external relationship context were supplied. This take therefore avoids attribution, active exploitation claims, impact claims, and guaranteed detection coverage. Local Android version, device state, mobile security tooling, MDM/EMM visibility, and privacy constraints will determine what evidence is actually collectible.
Analytic 1804
Defender observes an app/package attempting to enumerate running processes by triggering restricted process visibility mechanisms (e.g., repeated queries for running tasks/services, rapid iteration over process identifiers, or access attempts against /proc entries) that are atypical for its declared function and occur without an associated user-facing diagnostic workflow. The detection relies on correlating (1) OS/API calls or shell/system utility execution indicative of process listing or /proc traversal, (2) app privilege context (root, debug build, device owner/profile owner, accessibility/IME status), (3) background execution state, and (4) optional follow-on behaviors consistent with automated discovery (short bursts of local IPC probes, network beacons immediately after enumeration, or rapid targeting of specific high-value package/process names). The analytic should describe what is observable: repeated enumeration signals + privilege context + timing relationship, not the adversary’s intent.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 974f685fab4e… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1804Open source URL
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.