Business email compromise — the money left this morning

Somebody in finance paid an invoice. The bank details on it were not your supplier's, and nobody noticed until the supplier asked where their money was.

The first instinct is to chase the payment, and that instinct is correct — it is time-critical in a way nothing else here is, and it should start immediately, with your bank, by phone, while somebody else reads the rest of this page.

But a business email compromise is a mailbox intrusion first and a payment fraud second, and the money is where the first day goes. The intrusion is what allowed the fraud, it can still be live while the recovery calls are being made, and it is not necessarily confined to the one mailbox everybody is looking at.

Two clocks, running at once

The money. Call the bank now, on the phone, and follow it with whatever written instruction they ask for. Your bank's fraud team, not your relationship manager. Have the transaction reference, the amount, the beneficiary account and the time of the instruction in front of you before you dial. This work belongs to finance and it does not need anybody technical.

Ask them what is possible in your specific case, and ask at once rather than after the internal investigation. Whatever they tell you, write down who you spoke to and when.

The mailbox. Everything else on this page. It runs in parallel, starting now, with different people.

The first hour on the mailbox

Do not just change the password. On its own it does very little. A session token issued before the reset can survive it, an app password or a legacy authentication path may not be affected by it, and an OAuth grant the attacker consented to keeps working regardless. Reset the credential and revoke the sessions, tokens and grants — that combination is what actually ends the access.

Look for the rules before you look at anything else. The artefact to look for is a mailbox rule the user did not create: forwarding to an external address, moving anything containing "invoice" or "payment" to a folder nobody reads, or deleting replies from a specific counterparty. That rule is what let the conversation continue without the real participants noticing, and it is what dates the intrusion. Record it — a screenshot, the rule's terms, and when it was created — before deleting it. It is evidence, and it is the thing everybody deletes first.

Assume it is not one mailbox. Access to one account can be used to reach others, internally and at counterparties. Check the sign-in records for every account with financial authority, not only the one that sent the payment instruction.

Preserve the mail. The compromised mailbox, the thread, the headers, and the audit records around it. The thread as it appears in the mailbox may have been edited by the rules above; the headers and the platform's own audit log have not.

Tell the counterparty, by a channel that is not email. Phone them. If your mailbox is compromised, the attacker may be reading the message in which you warn them, and if theirs is compromised, your email warning arrives to the attacker instead. This is also the step that stops a second payment: the same instruction gets re-sent as a "correction".

Then work out which side was actually compromised

This matters more than it seems, and getting it wrong sends the whole investigation in the wrong direction.

There are three shapes, and they are told apart from the headers and the audit records, not from the thread as displayed:

• Your mailbox. The attacker is inside your account, reading and sending as you. Your audit records show sessions you do not recognise.
• Their mailbox. The attacker is inside the supplier's account. The mail genuinely came from their domain and your records show nothing unusual — because on your side nothing happened.
• Neither. A lookalike domain, a display-name spoof, or a reply-to substitution. Nobody was breached; somebody was deceived. The headers show a sender that is not the domain it appears to be.

The remediation is completely different in each case, and so is the answer to the question your counterparty, your insurer and your auditor will all ask, which is whose systems failed.

What you owe CERT-In, and when

A business email compromise is on the six-hour list.

Annexure I to the CERT-In Directions of 28 April 2022 lists twenty types of cyber security incident that must be reported, and item (vii) is "Identity Theft, spoofing and phishing attacks". Where the mailbox itself was accessed, item (iii), "Unauthorised access of IT systems/data", describes it too — and where mail or attachments were taken, items (xi) Data Breach and (xii) Data Leak apply. Tick every one that fits.

Direction (ii) requires any service provider, intermediary, data centre, body corporate and Government organisation to report cyber incidents as mentioned in Annexure I to CERT-In "within 6 hours of noticing such incidents or being brought to notice about such incidents". On a BEC the trigger is often the second limb: the supplier's call is the moment you were brought to notice, not the moment you finished confirming it internally.

CERT-In provides in terms for filing on what you hold at the time. FAQ Q 30: "The entities may provide information to the extent available at the time of reporting. Additional information may be reported later within reasonable time to CERT-In." File on what you have. Then assign the filing to somebody who is not on the bank calls, because that is the task that slips.

The records that answer it

Direction (iv) requires logs of all ICT systems to be enabled and maintained securely for a rolling period of 180 days, within the Indian jurisdiction. On a BEC the relevant ones are the mail platform's own: sign-in records, mailbox audit entries, rule creation and modification events, and message trace.

Two things about them are worth knowing before you need them. Retention and depth for these record types are platform settings, and the deeper auditing is generally something somebody has to turn on beforehand — check yours rather than assuming. And the intrusion can be weeks older than the payment — the attacker reads the correspondence until an invoice of the right size appears, so the sign-in that matters is not the one nearest the fraud.

Pull them now, before any retention window rolls past the start.

What we do on these

Business Email Compromise is one of the eight incident types we handle. In practice that means containment first — "isolating compromised systems, revoking compromised credentials, blocking malicious IPs and domains" — and log collection "from endpoints, servers, network devices, cloud services, email platforms, and security tools", which is where the mailbox audit records in the section above come from.

The mechanics of how a Microsoft 365 mailbox is taken over, in detail, are set out separately in our Microsoft 365 attack anatomy, which is ungated and does not ask for an email address.

The short version

Two clocks, two teams.

Finance, now: call the bank's fraud team by phone with the transaction details to hand, and ask them what is possible in your case.

Everyone else, now:

• Reset the credential and revoke sessions, tokens and OAuth grants.
• Find the mailbox rule, record it, then remove it.
• Check every account with financial authority, not just the one that paid.
• Preserve the mail, the headers and the platform audit records.
• Warn the counterparty by phone.
• Establish which side was compromised, from headers and audit records.
• File with CERT-In within six hours of being brought to notice — Annexure I item (vii), and items (iii), (xi) and (xii) where they fit.
• Pull the mail platform logs before the retention window moves.

If you want somebody on this with you, we respond 24/7 — +91 22 4164 2220.