The 3 a.m. alert: anatomy of an ITDR save before payroll Monday

This is a scenario walkthrough, not a client case study. The details are composed from common business email compromise mechanics and the response pattern a managed identity program should follow.

The 3 a.m. alert

Friday night before a long holiday weekend. A mid-market organization with roughly 80 employees and a full Microsoft 365 tenant gets an ITDR alert at 02:47 a.m. Eastern: a successful sign-in to the Finance Director's account from a country where the company has no operations, followed within 90 seconds by an Outlook inbox rule being created that auto-forwarded any email matching wire OR ACH OR routing to an external address and then deleted the original.

Classic business email compromise (BEC) staging. The attacker was not in the inbox to read mail. They were in to redirect one specific kind of mail — wire instructions — and to make sure nobody else in the company saw them.

What the SOC did before anyone in the company woke up

The Huntress Security Operations Center isolates the session, revokes all active access tokens for the account, and triggers the escalation path — around the clock, without waiting for anyone. Obsidian Ridge picks the case up within one business day. By the time it has been worked through:

• Confirmed the attacker had bypassed MFA via an adversary-in-the-middle (AiTM) session hijack: the original phish, weeks earlier, had captured the authenticated session and refresh tokens, which the attacker then used to mint new access tokens from a foreign IP. The user's password was unchanged. The attacker's foothold was the session, not the credentials.
• Identified the source of the original credential capture: a phishing message from three weeks earlier that had bypassed the email filter because it was sent from a compromised legitimate vendor's mailbox. The user clicked, "logged in" on a fake Microsoft page, and the session was hijacked silently.
• Pulled the inbox rule the attacker created, plus three additional rules they had created in other accounts inside the same tenant during the same session window — one of which was already forwarding invoices to an external Gmail.
• Identified two outbound emails the attacker had already sent from the Finance Director's account — both addressed to vendors with "updated wire instructions" attached. Neither vendor had actioned the change yet.

What we coordinated by Monday morning

By the time leadership sees the incident summary at 7 a.m. Monday, the following has already happened:

• All affected accounts had passwords rotated, MFA reset, and active sessions revoked.
• Inbox rules created by the attacker had been removed. The forwarded emails sent to external Gmail were retrieved from the audit log and added to the case file.
• The two vendors who received the fraudulent wire-instructions emails had been contacted out of band — both confirmed they had not acted. Both received written follow-up explaining what had happened so they could check their own systems.
• An incident report had been written for the company's cyber-insurance carrier, formatted to the carrier's specific notification requirements. The notification window for this carrier was 72 hours, and the report went in inside it.
• The original phishing message that captured the session three weeks earlier had been retro-actively pulled from every other mailbox in the tenant. Twelve other employees had received it; none had clicked.

The owner's first question

When leadership reads the report, the first question is the same one almost every owner asks after a BEC near-miss: how much did this cost?

Two answers:

• Cost of the incident response work: in a properly scoped Managed ITDR + IR-coordination retainer, this should be covered by the operating model rather than improvised as a separate emergency project.
• Cost of the wire fraud the attacker was trying to execute: the two staged invoices totalled ~$96,000. That is what the attacker was 24-48 hours away from getting paid.

The math on managed identity threat detection is rarely complicated. One stopped BEC attempt can justify years of monitoring when the attempted transfer is large enough. The point is not the story; it is the control sequence: identity visibility, session revocation as the first move, mailbox-rule review, and out-of-band vendor confirmation.

Why this attack succeeded as long as it did

Three things are common in SMB tenants:

1. MFA was on, and it didn't matter. Modern phishing kits capture session tokens, not passwords. Once the token is replayed from another country, the attacker is "MFA-authenticated" from the platform's point of view. Detection has to happen on session behaviour (impossible travel, suspicious app consents, anomalous mail rules), not on credentials.
2. Nobody was watching the audit log. Microsoft 365 records every inbox rule creation, every token grant, every suspicious sign-in. Almost no SMB has someone reading those logs at 03:00 a.m. on a holiday weekend. That is precisely when attackers act.
3. The attacker came in through a third-party mailbox. The vendor whose mailbox was compromised three weeks earlier was a small, legitimate business. They had no idea their account was being used to phish their customers. This is the most common initial-access pattern we see now.

What you can do this week, even without us

• Turn on Microsoft 365 Conditional Access with a short sign-in frequency (4–8 hours) on Exchange Online, plus step-up MFA on risky sign-ins and OAuth app consents. Conditional Access evaluates at sign-in, not on individual mailbox actions, so it shrinks the useful life of a stolen session rather than gating each inbox rule directly.
• Block external auto-forwarding at the tenant level. Microsoft's current canonical control is the outbound anti-spam policy: in the Defender portal, go to Email & collaboration → Policies & rules → Threat policies → Anti-spam → Outbound and set Automatic forwarding rules to Off. Microsoft's "secure by default" rollout already disables this for new tenants, but it is worth confirming on tenants that pre-date the rollout. The older remote domain lever still works but is no longer the primary recommendation. Almost no legitimate business need requires auto-forwarding; almost every BEC uses it. Even if an attacker manages to create a forwarding rule, the mail never leaves the tenant.
• If you have Microsoft Defender XDR (E5 Security or the Defender XDR plan), use the unified hunting console at security.microsoft.com → Hunting → Advanced hunting to query the AlertInfo and AlertEvidence tables for inbox-rule and consent-grant events, and CloudAppEvents for the broader audit-event stream. Advanced hunting requires Defender XDR to be enabled plus an appropriate RBAC role; MDO Plan 2 alone surfaces only the Email/Collaboration hunting tables, not endpoint or identity ones.
• If you have Microsoft Defender for Cloud Apps, switch on the "Suspicious inbox forwarding rule" policy — it detects and can auto-disable the exact rule pattern used in this incident.
• Re-train your finance team on out-of-band confirmation: any wire-instructions change, no matter how legitimate the email looks, gets a phone call to a previously-known number before it is actioned. Not the number on the email. The number on the previous invoice.

If you want this kind of monitoring without staffing it yourself, that is what Managed ITDR is for, and it is included in our Protected and Complete tiers. If you want help right now because something has already happened, the briefing form has an option for that.

We publish scenario walkthroughs like this occasionally when the response sequence is more useful than another buyer's guide. Subscribe if you want them in your inbox once a month.