The Binance hack and a lesson in how to manage a catastrophe

On October 29, about $6.34 billion in digital assets were stolen from Binance, in the largest crypto theft on record. According to the company, $2.85 billion were frozen or intercepted. On November 3 it published an initial report, apologizing and describing the whole process, including its own mistakes.

Binance said on October 30 that it had found no evidence of any wallet private key leak. According to the report, the attacker used unauthorized access to an internal wallet signing service to initiate transactions outside the normal withdrawal process.

I don't think people are getting this hack wrong. But, in general, I think they don't really grasp that a service with access to send transactions for a key to sign is, in practical terms, basically the same thing as having the key compromised. As I told WIRED Middle East, "once software with signing permissions is compromised, it doesn't really matter if the key itself is secure."

What happened

In June, an engineer installed a tampered version of Homebrew. Binance detected the anomaly, replaced the computer and renewed the credentials, but that engineer's role and that of the wallet team were exposed to the attacker. In September, another engineer was approached on a job platform and, after a fake interview, downloaded onto a work computer an "assignment" with a malicious repository. On October 20, from that computer and with an internal AI tool, the attacker compromised two more engineers on the wallet team, among them the one from June, who had a token to deploy containers. On October 29, the attacker deployed a container with a malicious script. That container would have had privileged access to the software that signs withdrawals. On October 30, Binance had already said that access to a service container allowed unauthorized withdrawals to be submitted.

Between 20:05 and 20:09 UTC, five hot wallets sent 233 million XRP. On Ethereum, the attacker used the signing service to give a contract of their own, through EIP-7702, partial execution rights over a hot wallet, with 50 pre-signed authorizations, one for each upcoming transaction number. That hot wallet used MPC, with no single private key, and that did not stop the theft. The last transfer was finalized at 23:56 UTC, almost four hours after the first ones.

Where it could have been stopped

The biggest cybersecurity problem companies have is always the same: people. There is a lot that can be done to build a strong security culture, because, at the end of the day, a team that is aware of the risks has fewer problems than one that isn't. However, a company has to recognize that humans are weak and that, at some point, they will make a mistake. That is why its security systems have to take this into account and seek resilience that, as far as possible, does not depend on any human.

As this case shows, there are several levels of prevention. First, engineers must know they can't do personal activities on the company computer, and that would have prevented any malicious file coming from a fake job interview. Assuming they knew and were fooled anyway, monitoring systems can do a better job of checking the files being downloaded to the machines, the sites they come from and inbound and outbound traffic, among other things. Binance says the malware, which it classifies as a 0-day, was not detected by its endpoint security tools.

In the end, the problem always comes down to the most standard things in cybersecurity: least privilege, continuous monitoring of files and applications on employees' computers, frequent rotation of service account credentials and tokens, and making sure those accounts only have the privileges they need. All of this is easy to say, but at the end of the day it is hard to plug every hole, especially when it is a nation trying to get in. The FBI attributes the attack to North Korea.

One thing is certain: if it isn't normal for these amounts of money to be withdrawn, the service should have gone into lockdown right at the first transaction. That might not have solved the authorizations placed on-chain on Ethereum, and the report says suspending withdrawals did not automatically invalidate them, but it could at least have prevented some transactions on other blockchains. Between the first transfer, in XRP, and the theft of $1.47 billion from the Bitcoin hot wallet, fifteen minutes went by.

Data: TRM Labs and Galaxy Research.

Measures can also be implemented to check in advance how much money a transaction is going to extract, and tied to which user, and to block it in suspicious cases. To sign a new message, you have to identify clearly what it contains. In the case of the EIP-7702 authorization used on Ethereum, which gave a malicious smart contract access that was hard to revoke, you at least have to understand who you are giving those authorizations to, and block anything unwanted. Binance says it is reviewing signing policy coverage and hot wallet controls.

It remains to be seen why the compromised credentials reached this level of access. The report doesn't explain it, and warns that some technical details will remain confidential.

Timeline according to the Binance report.

How Binance responded

That said, I give 10 out of 10 to the way Binance handled the situation after the attack. "This should not have happened," it writes, before apologizing to its users, partners and the wider industry. The report shows transparency and detail. Binance admits security failures in its team and in its monitoring systems, which makes the announcement far more genuine. What sets this case apart is the unprecedented magnitude of the hack and the exemplary way they handled a catastrophe of this size.

On October 30, I told Bloomberg that, while Binance claimed it would cover the losses, "at the end of the day we will have to wait and see." It was a pragmatic statement. On November 1, Binance said it had replenished approximately 95% of the impacted assets, and the report mentions 98%. Galaxy estimated, on October 30, that the net loss was around 4% of the roughly $144 billion in assets Binance held before the attack, while warning that it can't verify the company's whole financial condition. The company writes that it will absorb the financial impact, not its users. Which, once again, shows how Binance was able to do right by its users and, to some extent, preserve the relationship of trust with them and with the whole industry.

Some may say that Binance's first statement, on the same day, assured that user funds were "completely safe", and that the cause started out as one engineer's laptop and turned out to be a chain spanning months. But in the first hours of a crisis nobody has the full picture, and Binance kept correcting the explanation in public as the investigation progressed. And the assurance given to users is being honored.

The investigation continues and the independent review the company announced is still to come. Even so, the response was a true lesson in how to manage a catastrophe. Maybe people don't realize just how well Binance handled this.