Ronald Spektor: the fake Coinbase support rep who gambled away $6 million of what he stole

Background

Crypto platforms are a specific kind of target for impersonation fraud, for a reason that has nothing to do with their own security: a cryptocurrency transaction, once confirmed, doesn't reverse. There's no chargeback, no bank fraud department that can claw a wire back on a phone call. That single structural fact is what makes "someone posing as platform support" such a durable, profitable scam — the victim doesn't need to be tricked into handing over a password, just into moving their own funds somewhere the attacker controls, once, voluntarily, because they believe they're protecting themselves.

Ronald Spektor, a 23-year-old from Brooklyn, ran exactly that playbook against Coinbase users for at least a year. He wasn't inside Coinbase's systems. He didn't need to be.

How a phone call became $15.94 million

What actually happened

The pattern, pieced together from victim accounts, was consistent: a call, text or email arrived claiming to be from Coinbase's security or support team, warning that the recipient's account showed signs of compromise. One named victim recalls a September 2024 call from someone identifying himself as "Fred Wilson" from Coinbase's "security department." The fix offered was always the same — move your crypto to a new wallet, right now, to get it out of reach of whoever had supposedly broken in.

The new wallet belonged to Spektor. Victims believed they were securing their own funds under their own control. They weren't. Over roughly a year, about 100 people sent their crypto to wallets he controlled — some individual losses ran past $1 million. The total came to approximately $15.94 million.

He wasn't anonymous enough. Blockchain investigator ZachXBT, whose on-chain tracing work has surfaced in multiple major crypto-fraud cases, contributed to identifying him. The Brooklyn District Attorney's office indicted Spektor on 31 counts — first-degree grand larceny, first-degree money laundering, and related charges — reported in December 2025.

He pleaded guilty to all 31 counts on September 2, 2026. Investigators had recovered messages in which Spektor admitted losing roughly $6 million of the stolen funds to online gambling — money that was never going to be available for restitution regardless of what the court ordered. He was sentenced September 23, 2026 by Brooklyn Supreme Court Justice Danny Chun to an indeterminate 4-to-12-year prison term. The DA's office had asked for 7 to 21 years; the judge held to the plea agreement's lower range over the prosecution's objection. The court ordered approximately $16 million in restitution and more than $500,000 in cash, crypto and property was forfeited. As of the most recent reporting, only about $605,000 had actually been recovered.

Root cause

Timeline

Detection

What to monitor for in your own environment

Containment, eradication & recovery

Security control analysis

Controls that would have prevented or limited this

Blast radius

What the court ordered, against what's actually come back

What they got right

The investigation didn't stop at identifying a pattern — it traced specific transactions back to a specific person, using on-chain analysis that included outside blockchain-forensics expertise, in an asset class attackers often assume is harder to follow than it actually is.

The Brooklyn DA's office pursued a full 31-count indictment rather than a lesser plea-down, and secured an actual guilty plea with a real custodial sentence — accountability that a meaningful share of crypto-fraud cases never reach, given how many attackers in this category operate from outside any jurisdiction willing or able to prosecute them.

Prosecutors moved to forfeit what could still be recovered — cash, crypto, property — rather than treating the case as closed once a conviction was secured. Partial recovery is still real recovery, even when it falls far short of the total loss.

Why this keeps happening

The FBI's Internet Crime Complaint Center recorded roughly $11.3–11.4 billion in US crypto-fraud losses in its most recent annual report — up about 22% year over year, across more than 180,000 complaints. Tech-support-impersonation scams specifically accounted for about $2.1 billion of reported fraud losses, with crypto used as the payment method in 43% of those cases. Spektor's scheme is not an outlier; it's a documented, scaling category.

The structural reason this specific variant works is that it doesn't ask for a password or a one-time code — the things years of phishing-awareness training have taught people to protect. It asks the victim to do something that feels protective: move your own money, under your own authority, to keep it safe. That framing routes around a lot of the security instincts people have actually been trained to use.

Irreversibility is the other half of why crypto specifically gets targeted this way. A fraudulent bank wire can sometimes be recalled within a narrow window; a confirmed on-chain transaction essentially never can. The same feature that makes cryptocurrency resistant to censorship and seizure by anyone else also makes a successful theft almost permanent the instant it's confirmed.

Brand impersonation at this scale doesn't require any compromise of the brand itself. Coinbase's own systems being secure or insecure is almost beside the point here — Spektor needed the company's name and a plausible-sounding warning, not access to anything Coinbase actually controlled.

Lessons for your own environment

1. A platform's real support team doesn't ask you to move funds to "safety"

   No legitimate crypto platform's actual security response to a compromised account involves instructing the customer to transfer their own holdings to a new wallet over the phone. That single pattern, recognized and refused, would have stopped every loss in this case.

2. Out-of-band verification is the one step that actually works here

   Hanging up and logging into the platform directly, or calling a number looked up independently rather than one provided by the caller, breaks the entire scheme. It's not a technical control — it's a habit, and it's the single highest-leverage one against this specific fraud pattern.

3. Crypto's irreversibility removes the safety net other fraud victims have by default

   A fraudulent wire or card charge can sometimes be clawed back. A confirmed crypto transfer essentially can't. Anyone holding meaningful crypto assets needs to treat that irreversibility as a standing risk factor, not a detail that only matters after something goes wrong.

4. Blockchain's public ledger is a real investigative asset, not just a privacy tradeoff

   The same transparency that makes crypto transactions traceable by researchers and investigators is what ultimately identified Spektor. Victims and platforms alike benefit from treating on-chain forensics as a genuine recovery tool, not an afterthought.

5. A restitution order is not the same thing as money coming back

   The court ordered about $16 million. About $605,000 had actually been recovered as of the most recent reporting, with a third of the original theft already gambled away and gone. Treat a restitution figure as a legal milestone, not a financial outcome, when assessing what a prosecution actually delivers victims.

6. Brand impersonation needs no breach of the brand at all

   Spektor never touched Coinbase's own systems. He needed the company's name and a convincing enough warning. Any organization whose brand carries trust in a financial or security context is exposed to this regardless of how well its own infrastructure is defended.

CISO & board lessons

• If your organization's brand is trusted enough that customers would believe a call claiming to be your security team, you have a brand-impersonation exposure whether or not your own systems have ever been breached. Budget for customer-facing anti-impersonation education as a standing program, not a one-time notice after an incident.
• Publish, prominently and repeatedly, exactly how your real support and security teams will and will not contact customers — and specifically call out that you will never ask someone to move funds or assets to a new account "for safety." A policy that exists only in a help-center article nobody reads doesn't function as a control.
• Treat blockchain-forensics capability — in-house or via partnership with firms and independent researchers who do this work — as part of your incident-response and customer-protection posture, not an optional extra. It's what actually closed this case.
• When your platform suffers any real data exposure (even one involving a bribed insider rather than a technical breach, as Coinbase's separate 2025 incident did), assume the exposed information will be used to make impersonation attempts more convincing against your own customer base, and communicate that risk proactively rather than waiting for complaints to surface a pattern.

Action plan

Could this happen in your organization?

• If someone called you right now claiming to be your bank's or crypto platform's security team and said your account was compromised, would you verify independently before taking any action — or would the urgency of the warning itself push you to act first?
• Do you know, specifically and in advance, how your platform's real support team will and won't contact you — and would you recognize a deviation from that in the moment?
• If you operate a platform or company whose name could plausibly be used in an impersonation scam, have you published clear, specific, repeated guidance on how your real contact looks — not just a buried help-center article?
• Would your organization notice a pattern of customers reporting similar impersonation attempts quickly enough to warn others before the damage scales to dozens or hundreds of victims?
• Does your organization have an existing relationship with blockchain-forensics investigators or law enforcement cybercrime units, or would that relationship need to be built from scratch during an active fraud case?
• If a customer transferred funds based on a fraudulent contact claiming to be your company, is there a clear, fast internal process for supporting that customer's report and preserving evidence, or would it be handled ad hoc?

If this happened to you: what to ask, and what to say

Knowing the lesson isn’t the same as knowing what to do with it Monday morning. A security lead, a CISO, and a customer-facing team each need something different from this incident.