AN1674: Analytic 1674
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 is intended for application-vetting workflows, but the supplied ATT&CK fields are sparse and internally inconsistent: the platform is listed as iOS, while the official description refers to Android-specific system property access and getprop execution. The practical value for leaders is to treat this as a quality-control and mobile app risk-review signal rather than a standalone detection: verify whether mobile applications are attempting environment or system-property checks that may indicate sandbox-evasion behavior, and confirm which mobile platform the control actually applies to in your environment.
Executive priority
Prioritize this as a mobile application assurance and compliance-evidence question: do app-vetting processes inspect applications for behaviors that may weaken trust in sandbox analysis or mobile security review? Because the supplied object has no tactic, no detection text, and no relationships, it should not drive incident severity by itself. Its main decision value is in validating mobile app review coverage, documenting what static or dynamic vetting can see, and resolving the iOS-versus-Android platform mismatch before assigning budget, ownership, or control coverage.
Technical view
SOC, mobile security, and application-vetting teams should validate whether their vetting pipeline can identify attempts to access Android system properties or invoke getprop through runtime exec-style behavior, while also checking why the ATT&CK platform field is iOS. Treat matches as triage leads for mobile app review, not proof of malicious activity. Because no official detection logic is provided and no ATT&CK relationships are supplied, teams need local analysis context: application provenance, expected functionality, sandbox results, code-review findings, and whether the behavior is present in production-distributed apps or only in test builds.
Likely telemetry
- Mobile application static-analysis findings
- Mobile application dynamic-analysis or sandbox execution logs
- Application vetting service results
- Code or package indicators showing system-property access attempts
- Runtime behavior evidence showing command execution attempts such as getprop where applicable
Detection direction
- First resolve platform applicability: the object lists iOS, but the description references Android APIs and commands.
- Use this analytic as an application-vetting rule or review heuristic rather than a complete SOC detection, because official detection content is not provided.
- Tune review outcomes around application purpose; some system or diagnostic functionality may create benign findings depending on app role and distribution context.
- Correlate any finding with app source, signing/provenance, requested permissions, observed runtime behavior, and sandbox-analysis notes before escalation.
- Document blind spots in vetting coverage, especially whether analysis can observe runtime exec-style behavior and whether platform-specific checks are correctly scoped.
Mitigation priorities
- Establish ownership for mobile application vetting across security, mobile engineering, and third-party app risk review.
- Confirm that vetting tools and procedures inspect for system-property access and runtime command execution where relevant to the actual platform.
- Require documented review and exception handling for applications that perform environment or system-property checks.
- Use application provenance, signing, and approved-source controls to reduce reliance on a single behavioral signal.
- Maintain audit evidence showing which mobile platforms, app sources, and analysis methods are covered by the vetting process.
Analyst notes and limits
The official description says application vetting services could look for attempts to access android.os.SystemProperties or getprop via runtime exec(), and notes this could indicate sandbox evasion because Google recommends against using system properties within applications. However, the supplied platform field is iOS, and no tactic, detection logic, aliases, labels, or relationship context is supplied. That mismatch should be highlighted in any ATT&CK mapping or control-coverage report.
This take is limited to the supplied STIX fields, external reference, and absence of relationships. It does not establish active exploitation, adversary use, maliciousness, impact, or guaranteed detectability. Local platform scope, mobile app inventory, vetting-tool capability, and application context are required before operational decisions are made.
Analytic 1674
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 | f532a23c7b8a… |
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 AN1674Open 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.