Illustration showing a phishing email disguised as an invoice and a fake OAuth permission screen that asks the user to read their mail.

Why OAuth Phishing Sounds Complicated but Is Really Just the Same Old Problem – Phishing

I came across a LinkedIn article about an OAuth phishing attack, and I want to explain why it’s far simpler than the security industry makes it sound. The article is full of technical language, reactive controls, and long descriptions of Microsoft audit logs, but once you strip away the jargon it becomes clear that the entire event was just phishing. Nothing more, nothing less. And the reason it worked is the same reason every phishing attack works. A link persuaded someone to click.

The article is a good example of how the security industry focuses on symptoms instead of causes. It’s the same mistake police would make if bank robberies kept happening and their solution was to hire more cleaners to sweep up broken glass after each break in.

Phishing succeeds because their security controls assumed a link was trusted when it should’ve been assumed untrusted unless verified as legitimate.
To show this clearly, I’ve lifted short excerpts from the article and added my analysis underneath each one.

1. The article says

“One of the fastest growing threats is OAuth phishing. The attacker sent a phishing email that looked like a notification from a trusted service. The link in the email took the user to the real Microsoft login page. When the user clicked Accept on the OAuth consent screen, the malicious app was granted broad permissions like Mail.ReadWrite, Mail.Send, and Files.ReadWrite.All.”

My analysis

This sounds advanced, but it isn’t. The attack happened because someone clicked a link that security was unable to detect. Everything else was a consequence of that single moment. The attacker didn’t break in. They didn’t bypass MFA. They simply persuaded someone to trust a link. OAuth isn’t the innovation. It’s just the tool used after the user has already clicked.

OAuth isn’t the breakthrough here. It’s simply a mechanism the attacker used after the user already clicked. The moment that mattered was the click.

2. The article says:

“The login page was real and made the flow look legitimate.”

My analysis

This has been normal since reverse proxy phishing took off. Attackers have been routing people through real login pages for years. The only thing the victim needs to do is approve a familiar looking screen. The visual identity makes the victim feel safe because it’s identical to what they see every day. They reached that point because they clicked an unverified link.

I first wrote about this type of phishing technique in 2019 when the PKI Consortium invited me to explain the behavioural and technical reasons why people fall for phishing attacks. Everything I wrote then still applies now.

3. The article says:

“We analysed Microsoft 365 and Entra ID audit logs. We saw that the malicious app had been authorised. We revoked the permissions, revoked active tokens, and required reauthentication on all devices.”

My analysis

Everything they describe is reactive. These are cleanup steps. They don’t prevent the next attack. They simply tidy up after the attacker has already been inside. This is the classic pattern. Respond after the failure instead of preventing the failure.

4. The article says:

“We disabled user level OAuth consent, added approval workflows, configured alerts for apps requesting high risk permissions, enabled more logs, forwarded them to SIEM, and strengthened conditional access policies.”

My analysis in plain English:

These steps can reduce impact but they don’t solve phishing. They still rely on detecting something after the user has already clicked. More alerts, more monitoring, more rules. None of this challenges the real problem which is that users are constantly exposed to links they have no way to evaluate.

They’re describing how to clean the floor rather than how to stop the leak.

5. The article concludes:

“OAuth phishing is a major concern for BEC, cloud account takeover, and SaaS security incidents. It’s essential for organisations to understand how OAuth phishing works and how to protect against it.”

My analysis

The article treats OAuth phishing as if it’s a separate type of crime. It isn’t. It’s still phishing. It still relies on impersonation. It still relies on trust. And it still begins with a link. The industry keeps inventing categories, but the technique hasn’t changed.

Phishing is phishing. Everything else is noise.

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay informed with MetaCert’s latest updates, expert analysis, and real examples exposing how digital deception works and how it can be stopped.

Illustration showing a phishing email disguised as an invoice and a fake OAuth permission screen that asks the user to read their mail.

Why OAuth Phishing Sounds Complicated but Is Really Just the Same Old Problem – Phishing

I came across a LinkedIn article about an OAuth phishing attack, and I want to explain why it’s far simpler than the security industry makes it sound. The article is full of technical language, reactive controls, and long descriptions of Microsoft audit logs, but once you strip away the jargon it becomes clear that the entire event was just phishing. Nothing more, nothing less. And the reason it worked is the same reason every phishing attack works. A link persuaded someone to click.

The article is a good example of how the security industry focuses on symptoms instead of causes. It’s the same mistake police would make if bank robberies kept happening and their solution was to hire more cleaners to sweep up broken glass after each break in.

Phishing succeeds because their security controls assumed a link was trusted when it should’ve been assumed untrusted unless verified as legitimate.
To show this clearly, I’ve lifted short excerpts from the article and added my analysis underneath each one.

1. The article says

“One of the fastest growing threats is OAuth phishing. The attacker sent a phishing email that looked like a notification from a trusted service. The link in the email took the user to the real Microsoft login page. When the user clicked Accept on the OAuth consent screen, the malicious app was granted broad permissions like Mail.ReadWrite, Mail.Send, and Files.ReadWrite.All.”

My analysis

This sounds advanced, but it isn’t. The attack happened because someone clicked a link that security was unable to detect. Everything else was a consequence of that single moment. The attacker didn’t break in. They didn’t bypass MFA. They simply persuaded someone to trust a link. OAuth isn’t the innovation. It’s just the tool used after the user has already clicked.

OAuth isn’t the breakthrough here. It’s simply a mechanism the attacker used after the user already clicked. The moment that mattered was the click.

2. The article says:

“The login page was real and made the flow look legitimate.”

My analysis

This has been normal since reverse proxy phishing took off. Attackers have been routing people through real login pages for years. The only thing the victim needs to do is approve a familiar looking screen. The visual identity makes the victim feel safe because it’s identical to what they see every day. They reached that point because they clicked an unverified link.

I first wrote about this type of phishing technique in 2019 when the PKI Consortium invited me to explain the behavioural and technical reasons why people fall for phishing attacks. Everything I wrote then still applies now.

3. The article says:

“We analysed Microsoft 365 and Entra ID audit logs. We saw that the malicious app had been authorised. We revoked the permissions, revoked active tokens, and required reauthentication on all devices.”

My analysis

Everything they describe is reactive. These are cleanup steps. They don’t prevent the next attack. They simply tidy up after the attacker has already been inside. This is the classic pattern. Respond after the failure instead of preventing the failure.

4. The article says:

“We disabled user level OAuth consent, added approval workflows, configured alerts for apps requesting high risk permissions, enabled more logs, forwarded them to SIEM, and strengthened conditional access policies.”

My analysis in plain English:

These steps can reduce impact but they don’t solve phishing. They still rely on detecting something after the user has already clicked. More alerts, more monitoring, more rules. None of this challenges the real problem which is that users are constantly exposed to links they have no way to evaluate.

They’re describing how to clean the floor rather than how to stop the leak.

5. The article concludes:

“OAuth phishing is a major concern for BEC, cloud account takeover, and SaaS security incidents. It’s essential for organisations to understand how OAuth phishing works and how to protect against it.”

My analysis

The article treats OAuth phishing as if it’s a separate type of crime. It isn’t. It’s still phishing. It still relies on impersonation. It still relies on trust. And it still begins with a link. The industry keeps inventing categories, but the technique hasn’t changed.

Phishing is phishing. Everything else is noise.

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay informed with MetaCert’s latest updates, expert analysis, and real examples exposing how digital deception works and how it can be stopped.

Recent blog posts