# BEC Wire Fraud at a Title Company: How We Stopped a High-Six-Figure Loss URL: https://limehawk.io/reports/bec-wire-fraud-incident-response Published: 2025-12-23 Author: Corey Watson, Managing Member Topic: Security Read time: 6 min An attacker got into a closer's inbox and sent fraudulent wire instructions to the other side of a real estate deal. We contained it in under three hours. - Time to contain: ~2.5 hrs - Funds at risk: high six fig. - Funds lost: $0 - Root cause: inherited optional 2SV > **TL;DR** Attacker took over a title closer's Google Workspace inbox on a tenant we inherited from a prior admin: users had 2SV enrolled, but tenant enforcement was still optional, so a clean-looking login got through on password alone. 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. Same day we locked the account, we flipped org-wide 2SV enforcement and started the rest of our managed security baseline — the controls that should have been on before anyone handed us the keys. > 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](/industries/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: 1. Force password change on the compromised account. 2. Terminate every active session via the admin console. This 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 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. ## Key takeaways - 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. - 2SV enrolled is not 2SV enforced. Google only challenges on suspicious signals unless tenant enforcement is on — check that toggle on every Workspace you inherit, day one. - 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. - Every wire-instruction change should be verified out-of-band, by phone, to a number on file, before a penny moves. - Credential-only compromises can be fully remediated by password change plus session invalidation, but only if you're sure nothing else was touched. - Inherited tenants are not 'our' baseline until we apply it. Prior-admin optional 2SV is a takeover finding, not a managed-service default.