A finance manager received a document sharing notification, signed in on a page that looked exactly like the company’s own, and approved the multi-factor prompt on her phone. Everything worked. The document opened. What she did not see was that her login had passed through a server belonging to somebody else, which kept the session cookie and used it to reach her mailbox for the next eleven days.
Table of Contents
How the attack works
An adversary-in-the-middle phishing kit sits between the victim and the real sign-in page. It forwards each request, shows the genuine page, and passes the multi-factor prompt through to the user, who approves it because they did initiate the login. When authentication completes, the service issues a session cookie and the proxy keeps a copy. From then on the attacker replays that cookie and is treated as an authenticated user without needing the password or a second factor. The NCSC’s guidance on defending against phishing describes this shift plainly: the goal has moved from stealing passwords to stealing sessions.
What the attacker did with eleven days
Very little that looked unusual, which was the point. They read the mailbox, learned the supplier names and the invoice format, and created a rule that moved messages containing certain keywords to an obscure folder. Then they replied on an existing thread with amended bank details, from the genuine account, on a thread the supplier already trusted. The payment was stopped by the supplier’s own process rather than by anything the company detected. Detection came later, from an impossible travel alert that fired when the attacker connected from a different country while the user was at her desk.
“People ask why the attacker waited. They wait because the reconnaissance is where the money is. Anyone can send a fake invoice. Sending the right invoice, on the right thread, in the right format, at the point in the month when payment runs happen, is what makes it work, and that takes a fortnight of reading somebody’s email.”
William Fieldhouse, Director, Aardwolf Security Ltd
The response that mattered
Revoking sessions came first, because a password reset alone leaves a stolen cookie working. The team revoked refresh tokens for the account, reset the password, and then went looking for persistence: inbox rules, mail forwarding, connected applications with consent granted, and any registered authentication method the user did not add. They found the rule and one newly registered authenticator app. Audit logs gave them the access window, which shaped what had to be disclosed to the supplier and to their own insurer.
Controls that would have stopped it
Phishing-resistant authentication would have ended the attack at the login page, since a passkey or hardware key is bound to the real domain and will not authenticate to a proxy. Conditional Access requiring a compliant, managed device achieves much the same by refusing sessions from an unmanaged machine. Token protection and continuous access evaluation shorten the window when a session is replayed elsewhere. Alerting on new inbox rules and on new authentication methods would have raised the alarm on day one rather than day eleven. Microsoft 365 and Azure penetration testing checks these settings under attack conditions, and web application security reviews cover the same weaknesses in customer-facing portals, which are targeted the same way.
Frequently asked questions about session theft
These questions follow every incident where multi-factor authentication did not help.
Does this mean MFA is pointless?
No. It stops password reuse attacks and spraying, which are far more common. It means MFA is one control rather than the answer, and that the phishing-resistant kind is worth the effort for people who handle money or data.
How would you spot it earlier?
Watch for sign-ins from unusual locations and hosting ranges, new inbox rules, new authentication methods and unexpected consent grants. Those four alerts catch most of these cases within a day.
