Phishing Case Study — How One Man Phished $121 Million from Google and Facebook
Between 2013 and 2015, a man in Lithuania sent invoices to Google and Facebook. The invoices were fake. The company that "issued" them was fake. The contracts, the corporate stamps, the executive signatures attached to them — all forged. And yet, over roughly two years, the accounts-payable teams of the two most technologically sophisticated companies on Earth wired him more than $120 million.
No malware was deployed. No firewall was breached. No zero-day exploit was purchased on the dark web. The entire attack ran on email, PDFs, and an understanding of how big companies pay their bills.
This is the definitive case study in business email compromise (BEC) — the category of phishing that the FBI consistently ranks among the most financially damaging cybercrimes in the world. If you are building a career in cyber security, this case is the cleanest possible demonstration of a truth the industry keeps re-learning: attackers don't hack machines when they can hack processes.
The Target: Two of the World's Most Sophisticated Companies
By 2013, Google and Facebook were spending billions of dollars a year on data-center hardware. One of their real, legitimate suppliers was Quanta Computer — a Taiwan-based manufacturer that builds servers and hardware for many of the world's largest technology companies.
That supplier relationship had three properties that made it the perfect disguise:
- High transaction values. Multi-million-dollar invoices from Quanta were normal, not suspicious.
- High frequency. Payments flowed regularly, so one more invoice raised no eyebrows.
- Distance. The vendor sat on the other side of the world, communicating mostly by email — nobody expected to meet their counterpart in person.
Evaldas Rimasauskas, a Lithuanian national in his 40s, understood all three. He never attacked Google's or Facebook's infrastructure. He attacked the relationship.
The Setup: A Fake Quanta Computer
In 2013, Rimasauskas incorporated a company in Latvia with the same name as the real Taiwanese supplier — Quanta Computer. He then opened bank accounts in the company's name in Latvia and Cyprus.
From the outside, everything looked plausible. A company called Quanta Computer was emailing invoices, and a company called Quanta Computer was receiving payments. The name on the wire matched the name on the invoice. The paperwork agreed with itself.

With the corporate shell in place, the emails began. Rimasauskas and his associates sent phishing emails to specific employees at Google and Facebook — the people who regularly transacted multimillion-dollar deals with the real Quanta. The emails were dressed to pass inspection:
- Forged invoices for goods and services the real Quanta had genuinely provided
- Forged contracts and letters that appeared to be signed by executives and agents of the two companies
- Fake corporate stamps embossed on the documents, mimicking the formality of cross-border B2B paperwork
- Spoofed sender identities that appeared to come from the legitimate vendor's staff
The Playbook: Anatomy of a Business Email Compromise
Strip the case to its skeleton and you get the standard BEC kill chain — the same one SOC teams defend against today:
| Stage | What Rimasauskas Did | Why It Worked |
|---|---|---|
| Reconnaissance | Identified a real vendor and the employees who paid it | Public info + patience; no intrusion needed |
| Infrastructure | Registered a same-name company in Latvia, opened accounts in Latvia and Cyprus | Bank checks matched name-to-name, not entity-to-entity |
| Pretext | Forged invoices, contracts, stamps and signatures | Paperwork mirrored genuine, ongoing transactions |
| Delivery | Phishing emails to targeted accounts-payable staff | Routine-looking requests inside a routine relationship |
| Extraction | Wire transfers to the fake vendor's accounts | Payments matched an approved vendor's name |
| Laundering | Rapidly moved funds onward across multiple banks | Money left the recovery window within days |
Notice what is absent from the table: malware, exploits, credential theft. The scam ran entirely above the technology layer. Every control that scanned attachments for viruses or blocked malicious links reported: all clear.
The Money Trail
Once the wires landed in Latvia and Cyprus, the money did not sit still. Prosecutors described funds being moved quickly onward through bank accounts in multiple countries — including Slovakia, Lithuania, Hungary, and Hong Kong — a classic layering pattern designed to outrun any recall request.
The totals, per the U.S. Department of Justice case:
- Facebook: roughly $99 million
- Google: roughly $23 million
- Combined: over $120 million across approximately two years
For perspective — this was not a smash-and-grab. It was a subscription. The fake Quanta billed, got paid, and billed again, quarter after quarter, without tripping an alarm.
How It Unraveled
The scheme was eventually detected and referred to U.S. law enforcement. In March 2017, the Department of Justice unsealed charges, and Rimasauskas was arrested in Lithuania. He was extradited to the United States later that year.

In March 2019, he pleaded guilty to one count of wire fraud. In December 2019, he was sentenced to five years in prison, and the court ordered him to forfeit roughly $49.7 million and pay restitution of tens of millions more. Both companies confirmed the incident after the charges became public, and both said they recovered the bulk of the stolen funds — an unusually good outcome that most BEC victims never see.
The uncomfortable footnote: recovery was possible largely because the victims were Google and Facebook, with the legal firepower and banking relationships to claw money back across borders. A mid-size company hit the same way usually absorbs the loss.
Why the World's Smartest Companies Fell for It
This is the section worth studying twice, because the failure was process, not technology:
- Single-channel trust. The invoice arrived by email, and the verification (if any) happened over the same channel the attacker controlled. Nobody picked up the phone to a known-good number at the real Quanta.
- Name-matching, not entity-matching. Payments went to "Quanta Computer" — the right name, the wrong company. Vendor records keyed on names and invoices, not on verified banking identities.
- Routine as camouflage. Approval fatigue is real. When the 40th invoice from a trusted vendor looks like the previous 39, human reviewers rubber-stamp it.
- No out-of-band control on banking changes. Redirecting payments to new accounts in new countries should have forced a second, independent verification path. It didn't.
Rimasauskas didn't beat Google's security team. He never met them. He beat a workflow.
Beyond Google and Facebook: BEC Is an Industry
The Rimasauskas case is the most famous, but it sits inside a much larger pattern. FBI IC3 data has repeatedly put reported BEC losses in the billions of dollars per year — typically an order of magnitude above ransomware's reported direct losses.
| Case | Year | Vector | Approximate Damage |
|---|---|---|---|
| Google & Facebook (Rimasauskas) | 2013–2015 | Fake vendor + forged invoices | Over $120M (mostly recovered) |
| Ubiquiti Networks | 2015 | Impersonated executives/vendor, redirected transfers | Roughly $46.7M disclosed |
| Toyota Boshoku (Europe) | 2019 | BEC targeting a subsidiary's payment process | Roughly ¥4 billion (about $37M) |
| 2020 | Phone spear-phishing of employees → internal admin tools | About 130 high-profile accounts hijacked; brand damage far exceeded the ~$118K Bitcoin haul |
The Twitter row matters because it shows the same social-engineering DNA jumping channels: from email to phone ("vishing"), from finance teams to IT support. The constant is the human, not the medium.
The Defense Playbook
Every control below exists, in part, because cases like this one made them non-negotiable. This is what modern security and finance teams deploy against BEC:

Email authentication
- SPF, DKIM, and DMARC enforced (with DMARC at
p=reject) so spoofed senders fail before a human ever sees them - Lookalike-domain monitoring and defensive registration of near-miss domains
Payment process hardening
- Out-of-band verification for any new vendor, any changed bank account, any "urgent" payment — a phone call to a number on file, never to a number in the email
- Dual control on wire transfers above a threshold: the requester can never be the approver
- Vendor master-data changes treated as privileged operations with their own audit trail
Human layer
- Phishing simulation programs that include invoice fraud and pretexting, not just credential-harvesting links
- A no-blame, one-click reporting culture — the earliest detector of a live BEC campaign is almost always an employee who felt something was off
What SOC Analysts Watch For
- First-time sender domains that visually resemble established vendors
- Reply-to addresses that diverge from the sender address
- Invoice anomalies: new bank country, changed account numbers, unusual amounts or cadence
- DMARC failure spikes and newly registered lookalike domains
- Finance-team mailbox rules created to auto-hide or auto-forward vendor threads — a classic post-compromise move
Key Takeaways
- The biggest breaches aren't always technical. A $120M+ loss required zero malware. Security careers that combine technical depth with process thinking are disproportionately valuable.
- Verify the entity, not the name. Identity is the control plane of finance. This is why vendor verification, KYC, and out-of-band confirmation exist.
- Controls must assume the email is hostile. SPF/DKIM/DMARC, dual approval, and out-of-band callbacks each independently break this kill chain. Defense-in-depth means the attacker must beat all of them.
- For analysts and IB/finance students too: understand that payment operations are attack surface. Anyone signing off on wires — in a bank, a startup, or a Big Tech AP team — is inside the threat model.
- Recovery is the exception. Google and Facebook got most of their money back because of who they are. Design controls as if you won't.
The Rimasauskas case is taught in security courses for the same reason pilots study accident reports: not because the failure was exotic, but because it was ordinary — and therefore repeatable. The next fake vendor is already emailing someone's accounts-payable team. The only question is whether the process it hits was built by people who studied this one.
