AN1673: Analytic 1673
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 apps that query system properties through `android.os.SystemProperties` or `getprop` via runtime `exec()` may be trying to understand whether they are running in a sandbox or analysis environment. For leaders, the practical value is not a standalone incident signal; it is a vetting and assurance check that can help reduce risk from mobile applications before they reach users or managed devices.
Executive priority
Prioritize this as a mobile application governance and assurance control. Security leaders should ask whether Android application vetting, mobile threat defense, or app store review processes can identify apps that access discouraged system-property mechanisms, and whether exceptions are documented for legitimate business apps. This supports mobile risk management, compliance evidence for app review, and incident readiness when suspicious Android applications are discovered.
Technical view
For Android application vetting, validate whether static or dynamic analysis can identify attempts to use `android.os.SystemProperties` or execute `getprop` through runtime `exec()` calls. Because ATT&CK provides no tactic mapping or separate detection logic for this analytic, treat matches as review triggers rather than confirmed malicious activity. SOC and IR teams should correlate this behavior with other mobile app findings, permissions, provenance, and sandbox-evasion indicators before escalation.
Likely telemetry
- Android application package static analysis results
- Mobile application vetting service findings
- Dynamic sandbox or runtime analysis logs showing runtime `exec()` usage
- Code references to `android.os.SystemProperties`
- Observed command execution of `getprop` during app analysis
Detection direction
- Confirm whether Android app vetting covers both direct references to `android.os.SystemProperties` and runtime execution patterns involving `getprop`.
- Tune triage so this behavior is treated as a sandbox-evasion concern or policy exception candidate, not as proof of compromise by itself.
- Review false positives from legitimate diagnostic, device-management, or compatibility logic that may query system properties.
- Correlate with broader mobile app risk signals because no relationship context, tactic, or official detection query is supplied.
- Maintain evidence of reviewed exceptions to support audit and mobile risk governance.
Mitigation priorities
- Require Android application vetting before approval or deployment of mobile apps in managed environments.
- Document acceptable business cases for system-property access and flag undocumented use for security review.
- Use mobile application governance processes to block, quarantine, or further analyze apps that exhibit unexplained property-query behavior.
- Ensure incident response playbooks include collection of app package, source, signer, vetting findings, and runtime analysis evidence when suspicious Android apps are investigated.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Android application vetting. Its official description specifically highlights `android.os.SystemProperties` and `getprop` through runtime `exec()` as possible indicators of sandbox evasion because Google recommends against using system properties within applications. No tactics, relationships, aliases, or official detection implementation were provided.
This take is limited to the supplied STIX fields and external reference. It does not establish maliciousness, active exploitation, attribution, or detection coverage. Local app inventory, vetting tooling, sandbox visibility, and business-approved exceptions are required to determine operational significance.
Analytic 1673
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 | c6f4e4a5e56b… |
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 AN1673Open 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.