Coinbase is not a company that cuts corners on security. They have a dedicated security team, world-class infrastructure, and the kind of compliance apparatus that comes with being publicly listed on NASDAQ and joining the S&P 500.
None of it mattered.
Because in late 2024, an attacker didn't try to break in. They simply walked up to the side door — the offshore customer support team — and offered someone cash to open it.
This is the Coinbase breach. And it's one of the most important security case studies any business leader could study in 2025, because the lesson has nothing to do with code.
What Actually Happened — The Full Timeline
The breach started on December 26, 2024. Attackers — working through methods still under investigation — identified and contacted customer support agents working for Coinbase's outsourced support operations, primarily based in India. They offered cash to those agents in exchange for accessing and exporting customer data from Coinbase's internal support tools.
Those agents had legitimate credentials. They weren't hacking anything. They were doing exactly what their access permissions allowed — looking up customer records — and quietly copying that data out.
Coinbase only discovered the insider wrongdoing on May 11, 2025 — nearly five months after the data had begun flowing out. That same day, the attackers sent an extortion email demanding $20 million in Bitcoin to stay quiet about the stolen data.
Coinbase CEO Brian Armstrong publicly refused to pay, stating "We will not fund criminal activity." Instead, Coinbase announced a matching $20 million reward for information leading to the attackers' arrest.
In December 2025, Indian authorities arrested a former Coinbase customer support agent in Hyderabad in connection with the breach.
The Technique: This Is Still Social Engineering
It's tempting to file this under "insider threat" and move on. But that misses the real lesson.
The support agents didn't wake up one day and decide to steal data. They were recruited, persuaded, and incentivised — by someone who understood their situation, identified their vulnerability, and constructed an offer they found difficult to refuse.
Cybercriminals contacted customer support agents working for an external vendor and successfully bribed at least one agent to hand over their credentials or otherwise facilitate access to Coinbase's internal support tools.
That's social engineering. The target just happened to be inside the organisation rather than outside it. The psychological levers — financial pressure, plausible deniability, perceived low risk — were pulled with precision.
This is a pattern with a name now. Threat groups like Muddled Libra (which we covered in Tuesday's post) have made BPO targeting — going after Business Process Outsourcing firms that handle support operations for large companies — a core part of their playbook. Common tactics include bribing insiders with legitimate access, social engineering support staff to grant unauthorised access, and compromising BPO employee accounts to reach internal systems.
What Was Actually Exposed
The stolen data included account data for a small subset of customers — less than 1% of Coinbase's monthly transacting users. No passwords, private keys, or funds were directly exposed, and Coinbase Prime accounts were untouched.
From Maine's state breach notification filing, the affected headcount was 69,461 people — names, addresses, partial Social Security numbers, account balances, and transaction history. Enough to build highly convincing impersonation attacks.
And that's exactly what happened next. Attackers used the stolen data to contact Coinbase customers while pretending to be Coinbase support — warning them of suspicious activity on their accounts and instructing them to move their funds to "safe" wallets. Wallets controlled by the attackers.
The Actual Cost: Up to $400 Million
The $20 million ransom demand was almost comically small relative to the actual cost of saying no.
Coinbase estimated their financial exposure from customer reimbursement and remediation at between $180 million and $400 million. That figure covers reimbursing customers who were deceived into transferring crypto, legal costs, regulatory response, the DOJ investigation, and remediation work across their support operations.
Plus the reputational hit of becoming a breach headline in the same week they joined the S&P 500.
The attacker spent almost nothing. The company it targeted will spend hundreds of millions.
What This Means for Your Business
You are almost certainly not Coinbase. But you very likely share one critical vulnerability with them: third-party and contractor access to your customer or operational data.
Ask yourself honestly: who has access to your customer records right now? Not just your employees — your CRM vendor's support team, your outsourced helpdesk, your software implementation partners, the offshore agency managing your email campaigns. How is that access monitored? What does it look like when someone starts pulling more records than their role requires?
Most companies don't have a clear answer. That gap is exactly what attackers are looking for.
Three Practical Steps to Reduce This Risk
1. Apply least privilege — and mean it. Every person who touches your systems — employee, contractor, or vendor — should have access to only what their specific role requires, for only as long as that role exists. A support agent who handles billing queries does not need access to identity documents. A vendor who handles email does not need access to your full customer database.
2. Log and monitor access behaviour, not just access events. Knowing who logged in is table stakes. Knowing that a support agent viewed 400 customer records in a two-hour window — when their average is 30 per day — is the signal that catches insider threats before five months pass. Anomaly detection on access logs is no longer an enterprise-only capability.
3. Vet contractors and vendors the same way you vet employees. Background checks, clear contractual obligations around data handling, and defined offboarding procedures are non-negotiable when a contractor has access to customer PII. The Coinbase breach happened through a vendor relationship. The outsourced employees already had legitimate access as part of their job functions, allowing attackers to bypass traditional cybersecurity defences without touching Coinbase's core systems. Legitimate access used maliciously is invisible to most security tools.
The Question Worth Asking Right Now
The Coinbase breach didn't start with a sophisticated exploit. It started with someone at a support desk deciding that a cash offer was worth the risk. Five months passed before anyone noticed.
Does your company know who has access to your customer data right now — and would you know within days, not months, if that access was being abused?
If that question makes you uncomfortable, it should. That discomfort is useful.
At Kuboid Secure Layer, our Cloud & Infrastructure Security Reviews specifically examine access control architecture, third-party access patterns, and the logging infrastructure that determines whether you'd detect an insider event. We also work with organisations to build the vendor security frameworks that catch these risks at the contracting stage, not after a breach.
If you've ever worked with a BPO, an outsourced support team, or a third-party vendor with access to customer data — we should talk.
Have you audited your third-party access controls recently? Or does your vendor list have doors you've forgotten about? Drop a comment — this is a conversation more businesses need to be having openly.
Top comments (0)