On Thursday, starting at around 4pm ET, hackers started quickly siphoning around $6.3 billion in cryptocurrencies, spread across multiple blockchains, from wallets belonging to crypto exchange Binance. According to analysis by crypto tracing firm TRM Labs, the majority of the stolen crypto was taken in a period of around 20 minutes on October 29.
What happened
The theft spanned multiple blockchains and moved fast. Following the theft, Binance almost immediately suspended all deposits and withdrawals from its services as part of its investigation into the hack.
Some of the funds have been stopped downstream. Elliptic's Robinson says that around $2.8 billion, or around 44 percent of the total amount stolen, has been frozen by crypto companies and exchanges so far, with almost all of this being stablecoins.
How it was done
The full path in has not been published. Binance's own account describes a starting point that widened as the investigation continued.
Our initial investigation suggested that the security incident may have involved a compromised laptop, however, our subsequent investigation has uncovered additional points of breach.
Beyond that, the details are still being worked out.
What to check
If your systems can move value or sign transactions, these are worth verifying this week.
Inventory which endpoints can reach signing systems
Pull the list of hosts with network or credential access to your signing, treasury or payout services from your asset inventory and firewall rules. Cross-check it against your managed device list. Any laptop that can reach a signing path but is not fully managed and monitored is a bad result.
Test that you can halt transfers in seconds
Run a drill of your withdrawal and payout kill switch in a staging environment, and time it from decision to effect. Confirm who can trigger it out of hours and that it does not depend on a single person or one unavailable system. Anything that takes a change deploy to activate is too slow.
Check for approval steps that one compromised account can satisfy
Review your signing policy and multi-party approval configuration for quorum thresholds, and look for shared accounts, break-glass keys or automation identities that count as an approver. A single credential that can both propose and approve a high-value transfer is the pattern to remove.
Alert on transfer volume and velocity, not just single large amounts
Add rules that fire on the rate of outbound transfers per minute and on value moving to newly seen destinations. Replay the last 90 days of transfer logs through the rule to see whether it would have fired. If only per-transaction limits exist, many small transfers in a short window pass unnoticed.
Confirm logs survive an endpoint being wiped
Check that endpoint, authentication and signing-service logs ship off host in near real time, and verify retention in your SIEM covers at least the period your incident plan assumes. Pick one developer laptop and confirm its logs are queryable centrally. Gaps after a reimage mean no reconstruction later.
Hunt for a second foothold, not just the first
After any endpoint compromise, query authentication logs for the affected identity across every system, not only the one that raised the alert, and review tokens, SSH keys and API credentials issued since the earliest suspicious activity. Treat closing the first finding as the start of the search.