FACGFACG
Anatomy of a modern business email compromise attack
All insights
Incident response March 2026 11 min read

Anatomy of a modern business email compromise attack

Step by step, with the actual artefacts and timestamps from a real (anonymised) incident we contained for a UK property client last quarter. Plus the controls that would have stopped it on day one.

By FACG incident response team

This is a real incident that happened to a UK property client in Q1 2026. The client has agreed to anonymisation. Names, IP addresses and dollar amounts have been changed. Everything else is verbatim from the timeline.

Day -7: reconnaissance

An attacker harvests the LinkedIn profiles of the senior leadership team at the client, identifies the CFO and a property fund manager who handles wire transfers, and notes that the fund manager has just posted about an upcoming international conference. The attacker registers the look-alike domain c1ient-property-group.com (with a digit-1 instead of an L).

Day -3: phishing payload

The fund manager receives a Microsoft 365 'shared document' email from what appears to be a known external counterparty (the email actually comes from a compromised mailbox at that counterparty, who themselves were breached two weeks earlier). The link goes to an Adversary-in-the-Middle (AITM) phishing kit (EvilProxy) hosted on a temporarily-leased domain. The fund manager enters credentials and approves the MFA push notification.

Day -3 + 4 minutes: token theft and persistence

The AITM kit harvests the session token. The attacker logs in to Outlook on the web from a residential proxy in the UK (geolocation matches the user, not flagged) and immediately:

  • Creates an Outlook rule to auto-forward any email containing 'invoice', 'payment' or 'wire' to an external address and mark it as read
  • Adds a permanent application consent grant to a malicious app named 'Outlook Sync', granting Mail.Read permission
  • Reads the last 30 days of conversations with the CFO and three counterparties

Day 0: the attack lands

The attacker drafts an email from the fund manager's account to the CFO referencing a real, in-flight property acquisition with the correct names, deal reference and amount. They request that the upcoming GBP 480,000 deposit be sent to an updated bank account, citing 'last-minute changes from the seller's solicitor'. They include a forged confirmation letter on the seller's solicitor's letterhead, generated using publicly-available branding.

The CFO replies asking for a quick call. The attacker, anticipating this, replies that the fund manager is in a meeting at the conference and will be on a flight in 20 minutes (the conference and flight are real and verifiable). The CFO authorises the payment.

Day +1: detection

The fund manager returns to the office, opens Outlook and notices that emails about a recent invoice are missing from the inbox. The IT team investigates the inbox rule, recognises the pattern and calls FACG. By 11:00 we are engaged. By 13:00 the bank has been called and the fraudulent payment has been recalled (it was still settling).

What the attacker did right

  1. Targeted reconnaissance: real names, real deal, real timing window
  2. AITM kit: bypassed MFA (push approval did not protect the session token)
  3. Persistence at two layers: inbox rule plus app consent grant
  4. Plausible cover story: aligned with public events the user was actually attending

What would have stopped it

  • Phishing-resistant MFA (FIDO2 keys or device-bound passkeys) for privileged finance roles: the AITM kit cannot replay a FIDO2 challenge
  • App consent governance: blocking user consent to third-party apps with Mail.Read, requiring admin consent
  • Outbound auto-forward block: a Conditional Access or Exchange Online policy blocking auto-forwarding to external recipients
  • Out-of-band verification for bank-detail changes: a documented requirement to re-verify any bank-detail change via a known phone number, never via email
  • Sign-in risk policy at 'medium' triggers MFA: the session would have been challenged when accessed from a different network

What we recommend you do this week

Open Entra ID, go to Enterprise Applications and User Settings, and turn off 'Users can consent to apps accessing company data on their behalf' for non-verified publishers. Open Exchange admin and add a transport rule that blocks auto-forwarding to external domains. Review your top 10 finance roles and put them on phishing-resistant MFA. Total effort: about 2 hours. Total impact: it would have stopped this attack.

Have a question on this?

Book a 30 minute discovery call. We answer questions in plain English, with or without a follow-on engagement.