Case study

Anatomy of a Microsoft 365 tenant compromise

160 accounts signing in from abroad, and a spam restriction was the only symptom.

An international school running Microsoft 365 across a little under three thousand enabled accounts.

The first and only signal came from Microsoft, not from anyone at the school. Defender restricted several mailboxes for anomalous sending patterns, and outbound mail began to be blocked.

That is a spam control protecting Microsoft’s sending reputation. It is not a security alert, and it understates the problem in both directions. It blocks sending only, so every restricted mailbox remained readable by whoever held the credentials. And the Restricted entities page shows only current restrictions, never the real victim count.

One of the restricted mailboxes belonged to the school’s owner.

Available with every hosting plan

$396 / year equivalent value

Premium WordPress capabilities available with every eligible Unisolva hosting plan.

Premium WordPress toolkit

Professional capabilities for building, growing and protecting your WordPress site.

Build

  • Premium page building
  • Advanced design add-ons
  • Theme and template capabilities

Grow

  • Professional forms
  • SEO capabilities
  • Multilingual capabilities

Protect and extend

  • Login security and two-factor
  • Advanced block components
  • Additional managed WordPress tooling

Available on eligible websites while the applicable Unisolva hosting service remains active.

Two operations, not one

Stage one was credential discovery: 3,313 distinct IP addresses across 70 autonomous systems, consumer broadband, spraying a handful of accounts. One account absorbed 3,366 sign-ins from 2,663 distinct addresses in eight days. No amount of travel produces that shape. It is a residential proxy network.

Stage two was delivery: small fixed relay clusters authenticating over SMTP on a daily schedule, using credentials that already worked. Four addresses on a single autonomous system handled 154 accounts between them. Stage two contains no failures at all, which is why hunting for brute force misses it. By that point nobody is guessing.

The root cause was provisioning, not passwords

106 accounts had their password set on a single day. 190 enabled accounts still held a password from that month, and two thirds of them were already compromised. The remaining third were not compromised because nobody had reached them yet.

Someone obtained or deduced the provisioning convention and walked the list. That explains the absence of spray traffic against those accounts, and why they fell together.

Enforcing MFA would not have been enough on its own

The delivery channel was SMTP AUTH. It is legacy authentication and it cannot perform a second factor: not “does not by default”, cannot. An MFA policy has no mechanism to challenge it.

The useful lesson is to audit legacy authentication protocol by protocol rather than as a category. SMTP AUTH had no legitimate use anywhere in this tenant, so it closed in a single setting with nobody affected. IMAP was different: a line-of-business system authenticates over it, so it could not simply be switched off. That is the position almost every real organisation is in, and the answer is not to leave a protocol open for three thousand accounts because one system needs it. It is to scope it to that account and its source address, or to move the integration to modern authentication.

One trap while doing this: a per-mailbox SmtpClientAuthenticationDisabled explicitly set to $false silently overrides the organisation-level setting, and nothing warns you.

What changed

229 accounts were remediated. Every account known to be compromised was reset, and sessions were revoked only after the school confirmed the reset had gone through. That order matters: revoking first leaves a window in which the attacker re-authenticates with the password they still hold.

SMTP AUTH was disabled tenant-wide, which closed the sending channel outright. No user was affected, because there was no legitimate SMTP use to affect.

What remains, and why

Enforcing multifactor authentication, scoping the remaining legacy protocol, and changing how accounts are provisioned are organisational decisions rather than settings. None of them is technical work waiting to be done.

That is not a footnote, it is the finding. The tenant was not compromised because somebody made a mistake on the day. It was compromised because a provisioning convention set once, two years earlier, was never revisited, and because nothing in the organisation’s routine would ever have surfaced it. Fixing the accounts closes the incident. Fixing the process is what stops the next one, and that decision belongs to the organisation rather than to whoever it hires to look.

Every control that would have prevented this was free and already present in the licence.

Find out what your tenant would actually tell us

A one-off Microsoft 365 assessment, or a managed agreement with somebody watching continuously.