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

A field-note format we publish occasionally — anonymized engagement narratives where the practitioner story is more useful than another buyer's guide. Names, industries, and specific details are altered. The shape of the attack and the response are not.

The 3 a.m. alert

Friday night before a long holiday weekend. Mid-market healthcare client, ~80 employees, full Microsoft 365 tenant. The Huntress Managed ITDR alert came in 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 isolated the session, revoked all active access tokens for the account, and triggered our escalation path. By 03:14 a.m. the on-call practitioner had:

• Confirmed the attacker had successfully passed MFA via a session-token replay from a previously-phished cookie. 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 the company's owner saw the incident summary at 7 a.m. Monday, the following had 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 called directly by the practitioner before opening — 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. We made it with 60 hours to spare.
• 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 the company's owner read the report, the first question was the same first question we get on almost every BEC engagement: how much did this cost?

Two answers:

• Cost of the incident response work: covered under the existing Managed ITDR + IR-coordination retainer. No additional invoice.
• 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. Stopping one BEC attempt covers years of service. Most clients get their first save inside the first 90 days.

Why this attack succeeded as long as it did

Three things that are true for almost every SMB tenant we onboard:

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 to require re-authentication for sensitive operations (mail rules, app consents, location changes).
• Enable Microsoft Defender for Office 365 Plan 2 if you have it, and review the "AlertInfo" table in your audit log monthly.
• Disable inbox auto-forwarding to external recipients at the tenant level. Almost no legitimate business need requires it; almost every BEC uses it.
• 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 field notes like this occasionally — anonymized, but real. Subscribe if you want them in your inbox once a month.