What are the signs that an OAuth phishing campaign has moved past the grant stage?

When OAuth phishing moves beyond the grant, what changes operationally?

The grant is only the entry point. Once a malicious app receives consent or an authorization code is exchanged, the campaign’s value comes from what it does with the token next: enumerate the mailbox, map relationships, and look for durable footholds. A simple consent event is noisy but limited; post-grant activity shows whether the attacker is turning access into intelligence and persistence.

In practice, the transition is visible in a short burst of Graph activity that is broader than a normal sign-in pattern. Reads of contacts, manager data, direct reports, sent items, and mailbox rules creation are the strongest indicators because they reveal both reconnaissance and attempts to keep access after the initial user interaction.

That distinction matters because many OAuth phishing kits are built to be fast and reusable. The attacker does not need to immediately exfiltrate everything; they first confirm the account’s value, then expand through the connected SaaS surface that the token allows.

Which post-grant actions are the clearest signs of abuse?

The most reliable signs are not the token issuance event itself, but the first few API calls that follow it. A benign application usually stays close to its declared purpose, while a malicious one quickly touches high-value data and account-control features. If you see contact harvesting, organisational graph traversal, or inbox-rule tampering soon after consent, treat the campaign as active abuse rather than a one-off phishing success.

This is also why OAuth security guidance emphasises the scope and audience of the token, not just how it was obtained. RFC 6749: The OAuth 2.0 Authorization Framework defines the grant model, but the security question is what the client can do once it has a valid token. When the observed calls move from consent to mailbox inspection and directory mapping, the attacker has crossed that boundary.

Look for these concrete behaviours together, not in isolation: rapid reads of contacts, manager, and direct report objects; enumeration of sent items to learn conversation threads and impersonation opportunities; creation or modification of inbox rules; and follow-on use of refresh tokens or repeated Graph access from the same app identity. Any one of these may be explainable, but the cluster is not.

Why does mailbox and Graph fan-out indicate persistence, not just curiosity?

Fan-out means the token is being used to widen access across adjacent data and control surfaces. That usually signals reconnaissance, because the attacker is trying to understand who the user talks to, what the mailbox contains, and what automation or rule changes will survive beyond a single session. The moment the kit starts making those calls, the incident is no longer about one phished consent screen.

Persistent abuse often depends on rules that survive password resets or user suspicion, such as inbox forwarding, mail rules, token reuse, or a newly authorised app that remains trusted. Microsoft-facing OAuth guidance and identity guidance both point to the need for token-bound and phishing-resistant controls, and the relevant standards increasingly focus on limiting replay and tightening token use. RFC 9700: Best Current Practice for OAuth 2.0 Security is especially relevant once token theft or replay becomes part of the post-grant pattern.

Mailbox rule creation is a particularly important threshold because it shifts the campaign from passive observation to active persistence. At that point, the attacker is not only reading content, they are shaping how future mail is delivered, hidden, or redirected.

Risk and Threat Considerations

Once an OAuth phishing campaign reaches post-grant Graph activity, the risk expands from account compromise to relationship mapping, inbox manipulation, and durable access. That widens both the blast radius and the dwell time, especially when the app can read organisational structure and automate mail handling.

Failure mechanism: The attacker leverages a valid token to query high-value mailbox and directory data, then uses inbox rules or repeated API access to maintain visibility and avoid detection.

Impact: The compromise can expose sensitive correspondence, reveal reporting lines and contacts for further targeting, and create a persistent foothold that survives the original phishing event.

Practitioner Guidance

What to verify: Correlate consent events with the first ten to thirty minutes of Graph activity. If the app reads contacts, manager fields, direct reports, or sent items, or if it creates inbox rules shortly after issuance, treat that as a confirmed abuse path rather than routine usage.

What to prioritise: Revoke the app grant and invalidate the token path first, then review mailbox rule changes and any downstream message exposure. Do not start with content triage if the app still has live access to the mailbox or directory surface.

Practitioner takeaway: The key judgement is timing plus breadth: a legitimate grant becomes a materially broader incident when the token is immediately used to map people, inspect mail history, or alter delivery behaviour.

Related resources from NHI Mgmt Group

• What are the signs that a phishing campaign is part of a larger multi-stage malware operation rather than a one-off lure?
• What actions should I take if my OAuth tokens are compromised?
• How do attackers operationalise stolen OAuth tokens at scale?
• How should organizations respond to OAuth token abuse incidents?