Adversaries are exploiting Microsoft’s OAuth model to maintain persistent access — even after users change passwords or enable MFA.

First reported late in October by ProofPoint, attackers are utilizing malicious internal OAuth applications within a victim’s tenant to maintain access to systems, including email and files, without detection. Unlike external third-party apps, these in-tenant applications appear legitimate and are often overlooked during incident response or disaster recovery processes.

How it Works

1. Initial compromise – The attacker gains access to a user’s account through phishing, session hijacking, or adversary-in-the-middle (AiTM) attacks.
2. App registration – Using these compromised credentials, the attacker registers a new OAuth application directly inside the organization’s Microsoft Entra ID (formerly Azure AD) instance.
3. Scope assignment – They grant the app broad permissions such as Mail.Read, Files.ReadWrite, and offline_access, enabling data access and refresh tokens.
4. Persistence – Because the OAuth app authenticates via its own client secret or certificate, it can continue to request access tokens even after the user’s password is reset or MFA is enforced.

Figure 1. User changes the account password after detecting suspicious activity — a legitimate defensive step before realizing that a malicious OAuth app still retains access via persistent tokens.

Why It Matters

This method undermines the assumption that resetting passwords or revoking sessions cuts off all attacker access. Since OAuth apps rely on service principals rather than user credentials, their tokens remain valid independently of user authentication changes. Organizations that rely solely on credential hygiene and MFA enforcement may therefore be blind to this form of persistence.

Figure 2. The malicious OAuth app remains registered in Entra ID with a persistent client secret (here expiring in 2027), allowing sustained access even after user password resets.

Indicators of Compromise

• A new App Registration, especially one created close to the initial detection of suspicious or malicious activity
• Apps with offline access or read/write scopes to mail, files, or sites
• Unusual mailbox rules, external forwarding, or API activity tied to unfamiliar app client IDs

Response Guidelines

1. Revoke client secrets and certificates from any suspicious internal apps
2. Delete the App Registration and service principal to remove its permissions
3. Revoke refresh tokens for affected users
4. Audit all app registrations within Entra ID: look for recent creations, unexpected owners, and risky scopes

Prevention Methods

• Restrict who can register applications within your tenant.
• Require admin consent for high-risk scopes.
• Shorten and rotate client secret lifetimes; monitor long-lived secrets.
• Automate detection of new internal apps with elevated permissions.

Conclusion

This attack highlights a critical gap in cloud identity defense: persistence through application-level credentials. Traditional responses like password resets or MFA activation are no longer enough. To close this blind spot, Casmer Labs thinks organizations must include OAuth app governance and secret lifecycle management in their incident response and monitoring workflows. Implementing and automating IR Runbooks, contemplating previous IoCs, is the best measure nowadays.

External Sources: ProofPoint