Tactic: Persistence (ATK-TA0003)
Technique ID: SAFE-T1202
Severity: High
First Observed: 2021 (Academic research documented by Fett et al.)
Last Updated: 2025-09-06
OAuth Token Persistence is a technique where adversaries steal and reuse OAuth access/refresh tokens for persistent access to MCP-connected services, including replay of refresh tokens after legitimate client sessions end. This attack exploits the long-lived nature of OAuth refresh tokens and the trust relationships established between MCP servers and external services.
Unlike traditional session hijacking that typically affects single applications, OAuth token persistence in MCP environments enables adversaries to maintain unauthorized access across multiple interconnected services through the protocol's standardized authentication mechanisms. The attack is particularly concerning in MCP deployments where refresh tokens may have extended validity periods (up to 90 days) and can be used to mint new access tokens without user interaction.
- Primary Vector: Theft of OAuth refresh tokens from compromised MCP servers or client applications
- Secondary Vectors:
- Browser-based token extraction from local storage or memory
- Man-in-the-middle attacks during OAuth flows
- Malware-based credential harvesting (infostealers)
- Social engineering attacks targeting OAuth authorization flows
- Cross-Site Scripting (XSS) attacks to steal tokens from web applications
- Compromise of MCP server infrastructure storing authentication tokens
- Target MCP server or client application uses OAuth 2.0 for authentication
- Refresh tokens are stored in accessible locations (browser storage, application memory, or server databases)
- Tokens have extended validity periods typical in OAuth implementations
- Insufficient token binding or device attestation mechanisms
- Initial Access: Adversary gains access to OAuth tokens through various vectors (malware, phishing, XSS, or server compromise)
- Token Extraction: Adversary extracts refresh tokens from browser storage, application memory, or server databases
- Token Validation: Adversary validates stolen tokens by attempting to refresh access tokens
- Persistence Establishment: Adversary uses refresh tokens to maintain long-term access to MCP-connected services
- Access Expansion: Adversary leverages Family of Client IDs (FOCI) or similar mechanisms to access additional services within the same ecosystem
- Post-Exploitation: Adversary conducts data exfiltration, privilege escalation, or lateral movement using persistent access
{
"attack_type": "oauth_token_persistence",
"target": "mcp_gmail_server",
"stolen_token": {
"refresh_token": "1//04_refresh_token_example",
"client_id": "123456789.apps.googleusercontent.com",
"scope": "https://www.googleapis.com/auth/gmail.readonly",
"expires_in": 7776000
},
"persistence_duration": "90_days",
"impact": "continuous_email_access_without_user_awareness"
}According to research from Secureworks and MITRE ATT&CK T1528, attackers have developed sophisticated OAuth token persistence methods:
- Family of Client IDs (FOCI) Exploitation: Using undocumented Microsoft Azure AD refresh token behavior where tokens issued to one client in a "family" can be redeemed for access tokens to other clients in the same family (Secureworks, 2022)
- Primary Refresh Token (PRT) Theft: Targeting Windows 10+ devices to steal PRTs that provide SSO access across Microsoft applications (Microsoft Security, 2024)
- Device Code Phishing: Social engineering attacks that trick users into approving OAuth device flows, granting attackers legitimate refresh tokens (Microsoft Threat Intelligence, 2024)
- Cross-Platform Token Reuse: Exploiting OAuth implementations that allow tokens to be used across different platforms or applications beyond their intended scope
The Model Context Protocol creates unique risks for OAuth token persistence:
- Centralized Token Storage: MCP servers often store multiple OAuth tokens for different services, creating high-value targets
- Cross-Service Token Access: Compromised MCP servers can provide access to tokens for multiple connected services simultaneously
- Long-Lived Sessions: MCP implementations may use extended token lifetimes to reduce authentication friction
Attackers can exploit MCP's tool chaining capabilities:
- Initial Compromise: Gain access to one MCP tool's OAuth tokens
- Lateral Movement: Use MCP's inter-tool communication to access tokens for other connected services
- Privilege Escalation: Leverage higher-privileged service tokens accessed through the MCP server
- Confidentiality: High - Unauthorized access to user data across multiple services
- Integrity: Medium - Potential for data modification through persistent access
- Availability: Low - Primarily focused on unauthorized access rather than service disruption
- Scope: Network-wide - Can affect multiple services connected through MCP infrastructure
According to security researchers and industry reports, organizations are implementing various mitigations:
- Microsoft has introduced token binding and Conditional Access policies to limit token reuse (Microsoft Security, 2024)
- Google has implemented device-bound session credentials to prevent token theft (Google Security Blog, 2024)
- OAuth 2.1 specification mandates PKCE and restricts implicit flows to reduce token exposure (IETF OAuth 2.1, 2024)
- Industry adoption of phishing-resistant authentication methods like FIDO2/WebAuthn is increasing
However, legacy OAuth implementations and the complexity of MCP environments continue to present challenges for comprehensive token security.
Note: OAuth token persistence attacks can be challenging to detect as they often appear as legitimate API usage. Organizations should implement multi-layered detection approaches combining behavioral analysis, anomaly detection, and token validation mechanisms.
- Unusual API access patterns from previously authenticated sessions
- Token usage from unexpected geographic locations or IP addresses
- Access token refresh attempts after user logout or password changes
- Multiple concurrent sessions using the same refresh token
- API calls outside normal business hours or usage patterns
- Attempts to access services not typically used by the account holder
Important: The following rule is written in Sigma format and contains example patterns only. OAuth token persistence attacks often leverage legitimate authentication mechanisms, making detection complex. Organizations should:
- Implement behavioral analysis to identify unusual token usage patterns
- Monitor for impossible travel scenarios in token usage
- Track token lifetime and refresh patterns for anomalies
- Correlate authentication events with user behavior baselines
# EXAMPLE SIGMA RULE - Not comprehensive
title: Suspicious OAuth Token Usage Pattern
id: a7d4c8e2-3f1b-4d5e-9a8c-7b6f5e4d3c2a
status: experimental
description: Detects potential OAuth token persistence through unusual token usage patterns
author: SAFE-MCP Team <safe-mcp@example.com>
date: 2025-09-06
references:
- https://github.com/safe-mcp/techniques/SAFE-T1202
logsource:
product: oauth
service: token_validation
detection:
selection_concurrent_usage:
event_type: 'token_refresh'
token_type: 'refresh_token'
selection_geographic_anomaly:
event_type: 'api_access'
geographic_distance: '>1000' # Miles from previous access
time_delta: '<3600' # Within 1 hour
selection_post_logout:
event_type: 'token_usage'
user_session_status: 'logged_out'
time_since_logout: '>300' # More than 5 minutes after logout
condition: any of selection_*
falsepositives:
- Legitimate users accessing services from multiple locations
- Mobile applications with background refresh mechanisms
- Shared accounts or service accounts with multiple access points
- Users traveling across time zones
level: high
tags:
- attack.persistence
- attack.t1528
- safe.t1202- API access patterns that deviate from established user baselines
- Token refresh activities occurring outside normal user active hours
- Simultaneous access from multiple geographic locations (impossible travel)
- Continued service access after user-initiated logout or password changes
- Access to services or data not previously accessed by the user account
- Unusual volume or frequency of API calls using refresh tokens
- SAFE-M-1: Architectural Defense - Token Binding: Implement cryptographic token binding to tie OAuth tokens to specific devices or sessions, preventing token reuse on unauthorized systems
- SAFE-M-2: Cryptographic Integrity: Use proof-of-possession (PoP) tokens and device attestation to ensure tokens can only be used by legitimate clients
- SAFE-M-3: AI-Powered Content Analysis: Deploy machine learning systems to analyze token usage patterns and detect anomalous behavior indicative of token theft
- SAFE-M-4: OAuth Security Best Practices: Implement OAuth 2.1 recommendations including:
- Mandatory PKCE for all OAuth flows
- Short-lived access tokens (1 hour maximum)
- Refresh token rotation to invalidate stolen tokens
- Restricted redirect URIs and client authentication
- SAFE-M-5: Secure Token Storage: Store OAuth tokens using secure mechanisms:
- HTTP-only, secure cookies for web applications
- Encrypted storage with hardware security modules (HSMs)
- Avoid localStorage or sessionStorage for sensitive tokens
- SAFE-M-6: Conditional Access Policies: Implement dynamic access controls that evaluate:
- Device trust and compliance status
- Geographic location and impossible travel detection
- Risk-based authentication requirements
- SAFE-M-7: Phishing-Resistant Authentication: Deploy FIDO2/WebAuthn and hardware-backed authentication methods to prevent initial token compromise
- SAFE-M-8: Network Security Controls: Implement network-level protections including:
- Zero Trust Network Access (ZTNA)
- Mutual TLS (mTLS) for API communications
- Network segmentation for MCP infrastructure
- SAFE-M-10: Behavioral Analytics: Deploy User and Entity Behavior Analytics (UEBA) to detect:
- Unusual token usage patterns
- Geographic anomalies in access patterns
- Impossible travel scenarios
- Access to previously unused services or data
- SAFE-M-11: Token Lifecycle Monitoring: Monitor OAuth token lifecycle events:
- Token issuance, refresh, and revocation events
- Concurrent token usage from multiple locations
- Token usage after user logout or password changes
- SAFE-M-12: Comprehensive Audit Logging: Implement detailed logging of:
- All OAuth token operations and API calls
- Device and location information for token usage
- Correlation with user authentication events
- Immediate Actions:
- Revoke all OAuth tokens associated with compromised accounts
- Force user reauthentication across all services
- Disable account access pending investigation
- Preserve forensic evidence from affected systems
- Investigation Steps:
- Analyze token usage logs for unauthorized access patterns
- Correlate access patterns with known threat intelligence
- Identify the initial compromise vector (malware, phishing, etc.)
- Assess the scope of data accessed using stolen tokens
- Remediation:
- Update OAuth implementations to current security standards
- Implement additional token binding and device attestation
- Enhance monitoring and alerting for token usage anomalies
- Conduct security awareness training on OAuth security risks
Microsoft Security reported a sophisticated campaign where attackers used device code phishing to:
- Attack Vector: Social engineering via Microsoft Teams messages
- Impact: Persistent access to Microsoft 365 services without triggering MFA
- Technique: Legitimate OAuth device flows exploited to gain refresh tokens
- Duration: Attacks maintained access for weeks before detection
Security researchers documented cases where:
- Attack Vector: Browser-based malware extracting OAuth tokens from local storage
- Impact: Unauthorized access to cryptocurrency exchange APIs
- Technique: Infostealers targeting saved authentication tokens
- Scope: Multiple exchanges affected through common OAuth implementations
Recent incidents have shown:
- Attack Vector: Compromised MCP servers exposing stored OAuth tokens
- Impact: Cross-platform access to enterprise SaaS applications
- Technique: Lateral movement through MCP tool chains
- Detection: Often discovered weeks after initial compromise
Based on Secureworks research:
- Attack Vector: Exploitation of undocumented Family of Client IDs behavior
- Impact: Single stolen refresh token provided access to multiple Google services
- Technique: Token reuse across applications within the same "family"
- Mitigation: Google has since implemented additional token validation
- SAFE-T1001: Tool Poisoning Attack - Can be combined with OAuth token theft for enhanced persistence
- SAFE-T1007: OAuth Authorization Phishing - Common initial access vector for token theft
- SAFE-T1102: Prompt Injection - May be used to manipulate MCP servers into exposing tokens
- SAFE-T1601: MCP Server Enumeration - Reconnaissance technique for identifying OAuth-enabled services
- Model Context Protocol Specification
- OWASP Top 10 for LLM Applications
- OAuth 2.0 Security Best Current Practice - IETF RFC
- Family of Client IDs Research - Secureworks
- MITRE ATT&CK T1528: Steal Application Access Token
- Understanding Primary Refresh Tokens - Microsoft
- OAuth 2.0 Threat Model and Security Considerations - IETF RFC 6819
- Session Token Theft: A Growing Threat to Modern Authentication - Halock Security
- Securing the Gatekeeper: Addressing Vulnerabilities in OAuth Implementations - IJGIS 2024
- The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems - Sun & Beznosov, 2012
- Machine learning approach to vulnerability detection in OAuth 2.0 - Munonye & Martinek, 2021
- OAuth 2.0 Redirect URI Validation Falls Short, Literally - Innocenti et al., 2023
- Why avoiding LocalStorage for tokens is the wrong solution - Pragmatic Web Security
- Broken OAuth Vulnerability - SecureFlag
- Common Security Issues in Implementing OAuth 2.0 - PullRequest
- Understanding Token Theft - Triskele Labs
- Primary Refresh Tokens Aren't Your Parent's Browser Token - KnowBe4
- Understanding Tokens in Entra ID: A Comprehensive Guide - Xintra
- T1528 - Steal Application Access Token
- T1539 - Steal Web Session Cookie
- T1556 - Modify Authentication Process
| Version | Date | Changes | Author |
|---|---|---|---|
| 1.0 | 2025-09-06 | Initial documentation of OAuth Token Persistence technique based on comprehensive research of OAuth 2.0 security vulnerabilities, MCP-specific risks, token theft methodologies, and real-world incidents. Includes detailed technical analysis, detection methods, and mitigation strategies. | Smaran Dhungana smarandhg@gmail.com |