On 3 November 2026 Binance published its first findings on the theft of 29 October, which affected assets worth about US$6.34 billion. It did not begin with a flaw in the exchange. It began with a job interview, and that method works against any company that employs developers.
What happened
Binance's initial report, summarised by The Hacker News, describes a campaign that ran for five months. In June 2026 an engineer from the wallet team searched for a popular AI coding tool and installed a tampered version of Homebrew, the package manager for macOS. Binance noticed, replaced the device and rotated the credentials. By then, however, the attackers knew who worked on the wallet infrastructure.
In September one of those colleagues was approached on a job platform, according to Fortune on LinkedIn. A "Project Director" of a company that does not exist referred to the engineer's experience at Binance. A fake HR person held a live video interview and shared a social media account with personal photos to seem genuine. In the second round a supposed CEO wrote in a chat app and, at the end, asked the engineer to download a coding assignment onto the work computer. Its setup ran the attackers' code.
The code replaced pyenv, a common tool for managing Python versions, inside the Homebrew directory with a manipulated copy, contacted a server and removed its traces. Binance calls it a zero-day that its endpoint protection did not detect at the time.
On 20 October the attackers used that computer and an internal AI tool to take over the computers of two more engineers. On one of them they found a token that allowed containers to be deployed. On 29 October, between 17:15 and 19:56 UTC, they deployed a container with a malicious script. It reached the internal signing service for the wallets and started transactions outside the normal withdrawal process.
A further step made the theft hard to stop. Using EIP-7702, an Ethereum feature that lets a wallet hand some execution rights to a smart contract, they gave a contract they controlled rights over a hot wallet. Suspending withdrawals did not help, because the authorisation already existed on the blockchain, and because the wallet is signed jointly by several parties, no single key could revoke it quickly. Binance cleared the delegation at 00:10 UTC on 30 October.
According to Binance, about US$2.85 billion was frozen or intercepted. Other outlets give slightly different figures for the loss and for the amount recovered, and the report is explicitly an interim one.
Who is behind it
Binance cites FBI information that North Korea is responsible. The FBI attributes the attack to the group it calls TraderTraitor, also known as Lazarus Group or Jade Sleet. Binance itself names no group. It says it detected and stopped 57 suspected North Korean attempts against it in 2026 alone.
The method is well known. In September, authorities from Japan, the US, Australia and Germany warned jointly about a campaign of fake job interviews known as Contagious Interview, with more than 30,000 infected devices in over 100 countries. Whether the attack on Binance belongs to that campaign has not been confirmed, but the pattern is the same: a credible offer, several rounds of conversation, and in the end code that the applicant runs themselves.
Why this concerns you
Few companies hold billions in cryptocurrency. Many have developers and administrators whose laptops hold access to production: deployment tokens, cloud keys, SSH keys, admin sessions. That is what this attack was after. A job interview is a good way in because it happens outside the company's processes, often in the evening and on a private channel, and because an applicant wants to make a good impression and does what is asked.
None of the individual steps is new. A fake Homebrew page delivered through ads was documented in the spring, and manipulated coding tests, fake video conferencing apps and supposed camera fixes have been described since 2023.
What to do now
- Treat interview assignments as untrusted code. Nothing from an application process runs on a work device. Anyone who wants to look at an assignment does so in a disposable virtual machine without access to company accounts. Write that down as a rule, so nobody has to decide it in the middle of an interview.
- Keep long-lived secrets off laptops. Deployment rights belong in short-lived, narrowly scoped tokens that are issued for a task and then expire. A token that sat on a laptop is what turned one compromised device into access to production here.
- Watch developer tools. Endpoint detection should alert when programs in package manager directories such as /opt/homebrew are replaced outside an update. Install tools from their official source, not from a search result or an ad.
- Limit internal AI tools. An assistant that can reach many systems on behalf of its users is an attractive stepping stone. Give it only the access it needs, and log what it does.
- Talk about recruitment lures. Awareness training usually covers invoices and parcel notifications. Add job offers: a real employer does not ask applicants to run code on their work computer, install a camera fix or paste a command into a terminal.
- Think about public profiles. According to Fortune, Binance's rules say that staff in roles that are not public-facing may not keep LinkedIn profiles. That will not suit every company, but people with privileged access should know that their profile tells attackers whom to approach.
- Plan for what cannot be stopped quickly. Here, suspending withdrawals did not stop authorisations that already existed. Every organisation has its own version of that, such as access that keeps working after an account is disabled. Find it before an incident, not during one.
For applicants the short version is simple: if a recruiter asks you to run something, run it on a machine that has nothing to lose, or not at all.
How far would one compromised developer laptop get in your company? Pentesting and consulting →