On this page
Multi-factor authentication is still the single best security investment most businesses can make. We’ve said so before, and nothing here changes that.
But there’s an attack going around that gets past it, and the people it catches are not careless. They are business owners doing exactly what they’re supposed to do: signing in, seeing a prompt, approving it. The password was strong. The second factor worked. The account was taken anyway.
And it happens at your own desk, on your own machine, on the office network, in the middle of an ordinary working day. There is no trip away from the office to explain it afterwards, no unfamiliar hotel wifi, no borrowed laptop. That is part of why it works: from the inside, nothing about the sign-in looks unusual, because nothing about it was unusual. You really did sign in, and it really was you.
It’s worth understanding, because the instinct afterwards — “reset the password and we’re fine” — leaves the attacker exactly where they were.
The attack: a relay, not a crack
It’s called adversary-in-the-middle, and the name is literal. The attacker stands between you and the real Microsoft sign-in page.
You click a link and land on what looks like the Microsoft login. It looks right because it is right — the attacker’s server is quietly passing every keystroke through to the genuine Microsoft page and passing Microsoft’s responses back to you. You type your password: relayed. Microsoft asks for your second factor: relayed. You approve the prompt on your phone: relayed.
Microsoft sees a completely legitimate sign-in, because it is one. It hands back a session token — the thing your browser holds afterwards so you aren’t asked to log in again every thirty seconds.
The attacker keeps a copy.
This is worth distinguishing from the two things people often confuse it with. Credential phishing steals your password and stops there — MFA defeats it. Device-code phishing tricks you into approving a sign-in on the attacker’s behalf using a legitimate Microsoft flow. Adversary-in-the-middle is neither: it captures the finished session, after every check has already passed.
Why MFA doesn’t stop it
Because MFA has already done its job by the time the theft happens.
Multi-factor authentication answers one question: is this the right person signing in? On the day, the answer was yes. The token issued afterwards is proof that the question was asked and answered. Steal the proof and you don’t need to answer the question again.
This is also why “we have MFA” is no longer a complete answer to “are we protected?” It’s a necessary control that a specific, common attack is built to route around.
The twenty seconds most people miss
Here’s the part that turns a bad afternoon into a long one.
Having captured the session, a competent attacker doesn’t just read email. They use it to register a device against your account — a machine they control, added to your organisation as though it were a new laptop. In the case that prompted this article, that happened roughly twenty seconds after the token was captured.
Once a device is registered, Microsoft issues it a Primary Refresh Token — a long-lived credential bound to that machine. And here’s the problem:
Resetting the user’s password does not remove a registered device. Neither does signing them out everywhere.
You can do both, feel like you’ve handled it, and leave the attacker holding working access. Microsoft’s own documentation is the reference here: a Primary Refresh Token is invalidated when the device is disabled or deleted, or when the user’s refresh tokens are revoked, not by a password change alone (Primary Refresh Token, Microsoft Learn). In the incident behind this article, the rogue device kept working after the reset. That is one case, not a law of nature, and how long a token survives depends on your Conditional Access and token settings. The safe assumption is that it survives until you act on the device. The device has to be found and dealt with.
What they were actually after
The assumption is always that this is about money — a fake invoice, redirected banking details. Sometimes it is.
But mailbox access buys something quieter: control over what the owner sees. A rule in the mailbox that silently deletes every email from one particular company, so a conversation can be conducted without the real person noticing. A deleted message that removes an opportunity from view. These rules are often given names like .. or a single full stop, so they’re nearly invisible in a list of rules.
That’s a different kind of damage. Nothing is stolen, no money moves, and there’s nothing to notice — because the whole point is that you don’t notice. A tender you never knew arrived. A supplier who thinks you’re ignoring them.
If you only check for fraudulent payments after an account compromise, you can miss this entirely.
What actually reduces the risk
Phishing-resistant sign-in. FIDO2 security keys, passkeys, Windows Hello for Business and certificate-based authentication are cryptographically tied to the real site. A relay page can’t complete the handshake, so the attack fails at step one. This is the highest-value change, and the right place to start is administrators and anyone who signs cheques. Note the word resistant — no control is absolute.
Restrict who can register a device. Microsoft Entra ID lets you require multi-factor authentication for the “register or join devices” user action through Conditional Access, which covers exactly the registered and joined device types used in this kind of attack. One caveat from Microsoft’s own guidance: if you configure this in Conditional Access, the older tenant-wide device setting should be set to No, or the two overlap.
Token protection. A Conditional Access control that binds sign-in session tokens to a device, so a stolen token can’t be replayed elsewhere. It’s available for Windows sign-in sessions with Microsoft Entra ID P1; coverage for web applications is still in preview. Worth planning for, and worth checking what it covers before assuming it closes the gap.
Alert on mailbox rule creation. A hidden rule is trivial to create and easy to miss for months. It should generate an alert the moment it appears, not wait for someone to go looking.
Someone actually watching. In the incident behind this article, the intrusion was detected and the account locked automatically about sixteen minutes after the attacker opened the mailbox. Sixteen minutes was enough for them to create a rule and delete a message. It was not enough to do real financial damage. That gap between detection and consequence is the entire value of monitored detection and response — and it only exists if someone is watching at 9:30pm.
If you think it’s happened to you
Contain first, then preserve, then investigate. This follows Microsoft’s procedure for a compromised account; the order is the point.
Contain
- Block sign-in on the account. Disable it in Entra. Nothing else you do matters while the attacker can still sign in.
- Reset the password and revoke every session and refresh token. Do the reset, then the revoke, so the new password is not handed straight back through a live session.
- Find any device registered to the account that you don’t recognise and disable it, then delete it. This is the step most people skip, and it is the access that a password reset alone leaves in place.
- Remove any MFA method the user doesn’t recognise. The attacker may have added their own phone.
Preserve
- Do not tidy up yet. Export the sign-in logs, the audit log and the mailbox rules before you change anything else, so you can see what was read, deleted or sent, not only what was changed.
Investigate and recover
- Check mailbox rules and forwarding on the user’s mailbox, and on every mailbox if the account held administrator rights.
- Read the audit log for what was actually accessed and sent. Look for the hidden rules described above.
- Re-enable the account only once steps 1 to 4 are done and you have a clean picture. If you are not certain, leave it blocked and get help.
And call the person. Ask what they clicked, and when. It’s usually still in their mailbox. If the account is a Microsoft 365 administrator, or you are not sure what the attacker did, treat it as an incident and bring in someone who does this regularly.
The short version
MFA is not the problem — going without it is far worse. But “we have MFA” is where security starts now, not where it finishes. The attacks that matter have moved on to the session behind it, and the fix is a handful of specific settings most Microsoft 365 tenants have never had turned on.
If you’re not sure whether yours are, that’s a short conversation and worth having before you need it. Get in touch and we’ll take a look.
Sources and last verified
Last verified 11 September 2026.
- Responding to a compromised email account, Microsoft Learn: the containment sequence above follows this procedure.
- What is a Primary Refresh Token?, Microsoft Learn: how the token is issued and when it is invalidated.
- Manage device identities, Microsoft Learn: disabling and deleting a registered device.
- The incident described is a real DVG Systems engagement, anonymised; the sixteen-minute figure is from our own ticket timestamps. Read the case study.
DVG Systems provides managed IT and cybersecurity services to businesses across Northern Ontario. Related reading: Why a Password Isn’t Enough Anymore and Phishing That Wears a Trusted Logo.