Business Email Compromise Response Has a Different Clock

The call arrives from finance at 2:47 PM on a Thursday. They want to know if email might have been compromised. Someone wired a payment to what turned out to be an attacker-controlled account. The vendor called to follow up on an overdue invoice, which is how the finance team discovered a payment had already gone somewhere else.

The wire went out that morning. It has been nine hours. If there is any chance of recovering the funds, the window is closing faster than the security team realizes.

This is business email compromise, and it does not look like a standard security incident until the money is already gone. The response is different from every other incident type your team has trained for, in one specific and consequential way: the urgent action is not technical.

What BEC Actually Is

Business email compromise is a category of attack built around manipulating financial transactions through compromised or impersonated email. The attacker either gains access to a legitimate email account (usually through phishing or credential theft) or creates a convincing lookalike domain. From there, they watch.

The interception phase is where BEC gets expensive. The attacker monitors legitimate payment communication between parties until they identify an ongoing transaction with a specific amount and timeline. Then they intercept or impersonate at the right moment, substituting their own bank account information for the legitimate recipient's. The vendor does not know they were impersonated. The payer does not know the account details changed. The money moves.

Sometimes the attack goes deeper. A compromised mailbox with months of monitoring gives the attacker enough context to initiate new fraudulent payment requests that look completely legitimate: the right vendor names, the right invoice formats, the right communication style. These attacks are harder to detect because nothing about the request looks wrong until someone checks whether the payment actually arrived.

The Clock That Overrides Everything Else

In ransomware, you have hours to days of meaningful response time before the situation substantially worsens. In a BEC incident, you have a shorter and less forgiving window to recover funds before they are gone permanently.

Domestic wire transfers in the United States can sometimes be recalled through the sending bank if you act within 24 to 72 hours and the funds have not yet been moved out of the receiving account. International wires move faster and the window is shorter. Funds routed through accounts that immediately forward to crypto exchanges or overseas accounts are, in most cases, unrecoverable regardless of how quickly you act.

The first call from the incident response team should not be to start a forensic investigation. It should be to the sending bank, telling them to attempt a recall or hold on the wire while you file a report with the FBI's Internet Crime Complaint Center. The IC3 has a Financial Fraud Kill Chain program specifically for this scenario. Banks coordinate through it. Speed matters more than a complete picture of what happened.

This is the reversal that catches most technical incident responders off guard. In every other incident type, you investigate before you act. In BEC, you act on incomplete information to preserve the financial recovery window, and you investigate in parallel.

What the Investigation Actually Looks Like

While the financial recovery track runs, the technical investigation answers a different set of questions than a typical compromise.

The inbox is the crime scene. Attackers who maintain persistent access to a compromised mailbox typically create forwarding rules, inbox filters, or folder redirects to intercept incoming messages and hide evidence of the conversation. Finding and removing these is the immediate step after locking the compromised account. Rules that redirect messages matching certain subjects or senders to a folder the legitimate user never sees, or that automatically delete messages from specific senders, are the residue of the monitoring phase.

OAuth token grants are a persistent access path that survives password resets. An attacker who gained access to a Microsoft 365 account may have authorized a third-party application with mail read permissions. Resetting the password does not revoke those tokens. Check for unfamiliar OAuth app authorizations and revoke them explicitly.

Authentication logs tell you when the unauthorized access began, what IP addresses were used, and whether the attacker was only reading or also sending. BEC attackers frequently access mailboxes from residential proxy services or compromised third-party hosts specifically to blend in with normal user authentication patterns. Geographic anomalies are useful signals, but do not assume an absence of anomalies means an absence of access.

The scope of what the attacker saw matters as much as what they sent. A mailbox monitored for weeks or months may have surfaced contract terms, personnel information, payment schedules, and communication patterns that give the attacker material for future attacks against this organization or against its vendors and partners.

Why BEC Is Hard to Stop at Detection

BEC creates a detection problem that most security tooling is not designed to solve. The attacker communicates through legitimate infrastructure, often a legitimately compromised account with a real email address and a valid TLS certificate. There is no malware. There is no command-and-control traffic. There is no anomalous network activity. The only signal is unusual email content or account behavior, and by the time those signals are visible, the transaction may already be complete.

The controls that actually reduce BEC risk are procedural, not technical. Out-of-band verification for any payment instruction that arrives by email, regardless of how legitimate it looks. A specific, pre-established phone number for vendor payment confirmation that is not sourced from the email thread being verified. Change-of-banking-information requests treated as high-risk events requiring voice confirmation with a known contact, not the number provided in the email.

These processes feel slow and awkward until a fraudulent wire attempt hits one and stops. Most organizations discover they do not have them when they are on the phone with their bank trying to recall a wire.

The Structural Reality

BEC is one of the most financially damaging categories of cybercrime specifically because it does not look like a cybersecurity event until it is already a financial one. The technical team's job in the response is real and important. It is just not first.

Build the financial recovery track into your incident response runbook before you need it. Know which bank contact to call and what information they need to initiate a recall. Know how to file with the IC3 before it is 3 AM and you are trying to remember the correct URL. Practice the out-of-band verification controls until they are automatic, because the moment that tests them will not come with advance notice.

The wire is already moving. Whether it comes back depends on whether your organization had a plan for the first two hours, worked out on a calm Tuesday rather than a panicked Thursday afternoon.