Skip to content
HackIT
Talk to a tester

Binance hack: what a compromised developer laptop can reach

How a fake job interview, a tampered developer tool and an internal AI tool led to the Binance theft of about $6.34 billion, and what one laptop can reach.

HackIT Security TeamUpdated

Explainer cover: Binance hack: what a compromised developer laptop can reach

In short: Binance says the theft, which it puts at about $6.34 billion, came from a multi-stage campaign against its engineers: a tampered Homebrew installation, a fake job interview whose "assignment" ran malicious code on a work computer, an internal AI tool used to reach other engineers, and a container deployment token used to abuse an internal wallet signing service. Binance says the latest information from the FBI indicates that North Korea is responsible; it is reopening withdrawals in phases and says it has replenished most of the stolen assets. For any engineering team the lesson is the path: limit what one developer machine can reach, and make high-impact actions need a second approval.

Updated 3 November 2026: Binance's initial post-mortem, the FBI's attribution, current figures and the phased reopening of withdrawals.

Corrected 3 November 2026: the first version said Binance had suspended deposits; Binance has since clarified that deposits were not affected and only withdrawals were suspended.

How did the Binance hack happen?

On 3 November 2026, Binance published its initial findings. It describes "a sophisticated, multi-stage campaign", not a single breach:

  1. June 2026. A Wallet DevOps engineer, Engineer A, downloaded a tampered Homebrew installation to install a popular AI coding tool he had searched for. Binance's security team detected it, replaced the device and rotated the related credentials, but his role and his colleagues on the wallet infrastructure team were exposed to the attacker.
  2. September. Another engineer, Engineer B, whose profile on a legitimate job-hunting platform referred to his experience at Binance, was contacted by someone posing as a project director. A video interview with a supposed HR representative, who shared a social media account with personal photos and videos to build trust, was followed by a second round in a chat app with someone claiming to be the chief executive of a fictitious company. Near the end, Engineer B was told to download an "assignment" repository onto his work computer, and its code ran during setup. The malware replaced a legitimate development tool component and was not detected by endpoint protection at the time.
  3. 20 October. From Engineer B's computer, the attacker used an internal AI tool to gain control over Engineer A and a third engineer, Engineer C, and found a container deployment permission token on Engineer A's computer.
  4. 29 October. Between 17:15 and 19:56 (Binance gives no time zone), the attacker logged onto Engineer C's computer, used Engineer A's credentials, deployed a container and triggered a malicious script. It then used unauthorised access to an internal wallet signing service to initiate transactions outside the normal withdrawal process.

The outflows began at 20:05 UTC, and the last unauthorised transfer was finalised at 23:56 UTC. Binance says suspending withdrawals alone could not stop every movement: the attacker had used the signing service to abuse an Ethereum authorisation mechanism, EIP-7702, and because the hot wallet used multi-party computation, there was no single key with which to revoke those authorisations at once.

Binance's account changed as it investigated. Its first update, early on 30 October, pointed to a compromised DevOps engineer's laptop; its second, that evening, said further investigation had uncovered additional points of breach and that it had found no evidence that wallet private keys were leaked. Binance calls the 3 November findings an initial report, and says it is engaging independent cybersecurity experts to review the incident.

How much was stolen in the Binance hack?

The figures differ, partly because they measure different things:

WhoFigureWhat it measures
Binance, 3 Novemberabout $6.34 billiondigital assets affected
Elliptic$6.43 billionstolen, by its own on-chain analysis
TRM Labsabout $6.36 billionmoved out of Binance wallets, valued at the time of each transfer

Binance says about $2.85 billion has been frozen or intercepted, subject to reconciliation and price movements; Elliptic says it has verified $2.85 billion of frozen or seized funds, almost all of it in the USDT and USDC stablecoins.

TRM Labs and Elliptic call it the largest cryptocurrency theft on record. TRM puts it at about four times the $1.5 billion taken from Bybit in February 2025, which the FBI attributed to North Korea.

Who is behind it?

Binance says the latest information released by the FBI indicates that North Korea is responsible. According to Elliptic and The Hacker News, the FBI attributed the theft on 31 October to TraderTraitor, its name for a North Korean state-sponsored hacking group, and with the US Secret Service and IRS Criminal Investigation has seen the group converting the stolen assets mainly into ETH. The FBI has published the addresses involved and urged others to block transactions linked to them, Elliptic reports.

The FBI uses the same name, TraderTraitor, for the North Korean activity behind the Bybit theft. TRM Labs had already attributed the Binance attack to TraderTraitor, with high confidence.

Binance's account also fits what the analysts read from the blockchain. TRM, before Binance had published a root cause, assessed that the attacker could make Binance's hot wallet signing system sign transactions of its choosing; Elliptic said the on-chain evidence suggests the attacker got Binance's own systems to sign transactions, rather than stealing its private keys.

Where do withdrawals and losses stand?

Deposits were not affected. Binance amended its first update on 30 October to say so; only withdrawals were suspended. It reopened withdrawals for selected networks and assets on 1 November, and said it would begin reopening them for more assets from 04:00 UTC on 3 November, progressively rather than all at once. It gives no date for full restoration.

Binance says it is covering the losses from part of its SAFU fund, part of its futures insurance fund and its own treasury, according to its 31 October update. Its figures for how much is replenished differ: its 31 October update said 90%, the updates of 1 and 2 November say about 95% of the affected amount had been covered, and the 3 November findings say 98% of the affected token assets had been replenished as of 31 October.

Binance also lists what it has changed. It has closed the entry points used in the attack, rebuilt the affected wallet system in a new environment, rebuilt the internal AI tool and its access controls, replaced the affected devices and decommissioned the engineers' credentials and tokens. It has also scanned all employee devices, enhanced its behavioural anomaly detection and strengthened its wallet-service risk controls.

Why one developer laptop can be enough

Binance's account follows a familiar pattern. In the Bybit case, the Safe{Wallet} team said the attack was achieved through a compromised Safe{Wallet} developer machine which led to a disguised malicious transaction being proposed. In 2022, the FBI, CISA and the US Treasury warned that TraderTraitor intrusions began with spearphishing of employees at cryptocurrency companies, often in system administration or DevOps, using fake job offers to get them to download trojanised applications. Binance says that in 2026 alone it detected and prevented 57 suspected North Korea-linked cases, whose techniques included fraudulent job interviews and malware disguised as popular developer tools.

The reason is what such machines hold. NIST notes that a developer's workstation typically holds source code, credentials and access to sensitive information, and says developer workstations should not be trusted as part of the build process, since they are at risk of compromise. The UK's NCSC puts the consequence plainly: an attacker who compromises a device used for administration could inherit the same level of access. A deployment token on an engineer's laptop, as at Binance, is exactly that kind of access.

None of this is specific to exchanges. Any company where an engineer's laptop can reach production, deployment pipelines or payment functions has the same question to answer.

What to check in your own organisation

  1. Map what a developer laptop can reach. List the production systems, containers, cloud consoles, pipelines, tokens and secrets that engineers can reach directly from their everyday machines. That list is what one compromised laptop gives an attacker.
  2. Administer from trusted devices. The NCSC's rule is to "browse down": administer a system only from a device trusted at least as much as the system. Where compromise would have significant impact, it recommends dedicated privileged access workstations.
  3. Use short-lived, narrow credentials. The NCSC recommends limiting how long an administration credential is valid and granting just enough permissions. OWASP recommends temporary credentials over static ones, scoped to conditions such as a source IP or identity, with least privilege for each.
  4. Make high-impact actions need a second person. With just-in-time administration, the NCSC notes, an attacker on a compromised administrator workstation still has to get through a request and approval process, which can require approval by someone else. OWASP recommends that no single person or account can ship code through the pipeline without outside verification, and that production deployments need additional approval. The same logic applies to withdrawals, payments and signing.
  5. Scope CI/CD secrets. OWASP recommends that each pipeline and step can reach only the secrets it needs. NIST calls for an isolated CI/CD environment, with elevated administrator credentials for deploying to the cloud.
  6. Control what runs on work machines. For companies with access to large amounts of cryptocurrency, the FBI recommends that devices on the company network may download or run only allow-listed programs. Binance's account starts with a developer tool installed after a search.
  7. Watch for the unusual. NIST calls for real-time monitoring and alerting for suspicious activity in CI/CD servers. The 2022 advisory recommends least-access models, enforced multi-factor authentication and monitoring for anomalous logins.
  8. Brief the people who are targeted. The FBI lists "pre-employment tests" that run unknown packages, scripts or repositories, and requests to move a conversation to another platform, among the signs of North Korean social engineering. It advises against taking such tests or running code on company devices; if a test needs code to run, use a virtual machine on a non-company device. It also advises verifying a contact's identity on a separate platform.

For teams that hold cryptocurrency, TRM Labs also recommends separating signing infrastructure and approval paths by chain and wallet tier.

If your company uses Binance

Binance says user funds are safe and that it will cover all losses. Deposits work; withdrawals are reopening asset by asset, so check Binance's announcements before planning transfers that depend on them. Binance has also warned customers, BleepingComputer reports, to stay cautious of scams and avoid unofficial links, messages or requests for account information.

How a security review fits in

The Binance case asks the inside question: assume one engineer's laptop is compromised, and follow what it can reach and what it can approve. Reviewing those access paths, devices and approvals is part of security consulting.

If you want to know how far one compromised laptop could get in your systems, talk to a tester.

Sources

All posts