BEC Wire Fraud at a Title Company: How We Stopped a High-Six-Figure Loss

LIMEHAWK - Managed IT

Home>Incident Reports>BEC Wire Fraud at a Title Company: How We Stopped a High-Six-Figure Loss

Time to contain

~2.5 hrs

Funds at risk

high six fig.

Funds lost

Root cause

MFA not enforced

★ TL;DR

Attacker took over a title closer's Google Workspace inbox via password-only login (2SV enrolled but not enforced). Sent fraudulent wire instructions on a real pending closing, then created mail-block rules to hide the thread from coworkers. We forced a password change, killed sessions, and — most importantly — phoned the counterparty out-of-band before the wire moved. Zero loss.

People are sending emails from her actual account changing wiring instructions, we need to shut down whoever it is.
— Title company owner, on the call

Incident

The call came in from the managing owner of a title and escrow company. One of his closers had lost control of her inbox — not a forgotten password, an active takeover.

Title companies are a prime BEC target. Every closing involves a large wire between parties coordinated by email. Own the closer's inbox on funding day and you own the wire. This attacker had done their homework: picked a real pending transaction, copied the closer's tone, and sent updated wire instructions to the opposite-side firm. A high-six-figure wire. The window to stop it was measured in hours.

Timeline

08:47Attacker sends benign-looking email referencing the pending closing — likely a probe to confirm the inbox is live.

09:04Fraudulent wire instructions sent to the closing agent on the other side of the deal.

11:02Attacker creates mail filters blocking incoming email from the firm's funding desk and another closer who would have spotted the fraud.

11:30Legitimate user regains access; password forced change.

12:03Secondary password change forced via backup code to kill any lingering session.

The inbox-blocking rules are the part that matters operationally. BEC attackers don't send the fraud email and leave — they stay logged in, watching. When the counterparty replies with "confirming, are these new wire instructions real?" the attacker wants to intercept that reply and answer it themselves, while keeping coworkers from ever seeing the thread. Blocking the funding desk was how they tried to keep the scheme alive long enough for the wire to hit.

Investigation

Point of entry: weak password plus unenforced MFA.

The account had 2-step verification enrolled but not enforced at the tenant level. Google Workspace only challenges for 2SV when the sign-in looks suspicious — new device, impossible travel, known-bad IP. The attacker's session didn't trip any of those heuristics, so they authenticated with the password alone and never saw a challenge. 2SV "on" for the user is not the same as 2SV enforced in the admin console.

Login activity traced to an IP in West Africa — direct residential connection, no VPN, no Tor. Typical for this class of attacker. Not hiding, just fast.

What we ruled out (technical investigation)

We ruled out the worse possibilities one by one:

- no malicious OAuth apps connected to the account
- no app-specific passwords created
- no email forwarding rules (they're usually the first thing an attacker sets)
- no mail filters other than the two "block sender" rules
- no malware or persistence on the endpoint — the laptop was clean

Credential-only compromise. No backdoor, no device implant, no session-token theft. Change the password, kill the sessions, attacker is locked out.

Response

Containment in order:

1. Force password change on the compromised account.
2. Terminate every active session via the admin console — invalidates the attacker's cookie even if they had one.
3. Remove the two attacker-created block rules so internal email flowed again.
4. Review sent mail, identify every outbound message from the attacker, phone the recipient firm directly and tell them to disregard the fraudulent wire instructions.
5. Enroll the user in a password manager and seed a new high-entropy password.

The call to the opposite-side closer was the highest-value action of the morning. Out-of-band, by phone, with the correct wire details — that's what stopped the loss.

Why this worked (and why it almost didn't)

The fix was mechanically simple because the compromise was mechanically simple. Password + no enforced MFA is a single-factor account, and single-factor accounts fall to credential stuffing and phishing constantly. We caught this fast because the owner called us immediately instead of trying to sort it out internally. Thirty more minutes and the wire would have been sent.

Structural fixes we rolled out across the client's environment afterward:

- 2-Step Verification enforced org-wide (Security > 2SV > Enforcement: ON)
- hardware security keys mandated for funding staff
- context-aware access blocking sign-ins from high-risk geographies
- Advanced Protection enabled for executives
- written rule: any wire-instruction change verified by phone to a number on file before funds move

Outcome

The attacker lost the account at 11:30. The wire was never sent — the counterparty had been warned. No funds lost. By the end of the afternoon the account was clean and the firm was back to normal business. MFA enforcement and hardware-key rollout went in over the following week.

Key takeaways

Takeaway

BEC attackers don't send one email and leave — they stay logged in and manipulate the inbox in real time. Look for block rules and filters during every compromise investigation.

Takeaway

2SV enrolled is not 2SV enforced. Google only challenges on suspicious signals, so a clean-looking login gets through on password alone.

Takeaway

The phone call to the counterparty is the single most valuable thing you can do in the first hour of a BEC — email them and the attacker can still intercept.

Takeaway

Every wire-instruction change should be verified out-of-band, by phone, to a number on file, before a penny moves.

Takeaway

Credential-only compromises can be fully remediated by password change plus session invalidation — but only if you're sure nothing else was touched.

Need help with something like this? Contact us

• Getting Verification Codes You Didn't Request? How to Tell Spam From Account Compromise (Security)

• Finding Your BitLocker Recovery Key After a Windows Update Breaks Boot (Security)

• Laptop Stolen at Airport: Emergency Remote Wipe via RMM (Security)