AN1736: Analytic 1736
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 application vetting for iOS apps to spot risky changes introduced through an app update, especially new permission requests, suspicious runtime behavior, and network destinations the app contacts. For leaders, the value is governance: updates can materially change an app’s risk profile after initial approval, so mobile app review should not be a one-time decision.
Executive priority
Prioritize this where iOS apps are used for sensitive business workflows, regulated data access, or executive/mobile workforce operations. The key decision is whether the organization can prove that app updates are re-assessed for permission changes, runtime risk indicators, and external communications before or soon after deployment. This supports mobile security oversight, compliance evidence, third-party/application risk review, and incident triage when a mobile app becomes suspect.
Technical view
SOC, mobile security, and IR teams should validate whether application vetting services can compare iOS app versions and surface newly requested permissions after updates. Teams should also confirm whether vetting produces evidence of runtime malicious-code indicators and enumerates domains or IP addresses contacted by applications. Because ATT&CK does not provide a specific detection logic for AN1736 and no tactic or relationship context is supplied, this should be treated as a validation requirement for mobile app vetting coverage rather than a ready-to-deploy detection rule.
Likely telemetry
- iOS application inventory and version/update history
- Application permission requests before and after updates
- Application vetting service findings or risk reports
- Runtime analysis or sandbox/vetting indicators, where available
- Domains and IP addresses contacted by vetted applications
Detection direction
- Validate that app vetting occurs after application updates, not only at initial onboarding.
- Tune review workflows to flag newly requested or expanded permissions as higher-priority findings.
- Correlate vetting findings with app update timing and deployment scope to support triage.
- Review listed domains and IP addresses for unexpected, high-risk, or policy-violating communications.
- Account for false positives from legitimate feature updates that require new permissions or new network endpoints.
Mitigation priorities
- Establish a mobile app governance process requiring review of iOS app updates for permission and behavior changes.
- Require application vetting evidence for apps used in sensitive business processes or regulated environments.
- Use mobile management controls to maintain app inventory, version visibility, and update deployment records.
- Define escalation criteria for new permissions, suspicious runtime findings, or unexpected network communications.
- Preserve vetting results and approval decisions as audit and incident response evidence.
Analyst notes and limits
AN1736 is a detection analytic in the mobile ATT&CK domain for iOS. The supplied description focuses on application vetting services detecting post-update permission requests, possible malicious runtime code indicators, and app network communications. No relationships, tactics, aliases, labels, or official detection procedure were supplied, so local implementation details must come from the organization’s mobile security tooling and app governance process.
The ATT&CK object does not provide detection logic, severity, related techniques, or relationship context. It does not state that any specific threat actor uses this behavior or that any organization has coverage. Applicability depends on whether the environment manages iOS apps, uses application vetting services, and retains update, permission, runtime, and network-destination evidence.
Analytic 1736
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 | 7679b0a4cd0a… |
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 AN1736Open 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.