AN1661: Analytic 1661
Unexpected behavior from an application could be an indicator of masquerading. Application vetting services may potentially determine if an application contains suspicious code and/or metadata.
Analyst context for executives and security teams
This analytic highlights a practical mobile risk: an Android application that looks legitimate may behave unexpectedly or contain suspicious code or metadata, indicating possible masquerading. For leaders, the decision value is whether the organization can vet mobile apps before use and recognize when an app’s behavior no longer matches its expected purpose.
Executive priority
Prioritize this where Android devices support business operations, workforce access, or regulated data handling. The key leadership question is not whether this analytic alone proves compromise, but whether mobile governance, app approval, monitoring, and incident response processes can identify and act on suspicious app behavior before it affects identity access, data exposure, or operational continuity.
Technical view
ATT&CK provides a high-level Android detection analytic with no formal detection logic or tactic mapping. SOC, mobile security, and IR teams should validate whether they collect enough application inventory, app metadata, code-vetting results, installation source, permission usage, and runtime behavior evidence to compare observed app behavior against expected behavior. Because the object references application vetting services, teams should also confirm how suspicious code or metadata findings are triaged and escalated.
Likely telemetry
- Android application inventory and package metadata
- Application vetting or mobile threat defense assessment results
- App installation source and version history
- Requested and granted Android permissions
- Runtime behavioral indicators from managed mobile devices, where available
Detection direction
- Validate that Android app vetting exists for business-approved applications and that findings on suspicious code or metadata generate reviewable alerts or tickets.
- Tune review workflows around deviation from expected app behavior rather than app name alone, because masquerading can rely on appearance or metadata similarity.
- Correlate suspicious app findings with inventory, install source, permission changes, and device compliance state before declaring an incident.
- Account for false positives from legitimate app updates, rebranding, regional builds, or permission changes that are documented by the software provider.
- Identify blind spots for unmanaged Android devices, personally owned devices, sideloaded apps, or app stores and installation paths not visible to enterprise tooling.
Mitigation priorities
- Maintain an approved Android application inventory and app governance process for devices that access business resources.
- Use application vetting or mobile security assessment services to inspect code and metadata for suspicious characteristics before approval and during major updates.
- Restrict or review unapproved installation sources where enterprise policy allows.
- Define escalation paths for suspicious mobile app findings so SOC and IR teams can quickly determine business exposure and containment needs.
- Preserve mobile telemetry needed for compliance evidence and post-incident review, including app versions, permissions, vetting results, and device compliance status.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Android in the mobile domain. It states that unexpected application behavior may indicate masquerading and that application vetting services may identify suspicious code or metadata. No relationships, tactics, aliases, labels, or official detection logic were supplied, so this take focuses on defensive validation and governance rather than specific analytic implementation.
Coverage and effectiveness depend on local Android device management, app vetting depth, telemetry availability, and whether devices are managed. The source does not provide detection logic, severity, known adversary use, active exploitation, or relationship context, so no claim of detection certainty or threat attribution should be inferred.
Analytic 1661
Unexpected behavior from an application could be an indicator of masquerading. Application vetting services may potentially determine if an application contains suspicious code and/or metadata.
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 | c8d663a8727f… |
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 AN1661Open 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.