Here is a scenario worth sitting with. Overnight, several hundred sign-in attempts hit one of your staff accounts from an overseas address. Every single one is blocked. The multi-factor prompt did its job, the conditional access policy did its job, nobody got in. In the morning the alert is reviewed, the verdict is "blocked, no action required", and everyone moves on with their day.
That verdict is wrong, and the reason is in the detail nobody reads twice. Those attempts were not blocked at the password stage. They got past the password and were stopped at the second factor. Which means that for several hundred consecutive attempts, somebody on the other side of the world was typing your staff member's correct password.
The attack failed. The credential did not. Those are two different findings, and only one of them was written down.
How the password got out
The most common route in 2026 is not guesswork and it is not a leaked database from a decade ago. It is a phishing page that sits in the middle of a real login.
Your staff member clicks a link, usually from a message that looks entirely ordinary, and lands on a page that looks exactly like the Microsoft sign-in screen, because it is relaying the real one. They type their password, and the page passes it straight through to Microsoft. Microsoft asks for the second factor. They approve it on their phone, because as far as they can tell nothing unusual is happening. The real login succeeds.
The attacker now has two things. The password, captured on the way through. And the session token Microsoft issued at the end, which is the thing that actually keeps someone signed in. That token does not ask for a second factor, because the second factor already happened. Stealing it is the whole point of the exercise.
Multi-factor authentication is not a wall. It is a gate at the front. The tokens it hands out on the way through are what an attacker is really after.
Why "blocked" is not the same as "safe"
Security tooling reports on events, and it reports them accurately. A blocked sign-in is genuinely a blocked sign-in. But the tool is answering "did this attempt succeed", when the question you care about is "does someone else know this password".
Those diverge constantly. A burst of failed attempts against one account, all failing at the second factor rather than the first, is a strong signal that the credential is already out. So is a single successful sign-in from a location the person has never been, followed by nothing obviously bad happening, because the quiet period after a successful token theft is a feature of the attack rather than evidence against it.
The same problem shows up in incident tooling more broadly. A ticket marked closed means somebody looked at it and made a decision. It does not, on its own, mean anything was changed. If you take one operational habit from this piece, make it that one: for anything security related, ask what was actually done, not what status it ended in.
What the clean-up has to include
When an account has been through this, three things need to happen, and the third is the one that gets skipped.
1. Reset the password properly
Not a variation, not a reminder to change it soon. A genuine reset, done now, on the assumption that the old one is known to somebody else. If the same password was used anywhere else, and it usually was, those need to move too.
The simple version: if someone was typing it, it is theirs now. Retire it.
2. Revoke the sessions
This is the step that changes the outcome. Resetting a password does not automatically evict an attacker who is already holding a valid session token, and in the platforms most Australian businesses run on, revoking active sessions is a deliberate, separate action. Skip it and you can do everything else correctly while the intruder stays signed in, watching you tidy up.
The simple version: change the lock and clear the building. One without the other achieves very little.
3. Look for what was left behind
Anyone who gets access to a mailbox or a tenant expects to lose it eventually, so they arrange to stay. A forwarding rule that quietly copies everything to an outside address. A mail rule that files anything mentioning invoices or payments into a folder nobody opens. An application consent granted in passing that keeps working long after the password changes.
These survive the password reset, which is exactly why they are used. I have written separately about the persistence that hides in mail configuration, because it deserves its own conversation.
The simple version: the reset closes the door. It does not check whether anyone left a window open.
What actually reduces the risk
Two changes do most of the work here, and neither makes life harder for your team.
The first is moving away from approval prompts that a tired person can tap through, towards factors that are bound to the device and the real site. If the second factor cannot be relayed by a page in the middle, the attack in this article stops working. That is the direction the whole industry is moving, and it is worth being early rather than late.
The second is watching for sign-ins that succeed from places and devices that make no sense, and treating them as worth a phone call. Not an alert in a queue. A phone call, to the person, that day.
Underneath both sits the habit I keep coming back to: someone has to own the follow-through. Most of the security failures I see are not missing tools. They are a correct alert, correctly raised, that ended in a status change rather than an action. If alert fatigue is real in your business, and it is real in most, that is the thing to fix first.
The honest summary
MFA is not optional and nothing here argues otherwise. It stops the overwhelming majority of attacks against your business and you should have it everywhere, today. But it changes what an attack looks like rather than ending attacks, and the businesses that get caught out are the ones who read "blocked" and stopped reading.
If you want to know how your identity setup would hold up against this specific attack, that is a good use of a conversation. Our security assessment covers it, and you can read more about how we approach identity and access.
