A fake job interview helped open the door to Binance’s wallet infrastructure: an employee downloaded a supposed coding exercise that installed malware, and the attackers ultimately used internal credentials and a company AI tool. Binance attributes the October 29 theft to this chain of events; published estimates range from $6.3 billion to $6.43 billion, depending on the source and valuation method.
The case cannot be reduced to a malicious file or a flaw in an AI tool. Binance’s reconstruction, published on November 3, describes an intrusion prepared over several months that combined the compromise of two engineers, access to other employees, and the ability to operate the wallet signing service. The FBI identified the perpetrators as TraderTraitor, a North Korean unit; TRM Labs also attributed the attack to that group.
Two entry paths and an internal escalation
The sequence had an earlier precursor in June. According to Binance, an engineer downloaded a tampered installer that was apparently distributed through a malicious Google ad. The Hacker News reports that it was a Homebrew installer used to install an AI tool. Binance detected that first infection and replaced the device, but information about the engineer’s role and colleagues on the wallet team had already been exposed.
In September, another person contacted a second engineer through a legitimate job-search platform, posing as a project manager. The scheme progressed through interviews: first, someone claiming to work in human resources got involved and shared a profile with personal photos and videos to gain trust; then another person presented themselves as the CEO of a fictitious company. The supposed candidate was then given a coding exercise hosted in a code repository.
The repository ran malicious code during setup. According to BleepingComputer, the malware replaced the legitimate pyenv executable in the Homebrew installation with a modified version, changed its symbolic link, and used it to launch a Z shell process. This allowed it to run commands received from a server controlled by the attackers. Binance said the program used obfuscation and evasion techniques, and removed traces of the infection to hinder its investigation.
Binance’s account links the two compromised computers to subsequent access to the wallet infrastructure:
flowchart TD A["Instalador manipulado en junio"] --> B["Datos del equipo expuestos"] C["Entrevista falsa en septiembre"] --> D["Ejercicio con malware"] D --> E["Equipo del ingeniero comprometido"] B --> F["Herramienta interna de IA abusada"] E --> F F --> G["Acceso a dos empleados más"] G --> H["Credenciales y token de despliegue"] H --> I["Servicio de firma de wallets"] I --> J["Transferencias no autorizadas"]
The AI tool was one link in the chain
On October 20, according to Binance, the attackers leveraged the compromised computer and an internal AI tool to reach two other employees connected to the wallet infrastructure. They obtained credentials and a container deployment token. The Hacker News reports that the token was on the first compromised engineer’s computer, while BleepingComputer explains that the stolen credentials were later used to deploy a malicious script.
On October 29, between 17:15 and 19:56, the attackers logged into a third employee’s computer, deployed a container, and activated the script, according to the timeline published by Binance. Access to the wallet signing service allowed them to generate transactions outside the usual withdrawal process. TRM Labs observed transfers from Binance wallets across ten blockchains and concluded that the breadth of valid signatures pointed to a compromise of the hot-wallet signing infrastructure.
Binance has not published a technical root cause explaining how this access was obtained. Nor has it detailed what role the internal AI tool played or why it could have helped the attackers. The available information is more limited: the company says it was abused to control other employees’ accounts. Portraying AI as the source of the theft would go beyond what Binance has explained.
“It was not a single isolated breach or a simple phishing incident,”
— Binance
Binance’s announced response includes rebuilding the affected wallet system in a new environment, rebuilding the internal AI tool and its access controls, replacing compromised devices, and revoking credentials and tokens. The company also said it strengthened the wallet service’s risk controls and expanded behavioral anomaly detection, including AI-based detection.
Why stopping transfers was not enough
The theft was not limited to Ethereum. TRM estimates that approximately $6.36 billion left Binance wallets across ten networks; BleepingComputer reports about $6.34 billion, and The Hacker News reports $6.43 billion. These are different figures, not a single amount confirmed across all publications. TRM valued each transfer at the asset’s price at the time of the theft and noted that those same assets were worth about $6.23 billion at later prices.
On Ethereum, TRM identified an EIP-7702 authorization that allowed a Binance hot wallet to be turned into a sweeping mechanism controlled by the attacker. The group had prepared 50 signed authorizations for different consecutive values of the wallet’s transaction counter; one remained valid when executed. The contract then sent the funds to an attacker-controlled address and swept subsequent deposits again.
Binance explained that the use of MPC in the hot wallet meant there was no single private key whose revocation could immediately cancel the malicious EIP-7702 authorizations. This limitation helps explain why suspending withdrawals did not stop all outflows: according to BleepingComputer, the attackers continued to exploit the authorization while Binance halted withdrawals on several networks. Other chains also recorded signed transfers, a pattern that led TRM to locate the problem in the signing infrastructure, not just in an Ethereum authorization.
Third-party intervention contained some of the damage. Binance said that about $2.85 billion in stolen assets had been frozen or intercepted, and that 98% of the affected tokens had been replenished by October 31; the company was still completing the remaining 2%. TRM counted nearly $2.7 billion frozen on-chain in its initial analysis on October 30. Its figures describe different points in time and different asset categories, so they should not be treated as the same measurement.
What this means for development and custody teams
For development teams, the episode highlights an entry route less conspicuous than a direct attack on production: a recruitment task that leads to running code on a work computer. In this case, the device was connected to information and people associated with the wallet infrastructure. Binance said the initial infection in June exposed information about an engineer’s role and colleagues; in September, another engineer was targeted in a fake job interview.
The enterprise risk lies in the chain of permissions. One compromised account did not have to drain the funds by itself: access to other employees, credentials, and a deployment token led to the service that signed transactions. That is why Binance lists controls at several points—devices, internal access, AI tools, and the wallet service—instead of attributing the solution to a single security product.
TRM recommends that exchanges and compliance teams monitor addresses linked to the attacker, and that treasury teams monitor EIP-7702 delegations in Ethereum-compatible wallets. It also proposes rejecting EIP-7702 authorizations that are not expected and separating signing policies by chain and wallet tier. These are measures proposed by TRM; Binance, for its part, has reported that it rebuilt affected systems and strengthened its controls.
Binance said that the identified entry points in the attack path had been closed and that affected systems had been rebuilt or replaced. The company also said withdrawals had largely resumed; assets still under the attackers’ control continued to be tracked by TRM.
Sources: The Verge, BleepingComputer, The Hacker News, TRM Labs