Fake Teams Invites Are Tricking Microsoft 365 Users Into Handing Over Their Accounts

A phishing crew is skipping the fake login page and walking victims straight through Microsoft's own device sign-in flow.

ThreatVectr Newsdesk· 4 min read
Full frame, photoreal news-editorial image of a laptop screen showing a generic corporate sign-in code entry page in a dimly lit office, with a smartphone besid
Share

Key points

  • A phishing campaign ran from the last week of June 2026 into early July, abusing Microsoft's device code sign-in flow to hijack Microsoft 365 accounts.
  • Researchers at ZeroBEC say the attackers used collaboration-themed emails, not fake Microsoft login pages, to lure victims.
  • Victims were sent to the real Microsoft device login page and asked to type in a code the attackers controlled.
  • Once the code was entered, the attackers received working session tokens for the victim's Microsoft 365 account.
  • Multi-factor authentication does not block this technique on its own, because the user is signing in on the genuine Microsoft site.

A new phishing campaign is quietly emptying out Microsoft 365 mailboxes without ever showing victims a fake login page.

Security firm ZeroBEC says the operation ran from the final week of June 2026 and into early July. The attackers dressed their emails up as ordinary work invitations: shared documents, meeting requests, team collaboration prompts. Nothing that screamed "scam".

The twist is what happens after the click.

How does the scam actually work?

The hackers abuse a real Microsoft feature called the device code flow. It is designed for signing in on gadgets that do not have a proper keyboard, like a smart TV or a printer. You type a short code into a Microsoft page on your phone or laptop, and the device you are setting up gets logged in.

In this campaign, the attackers start that sign-in process on their own machine. Microsoft hands them a short code. They then email that code to the victim, wrapped in a message that looks like a normal work invite.

The victim clicks through and lands on the genuine Microsoft device login page at microsoft.com. Everything looks right. The padlock is real. The domain is real. So they type in the code, sign in with their password, and approve any multi-factor prompt.

At that moment, Microsoft issues a valid session token, and it goes to the attacker's device, not the victim's.

"The campaign did not depend on a fake Microsoft password page," ZeroBEC noted in its writeup, first reported by The Hacker News. "It used a malicious collaboration-style lure to push users into the legitimate Microsoft device login experience."

Why is this harder to stop than normal phishing?

Most anti-phishing advice tells people to check the web address. Here, the address is correct. The site is Microsoft. The certificate is Microsoft's. Password managers will happily autofill, because the domain is legitimate.

Multi-factor authentication, the extra code or app prompt many workplaces now require, does not save the user either. They approve the login themselves, believing they are signing into a shared document.

Once the attackers hold a session token, they can read email, download files from OneDrive and SharePoint, and set up mail forwarding rules to quietly siphon future messages. Some tokens stay valid for weeks unless an administrator forcibly revokes them.

What should Microsoft 365 users and admins do?

For ordinary staff: if an email asks you to type a code into a Microsoft sign-in page, stop. Genuine collaboration invites from colleagues never require that. Ring the sender on a known number and check.

For IT teams, Microsoft has published guidance on restricting the device code flow through Conditional Access policies. In most office environments, no one has a legitimate need to use it. Blocking it outright removes the attack surface. You can read Microsoft's advisory on conditional access for the device code flow at https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows.

Admins who suspect exposure should review sign-in logs for device code authentications, revoke refresh tokens on affected accounts, and hunt for newly created inbox rules. The Australian Cyber Security Centre and the UK's National Cyber Security Centre both maintain current advice on Microsoft 365 account takeover response.

Regulatory jurisdiction depends on the victim. In the United States, business email compromise losses are reported to the FBI's IC3 and, where consumer data is involved, the FTC. In the UK, personal data exposure from a takeover triggers a 72-hour notification duty to the ICO.

© 2026 Threat Vectr