Check Point researchers documented a phishing campaign that ran from the final weekend of June into July, hitting users at 120 organizations across manufacturing, legal and healthcare. What makes it worth your attention is what the attackers left out: there was no fake Microsoft login page anywhere in the chain. (Source: Infosecurity-Magazine)

The lure was an email dressed up as a Microsoft Planner task-assignment notification. The sender display name read "There's New Activity On Teams," the body claimed HR had sent messages through Teams, and it referenced "overdue tasks" to push the recipient toward clicking. In a detail that defeats the usual visual check, the message appeared to arrive from the recipient's own email address.

Clicking the link sent the user to a genuine Microsoft OAuth authorize URL. OAuth is the consent mechanism that lets third-party apps act on your Microsoft 365 account without ever handling your password, so the sign-in screen, the domain and the certificate were all authentic.

The user was then prompted to "Approve permissions" or "Accept on behalf of your organization." Approving handed an authorization token to an attacker-controlled application and redirected the session to attacker infrastructure.

"Attackers have stopped forging Microsoft's front door and started walking through it. Every screen the victim sees is authentic, the only fake thing in this entire chain is the intent behind the app requesting access," Check Point said.

With that token, the attacker could do anything the account holder could do across Outlook, SharePoint and OneDrive — read mail, pull files out of the mailbox, and use the trusted account as a starting point for Business Email Compromise, where fraudulent payment or invoice requests come from a real internal sender.

Teams and Planner notifications are routine traffic in most offices, and staff working remotely have little reason to question an HR task alert. That familiarity is the part the attackers are counting on, and no password was stolen at any point.

Why Legitimate Microsoft Pages Make This Attack Effective

The mechanical core of this campaign is that no credentials were ever typed into anything attacker-owned. The link in the lure email resolved to a legitimate Microsoft OAuth authorize URL — Microsoft's own authentication endpoint, serving Microsoft's own sign-in experience, over a valid certificate on a domain your users have been trained to trust.

That single design choice removes almost every indicator users are taught to look for. There is no typosquatted domain, no lookalike subdomain, no cloned HTML on compromised hosting, and no certificate warning, because none of those components exist in the chain.

What the victim actually sees after signing in is a consent prompt asking them to "Approve permissions" or "Accept on behalf of your organization." That second option matters: it is the tenant-wide consent path, which grants the requesting application access across the organization rather than for one mailbox.

Approving the request sent the sign-in flow to attacker-controlled infrastructure via the application's registered redirect, and issued the attacker an authorization token. From there the operator held the same access a legitimate user holds across the Microsoft 365 suite — Outlook, SharePoint and OneDrive.

The business consequence of token-based access rather than password theft is durability. A stolen password is invalidated by a reset; a granted OAuth token keeps working as long as the consent record and refresh token remain valid, and it does not re-prompt for MFA because the multi-factor check already succeeded during the genuine sign-in.

In ATT&CK terms the chain runs:

• T1566.002 (Phishing: Spearphishing Link) — delivery through a task-notification themed message with an embedded authorize URL.
• T1528 (Steal Application Access Token) — consent abuse rather than credential capture, which is why traditional credential-phishing controls do not fire.
• T1114 (Email Collection) — reading and exfiltrating inbox contents once access is established.
• T1534 (Internal Spearphishing) — using the trusted, authenticated account as a springboard for Business Email Compromise.

Check Point published no attacker domains or hashes for this campaign, and that absence is itself informative. The durable artifacts in a consent-phishing intrusion are not network IOCs but identity objects: the application's client ID, its display name as shown on the consent screen, the redirect URI pointing to non-Microsoft infrastructure, and the resulting service principal and permission grant recorded inside the tenant.

The observable cues sit in two places. In the email, multiple buttons and text links resolved to the same destination URL — an inconsistency with genuine Planner and Teams notifications, where different controls point to different task and thread targets.

The second cue is the consent screen itself. Routine Teams or Planner navigation does not ask an employee to approve permissions for an application, and it certainly does not ask a non-administrator to accept on behalf of the organization. A prompt requesting mail, file and site scopes for an app nobody in IT registered is the point where the chain becomes visible.

Check Point states this specific campaign is no longer active, but describes it as another example of attackers changing how they bypass traditional phishing defenses. The technique is not tied to the Teams or Planner theme — any pretext that plausibly ends in a Microsoft sign-in can carry the same consent request, which is why the delivery lure is the most disposable part of the operation.

Business and Compliance Exposure from Compromised Teams Accounts

An attacker holding a valid authorization token for a Microsoft 365 account has the same reach as the employee who owns it. In this campaign that meant Outlook, SharePoint and OneDrive — your mail, your document libraries, and your file storage, all reachable through normal API calls rather than a suspicious remote session.

That access is not tied to the user's password. Because the account was reached through an approved app consent rather than a stolen credential, a routine password change does not necessarily end the attacker's session, and the activity continues to appear as authorized use by a known identity.

Think about what actually sits in a single employee's mailbox and OneDrive at your organization. For the sectors Check Point saw targeted, the contents are commercially and legally sensitive:

• Manufacturing: supplier pricing, production schedules, engineering drawings, and quote documents shared in SharePoint libraries.
• Legal: client files, draft filings, and privileged correspondence, where exposure raises client notification and professional responsibility questions beyond the technical incident.
• Healthcare: patient information in attachments, referral threads, and billing correspondence, which brings HIPAA breach notification obligations into scope once you cannot rule out access.

The mailbox also hands over your organizational map. Approval chains, who signs off on payments, which vendors you use, how your finance team phrases a payment request, and which executives are traveling are all readable in ordinary email history.

Check Point flagged Business Email Compromise as the likely follow-on use, and that is where the direct financial loss usually sits.

Internal fraud works the same way. A request to a junior finance employee carries very different weight when it arrives from the actual controller's account, in the controller's writing style, referencing a real project.

Teams and Microsoft 365 also connect outward. Shared channels, SharePoint sites tied to project teams, and connected line-of-business apps mean that compromising one account can expose data owned by teams the victim was never central to, including partners and clients invited into shared workspaces.

The compliance side is harder than the containment side, and it is where costs accumulate. Because every step of the sign-in was legitimate, your logs will show valid authentication and authorized application access rather than intrusion indicators, which makes it difficult to prove a negative during an investigation. If you cannot demonstrate which items were read or downloaded, you are generally forced to treat the full contents of that mailbox and its accessible file stores as potentially exposed.

That assumption drives the rest of your obligations: regulatory notification timelines for personal data under GDPR where EU residents are affected, HIPAA reporting if protected health information sat in the account, contractual duties to notify clients whose confidential material was accessible, and disclosure to your cyber insurer. Each of those carries forensic and legal spend independent of whether any money was ever stolen.

One compromised account is therefore not a single-user problem. It is a data exposure event scoped to everything that user could read, plus every counterparty who trusts messages from that address.

Detect and Respond to Teams Phishing and Account Compromise

The highest-value action is not a password reset — it is removing the app's consent grant and revoking active sessions. Pull your Microsoft Entra ID audit log for consent and OAuth permission-grant events covering the final weekend of June through July, list every third-party application that received delegated permissions, and delete the service principal for anything you cannot tie to a business owner.

Then revoke sign-in sessions for the affected users so existing refresh tokens stop working. Check whether any approval came from an account with privileges to consent for the whole tenant, because a single tenant-wide grant covers every mailbox rather than one.

Within the first few hours, work through these:

• Search your mail gateway logs for the sender display name and the Planner-style notification pattern, then pull the recipient list so you know exactly who saw it and who clicked.
• Query sign-in logs for the affected accounts and flag non-interactive token refreshes, unfamiliar IP ranges, and access occurring outside the user's normal hours.
• Audit Teams and Microsoft 365 administrator role assignments for additions made during the campaign window.

Over the next several days, close the paths an attacker uses after the initial grant. Inspect each affected mailbox for new inbox rules, SMTP forwarding addresses, and delegate permissions — quiet forwarding is how mail theft continues after you think you have contained the account.

Review SharePoint and OneDrive sharing activity for anonymous or externally shared links created by those users, and disable external sharing on document libraries that never needed it. Turn off end-user consent for third-party applications and route requests through an admin consent workflow, which stops one click from producing tenant data access.

MFA remains necessary, but this technique does not require a password, so pair it with conditional access rules that require a compliant or managed device for token-based access to mail and files. In environments Capstone manages, Adlumin ITDR monitors authentication behavior and consent activity across managed environments, surfacing token use from unfamiliar locations that looks authorized in the logs but does not match the user's pattern.

Longer term, four controls do the most work:

• Move DMARC to an enforcing policy with aligned SPF and DKIM, so mail claiming to come from your own domain — as this campaign's messages did — fails authentication at the gateway instead of landing in an inbox.
• Enable click-time URL inspection so links are evaluated when opened rather than only at delivery, which catches redirect chains that change after the message arrives.
• Run a simulated campaign built around an unexpected consent prompt rather than a fake login page, record both click rate and approval rate, and retrain the top 10% of clickers individually.
• Schedule a monthly review of registered enterprise applications and their granted scopes, with a named owner for each.

Set your detection threshold on consent events, not just credential events. Any new application granted permission to read mail or write files should generate an alert to your security team the same day it happens.

Document which users approved the request, what was accessed, and what you revoked. That record is what your legal and compliance teams will need if client data sat in the scope of the grant.

Key Takeaway and Immediate Action

The takeaway worth carrying out of this campaign is that the trust decision moved. Your users were trained to ask whether a login page is real. This attack never asked them that question — it asked whether an application should be allowed access, and most people have no basis for answering it.

Check Point noted this specific campaign is no longer active, but the technique it demonstrates does not expire with the infrastructure behind it. Consent-based access abuse works against any tenant where an ordinary employee can approve an application on their own, and it works regardless of password strength, password age, or how recently your awareness training ran.

Teams matters here because of how ordinary it is. Task assignments, activity alerts and mentions arrive constantly during a normal work week, so a message referencing them lands inside a pattern your staff already accept without much scrutiny. Microsoft's own branding and authentication surfaces are what carry the attack — the attacker supplies only the request, not the appearance of legitimacy.

The single most important thing to settle is who in your tenant is permitted to grant application permissions, and whether that permission currently sits with every user by default. That is one configuration decision with an owner, not a program of work, and it determines whether a single click by one employee in accounts payable can hand a third-party app standing access to mail and files.

Everything else follows from that answer. If consent is currently open tenant-wide, your exposure to this class of attack is defined by the judgment of whichever employee receives the next convincing notification email.