Between 2013 and 2015, a Lithuanian citizen named Evaldas Rimasauskas persuaded finance departments at Facebook and Google to wire him roughly $121 million across dozens of transactions. He did not breach either company's network. He did not compromise a single credential. He registered a lookalike company, printed matching stationery, and sent invoices. Two of the most sophisticated engineering organisations on earth paid every one of them.
The US Department of Justice announced Rimasauskas's guilty plea on March 20, 2019 (retrieved 2026-09-03). He was sentenced on December 19, 2019 to five years imprisonment and ordered to forfeit approximately $49.7 million ( DOJ, December 19 2019, retrieved 2026-09-03).
The scheme is the canonical business email compromise (BEC) case study for one reason: it describes, in detail, the exact controls a mid-sized organisation can put in place to prevent the same thing happening to them. Both Facebook and Google recovered most of the funds. Every organisation between them and a family-run business absolutely will not.
The scheme in one paragraph
Rimasauskas registered a company in Latvia and Cyprus using the name of a real hardware supplier — Quanta Computer Inc., a Taiwanese OEM that legitimately supplied both Facebook and Google with servers and data-center hardware. He opened bank accounts in the fake company's name. He sent forged invoices from an email domain designed to look like Quanta's. Finance staff at Facebook and Google approved and paid the invoices. Money went to Rimasauskas's accounts, was moved through a chain of intermediary accounts across Latvia, Cyprus, Slovakia, Lithuania, Hungary, and Hong Kong, and then vanished into cash and further layers.
The target: Quanta Computer
Quanta Computer is a real Taiwanese firm. It is one of the world's largest contract manufacturers of servers and notebook computers, and both Facebook and Google are real customers. Rimasauskas did not invent the vendor relationship — he inserted himself into an existing one. That is the leverage that separates this case from generic phishing. A finance team that receives an invoice from a vendor it has never worked with will scrutinize it. A finance team that receives an invoice from a vendor it has been paying for eighteen months will approve it.
Quanta itself lost nothing. Its name was used without its knowledge. The company assisted law enforcement once contacted. That is one of the reasons corporate victims of BEC schemes often stay quiet — the reputational damage of "our name was used to steal $121M from our customers" is real, even if the company is a bystander.
The mechanic — a lookalike company, not just a lookalike domain
Most BEC coverage focuses on the lookalike domain. Rimasauskas's scheme layered several controls at once, which is why it survived scrutiny:
- A legally-registered fake company. Rimasauskas incorporated an entity using Quanta's name in Latvia. Bank due diligence checks that turn up "yes, this is a legitimately registered company" satisfied basic KYC. The name matched the real vendor.
- A lookalike email domain. The domain used in invoices matched Quanta's real one closely enough that finance staff scanning email did not spot the difference. See what is typosquatting for the six families of lookalike that show up in this class of case.
- Physical documentation. Contracts, invoices, and letterheads matched the real Quanta's format. Rimasauskas also faked the signatures of Quanta executives and obtained forged corporate seals per the DOJ's charging documents (see the DOJ press releases below).
- A working bank account chain. Wires from Facebook and Google landed in Latvia and Cyprus, then moved rapidly through five countries. Every transfer was individually below the threshold that would have triggered automatic red flags on the sending side.
Any one of these controls is defeatable in isolation. Together they satisfied every check that finance departments and banks routinely run. The gap was that nobody was running the one check that would have caught it — comparing the sender's DNS-visible identity against the real vendor's.
The timeline: 2013 to 2019
- 2013 — Rimasauskas registers the fake Quanta entities in Latvia and Cyprus, sets up bank accounts, and begins sending the first forged invoices.
- 2013–2015 — Invoices are approved and paid by finance staff at Facebook and Google over roughly two years. Funds are moved through a chain of accounts across Latvia, Cyprus, Slovakia, Lithuania, Hungary, and Hong Kong.
- 2015 (approximately) — Discrepancies surface during internal audit at one of the two companies. Both begin coordinated recovery efforts and refer the matter to federal law enforcement.
- March 2017 — Rimasauskas is arrested in Lithuania on a US extradition request.
- August 2017 — Extradited to the Southern District of New York.
- March 20, 2019 — Rimasauskas pleads guilty to one count of wire fraud, one count of aggravated identity theft, and money-laundering charges ( DOJ, March 20 2019, retrieved 2026-09-03).
- December 19, 2019 — Sentenced to 5 years in federal prison, 2 years of supervised release, and $49.7M forfeiture ( DOJ, December 19 2019, retrieved 2026-09-03).
Two years to run the scheme. Four years from arrest to sentencing. The recovery process for the two victim companies took several years and did not fully close until 2020.
Why the scheme worked for two years
Every post-mortem of this class of BEC lands on the same four causes:
- Existing vendor relationships bypass scrutiny. Payment approval workflows are tuned to catch new vendor onboarding. Once a vendor is in the accounts payable system, invoice payments run on a lower-scrutiny path. Rimasauskas exploited the seam between "new-vendor" checks and "recurring-vendor" checks.
- Email is trusted as a channel by default. An invoice PDF arriving in the shared finance inbox from an address that visually matches the vendor's domain is treated as authoritative. Nobody phone-confirms an invoice they've paid ten times before.
- DMARC was not universally enforced in 2013–2015. Both Facebook and Google published DMARC records for their own domains but received email from a third-party vendor domain (Quanta's real one). A DMARC monitor on the vendor's domain — the control that would have flagged unaligned mail claiming to be from the vendor — was not a standard part of AP workflows anywhere in 2015. It arguably is still not.
- Cross-border wires clear before cross-border investigation begins. Money moved from a US bank to a Latvian bank clears in a day. Recovering it requires legal action in Latvia. By the time internal audit at either victim noticed, the funds had cleared two further layers.
What the DOJ's charging documents underline is how mundane the operational side was: no zero-days, no credential theft, no insider help. Just a lookalike, a wire request, and finance staff doing what their process asked of them.
What would have blocked it — three controls
Every serious BEC post-mortem — DOJ filings, IC3 recommendations, and vendor case studies — lands on the same three-control combination:
- DMARC at
p=reject, withsp=reject, on every domain the org corresponds with. For the sender side, this is table stakes; see what is DMARC and the DMARC enforcement gap analysis. For the receiver side — the side that matters here — the control is a DMARC-aware inbound filter that quarantines mail failing the sender's published policy. If Quanta had been atp=rejectand both victims had a DMARC-aware inbound filter, the forged-invoice email either would not have delivered or would have landed in a quarantine folder flagged as spoofed. - Lookalike-domain monitoring on every vendor of record. A finance ops team that receives a monthly report of newly-registered lookalikes of its top-100 vendor domains catches new impersonation before the first invoice arrives. Zscaler's ThreatLabz data suggests roughly 200 new lookalikes per major brand per six months — a real volume, but one that a continuous monitor sees in aggregate rather than as isolated one-offs. See the typosquatting deep-dive for the six families and the tools that generate them.
- Out-of-band verification for any payment change. The single simplest control that would have stopped Rimasauskas: a mandatory phone call to a pre-verified vendor contact whenever an invoice arrives with a new bank account or a new wire routing. Every one of Rimasauskas's invoices routed to a new bank account. Every one of them could have been caught by a rule with zero technology cost.
What CFOs should run this quarter
Six controls, in priority order, that a mid-sized organisation can put in place inside 90 days without new tooling budget.
- Audit your top-25 vendors' DMARC posture. Any vendor at
p=noneor with no DMARC record is a vendor whose brand can be spoofed at zero cost. Escalate as a vendor-risk finding. - Turn on DMARC-aware inbound filtering. Every major mailbox provider (Google Workspace, Microsoft 365) supports honouring the sender's DMARC policy. It is off by default in some configurations. Turn it on.
- Publish
p=reject; sp=reject;on your own domain. For the receiver side of your customers' AP workflows. See the 30-day p=none → p=reject path in the DMARC enforcement gap piece. - Add a "new-bank-account" trigger to AP workflow. Any invoice whose payment routing differs from the last invoice from the same vendor requires an out-of-band phone confirmation before payment. No exceptions. This is a policy change, not a tooling change.
- Deploy lookalike-domain monitoring on your brand and top vendors. Continuous generation and DNS-check of typosquats. Escalate any new-registration hit that resolves to a live mail server (MX present) as a high-priority finding.
- Practice the recovery process. Nobody thinks about wire recall until an actual incident. Have the phone number for your bank's fraud line and the FBI IC3 report URL saved in a shared runbook. Recovery windows for cross-border wires are measured in hours, not days.
FAQ
How did Rimasauskas get caught?
Internal audit at one of the two victim companies flagged discrepancies in the mid-2010s; both companies coordinated with US federal investigators, who traced the funds through the intermediary bank accounts. Rimasauskas was arrested in Lithuania in March 2017 on a US extradition request. The DOJ press releases from March and December 2019 detail the plea and sentencing.
Did Facebook and Google get their money back?
Substantially, yes. Both companies recovered the majority of the funds through a combination of asset forfeiture ($49.7M ordered forfeit at sentencing), bank recall of wires still in flight, and civil recovery from intermediary accounts. Neither company has published a final net-loss figure. The point of the case is not the recovery — it is that the scheme ran undetected for two years and got over $121M out before internal controls caught it.
What is the difference between BEC and phishing?
Phishing is a broad category — any social-engineering attack conducted over email. BEC (business email compromise) is the subset targeting payment workflows: fake invoices, fake payroll change requests, fake wire instructions, fake vendor-account-update requests. BEC is more lucrative per incident than commodity phishing, which is why the FBI IC3 tracks it separately in its annual report.
Would DMARC at p=reject alone have stopped this?
Alone, no. DMARC at p=reject only helps if the receiving inbound filter actually honours the sender's published policy. And it only protects against direct domain-spoofing — Rimasauskas registered a lookalike domain, not the real vendor's domain. DMARC would have blocked one attack path (exact spoof); the lookalike-monitoring control would have blocked the other (visual impersonation). Both controls in combination close the gap.
How common is $100M+ BEC?
Rare at the very top end. But BEC as a category is enormous. The FBI's Internet Crime Complaint Center attributed approximately $2.77 billion in reported US losses to BEC in 2024 alone — see the IC3 2024 BEC deep-dive. Most incidents are in the $50K–$5M range; the $121M outlier at the top of the distribution is what makes Rimasauskas famous, not what makes BEC dangerous.
Who is legally liable when a BEC succeeds?
Complicated and jurisdiction-dependent. The victim organisation typically bears the immediate loss. Cyber insurance policies may cover a portion under a "social engineering fraud" endorsement (often capped at $250K–$1M — well below typical BEC losses). Recovery from the perpetrator is exceptional. Recovery from the bank that processed the fraudulent wire is unusual unless the bank materially violated its own AML procedures. The realistic financial planning assumption is that a BEC loss is unrecoverable.