Case file · anonymized · Legacy protocol · BEC · M365

MFA was on. The attacker used SMTP.

Microsoft alerted on a foreign Microsoft 365 sign-in. The forensic engagement confirmed the breach. The unauthorized access wasn’t via MFA-bypass — it was via the legacy-protocol back door that was still wide open three years after Microsoft “deprecated” it.

· worked by the principal

220unique multi-language spam subject lines sent OUT of the compromised mailbox before the customer noticed

Microsoft sent the alert. The customer’s IT lead acted within hours. That’s how this engagement opened.

A remote engineer at a US specialty hardware manufacturer — his M365 account flagged by Microsoft for an unauthorized sign-in from Russia, 8:43 AM Monday local time. The IT lead saw the alert, changed the user’s password immediately, and reached out to us for the real forensic work.

The standard playbook ran like clockwork: 90 days of log analysis. Sysmon deployed for ongoing collection. Remote support installed on the laptop. EDR rolled out. Mailbox rules audited (one rule existed — legitimate, moving a known spam sender to junk). The user’s mobile device cleared. The laptop’s NTUSER.DAT analyzed for suspicious entries. Scheduled tasks reviewed. Hidden forwarding checked. Nothing.

Every line of the standard investigation came back clean. The laptop wasn’t the entry point. The user’s session wasn’t the entry point. There was no malware. There was no phishing kit dropped. The user’s MFA registration was intact and unchanged.

So how did the attacker get in?

The signal that didn’t fit anywhere else

Buried in the sign-in logs, between the user’s normal browser activity, was a different pattern entirely. Foreign-origin authentications that:

Never hit the interactive sign-in surface (no Conditional Access evaluation, no MFA challenge)
Used basic auth rather than modern OAuth2
Connected to SMTP, IMAP4, and POP endpoints
Carried username + password directly — no second factor required, because none of those protocols support it

The unauthorized access wasn’t via MFA-bypass. It wasn’t via session-cookie theft from a phishing kit. It wasn’t via OAuth grant abuse. It was via three legacy mail protocols that the tenant still had enabled, three years after Microsoft “deprecated” them.

Once the attacker had the username and password — and stuffed credentials from any one of the billion-record breach dumps in circulation will give you those — they were in. There was no challenge to fail.

What they did with it

Two-hundred and twenty unique email subject lines went OUT of that mailbox during the access window. Four languages — German, Italian, English, French. Dating-scam blasts. Pornographic spam. “We have a wide selection of girls” relay payloads. The compromised account was being used as relay infrastructure for an unrelated international scam campaign.

It wasn’t targeted. The user wasn’t the prize. The mailbox was the prize — specifically, the ability to send mail from a real corporate-domain address that no spam filter on the planet was treating as suspect. The credential was harvested from a breach dump, automated tooling tried it against the SMTP endpoint, the password worked, and the relay started.

This is the part that surprises people: the attacker didn’t care who the user was. The mailbox was the asset. The user’s actual content — their drafts, their attachments, their financial conversations — was never even read.

The remediation that mattered

Forget the password reset. Forget the laptop reimaging. The actual fix — the one that closed the door for good — was three tenant-level settings:

# Disable SMTP AUTH at the tenant level
Set-TransportConfig -SmtpClientAuthenticationDisabled $true

# Disable IMAP for every existing mailbox
Get-CASMailbox | Set-CASMailbox -ImapEnabled $false

# Disable POP for every existing mailbox
Get-CASMailbox | Set-CASMailbox -PopEnabled $false

Plus one Conditional Access policy:

Block legacy authentication for all users, all apps, all conditions.

That was it. Those four changes — thirty minutes of work for a competent admin — were enough to close the back door permanently.

What “deprecated” means at Microsoft (and why your tenant is probably still vulnerable)

Microsoft announced the end of basic auth in 2019. They began turning it off for new tenants in 2020. They began turning it off for existing tenants in October 2022. That’s the headline.

What that headline does NOT mean:

SMTP AUTH is governed separately from IMAP/POP. Microsoft turned off IMAP/POP basic auth for many tenants, but the “SmtpClientAuthenticationDisabled” tenant flag is a different toggle entirely. Many tenants still have SMTP basic auth ON because a single legacy multi-function printer needed it five years ago.
The disable wasn’t universal. Customers who filed exceptions, customers on hybrid configurations, customers with line-of-business apps using older auth — all kept the legacy stack open.
The exception list never expired. Once an exception was granted, the protocol stayed enabled until someone explicitly turned it off. Microsoft is not going back to audit who’s still using their exception.
Conditional Access “block legacy authentication” is a policy you have to create yourself. It’s not on by default. It’s in the security baseline templates but those templates aren’t automatically applied.

The result: a meaningful percentage of M365 tenants still have at least one legacy protocol enabled today. Mostly SMTP. Sometimes IMAP. Occasionally POP. The customer thinks they’re protected because they have MFA on every user. They’re not. The MFA only fires on the interactive sign-in surface that the attacker isn’t using.

How to check your own tenant in two minutes

From an account with Exchange Admin role, via PowerShell:

# Is SMTP basic auth on at the tenant level?
Get-TransportConfig | Select-Object SmtpClientAuthenticationDisabled
# False == basic auth is ENABLED tenant-wide. You have a problem.

# Which mailboxes still have IMAP enabled?
Get-CASMailbox -ResultSize Unlimited |
  Where-Object { $_.ImapEnabled -eq $true } |
  Select-Object Identity, ImapEnabled

# Which mailboxes still have POP enabled?
Get-CASMailbox -ResultSize Unlimited |
  Where-Object { $_.PopEnabled -eq $true } |
  Select-Object Identity, PopEnabled

# Are there exceptions to your block-legacy-auth Conditional Access policy?
# Open Entra ID -> Conditional Access -> find the policy -> check the exclusions list

If any of those return mailboxes — or if SmtpClientAuthenticationDisabled comes back False — you have legacy authentication still active in your tenant.

The diagnostic that would have caught it earlier

The customer’s SIEM had no alert on legacy-auth sign-in attempts. That category of event simply wasn’t in their detection coverage. When we ran a 90-day backfill against the Unified Audit Log filtered for ClientAppUsed in (SMTP, IMAP4, POP3, AuthenticatedSMTP), we found over a thousand attempts — almost all of them spray attacks from foreign IPs, but several that had succeeded and weren’t getting flagged by anything in the customer’s monitoring stack.

The customer hadn’t been monitoring for legacy-auth events because they believed legacy auth was “deprecated.” Microsoft’s own messaging had convinced them the threat was gone.

What you should require going forward

Disable SMTP AUTH at the tenant level. Set-TransportConfig -SmtpClientAuthenticationDisabled $true. If a service account needs to send mail, use OAuth2 (modern SMTP AUTH submission, supported by all current Microsoft Graph + SendMail flows) or use a transactional sender like SendGrid or Mailgun.
Disable IMAP and POP for every mailbox that does not specifically need them. Audit annually. The list of mailboxes that actually need IMAP/POP is much shorter than what’s enabled.
Conditional Access policy: block legacy authentication, no exceptions. If a business unit screams about a broken integration, treat that as a discovery moment — their integration needs to be modernized, not the policy weakened.
Monitor for ClientAppUsed in (SMTP, IMAP4, POP3, AuthenticatedSMTP) in your sign-in logs. Any success on those protocols by any user from any IP, alert.
Stop calling legacy auth “deprecated.” Microsoft uses that word; reality says it’s “mostly off, sometimes on, frequently exploited.”

The breach wasn’t at the front door. The front door had MFA, Conditional Access, and a security team behind it. The side door was open and nobody was watching.

This case has been fully anonymized per our marketing policy. The customer vertical, geography, exact dates, user identities, the specific attacker subject lines, and the IP ranges have all been generalized. The 220-subject-line figure and the tenant-config remediation are real.

Report an active incident Book an IR consult

Seeing this pattern in your tenant? The person who worked this case answers the email. Originally published on the Envyously blog.