Hackers hijack Microsoft 365 accounts without stealing passwords — how to stay safe

Full text

Phishing campaign used fake Teams notifications to route victims to a genuine Microsoft sign-in page

Rather than stealing passwords, attackers asked victims to approve permissions for an attacker-controlled app, gaining access to mail, files, Teams, SharePoint, OneDrive and calendars without defeating MFA

Check Point says the technique has been commoditized in 2026 into a rentable service; the practical defense is restricting app consent rather than relying on users to spot a fake

A phishing campaign that ran from late June into July 2026 did something that breaks most of the advice organizations have spent a decade teaching their staff: it sent victims to a real Microsoft login page.

Check Point's email research team, which disclosed the campaign , identified more than 200 phishing emails targeting users across roughly 120 organizations worldwide.

The lure was a fake Microsoft Teams notification with a genuine destination; what actually compromised accounts was not a stolen password but a permissions prompt that the victim clicked through voluntarily.

A sophisticated attack that relied on tricking users into granting permissions

Check Point noted in its brief that what actually compromised the accounts was not a stolen password but a permissions prompt that the victim clicked through voluntarily. This is a reminder of a stark change in attackers' tactics: they have stopped forging Microsoft's front door and started walking through it.

The email appeared to be a Microsoft Planner task-assignment notification. The sender name read "There's New Activity On Team," the subject line claimed that HR had sent three messages via Teams chat, and the body referenced a payroll and benefits update, along with a counter showing four overdue employee tasks.

To someone who works in security, the message had its own telltale signs of being a typical phishing attempt: every link in the email, including both call-to-action buttons, routed through the same redirect. And the visible sender address belonged to the recipient's own organization, meaning the email appeared to have been sent to the same person it came from.

The link opened a real OAuth authorization URL on login.microsoftonline.com, not a look-alike domain. Signing in displayed a permissions prompt asking the user to approve the permissions or accept them on behalf of their organization.

If they did, Microsoft redirected the browser to the redirect address specified in the original request, which in this particular campaign was an AWS API Gateway endpoint under the attackers' control. The authorization code was delivered there, and the attackers exchanged it for access. No password was stolen at any point, and there was no fake page to spot.

This is not unlike how the phishing-as-a-service Kali365 platform compromises Microsoft accounts, but instead of stealing session cookies or OAuth tokens, it opts for a more permanent illicit grant of consent.

This runs counter to the usual security training checklist, which emphasizes adhering to norms rather than going against the grain; users are told to check the URL, look for the padlock, and watch for misspelled domains. None of those measures matter because there is nothing forged to catch. The domain and certificate are Microsoft's, while the sign-in page is the one the user sees every morning, offering a false sense of security to a user not looking for this particular attack vector.

Multi-factor authentication does not help either; it protects the login sequence but not access to the user's data post-login. The attacker never needs the password or the second factor because they walk away with a token granted by the user's valid session, a technique called 'consent phishing'.

There are many ways to prevent this, but the simplest two are asking users to check every single permission/consent screen they click (the phishing attempt still requires users to allow it) and limiting access to permissions for user accounts that applications can request via Microsoft Entra at the system administrator level.

It would be prudent to do the latter at a minimum, even as Check Point notes that the campaign is no longer active because the underlying technique it used is not going anywhere.