The Essentials
The Binance hack, which led to theft of billions of dollars in cryptocurrency on October 29, stemmed from a chain of compromises that stretched over several months. According to the incident narrative, the attackers combined a malicious Google Search advertisement, a fraudulent recruitment effort, and the exploitation of engineers’ workstations to reach the platform’s wallet infrastructure.
- First access in June: a DevOps engineer downloaded software from a site promoted by a malicious advertisement. An infostealer gathered information about his workstation, enabling the attackers to map his role and professional connections.
- A fake interview in September: another engineer was lured by fake recruiters and invited to download a code repository containing malware. The malware escaped detection by the EDR.
- A rebound via an internal AI tool: on October 20, the attackers used a compromised workstation and an internal tool to reach other machines and retrieve an authorization token tied to container deployment.
- Exploitation of blockchain authorizations: on October 29, the attackers used these accesses and Ethereum’s EIP-7702 mechanism to authorize transfers from wallets. Revoking authorizations was complicated by the multipartite signature system.
The Binance attack began with… a malicious advertisement in Google Search.
An Engineer Trapped by a Malicious Search Advertisement…
In June 2026, a DevOps engineer wanted to install an AI coding tool on his Mac. By clicking the advertised link in question, he landed on a site inviting him to copy-paste a script into the terminal to download the Homebrew package manager.
Running the script opened a succession of pop-ups. The first urged updating system settings to run the application and presented a password-entry field. The second asked to grant the terminal permission to control the Finder. The third announced a failure: “Your Mac cannot run this application.” Meanwhile, the MacSync infostealer collected data, zipped in the /tmp directory before being sent to the C2 server.
Before Binance detected the anomaly and remedied it (by replacing the device and credentials), the attacker had mapped the engineer’s role and identified his colleagues.
… and another via a Fake Job Offer
The second phase took place in September. Another Binance engineer was contacted on a professional networking site by a fake project director. The latter arranged a video interview with a supposed HR manager who, to build trust, shared a social media account featuring “personal” photos and videos.
A second interview proceeded via a messaging application, allegedly with the CEO. The engineer was asked to download, onto his work machine, a tainted code repository. The malware contained there replaced a legitimate Homebrew component (pyenv), installed a symbolic link, opened a zsh shell, and established a C2 channel, without triggering EDR alerts.
A Third Workstation Compromised to Siphon Crypto
This workstation was used, on October 20, to compromise the first engineer’s machine by way of an internal AI tool. The attacker retrieved an authorization token for container deployment.
On October 29, it used this token on the third engineer’s machine to trigger the funds exfiltration script. It was around 9:00 p.m. in France when a first hot wallet sent about 233 million Ripple (XRP). This was followed by nearly one million Solana (SOL) and about 44 million of Optimism (OP).
Binance ultimately received an alert of abnormal transfer volumes. The attack did not stop there. For instance, another wallet transferred 18,270 BTC.
To establish a form of persistence, the attacker hijacked an Ethereum mechanism: EIP-7702, which allows a smart contract to acquire execution rights on a wallet without exposing the private key. He submitted 50 signature transactions to manipulate the nonce and lock in the authorizations on the blockchain.
These authorizations were separate from Binance’s normal withdrawal infrastructure. Revoking them was even more complex because the wallet in question used a multipartite signature system. There was therefore no single key that could be immediately revoked.
The final unauthorized move (about 2960 ETH and a bit more) occurred at 00:56 on October 30. It was a transaction that had already propagated. It sat in the mempool. The revocation of the delegation occurred at 01:10, by signing a new authorization to the zero address.
