← Back to all briefings
Cybersecurity 8 min read Published Updated Credibility 94/100

Microsoft Entra ID Token Replay Attack Campaign Exploits OAuth 2.0 Refresh Token Weaknesses

A sophisticated attack campaign targeting Microsoft Entra ID environments is exploiting weaknesses in OAuth 2.0 refresh token handling to maintain persistent access to enterprise cloud resources without triggering conventional authentication alerts. The campaign, attributed to a financially motivated threat group, harvests refresh tokens through adversary-in-the-middle phishing proxies and replays them from attacker-controlled infrastructure to access Microsoft 365, Azure, and integrated SaaS applications. Because refresh tokens bypass multi-factor authentication after initial issuance, compromised tokens provide sustained access that persists until the token is explicitly revoked or expires. Microsoft and CISA have published joint guidance on detection and remediation, but the incident underscores structural weaknesses in token-based authentication that affect the entire OAuth 2.0 ecosystem.

Reviewed for accuracy by Kodi C.

Cybersecurity pillar illustration for Zeph Tech briefings
Cybersecurity threat, control, and response briefings

Token-based authentication is the foundation of modern cloud identity, and its weaknesses are being exploited at scale. This campaign demonstrates that multi-factor authentication, while essential, does not provide complete protection against credential theft when attackers operate at the token layer rather than the password layer. An adversary who captures a valid refresh token can access cloud resources as the compromised user — from any device, any location, without repeating the MFA challenge — until the token is revoked. The attack is particularly dangerous because it produces minimal forensic artifacts: token replay sessions appear as legitimate authenticated access from the user's perspective, making detection dependent on behavioral analytics rather than traditional authentication monitoring.

Attack methodology and token harvesting

The attack chain begins with adversary-in-the-middle (AiTM) phishing. The threat group operates phishing infrastructure built on the EvilGinx framework, which proxies the legitimate Microsoft login page to the victim while intercepting the authentication exchange in real time. When the victim enters their credentials and completes the MFA challenge, the phishing proxy captures the resulting session tokens — including the OAuth 2.0 refresh token — before forwarding the authenticated session to the victim. The victim experiences a normal login; the attacker receives a copy of the tokens.

The captured refresh tokens are then replayed from attacker-controlled infrastructure to request new access tokens from Microsoft Entra ID. Because refresh tokens are bearer tokens — their possession alone is sufficient for authentication — no additional MFA challenge is required. The attacker can generate fresh access tokens repeatedly until the refresh token expires or is revoked, maintaining persistent access for days, weeks, or potentially months depending on the organization's token-lifetime configuration.

The phishing campaigns use highly convincing lures targeting users of Microsoft 365, Teams, and SharePoint. Messages impersonate IT departments, HR, and executive leadership, directing recipients to credential-harvesting pages that are visually indistinguishable from legitimate Microsoft login screens. The phishing pages use valid TLS certificates and domain names that closely resemble the target organization's single-sign-on URLs, defeating visual inspection by even cautious users.

Post-token-capture activities proceed rapidly. Within minutes of obtaining a refresh token, the attackers access the victim's mailbox to identify high-value contacts and active business processes. They then use the compromised account to send internal phishing messages to additional targets within the organization, using the trust associated with the legitimate sender identity. This internal phishing chain dramatically accelerates lateral movement within the target organization.

Scope of compromise and business impact

The campaign has compromised organizations across financial services, technology, healthcare, and professional services, with confirmed incidents reported in at least twelve countries. The threat group's objectives are primarily financial: business email compromise targeting wire transfers, invoice redirection, and procurement fraud. Secondary objectives include access to sensitive documents, intellectual property, and business communications that can be monetized through extortion or sold to interested buyers.

Business email compromise losses attributable to the campaign are estimated in the tens of millions of dollars globally. In several documented cases, the attackers established inbox rules that forwarded copies of specific messages to external addresses, monitored financial communications for days to understand payment processes and vendor relationships, and then impersonated the compromised user to request fraudulent wire transfers timed to coincide with legitimate payment cycles.

The compromised refresh tokens also provide access to Azure resources if the affected user has Azure role assignments. In multiple incidents, the attackers used cloud-resource access to provision cryptocurrency-mining infrastructure using the victim organization's Azure subscription, generating significant unexpected cloud costs before detection. The combination of direct financial fraud and cloud-resource abuse amplifies the financial impact of each successful compromise.

Data-exfiltration activities focus on email archives, SharePoint document libraries, and OneDrive file stores accessible through the compromised identity. The attackers use Microsoft Graph API calls to enumerate and download files matching keywords associated with financial data, contractual agreements, and personally identifiable information. The use of legitimate API endpoints for data access makes exfiltration difficult to distinguish from normal user activity without behavioral analytics.

Detection strategies and forensic indicators

Detecting token-replay attacks requires monitoring for behavioral anomalies that distinguish legitimate token usage from attacker-operated sessions. The primary detection signals involve geolocation inconsistencies — token usage from IP addresses and regions inconsistent with the user's normal access patterns — and device fingerprint mismatches, where a token issued to one device type and operating system is used from a different device configuration.

Microsoft's Entra ID sign-in logs provide several signals useful for detection. The "Token Issuer Type" field distinguishes between tokens issued through interactive authentication and those obtained through refresh-token redemption. Unusual patterns of refresh-token redemption — particularly from new IP addresses or device identifiers — warrant investigation. The "Risk Level" field in Entra ID Identity Protection may flag token-replay sessions as risky based on Microsoft's own anomaly-detection models, but this detection is not guaranteed and should be supplemented with organizational monitoring.

Mail-flow anomalies provide secondary detection signals. The creation of new inbox rules, particularly rules that forward messages to external addresses or move messages to less-visible folders, is a strong indicator of account compromise. Monitoring for inbox-rule changes through the Microsoft 365 audit log should be a standard detection control for all organizations.

Microsoft Graph API activity monitoring detects data-exfiltration patterns. Unusual volumes of file downloads, enumeration of SharePoint sites not previously accessed by the user, or OneDrive download patterns inconsistent with the user's normal activity profile indicate potential compromise. Organizations should baseline normal Graph API usage patterns for each user and alert on significant deviations.

Token lifecycle management and remediation

Effective defense against token-replay attacks requires active management of token lifetimes and revocation capabilities. Microsoft's Continuous Access Evaluation (CAE) feature enables near-real-time token revocation when security events are detected, reducing the window of vulnerability from the default refresh-token lifetime to minutes. Organizations should ensure CAE is enabled for all Entra ID applications that support it.

Token-lifetime policies should balance security with usability. Shorter refresh-token lifetimes reduce the duration of potential compromise but increase the frequency of re-authentication prompts that disrupt user workflows. Microsoft's recommended approach uses conditional-access policies to enforce shorter token lifetimes for sessions exhibiting risk signals — such as access from new locations or unmanaged devices — while allowing longer lifetimes for sessions that meet compliance conditions.

Remediation of confirmed compromises requires immediate token revocation for all affected accounts, followed by a forced re-authentication that invalidates all existing sessions. The Revoke-AzureADUserAllRefreshToken PowerShell command (or its Microsoft Graph equivalent) invalidates all refresh tokens for a specified user, forcing re-authentication across all devices and applications. This action should be complemented by a password reset and MFA re-registration to ensure the attacker cannot re-establish access through previously harvested credentials.

Post-compromise investigation should examine the full scope of the attacker's access: mailbox rules, file-access patterns, Azure role assignments, and delegated application permissions. Attackers commonly establish persistence through consent-grant attacks that assign application permissions to attacker-controlled applications, providing API-level access that survives user-credential remediation. Application consent logs should be reviewed and any unauthorized application grants revoked immediately.

Phishing-resistant authentication as structural mitigation

The fundamental structural mitigation for AiTM phishing is phishing-resistant authentication that prevents token harvesting at the authentication layer. FIDO2 security keys and Windows Hello for Business bind the authentication credential to the legitimate authentication endpoint through cryptographic channel binding. Because the credential is cryptographically linked to the real Microsoft login server, it cannot be replayed through a phishing proxy — the proxy receives a cryptographic response that is invalid for any endpoint other than the one the user intended to authenticate to.

Device-bound token protection extends phishing resistance to the token layer. When configured, Entra ID binds tokens to the device on which they were issued, preventing their use from any other device. An attacker who captures a refresh token through a phishing proxy cannot replay it from their own infrastructure because the token is cryptographically bound to the victim's device. Device-bound tokens require managed devices enrolled in Intune or compliant with device-compliance policies.

Conditional-access policies that require compliant devices, managed applications, and phishing-resistant authentication methods provide defense-in-depth against the entire attack chain. Organizations should implement conditional-access policies that enforce these requirements for access to sensitive resources — email, financial systems, administrative portals — even if universal enforcement across all applications is not immediately feasible.

Enable Continuous Access Evaluation for all supported applications in Entra ID. Verify that conditional-access policies are configured to enforce device compliance and risk-based session controls for access to sensitive resources.

Deploy phishing-resistant authentication — FIDO2 security keys or Windows Hello for Business — for high-value accounts including executives, finance personnel, IT administrators, and any user with privileged Azure role assignments. Transition remaining users to phishing-resistant methods as rapidly as organizational logistics allow.

Implement detection monitoring for token-replay indicators: geolocation anomalies in sign-in logs, device-fingerprint mismatches, unusual inbox-rule creation, and anomalous Graph API activity patterns. Integrate these detections into the SOC workflow with defined response procedures.

Conduct a review of application consent grants across the Entra ID tenant. Identify and revoke any application permissions that cannot be attributed to legitimate business use. Implement consent-governance policies that require administrator approval for new application consent grants.

Assessment and outlook

The Entra ID token-replay campaign illustrates a structural challenge in token-based authentication: tokens are bearer credentials whose possession alone confers access, and the protections designed to limit their misuse — short lifetimes, device binding, continuous evaluation — are not universally deployed. The campaign will accelerate enterprise adoption of phishing-resistant authentication and device-bound tokens, but the transition will take years, leaving a window of vulnerability that financially motivated attackers will continue to exploit.

For security leaders, the strategic lesson is that MFA is necessary but not sufficient. The authentication-security conversation must expand from "do we have MFA?" to "is our MFA phishing-resistant, are our tokens device-bound, and do we have the behavioral analytics to detect token misuse?" Organizations that ask and answer these questions will be materially better protected against the credential-theft campaigns that are now the dominant initial-access vector for both financially motivated and state-sponsored threat actors.

Continue in the Cybersecurity pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

Coverage intelligence

Published
Coverage pillar
Cybersecurity
Source credibility
94/100 — high confidence
Topics
Entra ID Security · OAuth Token Replay · Phishing Attacks · Cloud Identity · MFA Bypass · Business Email Compromise
Sources cited
3 sources (learn.microsoft.com, cisa.gov, microsoft.com)
Reading time
8 min

References

  1. Microsoft Security: Token Theft Attack Techniques and Mitigations — learn.microsoft.com
  2. CISA Joint Advisory: Cloud Identity Compromise Through Token Theft — cisa.gov
  3. Adversary-in-the-Middle Phishing: EvilGinx and AiTM Attack Frameworks — microsoft.com
  • Entra ID Security
  • OAuth Token Replay
  • Phishing Attacks
  • Cloud Identity
  • MFA Bypass
  • Business Email Compromise
Back to curated briefings

Comments

Community

We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.

    Share your perspective

    Submissions showing "Awaiting moderation" are in review. Spam, low-effort posts, or unverifiable claims will be rejected. We verify submissions with the email you provide, and we never publish or sell that address.

    Verification

    Complete the CAPTCHA to submit.