AN1694: Analytic 1694
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]
Analyst context for executives and security teams
AN1694 is an iOS mobile detection analytic focused on application vetting for insecure use of Intents and related native-app OAuth patterns. Its business value is preventative: before an app is approved, deployed, or trusted for workforce/customer workflows, teams should verify that inter-app communication and OAuth redirects cannot be misrouted to an inappropriate destination.
Executive priority
Treat this as an application assurance and mobile risk governance item rather than a SOC-only alert. Leaders should ask whether iOS apps handling identity, OAuth, or sensitive workflows are reviewed for safe destination binding, permission checks, signing-certificate checks, App Links usage, and OAuth native-app best practices. This supports control evidence for secure SDLC, third-party/mobile app vetting, identity protection, and incident prevention.
Technical view
The supplied ATT&CK object provides no runtime detection logic. For SOC, detection engineering, and IR teams, the practical validation point is whether mobile app vetting can identify insecure Intent handling and OAuth native-app weaknesses before deployment. Reviews should confirm that intent-like routing is constrained to appropriate destinations, that explicit routing is preferred where applicable, that permission and signing-certificate checks are used where relevant, that App Links are correctly implemented, and that OAuth implementations follow native-app best practice such as the referenced RFC 8252 guidance and PKCE-oriented implementation reference.
Likely telemetry
- Mobile application vetting results for iOS apps
- Static analysis or code review findings related to inter-app communication and destination validation
- Configuration evidence for App Links or equivalent app-linking behavior referenced by the analytic
- OAuth native-app implementation evidence, including redirect handling and PKCE-related review artifacts
- Application signing-certificate validation evidence where destination-app trust is checked
Detection direction
- Do not treat this analytic as a ready-made alert; ATT&CK provides no official detection query or event pattern for AN1694.
- Validate whether app-vetting workflows explicitly test for insecure Intent usage and inappropriate destination routing.
- Tune review criteria to distinguish acceptable inter-app communication from unsafe implicit routing or weak destination validation.
- Prioritize apps that use OAuth, handle authentication flows, or exchange sensitive data through app-to-app or app-link mechanisms.
- Check for blind spots where only runtime mobile telemetry is monitored but pre-deployment static review, code review, or third-party app vetting is absent.
Mitigation priorities
- Embed this check into secure SDLC and mobile app procurement/vetting gates for iOS applications.
- Require developers to use safer destination-control techniques where applicable, including explicit destinations, permission checks, signing-certificate checks, and App Links as described in the ATT&CK object.
- For mobile OAuth, require conformance with native-app OAuth best practice referenced by RFC 8252 and the supplied PKCE implementation reference.
- Maintain review evidence so security, audit, and incident response teams can confirm which apps were assessed and what exceptions were accepted.
- Reassess high-risk apps after authentication-flow changes, app-linking changes, or third-party SDK updates.
Analyst notes and limits
This object is a detection analytic in the mobile ATT&CK domain for iOS, but its content is primarily preventative application vetting guidance. It is most useful for mobile application security, identity engineering, secure SDLC, and governance teams, with SOC value coming from knowing whether weak apps were allowed into the environment.
No ATT&CK tactics, relationships, aliases, labels, or official detection logic were supplied. The object does not support claims about active exploitation, specific adversaries, runtime alert coverage, or impact. Local source code, app binaries, OAuth configuration, and app-vetting evidence are required to determine exposure.
Analytic 1694
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]
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 | 2.0 | Current bundle | ec038e24a0da… |
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]
SecureAuth_iOSOAuth_2025
SecureAuth. (2025). Build an iOS App Using OAuth 2.0 and PKCE. Retrieved March 2, 2026.
Open source URL -
[3]
mitre-attack AN1694Open 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.