# OAuth Consent Phishing Abuses Microsoft's Legitimate Login System to Harvest Microsoft 365 Tokens

> Check Point Research identified a phishing campaign (June 25 - mid-July 2026) that impersonated Microsoft Planner/Teams task notifications and routed roughly 200 emails at ~120 organizations through Microsoft's genuine login.microsoftonline.com OAuth authorization flow. Victims who approved the malicious application's permission request were redirected to an attacker-controlled AWS API Gateway endpoint that harvested authorization tokens, granting access to Microsoft 365 email, files, Teams chats, SharePoint, OneDrive, and calendar data without ever presenting a fake login page.

- **Published:** 2026-07-30T00:00:00Z
- **Last reviewed:** 2026-07-30T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1778
- **ID:** TL-2026-1778
- **Severity:** HIGH
- **Category:** PHISHING
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 22 (full data via the Threadlinqs MCP server — Purple tier)

## Description

Between 25 June and the second week of July 2026, Check Point Research tracked a phishing campaign that abused OAuth's delegated-authorization model rather than credential harvesting. Emails were sent from a spoofed sender using the recipient's own organizational domain, with the display name "There's New Activity On Teams" and a subject line pattern of "HR@[company].com Sent 3 Messages Via Teams Chat." The email body impersonated a Microsoft Planner task-assignment notification referencing a "Payroll, Compensation + Benefits Update" with a "4 Overdue Employee Tasks" urgency counter.

Clicking the embedded link took the victim to a completely legitimate login.microsoftonline.com OAuth 2.0 /authorize endpoint. The victim authenticated normally (including any MFA challenge) against real Microsoft infrastructure, then was shown a standard consent screen requesting permission for a third-party-registered application. Because every visible screen in the chain is authentic Microsoft UI, the flow evades detection controls built around fake login pages or spoofed domains — Check Point summarized the shift as "attackers have stopped forging Microsoft's front door and started walking through it."

Upon approval, Microsoft's OAuth flow redirected the victim's browser to the `redirect_uri` registered by the attacker's application: an AWS API Gateway endpoint under attacker control (not a Microsoft-owned domain). That endpoint received the authorization code/token, which the attackers exchanged for access and refresh tokens scoped to whatever permissions the victim approved — up to and including read/write mail access, file access (OneDrive/SharePoint), Teams chat access, and calendar data. No credentials were phished and no malware was delivered; the attacker's only asset is the malicious OAuth application registration and its AWS-hosted token-collection endpoint.

The campaign spanned roughly 120 organizations, concentrated in Industrial/Manufacturing (~19.3% of emails — 39 emails against 15 organizations), Legal/Professional Services (~13.9% — 28 emails against 21 organizations), Nonprofit/Associations (~10.9% — 22 emails against 16 organizations), Government/Public Sector (~8.9% — 18 emails against 9 organizations), and Healthcare (~6.9% — 14 emails against 11 organizations), overwhelmingly in North America (~98.3%), with minor Asia and Latin America exposure (~0.9% each). Check Point states the specific campaign is no longer active, but frames the underlying illicit-consent-grant technique as having evolved "from a targeted, manually built attack into a service that virtually anyone can rent" by 2026 — consistent with the broader 2026 proliferation of OAuth-consent-phishing-as-a-service platforms such as EvilTokens (340+ M365 orgs compromised within 5 weeks of its February 2026 launch) and Kali365 (FBI IC3 PSA260521, April 2026), and automated toolkits like ConsentFix v3 targeting Azure/Entra ID with MFA and Conditional Access bypass. Because the attacker holds a legitimately-issued OAuth token rather than a replayed credential, MFA provides no protection: the victim personally completes the MFA challenge and then clicks Accept on the attacker's behalf. Refresh tokens obtained this way commonly remain valid for weeks (up to ~90 days depending on tenant policy) and survive password resets, giving attackers standing, low-noise access that resembles normal user activity in audit logs. Check Point specifically flags the compromised mailbox access as "a common springboard for follow-on BEC fraud from a trusted internal address": because the token grants send-as capability from a real, previously-trusted account, attackers can pivot from silent token theft into internal spearphishing and invoice/wire-fraud schemes that are far harder for recipients or mail-flow rules to distinguish from legitimate internal correspondence. Check Point's own detection guidance for end users centers on three checks that generalize beyond this specific lure: verify a link's true destination before clicking, treat it as suspicious when multiple buttons/links in one email all resolve to the same URL, and confirm the sender's display name, address, and domain are mutually consistent — since display names remain trivially spoofable even when the underlying address looks internal.

## MITRE ATT&CK

- T1566.002 Spearphishing Link
- T1583.006 Web Services
- T1528 Steal Application Access Token
- T1550.001 Application Access Token
- T1684.001 Impersonation
- T1550.001 Application Access Token
- T1114.002 Remote Email Collection
- T1213.002 Sharepoint
- T1530 Data from Cloud Storage
- T1213 Data from Information Repositories
- T1041 Exfiltration Over C2 Channel
- T1589.002 Email Addresses
- T1583.007 Serverless
- T1204.001 Malicious Link
- T1098.001 Additional Cloud Credentials
- T1098.001 Additional Cloud Credentials
- T1534 Internal Spearphishing
- T1071.001 Web Protocols
- T1657 Financial Theft

## Sources

- [Attackers are using Microsoft's legitimate login system to camouflage phishing attacks](https://www.helpnetsecurity.com/2026/07/30/microsoft-authentication-system-phishing/)
- [Attackers Are Turning Microsoft's Trusted Login System Into Their Latest Phishing Weapon](https://blog.checkpoint.com/email-security/attackers-are-turning-microsofts-trusted-login-system-into-their-latest-phishing-weapon/)
- [Teams-Themed Phishing Campaign Abused Legitimate Microsoft Login Pages](https://www.infosecurity-magazine.com/news/teams-phishing-abused-legit/)
- [Attackers Weaponize Microsoft's Trusted Login System for Phishing](https://cxotoday.com/cybersecurity/attackers-weaponize-microsofts-trusted-login-system-for-phishing/)
- [The New Phishing Click: How OAuth Consent Bypasses MFA](https://thehackernews.com/2026/05/the-new-phishing-click-how-oauth.html)
- [The Illicit Consent Grant Part 1: Understanding Modern OAuth Consent Phishing](https://www.slashid.dev/blog/illicit-consent-grant-part-1/)
- [Use Alternate Authentication Material: Application Access Token, T1550.001](https://attack.mitre.org/techniques/T1550/001/)
- [Steal Application Access Token, T1528](https://attack.mitre.org/techniques/T1528/)
- [Phishing: Spearphishing Link, T1566.002](https://attack.mitre.org/techniques/T1566/002/)
- [Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens](https://www.ic3.gov/PSA/2026/PSA260521)
- [ConsentFix v3: Automated OAuth Abuse Targets Microsoft Azure and Entra ID, Bypassing MFA and Conditional Access](https://www.rescana.com/post/consentfix-v3-automated-oauth-abuse-targets-microsoft-azure-and-entra-id-bypassing-mfa-and-conditional-access)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1778