A reported mail asks staff to approve a third-party app for mailbox access - how do you triage it?

## Why the usual triage moves come up empty Most reported phishing gives you something to judge: an attachment, or a link to a credential-harvest page on a domain that is not yours. A consent-grant lure gives you neither. It asks the recipient to approve an application - typically dressed as an internal tool, a document viewer or a mailbox add-in - and the link genuinely does go to your own identity provider. It is the real sign-in and consent flow, on the real domain, with a valid certificate. Reputation lookups say clean, blocking the domain is unthinkable, and there is nothing to send to a sandbox. An analyst whose triage is a checklist of *attachment, link, domain* will close this as benign. ## What to extract instead The malicious object is the **application registration**, and it identifies itself in the URL: - **client_id** - the application's identifier in the directory. This is your pivot key; everything else follows from it. - **scope** - what the app is asking for. Mailbox read or read-write plus `offline_access` (which is what buys a refresh token, and therefore access without the user present) is the shape that matters. Contacts, files and directory read are common companions. - **redirect_uri** - where the authorisation response is sent. Infrastructure unrelated to the app's claimed vendor is strong evidence. - **publisher and app age** - an unverified publisher, and an application registered days ago, next to a display name imitating something internal. Note that the display name is attacker-chosen, exactly like a `From` display name in mail. *HR Document Sync* is not a fact about the application. ## The lookup that decides the case One reported mail is not the question. The question is whether the tenant already contains a grant for that client id: how many users consented, when, and whether the application has since obtained tokens. That is a directory and audit-log query, not a mail query, and it converts the case from *someone sent us a suspicious mail* to *we have an active third-party application reading mailboxes*. Two related facts change the blast radius. First, whether your tenant lets ordinary users consent at all, or requires an administrator: if users can consent, every recipient is one click from a grant. Second, whether an administrator was targeted, since some scopes granted by an admin apply tenant-wide rather than to one mailbox. ## The direction of every claim here - A consent event proves an **authorisation was granted**, not that mail has been read. Whether it was read is a separate question answered by the application's own token and access activity. - **MFA tells you nothing.** Nothing was bypassed. The user completed a legitimate, MFA-satisfied authentication to their own identity provider and then authorised an application. MFA defends against somebody else using the credential; it does not defend against the rightful user granting access. - **The grant is not the password.** Resetting the password, and the user signing in again, leaves the application's access in place. That fact is why this escalates rather than closes - the actual removal of the grant and its tokens is the responder's step, not the triage step, but knowing that it is a distinct step is what makes you escalate instead of ticking *password reset done*. ## Talking to the person who reported it The reporter is your fastest source and the one most likely to be defensive. Ask plainly what they clicked and what they saw, tell them they did the right thing by reporting, and do not make it a disciplinary conversation - a user who fears the answer gives you a vaguer one, and a vague answer costs you an hour. Then verify: memories of a consent screen are unreliable in both directions, and the directory record is authoritative. Someone who clicked but abandoned the flow leaves an authentication with no grant behind it. ## Deciding it is benign Consent requests are not malicious by nature; staff legitimately adopt third-party tools that need exactly these scopes, and a triage process that treats every one as an attack will be ignored within a month. The discriminating evidence is the combination: an unverified publisher, a recently registered application, a reply URL on unrelated infrastructure, a pretext in the mail that does not match how software is normally introduced here, and - the strongest signal of all - the same mail arriving to a broad recipient list rather than to the team that would actually use such a tool.