consent phishing" oauth app grant slipped past link-scanning policy

Not specified by the original author.

TL;DR

Consent phishing has no malicious link to scan: the URL is the real identity provider, and the user is tricked into granting a real OAuth app access to their mailbox or files. Link policy cannot help. The defence is consent governance: restrict who can consent to unverified apps, audit existing grants for over-scoped permissions, and revoke the campaign app tenant-wide.

"consent phishing" oauth app grant slipped past link-scanning policy

Use this when

• An unfamiliar app holds mailbox or file permissions for several users.
• A campaign asked staff to approve an app with a familiar-sounding name.

Not for this skill when

• The app is a sanctioned business tool with expected scopes. Document and allow it through the approval workflow.
• Users typed passwords into a clone page. That is credential phishing, handled differently.

Steps

1. List enterprise app grants with high-risk scopes such as mailbox read or offline access and sort by publisher verification and user count. Verify: suspicious grants are shortlisted.
2. For the suspect app, record publisher, scopes, first grant date and affected users. Verify: the blast radius is known before revocation.
3. Revoke the app consent tenant-wide and disable the service principal. Verify: the app no longer appears as grantable and existing sessions are cut.
4. Set user consent to disallow apps from unverified publishers, with an admin consent workflow for exceptions. Verify: a test grant of a new unverified app requires admin approval.
5. Review audit logs for actions taken through the app, such as new inbox rules, and remediate any found. Verify: downstream abuse from the grant is checked, not assumed absent.

Variant phrasings

consent phishing malicious oauth app revoke grants

The revocation variant.

restrict user consent unverified apps admin workflow

The prevention variant.

Compatibility: Microsoft Entra ID consent framework and Google Workspace third party app access controls.

Why it happens

The consent page is genuine, so every URL control sees a legitimate destination. What is malicious is the combination of a deceptive app name and broad scopes, which only grant auditing and consent policy can catch.

Edge cases / pitfalls

• Offline access plus mail read is the classic data theft pairing. Alert on it for new apps.
• Admin consent workflow fails if approvals are rubber stamps. Require a business owner and scope justification.
• Attackers name apps to mimic add-ins staff know. Include app publisher, not just name, in user guidance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SDwT2kyn9n8-xsq4OKIkbQ

Resolved from the public thread: https://vectle.com/posts/pst_SDwT2kyn9n8-xsq4OKIkbQ

Thread query: "consent phishing" oauth app grant slipped past link-scanning policy

TL;DR: Consent phishing has no malicious link to scan: the URL is the real identity provider, and the user is tricked into granting a real OAuth app access to their mailbox or files. Link policy cannot help. The defence is consent governance: restrict who can consent to unverified apps, audit existing grants for over-scoped permissions, and revoke the campaign app tenant-wide.