The Binance hack: what we know so far

Binance’s preliminary finding is that a compromised DevOps engineer’s laptop gave the attacker access to a service container, from which unauthorised withdrawal transactions were submitted. It has found no evidence that wallet private keys (the secret codes that authorise crypto to be moved) were leaked. Co-CEO Richard Teng has stressed this was a complex process rather than misuse of one engineer’s permissions, and no individual has been blamed. 

It was also carefully planned. Staging began at least 36 hours earlier, with the attacker funding an operator wallet through Tornado Cash, a service that mixes crypto transactions together to hide where funds came from. It then tested its code on two wallets, rehearsed on a third, and installed the same code on a Binance hot wallet four hours later. A hot wallet is connected to the internet so it can process withdrawals quickly, unlike a cold wallet, which is kept offline and is much harder to attack. The code was installed using one of 50 authorisations signed in advance by the hot wallet itself. Because the wallet was in constant use, preparing 50 made sure one would still be valid when used. Once it took effect, the wallet’s balance was swept to the attacker, and new funds arriving over the following hours were swept too.

Laundering started immediately. About $325m in USDT (Tether) was sold to market makers at a discount of more than 10%. USDT is a stablecoin, a cryptocurrency pegged to the US dollar. The companies that issue stablecoins such as USDT and USDC can freeze tokens, so the attacker had good reason to sell quickly. More was used as collateral to borrow Ether (ETH), the currency of the Ethereum blockchain, on Aave, a crypto lending platform where users borrow against assets they deposit. TRM estimates the attacker now holds around $2.4bn in ETH and bitcoin (BTC) beyond any issuer’s reach. 

Four areas deserve particular attention.

Treat engineer and admin endpoints as crown jewels. Threat actors beyond North Korea routinely get in through people: impersonating IT staff, ClickFix lures, fake recruiters and trojanised apps. Use dedicated conditional access policies for privileged accounts, phishing-resistant MFA, and endpoint detection and response (EDR) tools tuned to alert on new developer tooling. 

2. Limit access to live systems

Remove standing access to production from laptops. Admin access should be just-in-time, brokered through a bastion host, short-lived and recorded. No engineer device should be able to open a shell inside a container that can initiate payments.