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

AN1648: Analytic 1648

Defender correlates an app process performing a burst of OS/device attribute lookups (build, hardware, SDK level, system properties) with near-term execution branching (feature gating, module load, permission workflow changes) and/or immediate outbound communications, indicating environment evaluation used to shape follow-on actions.

MobileAN1648AnalyticObject v1.1 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This analytic matters because Android apps that rapidly inspect device and OS attributes and then change behavior may be making decisions about what to do next, such as enabling features, loading modules, changing permission flows, or communicating outward. For security leaders, the decision value is whether mobile monitoring can show not just that an app queried device details, but that those lookups were followed by behavior changes or network activity.

Executive priority

Prioritize this as a mobile security and incident-readiness validation point for Android environments. It supports questions such as: do we have evidence to explain why a suspicious app changed behavior on certain devices, can SOC or IR teams correlate app runtime behavior with outbound communications, and can mobile telemetry support audit or investigation needs when app behavior depends on OS version, hardware, SDK level, or system properties?

Technical view

For Android, validate whether available telemetry can correlate bursts of OS/device attribute lookups from an app process with near-term execution branching and/or immediate outbound communications. Because ATT&CK provides no separate detection text, teams should treat the official description as the analytic logic: attribute lookup burst plus subsequent behavior change or network activity. Tune carefully because legitimate apps commonly inspect device attributes for compatibility, feature gating, and permission handling.

Likely telemetry

  • Android app process activity or runtime instrumentation showing build, hardware, SDK level, and system property lookups
  • Application behavior events indicating feature gating, module loading, or permission workflow changes
  • Outbound network connection or communication metadata from the same app process
  • Timestamps sufficient to correlate lookups with near-term behavior changes
  • App identity, package name, process context, and device OS/version metadata

Detection direction

  • Confirm that mobile telemetry can observe both sides of the pattern: device/OS attribute lookups and the follow-on behavior they influence.
  • Correlate events by app process, package, device, and time window rather than alerting on attribute lookups alone.
  • Baseline legitimate Android application behavior, since compatibility checks and permission workflow changes can be normal.
  • Prioritize cases where lookup bursts are immediately followed by module loading, changed permission handling, or outbound communications.
  • Document blind spots where mobile device management, endpoint telemetry, app logging, or network visibility cannot capture process-level Android behavior.

Mitigation priorities

  • Establish mobile telemetry requirements for Android app behavior, process context, and network activity before relying on this analytic operationally.
  • Use mobile application vetting and security review processes to understand expected device-attribute checks in approved apps.
  • Limit unnecessary app permissions and enforce mobile security policy where organizational controls allow.
  • Prepare incident response procedures for collecting Android app, device, and network evidence when suspicious behavior depends on environment checks.
  • Use findings to improve compliance evidence around mobile monitoring and investigation readiness, rather than treating this analytic alone as proof of malicious activity.
Analyst notes and limits

This is a detection analytic object, not a technique description. The supplied ATT&CK fields identify Android as the supported platform and describe correlation logic involving OS/device attribute lookups followed by branching behavior or outbound communications. No tactics, relationships, aliases, labels, or separate official detection text were supplied.

The source object does not provide tactics, related techniques, data sources, detection pseudocode, thresholds, mitigations, or relationship context. Local telemetry quality, app baselines, and enterprise mobile architecture are required to determine practical coverage and alert fidelity.

Official MITRE ATT&CK definition

Analytic 1648

Defender correlates an app process performing a burst of OS/device attribute lookups (build, hardware, SDK level, system properties) with near-term execution branching (feature gating, module load, permission workflow changes) and/or immediate outbound communications, indicating environment evaluation used to shape follow-on actions.

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

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
1.1
Created
Modified
Raw hash
813ea93fba18b409...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 813ea93fba18…
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]
    mitre-attack AN1648
    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.