Can Money Be Stolen Without Stealing the Key?

What the key is allowed to sign

In principle, no. But it is too early to conclude that this is how the Binance hack happened.

A private key is needed to create a signature. In a large payment system, however, that key sits within a surrounding structure of software, staff, approval rules and access restrictions. Someone or something must determine the recipient, the amount and whether a transaction is allowed before a signature is created.

The key may be held in secure storage. If an outsider gains the ability to issue instructions to the signing system, they do not necessarily need to take the secret itself. In that scenario, the genuine key continues doing its job—except that it signs something the legitimate owner never intended to authorise.

This is the distinction examined by Hacken: stealing a key and taking control of transaction signing are different ways to produce an apparently valid transaction. A valid signature alone cannot reliably tell us which explanation is correct.

For a user, the word ‘confirmed’ usually means that a person saw a transfer and agreed to it. Cryptographically, a signature says something different: the transaction was signed with the corresponding key. It does not, by itself, reveal how the decision was made.

That is why asking whether a key is well protected does not complete a security review. There is another question: who can make it work, and under what circumstances?

Why one laptop does not explain everything

TRM Labs highlighted transfers from wallets on different blockchains. These networks use different rules and signing schemes, yet during the attack their wallets produced valid signatures to send funds to the attacker. The researchers consider a compromise of Binance’s signing infrastructure the most likely explanation. That is their assessment of the observed activity, not a published diagram of the exchange’s internal architecture.

This leaves room for an author’s interpretation: the problem may have been at an authorisation layer on which different wallets depended. In that case, differences between the blockchains could not protect against a shared weakness in the systems around them.

But ‘may’ is essential here. We do not know whether there was a shared service, several connected access points or some other sequence of events. We cannot invent a single server simply because that explanation fits neatly into a headline.

The account involving an employee deserves the same care. A compromised device may be part of an intrusion path. By itself, it proves nothing about the intentions of the person who used it.

The answers that matter

Binance has promised to publish a detailed report once the investigation is complete. In the verified November 1 update, that was still a future step.

It would be useful for that report to offer more than the name of the first infected machine. How did a transfer request reach the signing stage? What checks were supposed to stop unusual transactions? Were those checks independent, or did they rely on the same underlying information?

These are questions, not a list of failures that have already been established.

The statement that keys were not leaked matters to the investigation. Yet even if it is ultimately confirmed, another task will remain: explaining why protected keys were used to send money to an outsider.