Consent Phishing

What the attack actually exploits

Consent phishing works because modern SaaS platforms often treat a user’s approval as a valid delegation event. The attacker does not need the password if they can persuade the victim to grant an application scopes that permit mailbox, file, profile, or directory access. Once the grant exists, the access can look legitimate to basic sign-in checks.

The core danger is that the attacker is abusing the platform’s own authorization model, not breaking it directly. That shifts the problem from simple account compromise to delegated access abuse, where the malicious app may persist until the grant is revoked and any issued tokens are invalidated.

Why malicious OAuth grants are hard to spot

A consent-based attack often blends into normal application onboarding and third-party integration activity. Because the approval flow can present standard permission prompts, users may not realise they are authorising a hostile app rather than a helpful one. That makes the initial foothold especially effective in environments that rely heavily on cloud identity and app consent.

The most difficult part for defenders is that the attack may produce valid tokens and ordinary-looking API activity after the consent event. Reviewers therefore need to distinguish legitimate business app registration from suspicious scope requests, unusual publisher details, and grants that do not fit the user’s role or routine workflow.

For a broader view of phishing techniques, delivery patterns, and layered defences, see Phishing Guide.

How consent phishing leads to lasting access

Once the grant is approved, the attacker can use the app’s delegated permissions to read data, send messages, or pivot into other services according to the scopes that were approved. In some cases the malicious app can also survive password resets because the access path is tied to the grant and associated tokens, not only to the original login session.

This is why consent phishing is closely related to app governance and OAuth abuse. The attacker is effectively turning a victim’s trust in the identity platform into a durable access channel, which can make containment slower than in a typical phishing event.

Pages such as Entra ID Applications and Consent Guide and Consent Phishing and Illicit OAuth Grants Guide help explain how consent policies, admin workflows, and revocation fit into the control model.

Detection, revocation, and post-compromise review

Defenders should look for suspicious consent events, unfamiliar enterprise applications, abnormal permission sets, and token activity that does not match the user’s normal access pattern. If a malicious grant is found, the response should include revoking the app consent, invalidating active tokens, and checking whether the app or associated session already accessed mail, files, or other sensitive resources.

Post-incident review should focus on what the malicious app could reach, whether the user approved broader scopes than needed, and whether the environment allowed unverified or over-privileged apps to remain visible. Hunting for related grants across the tenant is often necessary because one successful consent event can reveal a wider policy gap.

For attack-path mapping and token-theft detection, MITRE ATT&CK T1528 Steal Application Access Token Guide is a useful reference, and Identity Threat Hunting Guide shows how to investigate identity abuse patterns across logs.

Risk and Threat Considerations

Consent phishing is dangerous because it turns a user’s legitimate authority into an attacker-controlled access path. The resulting grant can outlast a password reset, and the activity may look like ordinary application use until someone reviews consent records and token behaviour.

Failure mechanism: A user approves a malicious OAuth app, which receives delegated permissions that allow the attacker to act through valid tokens and app APIs rather than through stolen credentials.

Impact: The attacker can read or manipulate data, maintain persistence until the grant is revoked, and often evade simple sign-in-based detection because the access appears authorised.

Practitioner Guidance

What to watch for: Treat unexpected consent prompts, high-scope permission requests, and apps with weak or unfamiliar publisher signals as governance events, not just user behaviour issues. Consent phishing usually succeeds when users are left to judge technical permissions without enough policy guardrails.

Governance implication: Organisations should make app consent a controlled pathway with clear approval boundaries, because the key decision is not whether a user can click approve, but whether that approval should ever be enough to grant downstream access.

Practitioner takeaway: The fastest way to reduce this risk is to combine consent restriction, token revocation readiness, and routine review of granted apps against business need.

Related resources from NHI Mgmt Group

• Why do MFA and password resets fail to stop consent phishing?
• What is the difference between credential phishing and consent phishing?
• When does consent phishing become a governance failure rather than a user mistake?
• Why does MFA not stop consent phishing?