13.2 Incident Briefing: INC-2026-0315-002

Incident Briefing: INC-2026-0315-002

The alert

At 14:23 UTC on 15 March 2026, the CFO of Northgate Engineering forwards an email to the IT team with the subject: “This looks wrong — can you check this?”

The email is from a.patel@northgateeng.com (Anika Patel, Accounts Payable Clerk) to the CFO, forwarding a vendor payment confirmation. The CFO noticed that the bank account details in the confirmation do not match the bank details on file for the vendor (Meridian Precision Components Ltd). The confirmation states the £47,000 March invoice payment was sent to a new account at a UK bank — different from the Meridian account Northgate has paid for 3 years.

This is not an analytics rule firing. This is a human detecting a BEC attempt through operational awareness. The CFO’s instinct that “this looks wrong” is the detection mechanism.

What you know at this point

From the forwarded email chain:

a.patel sent a payment confirmation email to the CFO at 13:45 UTC. The email confirms payment of £47,000 to Meridian Precision Components Ltd — but the bank account details in the confirmation are different from the vendor’s known account. a.patel states she received updated bank details from Meridian’s accounts department via email 3 days ago.

From a quick conversation with a.patel:

a.patel confirms she received an email on 12 March from “accounts@meridian-precision.co.uk” requesting an update to their bank details for future payments. The email was part of an existing email thread about the March invoice. a.patel followed the standard process: updated the vendor record in the finance system and processed the March payment to the new account.

What you do NOT know:

Whether a.patel’s mailbox is compromised (the “vendor” email may have come from a spoofed address, or it may have been sent from a.patel’s own compromised mailbox by the attacker manipulating the thread). Whether the £47,000 has already left the company’s bank account. Whether other vendor payment threads have been targeted. Whether the email from “accounts@meridian-precision.co.uk” was genuinely from Meridian or from an attacker.

The organisation context

Same Northgate Engineering environment from Module 12. 500-seat M365 E5 tenant. a.patel was one of the accounts compromised in the February AiTM campaign (Module 12, Wave 2). Her account was contained, password reset, and MFA re-registered. However, the attacker may have maintained access through a mechanism not fully eradicated — or this may be a new compromise.

Investigation decision points

Decision 1: Was the payment sent? This determines urgency. If the payment is still pending: halt it. If it was sent within the last 24-72 hours: contact the bank immediately to attempt recall. If it was sent more than 72 hours ago: recovery is unlikely. This is the first thing you determine — before any technical investigation.

Decision 2: Is a.patel’s mailbox currently compromised? If yes: the attacker sent the fraudulent email from her mailbox, making it appear as a legitimate internal communication. Containment priority: revoke tokens, reset password. If no: the attacker spoofed the vendor’s domain or used a lookalike domain. Different investigation path — focus on email authentication analysis rather than mailbox compromise.

Decision 3: Was the “vendor” email genuinely from Meridian? Contact Meridian Precision directly (using a phone number from your records, NOT from the suspicious email) and ask: “Did your accounts department send us updated bank details on 12 March?” If yes: Meridian’s email may be compromised (vendor-side BEC). If no: the email was spoofed or sent from a lookalike domain.

Knowledge check

Operational timeline for this investigation

This is the sequence you will follow across subsections 13.3-13.11:

Minutes 0-5: Determine payment status (13.6). If payment was sent: contact bank immediately. Do not wait for the technical investigation.

Minutes 5-30: Assess mailbox compromise (13.3). Run sign-in log queries, check inbox rules, check delegate permissions. Determine: is the mailbox compromised, or was the vendor email spoofed?

Minutes 30-60: Analyse the email thread (13.4). Reconstruct which threads the attacker monitored. Identify the fraudulent email (13.5). Determine the spoofing technique.

Hour 1-2: Execute containment (13.7). Revoke tokens, reset password, place on litigation hold. Export evidence via eDiscovery. Block the attacker’s email infrastructure.

Hour 2-4: Notify law enforcement if financial loss occurred (13.8). Contact the vendor to determine if their email was compromised.

Day 1-3: Complete eradication (13.9). Remove inbox rules, forwarding, delegate permissions. Revert vendor bank details.

Week 1: Deploy hardening (13.11). Verbal verification policy, external email banner, forwarding block, dual authorisation.

Week 2: Deploy detection rules (13.10). 6 KQL analytics rules for ongoing BEC detection.

This timeline assumes the payment was sent. If the payment was intercepted before processing, the financial urgency is removed — but the technical investigation follows the same sequence.