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

AN1692: Analytic 1692

Application vetting services could look for applications attempting to get `android.os.SystemProperties` or `getprop` with the runtime `exec()` commands. This could indicate some level of sandbox evasion, as Google recommends against using system properties within applications.

MobileAN1692AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

AN1692 is a mobile application-vetting analytic focused on spotting apps that try to read system properties through `android.os.SystemProperties` or `getprop` via runtime `exec()` calls. In practical terms, this matters because those behaviors can indicate an app is checking the environment it is running in, including possible sandbox or analysis evasion. For security leaders, the value is not in treating this as a confirmed threat by itself, but in validating whether mobile app review processes can surface suspicious environment-checking behavior before apps are approved or trusted.

Executive priority

Prioritize this as a mobile application assurance and risk-screening control, especially where the organization approves, distributes, or relies on mobile applications. The main business question is whether app vetting produces usable evidence when applications attempt behaviors that may reduce analysis visibility. Because ATT&CK provides no tactic mapping, relationships, or detection implementation details for this object, it should be treated as a validation prompt rather than a complete detection requirement.

Technical view

SOC, mobile security, and application vetting teams should confirm whether their mobile app analysis pipeline can identify references to `android.os.SystemProperties` and runtime `exec()` use of `getprop`. The supplied object lists iOS as the platform, while the description references Android-specific APIs and commands; teams should resolve that discrepancy before using this analytic as a coverage claim. If applicable to the local mobile analysis environment, detections should distinguish benign framework/library references from executable behavior that actually attempts to query system properties during static or dynamic analysis.

Likely telemetry

  • Mobile application static analysis results showing API references and command strings
  • Dynamic sandbox logs showing process execution or runtime command invocation
  • Application vetting service findings and review notes
  • Mobile app package metadata and embedded library inventory
  • Sandbox or emulator analysis logs, where available

Detection direction

  • Validate whether app vetting tools can search for `android.os.SystemProperties`, `getprop`, and runtime `exec()` usage.
  • Tune findings to separate mere string/API presence from observed execution or meaningful use during analysis.
  • Review false positives from legitimate diagnostics, compatibility checks, embedded SDKs, or vendor libraries before escalating.
  • Do not claim coverage for iOS based solely on this object without resolving the Android-specific description versus supplied iOS platform field.
  • Because no official detection logic is provided, document local analytic assumptions, data sources, and review criteria as part of detection engineering evidence.

Mitigation priorities

  • Ensure mobile app approval workflows include static and, where appropriate, dynamic analysis for suspicious environment-checking behavior.
  • Require manual review or risk acceptance for applications that query system properties in ways not justified by business functionality.
  • Maintain evidence from application vetting for audit, compliance, and third-party risk discussions.
  • Use results to inform mobile application allowlisting, procurement review, and incident response triage rather than treating the analytic alone as proof of maliciousness.
Analyst notes and limits

This object is a detection analytic in the mobile ATT&CK domain with no supplied relationships and no official detection text beyond the description. The description specifically references Android APIs and commands, while the supplied platform field is iOS. That inconsistency is material and should be called out in any coverage assessment.

The source does not provide tactic mappings, related techniques, detection logic, severity, actor context, or evidence of exploitation. Local mobile platforms, app-vetting tooling, and sandbox telemetry determine whether this analytic is applicable and measurable.

Official MITRE ATT&CK definition

Analytic 1692

Application vetting services could look for applications attempting to get `android.os.SystemProperties` or `getprop` with the runtime `exec()` commands. This could indicate some level of sandbox evasion, as Google recommends against using system properties within applications.

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.0
Created
Modified
Raw hash
0778f1a483b52da3...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 0778f1a483b5…
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 AN1692
    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.