Skip to main content

Neotech Cloud Solutions

Home/Cybersecurity/Microsoft 365 session token theft: why a password reset isn’t enough
Personne tenant un téléphone devant un ordinateur portable, illustrant le vol de session Microsoft 365

Microsoft 365 session token theft: why a password reset isn’t enough

An employee lands on a fake Microsoft sign-in page. You find out, change their password and move on. According to research published on October 22 by the firm Huntress, that’s exactly what leaves the door open.

Between July 14 and September 22, 2026, a single session token theft campaign hit 79 organizations using Microsoft 365. The attackers didn’t need the password: they replayed stolen session tokens, issued after multi-factor authentication. Once inside, they added their own phone as an MFA method, registered fake devices and hid emails. Here’s how it unfolded, why a password change alone isn’t enough, and the order to follow to really take back control.

Session token theft in short: MFA worked, then it was bypassed

When you sign in to Microsoft 365 and your password and MFA are accepted, Microsoft hands your browser a token: a kind of wristband proving you’ve already been through the checkpoint. If someone steals that wristband, they walk in as you, without going through the checkpoint again. Huntress calls it “token spraying”: the same network addresses replayed tokens stolen from many victims, organization after organization.

The tokens came from several sources: pages that relay the real sign-in (adversary-in-the-middle, or AiTM), device-code phishing and social engineering. Every replayed sign-in went through six addresses in a single block, 193.26.115.0/24, at the hosting provider 1337 Services GmbH in Hamburg.

🏢

79 organizations

Hit between July 14 and September 22, 2026, over ten weeks.

🔓

At least 497 successful sign-ins

No password needed: attackers replayed sessions that had already passed multi-factor authentication (MFA).

💻

At least 48 fake devices

Registered in Entra ID under names like “DESKTOP-” followed by 8 characters.

📱

19 organizations

Where the victim’s MFA methods were wiped and replaced in under 3 hours.

The speed changed too. On July 21, 12 minutes passed between the victim reaching the MFA step and their session being hijacked. By September 22, it took only 4.

July 21, 2026: 50 minutes from a booby-trapped sign-in page to the attacker’s phone (Eastern Time)

1

1:18 p.m.

The victim reaches the MFA step

On a fake page that relays the real Microsoft sign-in (an “adversary-in-the-middle” technique). They approve the prompt, as usual.

2

1:30 p.m.

The session is hijacked

Twelve minutes later, an attacker address uses the session token. No password is asked for: as far as Microsoft 365 is concerned, MFA is done.

3

1:43 p.m.

A second address takes over

The same token is replayed from another address in the same network block.

4

2:08 p.m.

An “iPhone 13” is added as an authenticator

The attacker registers their own device as an MFA method. They can come back even after a password change.

What’s left behind after the intrusion

What makes this campaign dangerous for a small business is what comes next. In 19 organizations, the victim’s MFA methods were wiped and replaced with the attacker’s in under 3 hours. At least 48 fake devices were registered in Entra ID, giving a lasting foothold.

In mailboxes, rules with almost empty names (“.”, “sss”, “iT”, “s”, “d”) sent messages to folders nobody looks at, such as RSS Feeds or Conversation History. In one case described by Huntress, an email about payroll was sent to an outside accountant, and rules then hid everything mentioning payroll, direct deposit, banking or bonuses, plus every message from that accountant. It’s the same playbook as payment fraud: hijack the conversation, then hide the replies.

Why a password change isn’t enough

What each action removes Stolen session in use Fake Entra device Attacker’s MFA method Hidden mailbox rules
Password change only ◐ ✖ ✖ ✖
Revoke sessions ✔ ✖ ✖ ✖
Delete unknown devices ✖ ✔ ✖ ✖
Remove unknown MFA methods ✖ ✖ ✔ ✖
Delete suspicious mailbox rules ✖ ✖ ✖ ✔
Full containment (all five) ✔ ✔ ✔ ✔

✔ removed · ✖ stays in place · ◐ partial: according to Huntress, a password change without revocation leaves the already-issued access token valid for about 90 minutes, and doesn’t touch added devices or MFA methods.

The “let’s change the password” reflex fixes yesterday’s problem: someone knows the password. It doesn’t fix today’s: someone already has an open session, their own phone as a second factor and a device registered in your tenant. Microsoft’s token theft playbook points the same way: revoking sessions is part of containment.

Containing a hijacked Microsoft 365 account: the order that matters

1

Revoke all of the user’s sessions

Entra admin center: Users → the user → Revoke sessions. That’s what cuts off the access in progress.

2

Reset the password

Only then: the password may have been captured by the same fake page.

3

Check authentication methods

Users → the user → Authentication methods: remove any phone or app the person doesn’t recognize.

4

Check devices

Devices → All devices: look for recent devices named “DESKTOP-…” that don’t belong to anyone on your team, and delete them.

5

Read the mailbox rules

Outlook or the Exchange admin center: rules with very short names (“.”, “s”, “iT”) that move messages to RSS Feeds or Conversation History are a known sign of this campaign.

6

Warn the people involved

If emails were sent in the victim’s name (payroll, direct deposit, invoices), call the recipients using a number you already know.

🛡️ A block that tells you a lot: error AADSTS53003

On September 11, over four days, Huntress counted 303 successful sign-ins across 29 organizations. During the same period, 1,052 attempts were blocked, all of them in 4 organizations where Conditional Access did its job. In sign-in logs, those denials carry the code AADSTS53003. Huntress recommends treating them as a signal: if Conditional Access blocks it, the session or credential presented was valid.

Preventing session token theft this week

The paths below are those of the Microsoft Entra admin center.

1

Require MFA for all users, all apps and all client types

Entra admin center → Conditional Access → Policies

With no forgotten “temporary” exception. That baseline is what made the difference for the 4 protected organizations.

2

Block the “device code” flow if you don’t use it

Conditional Access → Conditions → Authentication flows → Device code flow

Tokens in this campaign also came from device-code phishing. Few small businesses actually need it.

3

Turn off user consent to applications

Entra admin center → Enterprise applications → Consent and permissions

And watch for new enterprise applications that nobody asked for.

4

Get an alert when a device or MFA method is added

Entra admin center → Audit logs

A new authenticator at 2 p.m. on a Tuesday, for someone who didn’t change phones, deserves a call.

We had already covered this campaign’s two entry points: device-code phishing and relay pages such as FlowerStorm and KrakVM. What Huntress’s research adds is what happens afterwards, and how fast.

At NeoTech, our Microsoft 365 services set up Conditional Access, block unneeded flows and clean up accounts after an incident, in the right order. With our cyber monitoring, automated 24/7 monitoring with on-call technician intervention flags new devices, new MFA methods and suspicious mailbox rules as soon as they appear.

Book your free cyber check

Not sure whether Conditional Access covers all your accounts, or whether an old incident left an unknown device in your Entra ID? The free cyber check reviews your access rules, MFA methods and registered devices, then we hand you a clear plan.

👉 Book your free cyber check

Call us at 438-476-2322 or email info@neotechcloudsolutions.com.

Sources

Photo: Christina Morillo, Pexels (Pexels licence).

Leave a Reply

Your email address will not be published. Required fields are marked *