Skip to content
★ Veteran-Owned. Built by engineers who've actually done the work.
← All briefs
high

A conditional-access bypass that survives password reset

A persistent OAuth grant pattern observed across three customer tenants this week. Resetting credentials does not revoke the implant — here is the cleanup runbook.

AI-assisted Drafted by Carbynix's structured-reasoning pipeline. Sources linked below. Errors? Tell us — we correct in 24 hours.

What happened

Three customer tenants this week showed a persistence pattern that survives the standard “rotate credentials, force re-auth” playbook. The attacker — assessed as Storm-1247 — registers a third-party OAuth application against a compromised tenant during initial access, grants it offline access to mail, files, and identity scopes, then drops the original session entirely. The OAuth grant remains valid even after the user’s password is reset, because OAuth tokens are bound to the application registration, not the password.

Who is affected

Any organization using Microsoft Entra ID (formerly Azure AD) or Google Workspace where users have rights to consent to third-party OAuth applications. This is the default tenant configuration in both products.

How to detect

  1. Entra ID: pull AuditLogs | where OperationName == "Consent to application" for the trailing 90 days. Anything you don’t recognize, anything that grants offline_access plus Mail.ReadWrite plus Files.Read.All together, is suspicious.
  2. Google Workspace: Admin console → Security → API controls → App access control. Review every “Trusted” or “Limited” third-party app added in the last 90 days.

Cleanup runbook

A password reset alone is not sufficient. The full sequence:

  1. Identify the rogue OAuth app (queries above).
  2. Revoke the app’s grants for the affected user (Entra ID: Enterprise applications → app → Users and groups → remove user; Google: Security → API controls → app → revoke).
  3. Disable the app at the tenant level if no legitimate user needs it.
  4. Reset the user’s password and force re-MFA.
  5. Pull mailbox audit log for the affected user covering the period from initial OAuth consent to revocation. Anything sent during that window is suspect.
  6. Tighten consent policy: require admin approval for new third-party apps requesting Mail.*, Files.*, or User.Read.All permissions.

What to do this week

  • Run the detection queries above.
  • If you find anything unexpected, treat it as confirmed compromise and run the full cleanup runbook.
  • Lock down OAuth consent policy at the tenant level so the same vector closes for the future.

The math, plainly

An OAuth-persistence incident discovered late typically costs $250K–$450K for a mid-market firm because exfiltration runs continuously over months. Disabling user-level OAuth consent costs zero dollars and roughly 30 minutes of admin time.

Drafted by Carbynix’s structured-reasoning pipeline from observed customer-environment telemetry and the linked threat-intelligence profile. Errors? Tell us — we correct in 24 hours.