Anatomy of a Microsoft 365 compromise.
Five stages, from a supplier's compromised mailbox to data read through the Graph API. At every stage the organisation's controls behave exactly as designed — and the attacker keeps going. This is what the chain looks like, and where it can be broken.
The chain
Nothing here requires a zero-day.
Every technique below is commodity, documented publicly, and available as a subscription service. The difficulty is not in executing it — it is in noticing.
A remittance advice from a supplier you actually use
What the attacker does
The mail arrives from a genuine, currently-compromised supplier mailbox. It passes SPF, DKIM and DMARC, because it is real mail from a real sender you have corresponded with for years. The attachment is a PDF; the link inside routes through a document-sharing service and a cloud host before it lands anywhere suspicious.
What it looks like from the inside
Nothing in the mail security stack has grounds to act. The sender is authenticated, the domain is aged and reputable, and the intermediate hops are all legitimate services. Awareness training that teaches staff to check the sender has, in this instance, actively worked against them.
What breaks the chain here
Supplier security requirements — MFA on their mail systems and prompt breach notification — plus behavioural detection on internal mail patterns rather than sender reputation alone.
The victim approves a genuine Microsoft prompt
What the attacker does
The chain ends at a real Microsoft device sign-in page showing a real code. The victim enters it and completes MFA — properly, on Microsoft's own domain. The authentication is not bypassed; it is transferred. The attacker receives access and refresh tokens and has never seen the password.
What it looks like from the inside
The sign-in log records a successful authentication with the MFA requirement satisfied. There is no failed-login spike, no impossible-travel alert if the timing is tight, and no credential to reset that would help. This is the moment most organisations would say their controls worked.
What breaks the chain here
Conditional Access blocking device code flow for all users bar break-glass accounts — the single highest-value change on this page. Audit existing device-code usage first so the control does not become an outage.
A device is registered, and the password stops mattering
What the attacker does
Within minutes, the attacker registers a device into the tenant and obtains a Primary Refresh Token. Access is now independent of the account password. Sessions refresh on a slow, irregular cadence — dormant for days, then active — which keeps the activity beneath volumetric thresholds.
What it looks like from the inside
This is where containment usually fails. The eventual incident response resets the password, forces MFA re-enrolment, and declares the account recovered. The registered device is untouched and the access continues.
What breaks the chain here
Restrict device registration to managed or compliant devices; alert on every new registration; enable Continuous Access Evaluation so revocation is immediate rather than waiting on token expiry.
Files are read, not downloaded
What the attacker does
Document libraries shared organisation-wide are enumerated and read through the Graph API — searches, previews, page views. The material of interest is customer documentation and internal audit output, because both are concentrated, sensitive and rarely watched.
What it looks like from the inside
If audit configuration records downloads but not previews, page views and searches, then a complete exfiltration produces no evidence at all. The investigation later cannot establish what was taken, which turns a contained incident into an unbounded disclosure question.
What breaks the chain here
Verify — do not assume — that audit logging captures preview, page view and search events across SharePoint, Exchange, OneDrive and Teams, and that it reaches the SIEM with retention longer than realistic dwell time.
An inbox rule named with a single full stop
What the attacker does
A mailbox rule files and marks-as-read anything matching the attacker's own correspondence, including replies from the people they are now emailing. The rule name is deliberately unremarkable. Onward mail goes out from the genuine account, often BCC, to suppliers, partners and regulators harvested from the contact list.
What it looks like from the inside
The account owner sees nothing. Recipients see authenticated mail from a person they know. The first external signal is frequently a supplier asking why they were sent something odd — by which point the campaign has propagated.
What breaks the chain here
Periodic tenant-wide inbox rule audits for hidden or obfuscated names, and rules combining move-to-folder with mark-as-read or stop-processing.
What the engagement looks like
Two to three weeks, run against your live tenant.
Production is the only environment where the answer means anything — a test tenant does not carry your Conditional Access exceptions, your legacy application estate or your sharing history.
Scope and reconnaissance
Rules of engagement, authorisation, escalation contacts and safe-words agreed in writing. Tenant reconnaissance from the outside: exposed authentication endpoints, discoverable users, and which authentication flows answer.
Attack-path execution
The chain above, run against your tenant with your controls in place. Where a step is blocked we record what blocked it, which is as valuable as the steps that succeed.
Detection assessment
Everything we did, set against what your SOC saw and what your logs retained. This routinely surfaces the audit-configuration gap in stage 04 before anything else.
Report and purple-team walkthrough
Attack-path narrative, Conditional Access coverage matrix, logging gap report, prioritised hardening plan — then a working session with your SOC on what should have fired and how to build it.
Retest
Once remediation lands, the same paths are re-run. Closure evidence is what a supervisory review or IT Committee submission actually asks for.
Common questions
About this walkthrough.
How realistic is the "MFA was satisfied" problem?
It is the defining characteristic of this attack class. The victim completes a genuine Microsoft multi-factor challenge, so the sign-in record legitimately shows the requirement as met. Any detection logic keyed on failed MFA, or on the absence of MFA, will never fire. This is why phishing-resistant authenticators — FIDO2/WebAuthn or certificate-based — are the control that matters here, rather than more MFA.
Our SOC monitors Microsoft 365. Would we catch this?
The honest answer is that it depends almost entirely on stage 03 and stage 04, and most monitoring is not configured for either. Specifically: do you alert on new device registrations in Entra ID, and does your audit configuration record file previews, page views and searches rather than only downloads? Those two questions separate organisations that would detect this from organisations that would learn about it from a supplier. Both are answerable today from your own admin centre — our readiness checklist walks through them.
What is the fastest thing we can do this week?
Block device code flow through Conditional Access for everyone except break-glass accounts, having first audited existing usage so you do not break legitimate tooling. It removes the initial access technique in stage 02 outright, it is a configuration change rather than a project, and it is a published mitigation in the FBI advisory. After that: block legacy authentication unconditionally, and check what your audit configuration actually records.
Would your tenant break the chain?
Work through the checklist first — it is free and it answers stages 02 to 04 on your own. If gaps remain, a scoping call takes thirty minutes.