AN1784: Analytic 1784
Defender observes an app enumerating installed security/management controls (AV/EDR/MDM/VPN/Play Protect) via PackageManager, DevicePolicyManager, AppOps, and Settings queries or shell ‘pm list’ usage, optionally probing Accessibility/Device Admin state. Enumeration is followed by local inventory artifact creation and/or small egress. Chain: capability to query → burst of security-focused checks (packages/permissions/policies) → optional foreground targeting → artifact write → quick POST.
Analyst context for executives and security teams
This analytic describes Android apps that look for installed security and management controls such as AV, EDR, MDM, VPN, Google Play Protect, Accessibility, or Device Admin state, then may write a local inventory artifact or send a small outbound POST. For leaders, the practical issue is not just app discovery: it is whether mobile security, device management, and SOC telemetry can show when an app is profiling defensive coverage before changing behavior or exfiltrating inventory data.
Executive priority
Treat this as a mobile security and resilience validation point. Ask whether Android fleet monitoring can evidence which apps query management/security controls, whether MDM and mobile threat defense policies generate reviewable audit data, and whether incident responders can quickly determine if a suspicious app inventoried controls or sent that inventory externally. This matters for regulated environments where mobile device posture, management coverage, and auditability are part of compliance evidence and operational risk decisions.
Technical view
For Android, validate visibility into app use of PackageManager, DevicePolicyManager, AppOps, Settings queries, shell-style package listing such as `pm list`, and checks of Accessibility or Device Admin state. The analytic pattern is a sequence: capability to query, a burst of security-focused package/permission/policy checks, optional foreground targeting, local artifact creation, and a quick outbound POST. Because no official ATT&CK detection logic is supplied, teams should translate this behavior into local rules using available endpoint, MDM, mobile threat defense, app vetting, and network telemetry.
Likely telemetry
- Android application/package inventory and app behavior telemetry
- MDM or mobile device management audit logs for Device Admin, policy, and managed app state
- Mobile threat defense or endpoint telemetry showing package, permission, AppOps, Settings, Accessibility, or DevicePolicyManager queries
- Android logs or EDR-style telemetry showing shell package enumeration such as `pm list`, where available
- File or app sandbox telemetry showing local inventory artifact creation
Detection direction
- Validate whether telemetry can correlate a burst of security-focused enumeration with later artifact creation or outbound POST activity on the same device/app.
- Tune for context: legitimate MDM, inventory, VPN, enterprise support, and security apps may perform similar checks, so allowlisting and expected-app baselining are important.
- Prioritize unknown, sideloaded, newly installed, or low-reputation apps that enumerate security/management controls and then egress data.
- Check blind spots around personal Android devices, unmanaged devices, limited app-level telemetry, encrypted network traffic, and environments that only collect device compliance state rather than behavioral events.
- Because ATT&CK provides no detection query for this analytic, confirm detection engineering assumptions with local Android logging, MDM, and mobile security product capabilities.
Mitigation priorities
- Maintain authoritative Android app inventory and management coverage for in-scope devices.
- Restrict or review sideloaded and untrusted apps where policy permits.
- Use MDM/mobile security controls to monitor Device Admin, Accessibility, VPN, Play Protect, and managed-app posture changes.
- Baseline legitimate enterprise apps that enumerate packages or device policy so suspicious deviations can be triaged faster.
- Ensure incident response playbooks include collection of app inventory, device policy state, local artifacts, and recent network connections for suspected Android apps.
Analyst notes and limits
The supplied object is a detection analytic, not a technique or campaign report. It identifies an Android behavior pattern around security-control enumeration and optional local artifact creation or small egress. There are no supplied relationships, tactics, aliases, or official detection code, so the Glexia take focuses on defensive validation and telemetry readiness rather than attribution or prevalence.
No relationship context, ATT&CK tactics, or official detection logic were supplied. This summary does not establish active exploitation, actor attribution, impact, or guaranteed detectability. Local device management architecture, Android version, app permissions, privacy constraints, and telemetry products will determine practical coverage.
Analytic 1784
Defender observes an app enumerating installed security/management controls (AV/EDR/MDM/VPN/Play Protect) via PackageManager, DevicePolicyManager, AppOps, and Settings queries or shell ‘pm list’ usage, optionally probing Accessibility/Device Admin state. Enumeration is followed by local inventory artifact creation and/or small egress. Chain: capability to query → burst of security-focused checks (packages/permissions/policies) → optional foreground targeting → artifact write → quick POST.
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 | e8bbfea7a4f0… |
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 AN1784Open 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.