How it works
The lure impersonates a person or service the target already trusts and supplies a reason to act quickly. The objective may be a credential, an OAuth authorisation that requires no credential at all, or simply a payment redirected to a new account.
Three objectives, one delivery method
These are usually treated as separate problems and are better understood as three objectives sharing a delivery method. In each, a message arrives through a channel the recipient trusts and asks them to do something reasonable-looking.
Classic phishing wants a credential, and increasingly wants the session that follows it. Consent phishing wants an authorisation — and notably does not want the password at all. Business email compromise wants a payment, and often needs no technical compromise whatsoever.
Grouping them clarifies why credential-focused defences leave gaps. Hardening authentication does nothing against an attack that asks the user to authorise a legitimate token, and nothing at all against one that simply asks the finance team to update bank details.
Consent phishing: no password required
OAuth consent abuse deserves particular attention because it defeats the controls organisations most rely on, and it does so without breaking anything.
The victim receives a link to what appears to be a normal integration — a document viewer, a meeting assistant, a productivity add-in. The authorisation page is genuinely hosted by the identity provider, the URL is legitimate, and the certificate is valid. Every signal a user is taught to check reads as correct, because everything on that page is correct.
What the user approves is a set of scopes for an attacker-controlled application. The provider then issues real tokens. No password was disclosed, so a password reset does nothing. MFA was satisfied by the user themselves, so MFA does nothing. The grant persists until someone revokes it explicitly, which means access can survive every remediation step an incident response typically performs.
Defences are administrative rather than technical: require admin approval for sensitive scopes, allow only verified publishers, and audit existing grants — most organisations that look for the first time find applications nobody can account for.
Business email compromise
BEC is the highest-value variant per incident and frequently the least technical. The attacker either compromises a mailbox or convincingly impersonates one, studies genuine correspondence, then inserts a request that fits the existing conversation.
The distinguishing feature is context. This is not a generic lure — it references a real invoice, a real project, real people, and arrives at a plausible moment. Where a mailbox has genuinely been taken over, the request may appear as a reply within an existing thread, which removes nearly every signal a recipient might otherwise notice.
Mailbox rules are the recurring technical artefact and the most reliable detection opportunity. Attackers create rules that move or delete replies so the legitimate owner does not see responses to messages they never sent. Alerting on rule creation is cheap and catches compromise that is otherwise silent.
The control that actually stops the loss is procedural: any change to payment details requires verification through a channel and a contact established beforehand, not one supplied in the message requesting the change. This works precisely because it does not depend on anyone detecting the deception.
Why user training underperforms
Training helps and should not be abandoned, but expectations should be calibrated. The advice given to users has been substantially eroded by circumstance.
Checking the URL fails against consent phishing, where the URL is genuinely the provider's. Checking for poor spelling fails against text that is now generated fluently at scale. Distrusting unexpected messages fails when the message is a reply in a real thread. Hovering over links fails on mobile, where a large share of messages are read.
More fundamentally, a control that requires every person to be correct every time will fail on a long enough timeline. Treat training as reducing volume, and place the controls that must not fail somewhere other than human judgement — origin-bound authentication that cannot be relayed, and payment procedures that require verification regardless of how convincing a request appears.
Also known as
What defenders may observe
- Lookalike sender or destination domains
- Unexpected credential prompts or authorisation requests
- New third-party application grants with high-risk scopes
- Mailbox forwarding or filter rules the user did not create
- New payment instructions, urgency, and requests for secrecy
- API access that continues after a password change
Prevention and mitigation
- Deploy phishing-resistant, origin-bound authentication
- Enforce email authentication and inspect links at delivery time
- Require admin consent for high-risk OAuth scopes and verify publishers
- Review and revoke unused application grants on a schedule
- Require dual approval and out-of-band call-back for payment changes
- Alert on mailbox rule creation and audit them periodically
Initial response priorities
- Revoke sessions and reset the affected authentication factors.
- Review identity-provider and mailbox audit logs.
- Verify sensitive requests through a separate trusted channel.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.