AN1735: Analytic 1735
Application vetting services may detect when an application requests permissions after an application update. Application vetting services may look for indications that the application’s update includes malicious code at runtime. Application vetting services may be able to list domains and/or IP addresses that applications communicate with.
Analyst context for executives and security teams
This analytic is about using Android application vetting to spot risk introduced by app updates, especially when an updated app requests new permissions, appears to add malicious runtime behavior, or communicates with identifiable domains or IP addresses. For leaders, the value is change control for mobile software: an app that was acceptable yesterday may become riskier after an update.
Executive priority
Prioritize this where Android devices support business operations, regulated data access, executive communications, or field workflows. The key decision is whether the organization can prove that mobile app updates are reviewed for new permission requests and suspicious network destinations before they create operational, privacy, or compliance exposure. This is especially relevant to mobile security governance, compliance evidence, and incident triage involving potentially risky applications.
Technical view
SOC, mobile security, and IR teams should validate whether application vetting services are in place for Android apps and whether they evaluate app updates, not only initial installations. The supplied ATT&CK object highlights three review areas: newly requested permissions after update, indications of malicious code at runtime, and domains or IP addresses contacted by applications. Because no official detection logic is provided, teams should treat this as a validation objective rather than a ready-to-deploy analytic.
Likely telemetry
- Android application inventory and version/update history
- Application permission manifests before and after updates
- Mobile application vetting or mobile threat defense findings
- Runtime behavior or sandbox analysis results from app vetting services
- Application network communication metadata, including contacted domains and IP addresses
Detection direction
- Confirm that app vetting covers updates as well as first-time installs.
- Compare permissions requested before and after an Android app update and alert on unexpected or higher-risk changes according to local policy.
- Review vetting outputs for indications of malicious runtime behavior, while accounting for legitimate feature changes that may add permissions or network destinations.
- Correlate listed domains and IP addresses contacted by apps with internal allowlists, threat intelligence, and business justification where available.
- Identify blind spots where unmanaged Android devices, sideloaded apps, or apps outside the vetting workflow would not be assessed.
Mitigation priorities
- Establish or validate a mobile app vetting process for Android applications used in the organization.
- Require review of permission changes introduced by application updates, especially for apps with access to sensitive business data or identity workflows.
- Maintain an approved application inventory and expected permission/network behavior baseline where feasible.
- Integrate app vetting findings into SOC triage and incident response procedures for mobile-related investigations.
- Use policy and governance controls to limit use of apps that cannot be vetted or whose update behavior cannot be justified.
Analyst notes and limits
This object is a mobile ATT&CK detection analytic for Android application vetting. It provides useful direction for what app vetting services may inspect, but it does not include specific detection logic, thresholds, tactics, or related techniques. Local mobile management architecture, app sourcing model, and telemetry availability will determine practical coverage.
The supplied ATT&CK fields do not specify tactics, relationships, exact analytic logic, false-positive criteria, or evidence of active exploitation. Any assessment of coverage, risk severity, or exposure requires local Android device, application, and vetting-service data.
Analytic 1735
Application vetting services may detect when an application requests permissions after an application update. Application vetting services may look for indications that the application’s update includes malicious code at runtime. Application vetting services may be able to list domains and/or IP addresses that applications communicate with.
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 | d84ebaf557f6… |
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 AN1735Open 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.