“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:
- Force password change on the compromised account.
- Terminate every active session via the admin console — invalidates the attacker's cookie even if they had one.
- Remove the two attacker-created block rules so internal email flowed again.
- Review sent mail, identify every outbound message from the attacker, phone the recipient firm directly and tell them to disregard the fraudulent wire instructions.
- 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.