“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:47 Attacker sends benign-looking email referencing the pending closing, likely a probe to confirm the inbox is live.
- 09:04 Fraudulent wire instructions sent to the closing agent on the other side of the deal.
- 11:02 Attacker creates mail filters blocking incoming email from the firm's funding desk and another closer who would have spotted the fraud.
- 11:30 Legitimate user regains access; password forced change.
- 12:03 Secondary 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 on a Google Workspace tenant we inherited with 2-Step Verification left optional by the prior admin.
This was not Limehawk’s security posture. The firm had stood up Workspace under a previous IT shop: users could enroll in 2SV, and some had, but the admin console never flipped org-wide enforcement. Under our managed baseline that toggle is on for every tenant we own — funding staff get hardware keys on top. We took the account over mid-stream; security-baseline cutover on this Workspace was not complete when the attacker walked in on password alone.
How the gap works technically: Google only challenges for 2SV when the sign-in looks suspicious (new device, impossible travel, known-bad IP) unless tenant enforcement is on. The attacker’s session did not trip 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 at the tenant. Day-one job on any inherited Workspace: verify Security → 2SV → Enforcement is ON, not optional.
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. This 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 plus a prior-admin tenant left on optional 2SV is a single-factor account in practice, 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.
Containment closed the incident. The same afternoon we finished what takeover should have finished first — applying Limehawk’s managed security baseline to this Workspace, not leaving the inherited optional-2SV config in place:
- 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
That is day-one baseline on every tenant we fully own. This one still had prior-admin settings when the attacker got lucky. It does not anymore.
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. Org-wide 2SV enforcement went on the same day; hardware-key rollout for funding staff finished over the following week. Inherited optional 2SV is closed — this tenant runs on our baseline now.