Skip to main content
Phishing 7 min read

Hackers Are Taking Over Microsoft 365 Accounts Without Stealing a Password

Brad Slavin
Brad Slavin General Manager

Quick Answer

A 2026 phishing wave takes over Microsoft 365 accounts without stealing a password by abusing Microsoft's device code sign-in flow: the attacker generates a device code, the phishing page convinces an employee to enter it at the real microsoft.com/devicelogin, and the victim's genuine login authorizes the attacker's session. Because the user completes a real Microsoft login and satisfies MFA, multi-factor authentication does not block it, and the attacker receives long-lived tokens that survive a later password change. The delivery pages use 'ghost phishing' (AES-GCM-encrypted HTML that only decrypts in the browser) to pass URL scanners. No single control stops this. The defense is layered: enforce SPF, DKIM, and DMARC so spoofed and compromised-sender mail is caught; run phishing protection that follows and renders links before and at click time; block Microsoft device code flow with a Conditional Access policy; and require phishing-resistant MFA for administrators.

Phishing attack that takes over Microsoft 365 without a password

Most phishing advice still assumes the goal is your password. A fast-growing 2026 attack shows why that assumption is out of date.

Picture the cleanest possible version of an account takeover. No cracked password. No brute force. No credential dumped from some other breach. The attacker never learns your password at all, and the victim does everything correctly, including passing the multi-factor prompt. At the end of it, the attacker is inside the Microsoft 365 account with a valid session that survives a password reset.

That is the shape of the phishing wave researchers are now tracking through kits like EvilTokens, and it deserves attention because it defeats two things most organizations lean on hardest: MFA and URL scanning.

Phishing attack that takes over Microsoft 365 without a password

The device code trick, in plain terms

Microsoft supports a sign-in method called the device code flow. It exists for good reasons. Some devices, like smart TVs and conference-room systems, are painful to type a password into, so Microsoft lets them display a short code and asks you to finish signing in on your phone or laptop by visiting microsoft.com/devicelogin and entering that code.

Attackers turn this into a weapon by inserting themselves in the middle:

  1. The attacker asks Microsoft for a fresh device code, as if they were setting up a new device.
  2. A phishing email drives an employee to a page urging them to “verify” or “activate” access by entering that code at the real microsoft.com/devicelogin.
  3. The employee does exactly that, on Microsoft’s genuine site, and completes a real login, MFA prompt included.
  4. Microsoft, seeing a valid login, hands over the tokens. Except the session those tokens authorize belongs to the attacker’s device, not the employee’s.

Read step four again. The password never travels to the attacker. There is no spoofed login page harvesting keystrokes. The victim authenticated on Microsoft’s own domain. This is why the usual advice to “check the URL before you sign in” does not help here: the URL is legitimately Microsoft’s.

Why MFA does not save you this time

MFA stops an attacker who has your password but not your second factor. This attack sidesteps that entirely, because the real user provides the second factor as part of a login they believe is routine. MFA sees a legitimate, fully satisfied challenge and lets it through.

Worse, the payoff is not a one-time entry. The tokens issued at the end include long-lived refresh tokens. An attacker holding those can keep pulling fresh access even after the employee later changes their password, which is exactly the reaction most teams have when they suspect something is wrong. Unless you explicitly revoke the tokens and the sessions, “we reset the password” leaves the back door open.

Once inside, the tradecraft is well documented. Attackers quietly create mailbox rules that auto-forward or hide messages containing words like “invoice” or “payment,” so they can watch and hijack finance conversations without the real user noticing. They read confidential email, reach into SharePoint and Teams, harvest internal contacts for the next round of targeting, and set up business email compromise from a trusted internal account. The more advanced kits use AI to scan the mailbox, find live wire-transfer threads, and draft convincing replies in the victim’s own writing style.

The delivery is engineered to pass your scanner, too

The link that starts all this is built to survive inspection. Many of these kits use a technique ANY.RUN calls ghost phishing: the phishing page ships as encrypted data (AES-GCM ciphertext) with a small script that only decrypts it inside the browser. When your email gateway or a URL scanner fetches the link, it sees opaque encrypted content and a generic decryption routine, with no login form and nothing obviously malicious to flag. The real page only assembles itself after a live browser runs the script. The tool that scanned the link and the employee who later clicks it are, quite literally, not looking at the same page.

This is not a fringe experiment. Device code phishing has become an off-the-shelf service sold on Telegram, with EvilTokens joined by kits named Kali365, Ghost Hub, Cyb3r, and the well-known Tycoon2FA, and activity climbing sharply into a mid-2026 peak. ANY.RUN, drawing on submissions from around 15,000 organizations, puts 2026 phishing exposure above 70% in consulting, financial services, and manufacturing, and around two-thirds in banking and technology. The lures are ordinary on purpose: fake voicemail alerts, DocuSign and Adobe document shares, IT and payroll notices, often sent from an already-compromised account so they pass sender checks.

No single control stops this, and that is the real lesson

We have written before about how most phishing advice puts the entire defense on people. This attack makes the same point about tools: no one control stops it, because it was designed to slip through the seams between them. The answer is layers that each cover a different seam.

Layer 1: Authenticate your mail with SPF, DKIM, and DMARC. These do not inspect the linked page, so they will not catch ghost phishing on their own. What they do is cut off the easiest delivery path, spoofed and impersonated senders, and give you visibility into who is sending as your domain. Enforcing DMARC (moving past p=none to quarantine or reject) is table stakes, and if you are not there yet, DuoCircle’s SPF management and DMARC setup get the foundation right without the usual guesswork.

Layer 2: Filter links with live scanning, before and at click time. DuoCircle’s phishing protection reroutes inbound mail through a filtering layer that scans content and follows links to their real destination before delivery, and re-checks them at the moment of click rather than trusting a single scan on arrival. The distinction that matters here is real-time versus cached: a scanner that stores a verdict at delivery and serves that stored answer later is exactly the wrong tool for a page that was clean on arrival and armed an hour afterward. Our link protection leans on real-time URL scanners such as Vade, Google Safe Browsing, and Webroot BrightCloud Intelligence (BCI), which return a current verdict at the moment of the click instead of a historical one. Timing is the key, because these pages are often armed after delivery specifically to beat the first scan.

Layer 3: Turn off the flow the attack depends on. Most organizations never legitimately use device code sign-in. In Microsoft Entra ID, a Conditional Access policy using the “Authentication flows” condition can block device code flow across the tenant, with narrow exclusions for the rare device that truly needs it. Microsoft even ships a template for this; run it in report-only mode first to confirm nothing breaks, then enforce. This one setting removes the attacker’s entire mechanism.

Layer 4: Make a stolen session worthless. Require phishing-resistant MFA (FIDO2 security keys or passkeys) for administrators and other high-value accounts, so the most damaging targets cannot be handed over through a code at all. And build token revocation into your incident response, not just password resets, so a compromised session actually ends when you close it.

What to do this week

You do not need to boil the ocean. In priority order:

  • Block device code flow in Conditional Access. It is the highest-leverage single change and it directly kills this technique. Check your sign-in logs first for any legitimate device code usage, then roll the policy out in report-only mode.
  • Confirm DMARC is actually enforcing. A policy of p=none reports problems but blocks nothing. Move to quarantine or reject once your legitimate senders are aligned.
  • Add link protection that renders and re-checks at click time, so an armed-after-delivery page does not get a free pass on arrival.
  • Switch to token revocation in your takeover playbook, and check for suspicious mailbox forwarding rules whenever an account is even suspected of compromise.

The uncomfortable truth in this campaign is that an email can pass every gateway check, a login can pass MFA, and an account can still be taken over, all without a password ever changing hands. The defense is not one clever product. It is a small number of layers that each close a door the attacker was counting on staying open.

If you want the email side of that handled without stitching it together yourself, DuoCircle’s phishing protection sits in front of Microsoft 365 and Google Workspace, and you can try it free for 30 days.

Topics

Phishing ProtectionEmail Security
Brad Slavin
Brad Slavin

General Manager

General Manager at DuoCircle. Product strategy and commercial lead across the email security portfolio.

Secure your email infrastructure

Protect, authenticate, and deliver. Contact our team to find the right solution.