> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# OAuth Consent Grant Abuse

> Remove a malicious or over-privileged OAuth consent grant from a client tenant: identify the grant, revoke it, and tighten tenant consent policy.

<Info>
  **Category:** Security · [View source ↗](https://github.com/Thread-Magic/super-magic-skills/blob/main/skills/security/oauth-consent-grant-abuse/SKILL.md)
</Info>

**Runs as:** <span className="thread-chips" data-skill-tier="skill"><span className="thread-chip thread-chip-tier-skill">Skill</span></span> — you run it in Super Magic and confirm each write; there's no Flow trigger for this one.

**Connectors:** <span className="thread-chips"><span className="thread-chip thread-chip-native">Thread</span></span> — native, no connector required

**Role:** [Security & Compliance Owner](/start-here/roles/security-compliance-owner), [Technician](/start-here/roles/technician)

**Outcome:** Risk & Compliance, Faster Resolution & Response

**When to use:** An alert fires for a newly consented enterprise app, a risky OAuth grant, or an unfamiliar app with mail/file permissions; a user reports approving an app "to view a document" that then behaved oddly; or persistence hunting during a takeover/BEC recovery surfaces an attacker-added app consent.

**Run it:** on one ticket (a suspicious OAuth grant).

## Prompt

```
Consent phishing skips the password entirely: the user is tricked into granting a rogue app
OAuth permissions (read mail, send mail, read files), and the app now holds durable access
via a refresh token — no password to reset, MFA never challenged again. Find the grant,
revoke it, close the consent path. You drive and document; the client's admin executes tenant
changes. In order:

1. Identify the grant: which app, which account(s) consented, what permissions (delegated vs
   application/tenant-wide), and when. Application-level and admin-consented grants are the
   most dangerous and outrank single-user grants — they persist beyond any one account's
   cleanup.
2. Judge legitimacy before revoking: is this a known business app the client uses, or an
   unfamiliar or lookalike app requesting broad mail/file scopes? Broad "read/send
   mail" or "read all files" on an unknown app is malicious until proven otherwise. Check
   publisher verification and the consent timestamp against any sign-in anomaly. A wrongful
   revoke breaks a real integration — but broad scopes on an unverified publisher outvote
   convenience.
3. Revoke on the malicious verdict: direct the client's admin to remove the app's grant and
   service principal and revoke its issued tokens tenant-side, which kills the refresh token
   giving the app standing access. A password reset and session revocation do NOT touch an
   OAuth grant; the app keeps access until the grant itself is revoked.
4. Assess what the app could reach during its access window: mailbox contents, files,
   directory data. Preserve the grant definition and app audit logs before removal. If mail
   was accessible and fraud may have flowed, branch to business-email-compromise-recovery.
5. Close the vector tenant-wide: recommend the client restrict user consent — require admin
   approval for third-party apps, or limit consent to verified publishers and low-risk scopes
   — and enable an admin-consent request workflow. Flag it as the priority remediation, owned
   by the client's admin.
6. If the grant accompanied a takeover, check for co-planted persistence: inbox rules,
   forwarding, delegates.
7. Document the decision, not just the action: the app, its scopes, the legitimacy reasoning,
   what was revoked and when, the access-window assessment, and the consent-policy
   recommendation with its owner. Classify per soc-classification-tree.

Revoking grants and changing tenant consent policy are the client admin's actions — recommend
and drive them, never modify tenant app registrations or consent settings yourself. Write
defensively: "an unauthorized application grant was detected and removed", not "your tenant
was breached", and never assert data exfiltration without log evidence. Notes are plain text,
no markdown (apply the PSA Note Discipline base skill). When in doubt, escalate and restrict
consent.
```


## Related topics

- [Account Takeover Runbook](/skill-library/security/account-takeover-runbook.md)
- [How Thread handles your data](/start-here/roles/security-compliance-owner/data-and-compliance.md)
- [Thread MCP Server: Developer Guide](/super-magic/thread-mcp-server-developer-guide.md)