When MFA Isn't Enough
A Real-World Microsoft 365 Compromise, and What Small Firms Can Learn From It
By Mike Frangopol, ellwood Technology Inc. — May 2026
A few weeks ago, I worked through a Microsoft 365 account compromise at a small professional services firm. The user had multi-factor authentication. She had been through the firm's annual security training. She used a strong, unique password. She still got compromised — twice in two months, by the same attacker pattern — and by the time we contained the second incident, unauthorized emails had been sent from her account to nearly 3,000 of her professional contacts.
I'm writing this case study because I think the lessons matter for any small firm running on Microsoft 365 and trusting that "we have MFA" is enough. It isn't, and the reason it isn't is worth understanding.
I've kept identifying details out of this post — the firm, the user, specific timestamps, IP addresses. The story is the lesson, not the names.
What happened
The attack pattern was Adversary-in-the-Middle (AiTM) phishing. Here's how it works in plain language:
The user receives an email that looks legitimate — typically a fake voicemail notification, a "shared document" link, or a docusign request. She clicks the link and is taken to a page that looks exactly like the Microsoft 365 sign-in page. It even has the right URL formatting in the address bar at a quick glance.
She enters her email and password. The page shows her the genuine MFA prompt on her phone (because the attacker's server is, in real time, relaying her credentials to the actual Microsoft sign-in page and capturing the response). She approves the prompt — and at that exact moment, the attacker captures the session cookie that Microsoft issues after a successful sign-in.
That cookie is the key to the kingdom. It's the thing your browser holds that says "this user is signed in right now and doesn't need to re-authenticate for the next several hours." The attacker copies it, loads it into their own browser, and is now signed in as the user. From Microsoft's perspective, both sessions look legitimate.
This is not a theoretical attack. There are commercial AiTM toolkits — Evilginx, Tycoon 2FA, EvilProxy, others — that automate the entire process. They are widely used. They defeat traditional MFA by design.
What the attacker did with that access
In the case I worked, the attacker did three things in quick succession:
First, they installed a malicious OAuth application. OAuth is the protocol that lets third-party apps connect to your Microsoft 365 account — like when you authorize a calendar app to read your schedule. The attacker prompted the user to consent to a fake app with a generic-looking name, requesting broad permissions including the ability to read mail, read files, and — critically — offline access, which produces a long-lived refresh token.
The user clicked through the consent dialog, the way most of us click through consent dialogs.
Second, they used that token to read the user's mailbox via Microsoft's Graph API. Not through Outlook — through the API directly, using a Python script. This is invisible from the user's perspective. The mailbox shows nothing unusual.
Third, weeks later, they used the same token to send phishing emails from the user's account. Same API path. The attacker called Microsoft Graph with a parameter that suppresses saving sent messages to the Sent folder. The user's Sent folder showed nothing. The standard Microsoft 365 audit log under the user's identity showed no Send events. From every visible angle, nothing happened.
The attack was discovered when the user started receiving phone calls from contacts asking about the unauthorized messages they'd received from her. She checked her Sent folder, saw it was empty, and called us.
Why password reset isn't enough
Here's the part that matters most for IT decisions:
When we first contained the user's account, we did the standard thing — reset her password and revoked her active sessions. That worked for her interactive sign-ins. The attacker could no longer sign in as her in a browser.
But the OAuth application's refresh token was separate from her user-level session. It survived the password reset. The attacker continued sending mail through the API path for hours after we thought the account was contained. The attack only stopped when we identified and removed the malicious OAuth application from the tenant.
This is a big deal, and it's not widely understood outside the security community. The standard playbook for "compromised account" — password reset and session revoke — does not address OAuth-based persistence. If you don't audit and remove the malicious app, you haven't ended the incident. You've just made it temporarily quieter.
The audit log gap
The other surprise was about visibility. When we tried to determine the scope of the outbound spam from the standard audit log, we got nothing. The attacker's send method — Graph API with a specific parameter set — bypasses Microsoft 365's standard mailbox audit logging entirely at the E3 licence tier.
We only confirmed the actual spam volume by pulling Exchange Online's Message Trace, which is a separate logging system that records mail in transit regardless of how the sending client behaved. That gave us the real number: thousands of messages, to nearly 3,000 unique recipients.
The takeaway here is uncomfortable: at the E3 licence tier, the absence of audit log entries does not mean nothing happened. For breach-assessment purposes, this matters. You cannot say "we checked the logs and nothing was accessed" if the attack technique used is one the logs don't capture.
What would have prevented this
I want to be specific here, because "improve your security posture" is meaningless advice. The controls that would have prevented this attack are concrete and available today.
Conditional Access policy requiring a compliant device for Microsoft 365 access. This is the killer policy against AiTM. A stolen session cookie replayed from the attacker's machine fails the device-compliance check, because the attacker's machine is not enrolled. The token becomes worthless on the attacker's side. Requires Microsoft 365 E3 or Business Premium plus Intune device management.
Token Protection (sign-in token binding). Cryptographically binds the session token to the device that obtained it. Stolen tokens are mathematically useless on other devices. Same licensing requirement.
Country-based sign-in restriction. If your firm only operates in (say) Canada and the United States, block sign-ins from everywhere else. This single policy stops most foreign-IP attackers at the network edge. Takes thirty minutes to deploy.
Restricted user OAuth consent. Microsoft 365's default tenant configuration lets users consent to any third-party application. Lock this down. In the tenant I worked, this single setting change closes the persistence vector that was used in both incidents. It's free. It takes ten minutes.
Passkeys (FIDO2) for high-value users. This is the only authentication method that defeats AiTM by design. The cryptographic challenge is bound to the legitimate Microsoft sign-in domain. Even if the user clicks the phishing link and tries to authenticate, the passkey simply will not produce a valid response against the fake page. There is no equivalent attack against passkeys yet, because the design forecloses it. Microsoft Authenticator passkeys are free.
24/7 managed detection and response (MDR). A monitored SOC catches anomalous outbound mail volume within minutes. In the incident I worked, the spam blast continued for around 20 hours before we even started investigating, because the engagement type didn't include continuous monitoring. With MDR in place, that window closes to minutes.
What this means for small-firm leadership
If you run a small professional services firm — legal, accounting, medical, financial — and your IT setup looks like this:
- Microsoft 365 with MFA enabled
- Standard endpoint antivirus
- An IT consultant or break-fix vendor for support
…then you are in approximately the same risk posture as the firm I worked with. You are protected against the threats of five years ago. You are not protected against the threats of today.
The good news is that the controls listed above are all available, all reasonably priced for a small firm, and most can be deployed within 30-60 days. The hard part is not the technical work — it's the budget conversation. Each of these controls costs something, and "we already have MFA" makes it feel like the spending is unnecessary. It isn't.
If you want one piece of advice from this case study: ask your IT person, in writing, whether your tenant has Conditional Access policies enforcing compliant-device and token protection, and whether user OAuth consent is restricted. If the answer to any of those is "no" or "we should look into that," you have actionable work to do.
The user in the case I worked is fine. The firm is fine — contained, recovered, and now in the process of approving the security upgrades that should have been in place months earlier. But "fine" took a lot of work, a lot of stress, and a recipient notification to thousands of contacts that no professional services firm wants to send.
The post-incident upgrades are the same upgrades anyone could have specified before the incident. They're cheaper before than after. And they work.
Mike Frangopol is the founder of ellwood Technology Inc., a Toronto-based IT and cybersecurity consultancy specializing in Microsoft 365 security for professional services firms. ellwood Technology partners with law firms, medical practices, and financial services firms across the GTA to design, deploy, and maintain modern, defensible IT environments. If you'd like to discuss your firm's security posture, you can reach Mike at mike@etisupport.ca.