DET0656: Detection of Steal Application Access Token
DET0656 is a mobile ATT&CK detection strategy intended to help detect attempts to steal application access tokens. The related technique, T1635, matters be...
Analyst context for executives and security teams
DET0656 is a mobile ATT&CK detection strategy intended to help detect attempts to steal application access tokens. The related technique, T1635, matters because stolen application tokens can let an adversary make authorized API requests as a user against remote systems, cloud applications, and SaaS resources without needing the user’s password again. For leaders, the practical issue is whether mobile, identity, and cloud monitoring can connect a user-driven mobile event to later suspicious token use in business applications.
Executive priority
Prioritize this as an identity and cloud-access risk, not only a mobile endpoint issue. Security leaders should ask whether the organization can prove how application tokens are issued, protected, revoked, and monitored for mobile users, especially for SaaS and cloud-based applications. This supports incident decision-making when a mobile compromise may require token revocation, session invalidation, conditional access review, and evidence for audit or compliance reporting.
Technical view
ATT&CK provides no official detection logic for DET0656, so SOC and detection teams should validate coverage around the related mobile technique T1635: Steal Application Access Token. Defensive validation should focus on Android and iOS environments where application access tokens may be granted through user action, including social engineering or URI hijacking scenarios involving system application-selection flows such as an “Open With” dialogue. IR teams should be prepared to correlate mobile app events, identity-provider token issuance, SaaS/API access, and post-event resource access under the affected user account.
Likely telemetry
- Mobile device management or mobile endpoint telemetry for Android and iOS devices
- Mobile application inventory and app-open or intent/URI handling evidence where available
- Identity-provider logs showing token issuance, consent, refresh, revocation, and session activity
- SaaS and cloud application API access logs tied to user tokens
- User activity and authentication context around unusual application authorization or access patterns
Detection direction
- Because ATT&CK does not supply a detection analytic, first confirm which telemetry sources can observe token grant, token use, and token revocation events across mobile, identity, and SaaS systems.
- Tune detections for suspicious application authorization patterns, unexpected token use, or API access that is inconsistent with the user, device, application, or recent mobile activity, while accounting for legitimate new app installs and user-approved integrations.
- Validate whether mobile URI handling or application-selection events are visible in the environment; these may be a blind spot if mobile telemetry is limited to enrollment and compliance status.
- Correlate mobile-side indicators with cloud/SaaS API activity rather than relying on either source alone, since the business impact occurs when the token is used to access remote resources.
- Include false-positive review for normal OAuth-style consent, application updates, device migrations, and sanctioned third-party SaaS integrations.
Mitigation priorities
- Inventory mobile applications and SaaS integrations that can request user application access tokens.
- Ensure identity and SaaS administration teams can revoke application tokens and invalidate sessions quickly during incident response.
- Review access policies for mobile users and cloud/SaaS applications, including device trust and application consent controls where available.
- Maintain mobile device management and application governance evidence for audit and incident response readiness.
- Run tabletop or validation exercises that test the path from suspected mobile token theft to identity investigation, token revocation, and SaaS access review.
Analyst notes and limits
This take is based on ATT&CK detection strategy DET0656 and its relationship to technique T1635, Steal Application Access Token. The source object has no official description, detection text, tactics, or platforms; platform context comes only from the related technique, which lists Android and iOS. The most important local validation question is whether the organization can correlate mobile events with identity-provider and SaaS/API token activity.
ATT&CK supplies sparse fields for this detection strategy and does not provide a concrete analytic, data source list, or mitigation text. Recommendations are therefore conservative and relationship-driven. Local architecture, identity provider, SaaS platforms, mobile management tooling, and logging retention will determine actual detection and response coverage.
Detection of Steal Application Access Token
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1635 | Steal Application Access Token | This object detects Steal Application Access Token. |
All related ATT&CK context
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 | 179cc4ea65e7… |
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 DET0656Open 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.