AN1744: Analytic 1744
When vetting applications for potential security weaknesses, the vetting process could look for insecure use of Intents. Developers should be encouraged to use techniques to ensure that the intent can only be sent to an appropriate destination (e.g., use explicit rather than implicit intents, permission checking, checking of the destination app's signing certificate, or utilizing the App Links feature). For mobile applications using OAuth, encourage use of best practice.[1][2] On Android, users may be presented with a popup to select the appropriate application to open a URI in. If the user sees an application they do not recognize, they can remove it.
Analyst context for executives and security teams
AN1744 is best treated as a mobile application vetting control, not a traditional SOC alert. Its business value is in finding insecure mobile app behaviors before deployment—especially unsafe intent/deep-link handling and OAuth flows that could send users or data to the wrong destination. For leaders, the key question is whether mobile apps are reviewed for these weaknesses as part of release governance, third-party app approval, and compliance evidence.
Executive priority
Prioritize this where the organization develops, distributes, or approves mobile applications that use app-to-app communication, deep links, or OAuth. The control supports resilience by reducing preventable mobile identity and data-handling weaknesses before they become incident-response issues. Executives should ask whether mobile app vetting produces auditable evidence, whether OAuth native-app best practices are enforced, and whether risky app-linking behavior is blocked before production or enterprise approval.
Technical view
The supplied ATT&CK object describes a vetting analytic for mobile applications, with platform listed as iOS, while the official description and references discuss Android Intents, Android App Links, and OAuth for native apps. SOC, mobile security, and application security teams should therefore validate this as an application review requirement rather than assume runtime detection exists. Review mobile app code, configuration, and release artifacts for unsafe implicit intent/deep-link patterns where applicable, inadequate destination validation, missing permission checks, weak signing-certificate validation, and OAuth native-app flows that do not follow RFC 8252 guidance.
Likely telemetry
- Mobile application source code and build artifacts available to the vetting process
- Application deep-link, URI-scheme, app-link, and OAuth redirect configuration
- Static analysis or mobile application security testing results
- Mobile app signing and certificate validation evidence
- Enterprise mobile application approval or release-review records
Detection direction
- Validate that mobile app vetting explicitly checks for unsafe app-to-app routing and OAuth native-app implementation issues; the official detection field is not provided.
- Tune review logic to distinguish legitimate deep-link and OAuth behavior from insecure destination selection or insufficient validation.
- Confirm whether the analytic is intended for pre-release/static review, enterprise app approval, or runtime monitoring; ATT&CK does not provide a runtime detection procedure here.
- Account for the source-field mismatch: the object platform is iOS, but the description references Android Intents and App Links, so local implementation scope must be clarified before measuring coverage.
- Use external-reference guidance from Android App Links and IETF RFC 8252 as review criteria where those technologies are applicable.
Mitigation priorities
- Make secure mobile app communication and OAuth handling part of release gates and third-party app vetting.
- Require developers to prefer explicit destinations where applicable, perform permission checks, validate destination signing certificates, and use app-linking mechanisms supported by the platform.
- Require OAuth for native apps to follow current best-practice guidance, including secure redirect handling.
- Document review outcomes as compliance and risk evidence for mobile applications that handle identity, sensitive data, or business workflows.
- Educate users, where Android behavior is relevant, to report unfamiliar applications appearing as URI handlers, but do not rely on user choice as the primary control.
Analyst notes and limits
This object is a detection analytic in the mobile ATT&CK domain with no tactics specified and no relationship context supplied. It is most useful as a control-validation and app-vetting prompt for mobile security and application security teams. The official text includes Android-specific concepts despite the platform field listing iOS, so analysts should verify the intended scope in their local ATT&CK content pipeline before using it for coverage reporting.
Official detection content is not provided, and no relationships to techniques, mitigations, software, or groups were supplied. The description supports secure review guidance but does not establish active exploitation, attribution, impact, or guaranteed detection coverage. Local mobile platforms, application architecture, and available review artifacts determine practical applicability.
Analytic 1744
When vetting applications for potential security weaknesses, the vetting process could look for insecure use of Intents. Developers should be encouraged to use techniques to ensure that the intent can only be sent to an appropriate destination (e.g., use explicit rather than implicit intents, permission checking, checking of the destination app's signing certificate, or utilizing the App Links feature). For mobile applications using OAuth, encourage use of best practice.[1][2] On Android, users may be presented with a popup to select the appropriate application to open a URI in. If the user sees an application they do not recognize, they can remove it.
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 | 288eb600f8ec… |
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]
IETF-OAuthNativeApps
W. Denniss and J. Bradley. (2017, October). IETF RFC 8252: OAuth 2.0 for Native Apps. Retrieved November 30, 2018.
Open source URL -
[2]
Android-AppLinks
Android. (n.d.). Handling App Links. Retrieved December 21, 2016.
Open source URL -
[3]
mitre-attack AN1744Open 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.