OAuth Consent Abuse: A Trust Boundary Collapse in Microsoft 365

A user installed a browser extension that was granted delegated access to the organization’s entire Microsoft 365 tenant through OAuth consent. This is not a compromised account. It is a trust boundary collapse.

The extension requested application-level permissions - Mail.ReadWrite, User.ReadWrite.All, Files.ReadWrite.All - through Microsoft’s OAuth 2.0 consent framework. A user with administrative privileges approved the consent prompt. At that point, the application was granted the ability to read, write, and manage every mailbox, calendar, file, and identity in the tenant. MFA authenticated the user. It did not gate the consent decision. No additional verification was required to approve tenant-wide scope.

Once consent was granted, the application operated independently of the user’s session. Through client credentials flow, it authenticated using its own secret against Azure AD and called Microsoft Graph API endpoints directly. The user’s password, session state, and device posture became irrelevant. Access tokens issued via client credentials default to approximately one hour, but the application can request new tokens indefinitely as long as the consent grant remains active. Revoking the user’s credentials does not revoke the application’s access.

The only visible artifact is a single entry in the Azure AD sign-in log: consent granted for a non-registered application with tenant-wide permissions. This event type is not flagged as high-severity by default in Microsoft Defender for Identity or standard SIEM configurations. Without a custom detection rule targeting tenant-wide consent grants from non-verified publishers, this entry is noise.

Specific attacker behavior following consent is not confirmed. The mechanism itself is sufficient to define the risk: any party with access to the application’s credentials can perform full tenant operations - mailbox access, identity enumeration, file exfiltration, permission modification - without triggering authentication-based detections. No lateral movement is required. The consent grant is the lateral movement.

The control failure is systemic. The Azure AD consent framework permits a single user action to escalate an application’s privilege to full tenant scope with no administrative gate, no risk-based challenge on high-scope requests, and no mandatory review for applications requesting all-scoped permissions. This is default behavior. Most organizations do not override it because doing so introduces operational friction - users cannot self-service app integrations, and IT must review every consent request.

Timing of access following consent is not confirmed. Replication details are not confirmed for public disclosure. The pattern is consistent with known adversarial tradecraft around OAuth abuse and consent phishing - MITRE ATT&CK T1550.001 (Application Access Token).

This is not platform-specific. Any identity system where user-initiated consent can expand an application’s privilege boundary without an administrative gate exhibits the same architectural flaw. The core condition: when trust boundaries are defined by user action rather than system-enforced policy, the security model depends on human judgment at the moment of the prompt. That is not a control. That is a gap.

Remediation is structural. Disable user consent for unverified applications. Require admin approval for any permission request classified as high-privilege. Deploy detection for consent grant events scoped to tenant-wide permissions. Maintain an inventory of consented applications with regular attestation cycles. Revoke the application’s consent grant and rotate any secrets associated with it immediately.

Most organizations do not maintain this inventory. Most do not audit consent grants. The extension is still authorized until someone explicitly removes it.