Business Email Compromise Investigation — Hard Lab

The Ticket

TicketINC-2026-0814

PriorityHigh

Reported byVendor AP contact, via David Okafor (Argosy Freight, AP Lead)

Assigned toYou — SOC Analyst

Summary: A client placed a $184,500 wire payment to Argosy Freight & Logistics on hold after the "updated" bank details in a recent email didn't match the vendor master file. The email came from a genuine Argosy Freight address — priya.raman@argosyfreight.example. Finance wants to know before the hold expires: is this fraud, and if so, how did it happen?

Overview

Anatomy of a Business Email Compromise

Before diving into individual evidence, here's the shape of the attack you're about to reconstruct — six stages from initial phish to the point finance caught it.

Diagram of a BEC attack chain: initial phishing email, account takeover, mailbox rule abuse, reconnaissance, fraud email sent, and investigation begins

Every real BEC case looks roughly like this. Your job below is filling in the specifics — the actual timestamps, IOCs, and evidence — for this case.

Evidence

Five artifacts were pulled from Argosy Freight's mail system and identity logs. Review each one, form your own read, then expand the analyst notes to check yourself.

Evidence 1

The Initial Phishing Email

Pulled from Priya Raman's mailbox, dated two days before the fraud email was sent.

From"SharePoint Notifications" <notify@sharepoint-docs-view.example>

Topriya.raman@argosyfreight.example

Subject"Q3-Vendor-Statement.xlsx" has been shared with you

David Okafor shared a file with you on SharePoint. This link will expire in 24 hours.
Open Q3-Vendor-Statement.xlsx →

Field	Value
Envelope sender	notify@sharepoint-docs-view.example
Link destination	argosyfreight-sso-verify.example/login
Authentication	spf=fail, dkim=none, dmarc=fail

Reveal Analyst Notes

The destination domain argosyfreight-sso-verify.example mimics an internal single-sign-on page but isn't Argosy's real domain — a classic credential-harvesting lure disguised as a routine file-share notice from a real colleague's name (David Okafor genuinely works in AP, which is what makes it convincing). No malware, no attachment — just a fake login page designed to capture Priya's password.

Evidence 2

Sign-In Log — Priya Raman's Account

Identity provider audit log for the two weeks around the incident.

Date / Time (UTC)	Source IP	Location	Client	MFA	Result
Aug 05, 09:14	203.0.113.18	Chennai, IN	Outlook Mobile	Satisfied	Success
Aug 09, 08:47	203.0.113.18	Chennai, IN	Outlook Web	Satisfied	Success
Aug 12, 19:03	198.51.100.231	Unknown VPN — Eastern Europe	Legacy IMAP4	Not required	Success
Aug 12, 19:05	198.51.100.231	Unknown VPN — Eastern Europe	Outlook Web	Not required	Success
Aug 14, 22:40	198.51.100.231	Unknown VPN — Eastern Europe	Outlook Web	Not required	Success

Reveal Analyst Notes

Three sign-ins from a completely different IP and region, minutes after the phishing email's likely open time, all succeeding without an MFA challenge. That's the tell: the first flagged sign-in used legacy IMAP4, a protocol that in many tenants doesn't support modern MFA at all — a well-known way to walk straight past a security control that would otherwise have stopped this cold. The Aug 14 sign-in lines up exactly with when the fraud email (Evidence 4) was sent.

Evidence 3

Mailbox Rule Created

Mailbox audit log entry, six minutes after the first anomalous sign-in.

Action: New-InboxRule
Mailbox: priya.raman@argosyfreight.example
Created: 2026-08-12 19:06:41 UTC
Rule name: "."
Condition: Subject or body contains "invoice", "wire", "payment", "bank", "remittance"
Action: Move to RSS Subscriptions folder; mark as read; stop processing more rules

Reveal Analyst Notes

A rule named "." — a single period — is a deliberately easy-to-miss name in a long rule list. Its effect: any reply that mentions the exact words a real follow-up about this fraud would use gets silently filed away and marked read, so Priya never sees them land in her normal inbox. This is one of the single most common BEC indicators, and one most organizations don't actively monitor for.

Evidence 4

The Fraud Email

Sent from Priya's genuine, fully-authenticated mailbox. (Full header breakdown also covered as Case 2 in the Medium lab.)

From"Priya Raman — Argosy Freight" <priya.raman@argosyfreight.example>

Toap@[client].example

SubjectRe: Invoice #4471 — please use our new bank details

Hi, following our earlier invoice thread — our finance team completed a routine bank audit and moved to a new account this week. Could you please route the pending payment for INV-4471 to the updated details below instead? Sorry for the short notice, trying to close this out before month-end.
New Bank Details (PDF) →

Raw Headers Annotated Analysis ← click to flip view

From: "Priya Raman — Argosy Freight" <priya.raman@argosyfreight.example>
To: ap@client.example
Subject: Re: Invoice #4471 — please use our new bank details
Date: Fri, 14 Aug 2026 22:47:03 +0000
References: <4471-orig@argosyfreight.example>
Received: from mail.argosyfreight.example (mail.argosyfreight.example [203.0.113.90])
        by mx.client.example; Fri, 14 Aug 2026 22:47:19 +0000
Authentication-Results: mx.client.example;
    spf=pass smtp.mailfrom=argosyfreight.example;
    dkim=pass header.d=argosyfreight.example;
    dmarc=pass (p=REJECT) header.from=argosyfreight.example

Auth

Passes every check, exactly as expected for a compromised real account. This is not a spoofed sender — it's Priya's own mailbox, sending 7 minutes after the anomalous Aug 14 sign-in in Evidence 2.

Behavior

Matches the exact keywords the malicious rule in Evidence 3 is built to hide. Any reply asking to confirm or verify this change would be auto-filed away — Priya would never see it, and would have no idea her account sent this.

Evidence 5

Bank Details — Before vs. Requested

Field	On File (Vendor Master)	Requested in Fraud Email
Bank name	First Continental Bank	Meridian Pacific Trust
Account (last 4)	••4471	••9902
Routing / IFSC	021000021	098001129

Reveal Analyst Notes

A completely different bank, not just an updated account number at the same institution — the pattern real vendor bank changes almost never actually take. This is the detail the client's AP team caught, and exactly the kind of change that should always trigger an out-of-band phone call to a known contact before any funds move.

Reconstructed Timeline

Once you've reviewed all five pieces of evidence, here's how they chain together.

Reveal Full Timeline

AUG 12 · 19:01 UTC

Phishing email delivered to Priya Raman's inbox, disguised as a SharePoint file-share notice.

AUG 12 · ~19:02 UTC

Priya opens the email and enters her credentials on the fake login page (inferred — no direct log of this step, but consistent with the sign-in that follows a minute later).

AUG 12 · 19:03 UTC

Attacker authenticates from an unrecognized IP via legacy IMAP4 — no MFA challenge presented.

AUG 12 · 19:06 UTC

Malicious inbox rule "." created, set to silently hide any reply mentioning invoice, wire, payment, bank, or remittance.

AUG 12 – 14

Attacker reads existing AP correspondence undetected, learning the real invoice number, vendor contact, and tone to imitate.

AUG 14 · 22:47 UTC

Fraud email sent from Priya's real, authenticated account requesting a switch to fraudulent bank details for a pending $184,500 payment.

AUG 18

Client's AP team notices the requested bank details don't match the vendor master file and places the payment on hold instead of releasing it.

AUG 19

Incident reported to Argosy Freight IT Security — investigation opened. You are here.

Indicators of Compromise

What you'd hand to the email gateway, EDR, and firewall teams to hunt for and block.

Type	Indicator
Phishing sender domain	sharepoint-docs-view.example
Credential-harvest domain	argosyfreight-sso-verify.example
Attacker source IP	198.51.100.231
Malicious inbox rule name	"." (single period)
Fraudulent bank — name	Meridian Pacific Trust
Fraudulent bank — account (last 4)	9902

Writing It Up

This is what a completed incident summary for INC-2026-0814 looks like — the deliverable this whole investigation was building toward.

Incident Summary Report

INC-2026-0814 · Business Email Compromise

Executive Summary

Priya Raman's mailbox (priya.raman@argosyfreight.example) was compromised via a credential-phishing email on Aug 12, 2026. The attacker authenticated using legacy IMAP4 without an MFA challenge, created a concealment inbox rule, and on Aug 14 used the account to send a fraudulent bank-detail-change request for a $184,500 vendor payment. The receiving client's AP team identified the mismatched bank details before releasing funds. No confirmed financial loss as of this report.

Root Cause

Successful credential phishing, combined with legacy authentication (IMAP4) that allowed sign-in without satisfying the tenant's MFA policy.

Impact

No funds released. Exposure of internal AP correspondence to the attacker for approximately two days. Reputational/trust impact with the affected vendor contact pending outreach.

Remediation Actions

Reset Priya Raman's credentials and revoke all active sessions and refresh tokens.
Force MFA re-registration before the account can authenticate again.
Disable legacy authentication protocols (IMAP4, POP3, legacy SMTP AUTH) tenant-wide.
Remove the malicious inbox rule and audit all mailboxes for similarly-named rules.
Block identified IOCs at the email gateway and firewall.
Contact the client's AP team directly by phone to confirm no funds were released and the fraud email should be disregarded.
Enable Conditional Access policies to block sign-ins from unexpected locations / impossible travel.
Run BEC-specific awareness training for AP and Finance staff, focused on out-of-band verification for any payment-detail change.

Why This Matters

Why this matters: BEC doesn't need malware, and it doesn't need to beat SPF, DKIM, or DMARC — it needs one set of stolen credentials and a security control gap (here, legacy auth bypassing MFA) to walk straight through. It's consistently one of the costliest categories of cybercrime by dollar loss precisely because it looks so unremarkable in the logs until someone reconstructs the whole chain, the way you just did.

How to Detect & Protect

Disable legacy authentication protocols (IMAP4, POP3, legacy SMTP AUTH) tenant-wide — they're a well-known way to bypass modern MFA enforcement entirely.
Alert on new inbox rules that move, delete, or mark-as-read messages matching financial keywords — this is one of the highest-signal BEC indicators available and is rarely monitored by default.
Require out-of-band verification for any bank-detail or payment-instruction change — a phone call to a number already on file, never one supplied in the email itself.
Enable Conditional Access / impossible-travel alerting so a sign-in from an unexpected country triggers review, even when it technically succeeds.
Treat "the account is genuine" as the start of an investigation, not the end — reconstruct the full timeline (sign-ins, rules, sent mail) rather than judging a single message in isolation.
Train Finance/AP staff specifically on BEC, separate from general phishing awareness — the psychological pressure and business context are what make it work.