How Microsoft 365 Accounts Get Compromised And why the MFA you already have didn't stop it
Almost every Microsoft 365 breach we are called into starts in one of two ways. Neither one involves guessing a password, and neither is stopped by the MFA prompt most businesses rely on. Here is what actually happens, in plain English, and where the chain can be broken.
The short version
- Attackers are not after your password. They are after the session token your browser receives after you sign in.
- A token can be captured on a fake sign-in page that relays to the real Microsoft, or copied off a device that has been compromised.
- Once they hold a token, they are signed in as the user. No password, no MFA prompt, and nothing that looks unusual to Microsoft.
- Resetting the password does not sign them out. Sessions have to be revoked, and the device has to be trustworthy in the first place.
It starts with a token, not a password
When someone signs in to Microsoft 365, Microsoft hands their browser a session token. It is the reason you are not asked for a password every time you open Outlook. Think of it as a wristband at a festival: once you are wearing it, you walk back in without showing ID again.
That is convenient, and it is also the whole problem. A wristband does not care who is wearing it. Anyone holding a copy of your token is treated as you — from any machine, in any country, without triggering a single prompt. Every attack below is just a different way of getting hold of that token.
The sign-in page that wasn't Microsoft
An email arrives about a voicemail, a shared document, or an invoice that needs approving. The link opens what looks exactly like the Microsoft sign-in page — right logo, right company branding, sometimes the user's own profile photo, because the page is pulling those details from Microsoft live.
It is not a static copy. It sits in the middle and forwards everything to the real Microsoft as the user types. Microsoft genuinely receives the sign-in, so it genuinely sends the MFA prompt. The user approves a legitimate request, sees a normal-looking page afterwards, and gets on with their day.
On the way back, Microsoft's response passes through the attacker's site, which keeps a copy of the session token before handing the user through. Minutes later that token is loaded into the attacker's browser and the mailbox is open. Nothing prompts for MFA, because from Microsoft's point of view MFA already happened.
What they do next is the expensive part
Inbox rules are created to hide replies. A real invoice thread is found, the document is edited with new bank details, and it is re-sent from the genuine account. Chats, files and saved passwords are read. The same phishing link then goes out to colleagues and customers from a domain everyone already trusts. This is why the finance team is often the first to notice, not IT.
The device was already compromised
The second path needs no fake website at all. If anything malicious runs on the laptop, it can take the tokens that are already sitting there. Browser cookies and cached Microsoft 365 tokens live in the user's Windows profile, and code running as that user is allowed to read them — that is not a bug, it is how the profile works.
The important question for a business is not "was there malware", it is how did code end up running on that device in the first place. In practice it is one of four things, and none of them look like hacking.
A script or installer the user ran themselves
This is the most common one, and the least dramatic. Someone wants a PDF tool, a driver, a cracked copy of software the business would not pay for, or a "clean up my slow PC" utility. Maybe a forum answer or an AI chat told them to paste a PowerShell command into a terminal to fix a printer.
No firewall was breached and no password was guessed. The user was handed a file and chose to run it, which is exactly what the operating system is designed to allow.
Firmware and drivers nobody has looked at since purchase
Laptops ship with a BIOS/UEFI version, and most never get updated again. Secure Boot gets switched off during some troubleshooting session years ago and stays off. Vendor driver packages sit at whatever version came in the box.
Attackers exploit this directly. "Bring your own vulnerable driver" is a routine technique: the attacker ships a legitimately signed but flawed driver, Windows loads it because the signature is valid, and that driver is then used to switch off security tooling from underneath. Old firmware also means missing mitigations for hardware-level attacks and, in the worst case, malware that survives a full reinstall.
An unpatched OS, browser or third-party app
A browser, PDF reader or VPN client several versions behind is an open door that needs no user decision at all. For some vulnerabilities, visiting a page or previewing a document is the entire attack.
Patching Windows is usually handled. It is the long tail — the reader, the runtime, the conferencing client, the firmware — that quietly falls behind and never appears on a report.
A device that was never really managed
A personal laptop used "just for email". A machine set up before the current IT arrangement. A contractor device. Not enrolled, no EDR, nothing deciding which programs are allowed to run, and the disk is not encrypted.
It has full access to company mail and files, and no one has any visibility into it. When something goes wrong on that device, the first anyone hears about it is a customer asking why they were emailed a new set of bank details.
From there the stages are the same regardless of how it got in. The code runs with the user's own rights, settles in quietly, and copies the tokens, cookies and saved passwords out of the profile. A small archive leaves the network — often the only visible trace of the entire step. The tokens are then loaded on the attacker's own machine, and Outlook, Teams and SharePoint open normally.
Worse, this route tends to outlive the clean-up. An extra MFA method gets registered, a mail rule is left behind, or the token is refreshed before anyone notices — so access survives the password reset that everyone assumes fixed it.
Why the MFA you have today didn't stop either one
MFA is not useless — it stops password spraying and credential stuffing outright, and it should stay on. But it answers one narrow question: who is signing in right now? It says nothing about who holds the token afterwards, and that is precisely what both attacks steal.
It proves the sign-in, not the session
Both attacks steal the result of a successful MFA, so the user is never challenged a second time.
Codes and pushes can be relayed live
A middleman site forwards a code or an approval to Microsoft in real time, seconds after the user gives it.
A password reset does not evict them
Stolen tokens keep working until sessions are explicitly revoked across every device.
Four places the chain breaks
There is no single control that fixes this, which is exactly why it keeps happening. What works is a handful of controls at different stages, applied to every user and every device, and — the part everyone underestimates — kept switched on.
Before anything runs
Only enrolled, managed devices get to company data, and application control decides what is allowed to execute — unknown installers, unsigned binaries and scripts are blocked even when the person running them has every right to run them. Firmware, drivers and applications are patched on a schedule rather than on request.
At execution
Defender for Endpoint with attack surface reduction rules enabled, macros from the internet blocked outright, and a compliance policy that flips the device to non-compliant the moment it looks wrong — which immediately cuts its access to company data.
At sign-in
Phishing-resistant credentials — passkeys, Windows Hello for Business, FIDO2 keys — are bound to the genuine Microsoft sign-in address, so a relay page has nothing it can usefully forward. That removes the approve-the-push weakness entirely.
At replay
Conditional Access requires a compliant, managed device, so a token replayed from an unknown machine is refused. Where Microsoft supports it, token protection ties the session to the device it was issued to. Sign-in risk is re-evaluated mid-session rather than once at the door.
Configuring it once is not the same as keeping it
Most of these controls are already available in licences businesses hold today. The reason they are not in place is rarely a decision — it is that they were configured by hand, in one tenant, by someone who has since moved on. A policy gets excluded "temporarily" for one user during a support call. A new tenant is set up in a rush and only gets half the settings. Nobody can say what changed, when, or by whom.
That is the gap CONFIG365 was built to close. The baseline is stored as code, deployed identically to every tenant, and compared against what is actually live so drift is visible instead of invisible. Every change has an author, a timestamp and a diff. If a control gets switched off, that shows up as a difference rather than as an incident six months later.
Five questions worth asking your IT provider
- 01 If a laptop was compromised this afternoon, how would we know — and how long would it take?
- 02 Can someone sign in to our mailboxes from a device we have never seen, if they have a valid token?
- 03 Are we still using SMS codes or "approve this notification" MFA anywhere, including for admins?
- 04 When we reset a password after an incident, do we also revoke every active session?
- 05 Who is responsible for firmware and driver updates on our laptops, and when did that last happen?
Want this checked against your tenant?
We can show you which of these controls are in place today, which are missing, and what it takes to close the gap — across one tenant or a hundred.