Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1635: Steal Application Access Token

Adversaries can steal user application access tokens as a means of acquiring credentials to access remote systems and resources. This can occur through social engineering or URI hijacking and typically requires user action to grant access, such as through a system “Open With” dialogue.

Application access tokens are used to make authorized API requests on behalf of a user and are commonly used as a way to access resources in cloud-based applications and software-as-a-service (SaaS).[1] OAuth is one commonly implemented framework used to issue tokens to users for access to systems. An application desiring access to cloud-based services or protected APIs can gain entry through OAuth 2.0 using a variety of authorization protocols. An example of a commonly-used sequence is Microsoft's Authorization Code Grant flow.[2][3] An OAuth access token enables a third-party application to interact with resources containing user data in the ways requested without requiring user credentials.

MobileT1635TechniqueObject v1.2 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Steal Application Access Token matters because a mobile user can be tricked or routed into granting an application token that lets another app make authorized API requests to cloud or SaaS resources as that user. The business issue is not only mobile malware; it is whether identity, SaaS, and mobile app controls can prove which app received access, what scope was granted, and whether suspicious token use can be contained quickly.

Executive priority

Prioritize this where Android or iOS devices are used to access cloud applications, protected APIs, or SaaS data through OAuth-style flows. Leaders should ask whether mobile OS currency, user guidance, and secure application design are treated as identity controls, not just endpoint hygiene. For audit and incident readiness, the key decision point is whether the organization can reconstruct token grants and revoke risky access without relying solely on passwords or device wipe actions.

Technical view

For SOC, detection engineering, and IR teams, validate coverage across Android and iOS mobile access paths involving application access tokens, OAuth authorization flows, and URI or app-link handling. ATT&CK provides no official detection text for T1635, but the relationship to DET0656 indicates a detection strategy exists. The supplied relationship context also highlights URI Hijacking as a sub-technique, so teams should specifically review whether app link, deep link, redirect URI, and system 'Open With' behaviors are visible enough to investigate token interception or suspicious consent events.

Likely telemetry

  • Identity provider and OAuth authorization logs showing token grants, scopes, redirect URIs, client/application identifiers, and consent events
  • Cloud/SaaS API access logs showing token-based access to protected resources
  • Mobile device inventory and OS version data for Android and iOS
  • Mobile application inventory, including apps registered to handle links, app links, or URI schemes
  • User-reported prompts or 'Open With' selections associated with authentication or single sign-on flows

Detection direction

  • Confirm whether token issuance, consent, scope changes, and API access are logged with enough context to identify the user, application/client, device, and time sequence.
  • Review URI and app-link handling assumptions for mobile apps, especially where external account login or single sign-on redirects are used.
  • Tune investigations around unusual token grants or unexpected application clients while accounting for legitimate third-party app integrations to reduce false positives.
  • Do not assume password monitoring will detect this behavior; the technique concerns application access tokens that can authorize API activity without exposing the user password.
  • Because the official ATT&CK detection field is not provided, local validation and the related DET0656 strategy details are necessary before claiming coverage.

Mitigation priorities

  • Keep Android and iOS devices on recent operating system versions, aligning with M1006, because OS updates may include security architecture improvements relevant to mobile app and link handling.
  • Provide user guidance, aligned with M1011, on risky authentication prompts, unexpected app-opening choices, and consent requests for cloud or SaaS access.
  • Apply application developer guidance, aligned with M1013, for secure OAuth/native-app design, redirect handling, and API access-token use.
  • Ensure incident response procedures include token review and revocation for affected cloud/SaaS applications, not only password reset or device remediation.
Analyst notes and limits

This object is a mobile ATT&CK technique for Android and iOS with no tactic specified in the supplied fields. Its strongest defensive value is at the intersection of mobile security, identity access management, cloud/SaaS logging, and secure application design. The URI Hijacking sub-technique relationship should shape testing and tabletop scenarios, but implementation-specific OAuth and app-link details must be verified locally.

The official detection text is not supplied, and the relationship data does not include DET0656 implementation details. The object does not state active exploitation, threat actor attribution, business impact, or guaranteed detection methods. Any assessment of exposure or control effectiveness requires environment-specific mobile, identity provider, SaaS, and application telemetry.

Official MITRE ATT&CK definition

Steal Application Access Token

Adversaries can steal user application access tokens as a means of acquiring credentials to access remote systems and resources. This can occur through social engineering or URI hijacking and typically requires user action to grant access, such as through a system “Open With” dialogue.

Application access tokens are used to make authorized API requests on behalf of a user and are commonly used as a way to access resources in cloud-based applications and software-as-a-service (SaaS).[1] OAuth is one commonly implemented framework used to issue tokens to users for access to systems. An application desiring access to cloud-based services or protected APIs can gain entry through OAuth 2.0 using a variety of authorization protocols. An example of a commonly-used sequence is Microsoft's Authorization Code Grant flow.[2][3] An OAuth access token enables a third-party application to interact with resources containing user data in the ways requested without requiring user credentials.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

1 rows
Domain ID Name Relationship / procedure
Mobile T1635.001 URI Hijacking Sub-technique URI Hijacking subtechnique of this object.
Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0656: Detection of Steal Application Access Token Mobile mitigates · Mitigation M1006: Use Recent OS Version Mobile mitigates · Mitigation M1011: User Guidance Mobile mitigates · Mitigation M1013: Application Developer Guidance Mobile subtechnique of · Technique T1635.001: URI Hijacking Mobile
Mitigations

Mitigation direction

Mitigation Mobile

M1006: Use Recent OS Version

New mobile operating system versions bring not only patches against discovered vulnerabilities but also often bring security architecture improvements that provide resilience against potential vulnerabilities or weaknesses that have not yet been discovered. They may also bring improvements that block use of observed adversary techniques.

Mitigation Mobile

M1011: User Guidance

Describes any guidance or training given to users to set particular configuration settings or avoid specific potentially risky behaviors.

Mitigation Mobile

M1013: Application Developer Guidance

Application Developer Guidance focuses on providing developers with the knowledge, tools, and best practices needed to write secure code, reduce vulnerabilities, and implement secure design principles. By integrating security throughout the software development lifecycle (SDLC), this mitigation aims to prevent the introduction of exploitable weaknesses in applications, systems, and APIs. This mitigation can be implemented through the following measures: Preventing SQL Injection (Secure Coding Practice):

- Implementation: Train developers to use parameterized queries or prepared statements instead of directly embedding user input into SQL queries. - Use Case: A web application accepts user input to search a database. By sanitizing and validating user inputs, developers can prevent attackers from injecting malicious SQL commands.

Cross-Site Scripting (XSS) Mitigation:

- Implementation: Require developers to implement output encoding for all user-generated content displayed on a web page. - Use Case: An e-commerce site allows users to leave product reviews. Properly encoding and escaping user inputs prevents malicious scripts from being executed in other users’ browsers.

Secure API Design:

- Implementation: Train developers to authenticate all API endpoints and avoid exposing sensitive information in API responses. - Use Case: A mobile banking application uses APIs for account management. By enforcing token-based authentication for every API call, developers reduce the risk of unauthorized access.

Static Code Analysis in the Build Pipeline:

- Implementation: Incorporate tools into CI/CD pipelines to automatically scan for vulnerabilities during the build process. - Use Case: A fintech company integrates static analysis tools to detect hardcoded credentials in their source code before deployment.

Threat Modeling in the Design Phase:

- Implementation: Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to assess threats during application design. - Use Case: Before launching a customer portal, a SaaS company identifies potential abuse cases, such as session hijacking, and designs mitigations like secure session management.

**Tools for Implementation**:

- Static Code Analysis Tools: Use tools that can scan for known vulnerabilities in source code. - Dynamic Application Security Testing (DAST): Use tools like Burp Suite or OWASP ZAP to simulate runtime attacks and identify vulnerabilities. - Secure Frameworks: Recommend secure-by-default frameworks (e.g., Django for Python, Spring Security for Java) that enforce security best practices.

Change history

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 .

ATT&CK release
19.1
Object version
1.2
Created
Modified
Raw hash
de56531bf18d1eb6...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.2 Current bundle de56531bf18d…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Auth0 - Why You Should Always Use Access Tokens to Secure APIs Sept 2019

    Auth0. (n.d.). Why You Should Always Use Access Tokens to Secure APIs. Retrieved September 12, 2019.

    Open source URL
  2. [2]
    Microsoft Identity Platform Protocols May 2019

    Microsoft. (n.d.). Retrieved September 12, 2019.

    Open source URL
  3. [3]
    Microsoft - OAuth Code Authorization flow - June 2019

    Microsoft. (n.d.). Microsoft identity platform and OAuth 2.0 authorization code flow. Retrieved September 12, 2019.

    Open source URL
  4. [4]
    Android-AppLinks

    Android. (n.d.). Handling App Links. Retrieved December 21, 2016.

    Open source URL
  5. [5]
    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
  6. [6]
    mitre-attack T1635
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use