How attackers hack Microsoft 365
By Kike Gandia · Co-Founder & CEO, OSCP
Understanding how Microsoft 365 is attacked is the first step to defending it. Most compromises don't exploit a Microsoft flaw, but the organization's configuration and behavior. These are the vectors we see again and again in audits and incident response.
AiTM phishing and token theft
Modern adversary-in-the-middle (AiTM) phishing campaigns don't just steal the password: they capture the session cookie and token, which lets them bypass MFA. With the stolen token, the attacker accesses email and files as if they were the legitimate user, without re-authenticating.
Illicit OAuth app consent
Instead of stealing credentials, the attacker tricks the user into granting consent to a malicious OAuth app with permissions over email and files. Access persists via a token even if the password is changed, and it bypasses MFA. It's one of the most effective and least controlled vectors.
Exchange persistence and Entra ID abuse
After gaining access, the attacker creates forwarding rules in Exchange Online to monitor email, and abuses Entra ID: registering new app registrations with their own credentials, adding permissions or manipulating federation to keep long-term access, even if the original account is reset.
How this is stopped
Defense combines phishing-resistant MFA (FIDO2/passkeys), conditional access that blocks legacy authentication, strict app consent control, monitoring of Exchange rules and new app registrations, and logging with alerts. A periodic audit verifies that these defenses actually work.
How it all fits together: the sequence of a real compromise
The vectors above rarely appear on their own. Chained, the typical sequence of an email fraud in Microsoft 365 looks like this.
An email takes the user to a page that sits between them and Microsoft’s legitimate sign-in. The user enters their credentials and passes MFA without noticing anything odd, because the form they see is the real one, proxied. The man in the middle keeps the session cookie. The attacker imports it into their own browser and gets in with no credentials and no MFA.
Once inside, they create an inbox rule that moves messages containing words like "invoice", "IBAN" or "transfer" into a low-visibility folder, and start reading. When they find an open payment thread with a supplier, they prepare the fraud. Before acting, they register an application or add their own secret to an existing one, to keep access even if the session is closed or the password reset. And then they reply inside the legitimate thread with changed bank details.
The detail worth keeping: between the cookie theft and the fraudulent email there is not a single authentication that MFA could block.
Vector, signal and countermeasure
Every step of that chain leaves a specific trace and is cut by a specific control.
| Vector | Signal in the logs | Countermeasure |
|---|---|---|
| AiTM phishing | Successful MFA sign-in from an unusual network provider and an anomalous user agent | Phishing-resistant MFA and conditional access requiring a compliant device |
| Session cookie theft | The same session used from mutually incompatible locations | Token binding to the device and session revocation on suspicion |
| Illicit app consent | A consent grant event for an unverified application | Restricted user consent and an admin approval workflow |
| Malicious inbox rules | Inbox rule creation in the unified audit log | Alert on rule creation and mandatory review after any incident |
| Entra ID persistence | A credential added to an app registration or service principal | Alert on application changes and periodic review of secrets and certificates |
| Fraud inside the mail thread | Outbound mail from the mailbox outside normal hours | Verification of bank detail changes through a channel other than email |
FAQ
If I change the password, do I lock the attacker out?
Not necessarily. Stolen session tokens, OAuth app consents, forwarding rules and credentials added to app registrations can keep access. After an incident you must revoke tokens and sessions, review consents and rules, and audit Entra ID.
Does MFA protect me from everything?
Phishing-resistant MFA is essential, but AiTM phishing can steal the session and illicit consent doesn't require the password. That's why you need to harden conditional access, control apps and audit the environment.
How do I know whether this has already happened to me?
By searching the unified audit log for the events the chain leaves behind: inbox rule creation, mailbox forwarding changes, consent grants to applications, credentials added to service principals and app registrations, and successful sign-ins from unusual locations. The bad news is that if logging was not enabled, there is no way to look backwards.
What do I do in the first hours if I suspect a compromise?
Revoke the user’s sessions and refresh tokens, reset the credential, remove inbox rules and forwarding, review granted consents and credentials added to applications, and —this is what saves the most money— warn the counterparties on the affected mail threads before somebody pays into a changed account.
Is SMS or app-based MFA any use against this?
It reduces simple credential theft, but it does not stop an AiTM attack: the man in the middle captures the code and the resulting cookie too. What does stop it is phishing-resistant MFA (FIDO2 or passkeys), because the credential is bound to the legitimate domain and cannot be replayed from an intermediate page.
Does this only happen to large companies?
No. Business email compromise is profitable at any size and much of the chain is automated, so the cost of attacking a small company is practically the same. In practice, SMEs tend to be easier targets because the audit log exists but nobody looks at it.