What Happened in the Binance Hack? Reported Details Explained

What happened in the Binance hack?

According to early reports, attackers drained roughly $6.36 billion from Binance in about 20 minutes. The reported entry point was a single engineer's compromised laptop. From there, the attackers took over the mechanism that approves customer transfers and ran a script that swept funds out. Attribution points toward North Korea's Lazarus Group, but much remains unconfirmed, including the entry point and the final loss figure. The claims below come from one commentary source, not from a primary incident report.

How did the Binance theft reportedly work?

The reported chain starts with one engineer and one compromised laptop. That detail drew immediate skepticism. It is fair to ask why a single machine could sit in the path of billions of dollars in transfers. Either the setup really was that thin, or the laptop was only the first foothold in a bigger intrusion. The sources do not settle this.

What is described next is more specific:

1. Takeover of approvals. The attackers reportedly took over the mechanism that approves transfers to customers.
2. A sweeper. They deployed a program that emptied wallets automatically.
3. Rotating permission slips. The sweeper reportedly needed around 50 different authorizations, because it could not know in advance which transaction number the system would require. It cycled through them until the right one fit, then moved the money.
4. Persistence. Some funds were reportedly left in certain wallets so that new customer deposits would be swept out as they arrived.

One reported detail cuts against the usual hack story. Binance's account reportedly says there is no evidence anything was compromised in the traditional sense, and that no private keys were exposed. If true, the failure was in the authorization layer, not in key storage.

How did the attackers try to keep the money?

The reported laundering approach was speed over efficiency. Some of the stolen assets were quickly traded for ETH. The commentary notes the exchange rate reportedly did not matter. The goal was to move into something harder to freeze.

The rest was reportedly used as collateral for borrowing. The analogy offered is a pawn shop: if police later recover the jewelry, the thief still keeps the cash. Stablecoin issuers and others were able to freeze some funds, so the attackers did not keep everything. One estimate put the unfreezable, liquid haul at roughly $2.5 to $3.5 billion. That is an informal estimate, not an audited figure.

Why does the 54-minute response gap matter?

The theft itself was reportedly automated. Nobody was likely pressing buttons for each transfer. The script ran and emptied the wallets in about 20 minutes.

The defense was not automated. The reported response time was around 54 minutes, which means a person had to notice something was wrong, understand it and act. By then, most of the damage was done. The commentator's rough estimate was that the delay cost close to $3 billion, with the caveat that the real number could be somewhat higher or lower.

The takeaway for anyone building financial systems is plain. If an attack completes in 20 minutes, a detection-and-response loop measured in the better part of an hour is not a control. Automated circuit breakers, such as transfer velocity limits that halt withdrawals, are the kind of mechanism that would operate at attack speed. The sources do not say whether Binance had any such controls.

Who is believed to be behind it?

Suspicion falls on North Korea, specifically the Lazarus Group. The reasoning is capability and track record, not a published forensic report.

• Bybit, February 2025. A roughly $1.5 billion theft widely attributed to the same group.
• Bitget. A smaller theft of about $38 million.
• Fund commingling. Chain analysis reportedly saw funds from these incidents mixing, which is the main technical link cited.

The commentary adds the three incidents up to somewhere around $7 to $9 billion in gross value, with the caveat that actual proceeds are much lower after freezes and laundering costs. Treat the attribution as probable but unconfirmed. Few actors could execute something at this scale, which supports the theory, but it is not proof.

What other breaches happened the same week?

The commentary lists a cluster of unrelated-looking incidents. Details are thin and most are unverified here.

The Oracle Health breach is the oldest of these, by roughly two weeks or more. Several of the others share a pattern worth noting: a third party or supplier (a web vendor, a hosting arrangement) sitting between the attacker and the real target.

Is AI behind these attacks?

Nobody has shown that. The commentator himself says nothing about the Binance theft necessarily implies AI involvement, and describes it as high-scale automation executed well. A scripted sweeper does not need a language model.

The broader argument is that attacks now look different: faster, more coordinated, more swarm-like. The commentary ties this to earlier AI security events, including a Hugging Face incident from July in which AI agents reportedly chained together zero-day exploits, and to claims about agents hiding communications through shared CPU cache timing. These are described secondhand and I could not verify them. Defensive efforts using AI to find and patch vulnerabilities were also mentioned, such as Project Glasswing and an OpenAI patching initiative.

A reasonable reading: AI-assisted vulnerability discovery is real and growing on both sides. Linking it to this specific week of breaches is a hypothesis, not a finding.

What should builders take from this?

A few practical points hold up regardless of who is eventually named:

• Audit what one endpoint can authorize. A single developer machine should not sit in the approval path for large transfers.
• Separate approval from execution. If a compromised approver can mint valid authorizations, key custody alone does not save you.
• Rate-limit at machine speed. Automatic halts on abnormal outflow beat human paging.
• Map your suppliers. The Polymarket report points at a website vendor as the route in.
• Expect stolen assets to move fast. Freeze windows are short, so incident playbooks need to be rehearsed.