Skip to content
REDMAW

SaaS & Identity

OAuth Consent Phishing

An attacker persuades a user to grant a malicious or over-privileged application delegated access, creating persistence that may survive a password change.

RedMaw

Definition

Consent phishing asks the user to approve an application rather than to reveal a credential. The authorization flow is legitimate; the application requesting it is not, or asks for far more than its function requires.

Why the usual response does not work

The standard reaction to account compromise is a password reset and forced re-authentication. A delegated grant is not a password. It can continue to function after the reset, because it was issued deliberately by the user and remains valid until it is specifically revoked.

That is what makes this a persistence technique rather than a one-time theft. The identity graph around the user outlives the credential.

What to examine

  • Applications holding grants across the tenant
  • Scopes broader than the application's stated function
  • Grants issued by privileged or administrative users
  • Publisher verification and application provenance
  • Grants that persisted through a known credential event
Where it leads
  1. User
  2. OAuth Consent
  3. Malicious Application
  4. SaaS Access
  5. Sensitive Data

Each hop validated by successful exploitation

Tags

  • oauth
  • persistence
  • identity

Validation

How RedMaw validates this attack

Validation runs only inside authorized scope, with agreed exploitation limits.

  1. 01Inventory delegated grants across the authorized tenant
  2. 02Compare granted scope against the application's function
  3. 03Establish what data each grant makes reachable
  4. 04Determine whether grants survive a credential-reset event

Stop assuming you are secure. Prove it.

Continuously test what an attacker can actually reach across your applications, SaaS identities, internal infrastructure and AI systems.