AN1691: Analytic 1691
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.
Analyst context for executives and security teams
This analytic matters because Android applications that query system properties through `android.os.SystemProperties` or by running `getprop` with runtime execution may be trying to learn whether they are inside an analysis sandbox. For leaders, the value is not just spotting a suspicious API call; it is validating whether mobile application vetting can identify apps that may behave differently during review than on real devices.
Executive priority
Prioritize this as a mobile application vetting and risk-governance question: do approved or internally distributed Android apps undergo review for sandbox-evasion indicators before they reach users or business workflows? This can support mobile security assurance, third-party app risk review, and compliance evidence around application screening. It should not be treated as proof of compromise by itself, but as a signal that an app deserves deeper review before trust decisions are made.
Technical view
For Android-focused SOC, mobile security, and application review teams, validate whether static or dynamic vetting can identify references to `android.os.SystemProperties` and runtime execution of `getprop`. The supplied ATT&CK object does not specify a tactic or runtime detection logic, so teams should treat this as an application-vetting analytic rather than an endpoint alert definition. Findings should be triaged in context: legitimate diagnostics or device-compatibility checks may create noise, while suspicious use is stronger when the property checks appear tied to environment detection, conditional behavior, or analysis avoidance.
Likely telemetry
- Android application package contents and decompiled code references
- Static analysis results for `android.os.SystemProperties` usage
- Static or dynamic analysis evidence of runtime `exec()` calls invoking `getprop`
- Mobile application vetting service findings
- Sandbox or application analysis logs showing property queries during execution
Detection direction
- Confirm whether mobile app vetting tools inspect Android code for `android.os.SystemProperties` references.
- Confirm whether dynamic analysis captures runtime `exec()` command usage, specifically calls to `getprop`.
- Tune review workflows so this signal triggers investigation rather than automatic malicious classification, because the ATT&CK description only states it could indicate sandbox evasion.
- Look for surrounding logic that changes behavior based on property values, since that context can help separate benign compatibility checks from possible sandbox-evasion behavior.
- Document coverage gaps where apps are allowed onto managed devices without static or dynamic vetting.
Mitigation priorities
- Establish or strengthen Android application vetting before apps are approved for enterprise use.
- Require deeper review for apps that query system properties in ways inconsistent with expected functionality.
- Use mobile application governance processes to restrict unreviewed or high-risk apps from managed environments.
- Maintain evidence of vetting decisions for audit, compliance, and incident-response readiness.
- Where internal Android apps are developed, discourage unnecessary reliance on system properties and review use of runtime command execution.
Analyst notes and limits
The object is a detection analytic for the ATT&CK mobile domain and Android platform. It describes an application-vetting approach for identifying possible sandbox-evasion behavior involving system property access. Because no relationships, tactic mapping, or official detection implementation were supplied, this take focuses on validation questions and review workflow value rather than a specific SIEM rule or incident conclusion.
The supplied ATT&CK fields do not provide a tactic, related technique, examples, adversary use, impact, or formal detection logic. Local application inventories, vetting tooling, and code-analysis results are required to determine relevance and severity in a specific environment.
Analytic 1691
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.
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.0 | Current bundle | f756889516e4… |
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 AN1691Open 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.