They Didn't Steal the Password. They Didn't Bypass MFA. The Employee Clicked "Allow."
FBI Advisory Identity & Access
The employee logged in to the real account. The password was correct. Multi-factor authentication worked exactly as designed. No malware touched the machine. And the attacker still walked away with access to the inbox. The mistake came one screen later.
You check the visitor's ID at the front desk. It's real. You verify it twice. It's still real.
Then you hand them a key to a specific filing cabinet, because they asked politely and the request looked routine.
The ID check was never the problem. The key was.
That's the shape of a technique the FBI issued a public warning about in September 2026: OAuth consent phishing. It doesn't need a stolen password. It doesn't need to defeat multi-factor authentication. It asks the user to do something that looks, and often is, completely ordinary: approve an app's request for permission.
Every step up to the mistake is legitimate
This is what makes the technique hard to catch with the tools most small businesses already rely on. There's no fake login page to spot, no misspelled domain, no suspicious sign-in alert to flag. The user is interacting with the real identity provider the entire time.
The FBI's September 3, 2026 public service announcement described attackers impersonating officials, media contacts, or known individuals over ordinary messaging apps specifically to get a target to approve one of these requests. No exotic infrastructure. No zero-day. Just a believable ask and a familiar-looking screen.
The same trust gap shows up in two other places
OAuth consent is one way attackers are learning to work around a login, rather than through it. Security researchers have flagged at least two more, worth knowing about even though this post centers on the consent-click pattern:
None of these three require breaking the login. A well-documented 2025 incident showed the scale this can reach: a single compromised third-party integration let unauthorized access spread across several hundred connected organizational accounts, entirely through legitimate, previously-granted tokens, no fresh phishing required against any of them.
The SMB translation: what to actually check this week
Most small businesses have never looked at the list of third-party apps with standing permission to their email or files. There usually isn't a monthly review process for it, because until recently there wasn't an obvious reason to think of it as a risk surface at all.
Review which third-party apps currently have permission to your business email or files.
Most cloud platforms have an admin page listing every app with granted access. If nobody on your team has looked at it, that's the starting point.
Revoke anything nobody can explain.
An unrecognized app with mail or file access isn't automatically malicious, but if nobody remembers approving it or can say why it needs that access, revoke it and ask questions after.
Train the specific click, not just "phishing" in general.
Most phishing training focuses on fake login pages. Add the permission-approval screen as its own category, since it looks nothing like the threat employees have been taught to recognize.
Confirm your help desk or IT provider verifies identity before resetting an MFA factor.
If a phone call or a chat message alone is enough to get a second factor reset, that process is a second path around MFA, independent of the one this post focuses on.
The short version
Attackers are moving one step sideways, past the login instead of through it. The password held. MFA held. The business was compromised anyway, in the moment an authenticated, legitimate user decided what to allow next. That decision point, not the login screen, is where SMB defenses increasingly need to extend.
Know which third-party apps actually have access to your business data right now.
View the Threat Intelligence feed → Find Out More About ThreatAngel →📚 Credential Security Series → Read the full series
Comments
Post a Comment