One year of dwell. 91 alerts. Nobody looked.

A customer asked us to look at “some authentication noise” their MSSP had been ignoring. The existing SIEM was generating alerts. They had 91 of them sitting in the queue from the last year. Nobody had triaged a single one.

We started reading.

The first alert was 367 days old.

The setup

This was a mid-sized organization. Microsoft 365 Business Premium tenant. Conditional Access policies in place — the standard suite. MFA enforced for everyone. Defender for Office 365 on. By the dashboards, they were doing everything right.

Their MSSP was a name-brand provider. The SIEM was reputable. The Microsoft 365 connector add-on was the vendor’s recommended one — installed from the marketplace, default configuration. Nobody changed it. Nobody had a reason to.

That was the problem.

What we did differently

The first thing we changed was the SIEM connector’s field mapping. The default vendor connector strips an Entra ID field called tokenIssuanceType before it lands in the customer’s index. We’ve never figured out why — there’s no documented reason. The result is that AiTM (adversary-in-the-middle) compromise indicators are functionally invisible inside the customer’s SIEM.

Add it back, re-run the search across 12 months of historical sign-in data, and what was zero hits becomes 91.

filter where tokenIssuanceType == "SamlToken"
group by user, src_ip, country, _time

Every row was a real sign-in. Every row was an account that had been phished via an AiTM kit. Every row was a session cookie that bypassed MFA cleanly — exactly as those kits are designed to do.

What we found in the data

Then we kept pulling.

The earliest victim signed in from a stolen session cookie 367 days before our engagement. The most recent: three days before our engagement. The same campaign had been active in the tenant for over a year, with periods of dormancy and resurgence.

We graphed sign-in pairs by user and computed time-distance between consecutive sessions:

• 18-second impossible travel. One user signed in from a U.S. east-coast city. Eighteen seconds later, the same account signed in from South America. The customer’s CA policy had a “geo block” rule. It had not fired. The reason: the stolen session cookie carried a claim that the original sign-in had already satisfied MFA + geographic rules, and the policy honored that claim. The geo block applied to NEW sign-ins, not to session-cookie-resumed sessions.

• A foreign-IP password spray had been hitting the tenant in low-and-slow bursts for months. Most attempts hit invalid users. A handful succeeded — those were the AiTM victims whose passwords had already been harvested.

• Multiple Microsoft Authenticator devices registered on accounts that should have had one. The attacker had been adding their own MFA device to maintain persistence.

We mapped 14 users across the campaign’s lifecycle. Their MSSP had alerted on all 14. Nobody had read the alerts.

Why the CA policies didn’t help

The customer’s Conditional Access policies were configured exactly the way Microsoft’s documentation recommends. They had geo blocks. They had MFA grants. They had session-frequency controls.

What they didn’t have:

1. A policy targeting “Other clients” + “Exchange ActiveSync” with Block (the legacy-auth bypass).
2. A policy requiring phishing-resistant MFA for admins (SMS was still the default factor for several).
3. A sign-in frequency control on the persistent-browser channel (where AiTM-stolen tokens live).

Each of those three is a one-policy change. None require a license upgrade beyond what was already in place.

What you can check in your own tenant today

Regardless of which SIEM or log platform you use:

1. Confirm your M365 connector retains the tokenIssuanceType field. Filter for SamlToken. Anything that’s not a legitimate federated sign-in deserves a second look.

2. Compute user-level impossible-travel pairs over the last 365 days. Sub-minute jumps across countries are not commute traffic.

3. Audit your CA policies for the three blocks above.

If you have Entra ID Premium P1, you also have direct access to:

1. /auditLogs/signIns — real-time sign-in detail with risk fields.
2. Cross-reference with /auditLogs/directoryAudits to catch “Add MFA method” events on accounts that already had factors registered — attacker persistence has a very specific signature there.

Why this matters

This wasn’t a sophisticated nation-state campaign. The toolkit is sold online. The phishing pages auto-generate. The session-cookie harvesting is templated.

What made the campaign successful was nothing the attacker did — it was the customer’s defenders not reading the alerts that were already firing.

When we ran our free risk assessment on this tenant, the first finding category that landed was “23 high-risk admin actions logged in the last 7 days, none reviewed.” The 91-alert backlog had been growing on top of an existing 12-month-old compromise. Nobody had ever asked who was approving the consent grants.

Most M365 compromises aren’t found because someone is brilliant. They’re found because someone finally looked.

---

This case has been fully anonymized per our marketing policy. No identifying details, organization name, vertical, geography, employee names, or exact timestamps have been retained.

Want to know if these patterns exist in your tenant?

Run the free Envyously Risk Score →

The assessment takes about six minutes, runs against your live Microsoft 365 tenant via OAuth (no credentials shared), and produces a graded report with every finding categorized, evidenced, and ranked. No credit card. No commitment.