The Binance hack began on one laptop: what to test in your own systems

What happened in the Binance hack?

The Binance hack is the theft of about USD 6.3 billion in cryptocurrency from Binance’s hot wallets on October 29, 2026. According to TRM Labs, it is the largest crypto theft on record, about four times the USD 1.5 billion that attackers took from Bybit in February 2025. Public reports give this sequence:

1. At 20:05 UTC, funds started to leave Binance wallets on ten blockchains. Most of the money moved in the next 20 minutes.

2. On Ethereum, the attacker used an EIP-7702 delegation, with 50 authorizations signed in advance, to turn a Binance hot wallet into a sweeper that the attacker controlled.

3. Stablecoin issuers froze funds during the night. TRM counted about USD 2.7 billion frozen at 00:30 UTC on October 30, and Tether alone froze about 1.77 billion USDT.

4. Binance suspended deposits and withdrawals and said that it would cover all losses with its Secure Asset Fund for Users (SAFU) and its own funds.

5. In a later update, Binance said that its investigation had “uncovered additional points of breach” beyond the laptop.

EIP-7702 is an Ethereum feature, added in 2025, that lets a regular account delegate its actions to smart contract code through a signed authorization (EIP-7702). The Hacker News quotes Binance’s statements, and Chainalysis gives its own estimate of about USD 2.8 billion frozen.

What is a hot wallet, and why do attackers target it?

A hot wallet is a cryptocurrency wallet whose signing system is online, so that an exchange can process withdrawals without a person in the loop. A cold wallet keeps its keys offline and needs manual steps for each transfer. Exchanges keep most funds in cold storage and a working balance in hot wallets.

The important detail is in Binance’s statement: it found no evidence that a wallet private key leaked. The 50 authorizations that TRM describes were signed in advance, so something had to sign them. If both facts hold, the attacker did not steal the keys. The attacker made Binance’s own systems sign. When a signing service signs any well-formed request from a trusted internal service, control of that internal service is enough to move funds.

This is not specific to crypto. A payment service, a core banking API or a transfer queue in a bank has the same weak point when it trusts every request that comes from inside the network.

How did the attacker reach Binance’s withdrawal system?

Binance’s preliminary account describes this path:

1. The attacker compromised a laptop that a DevOps engineer used. Binance has not said how.

2. From that laptop, the attacker got access to a service container in Binance’s infrastructure.

3. The attacker used that container to submit unauthorized withdrawal transactions.

4. Binance’s hot wallet infrastructure signed those transactions, and the funds left on ten blockchains.

Treat the laptop as a working hypothesis, not a confirmed root cause. Co-CEO Richard Teng told CoinDesk that the theft was not a single “one-click” action, that the EIP-7702 delegation got around Binance’s normal approval controls, and that a self-destruct mechanism wiped the attacker’s tools and traces. Binance is reviewing its cloud systems, employee devices, key management and signing. Each step in the path is a control point: the attacker had to pass all of them, and the defender had to stop only one.

Has the same chain of access caused losses in other organizations?

Yes. Banks, exchanges and wallet providers have lost money through the same sequence: the attacker compromises a person or a system with privileged access, and then uses that access to reach the system that moves money. These public cases follow that pattern:

Latin America has seen the first part of this chain too: an employee of Chile’s interbank network Redbanc was tricked into downloading malware, as we described in our post on cybersecurity in financial services. In each case, the first target was a person with privileged access, not a public application. We covered earlier exchange thefts in Top 10 crypto crimes.

How can Fluid Attacks help you test each link?

Endpoint protection and security awareness defend the first link. Most of the later links depend on how the software is written and configured, and Fluid Attacks tests them before an attacker does. These are the five links that we check in banking and fintech applications.

1. Secrets in repositories and pipelines

An attacker who controls a developer’s laptop can read every repository that the developer can read. Credentials, API keys and tokens in source code, configuration files or Git history turn that access into access to other systems. Look for sensitive information in source code, including credentials and secrets that were deleted but remain in Git history. The fix is to remove the secret, rotate it and move it to a secrets manager. Fluid Attacks’ secret scanning finds exposed secrets in code, configuration and infrastructure as code (IaC), and can break the build in your CI/CD pipeline when it finds one.

2. Malicious and vulnerable dependencies

Attackers also deliver malware through software packages and fake coding tests, as the DMM Bitcoin case shows. In September 2025, a phishing attack on an npm maintainer put code that redirected crypto transactions into npm packages with over 2 billion weekly downloads, as we explained in our analysis of that npm attack. Check each dependency for known vulnerabilities and for malware, and pin versions so that a new release does not enter a build without review. Our software composition analysis (SCA) builds a software bill of materials (SBOM) and ranks vulnerable dependencies by real risk.

3. Privileged functions inside your applications

Many applications have functions for operations teams: administration panels, support endpoints, debug routes, service accounts and tokens that services use to call each other. These functions often get less review than customer features, because only internal users reach them. After a laptop compromise, the attacker is an internal user. Check that each privileged function requires strong authentication, that each role has only the permissions that it needs (excessive privileges), and that no route lets a person act on production data without the normal controls. In our secure code review, analysts trace who can call each of these functions and with which identity.

4. Authorization and business logic in money-movement flows

The withdrawal system is where the attack turns into a loss. Teng’s statement that a delegation got around the normal approval controls shows why: an approval step that a second path can skip does not protect anything. Check how the services that create, approve and sign transactions authenticate each request, and what they check before they act on it:

• Does the signing service verify which service sent the request and that the request went through approval?

• Does a large or unusual transfer need a second, independent approval?

• Are there amount limits, rate limits and time delays that an operator can change only in a separate system?

Flaws here are improper authorization control and business logic weaknesses, and automated scanners rarely find them. Our pentesters test these flows in PTaaS: they try to move money with the access that a compromised employee would have.

5. Infrastructure as code

If your repositories define infrastructure in Terraform, Kubernetes manifests or Docker Compose files, a configuration flaw is also a code flaw. A container that runs with excessive privileges, a cluster role that any pod can use or a network rule that lets workstations reach production services makes the attacker’s second step easy. A pull request that changes a role binding or a firewall rule deserves the same review as a change to payment code. Static application security testing (SAST) checks these files with the rest of the code, before they reach production.

Which controls depend on operations rather than code?

The Binance hack began with the access that one person had to production systems. Application code cannot fix that, so it needs its own regular review. Validate the access of your technical team to production:

• List who has access to production and confirm that each person still needs it.

• Grant access for a limited time, after approval, instead of permanent access.

• Require multi-factor authentication for every production access, preferably a method that phishing cannot capture, such as a hardware security key. Keep sessions short: in the Bybit theft, the attacker reused an AWS session token that had already passed MFA.

• Make sure that no one can reach production containers or services directly from a work laptop. Use a controlled access path, such as a bastion host or an access broker, that records each session.

• Log each access and each sensitive action, and send alerts when activity is unusual, such as a burst of withdrawals at an unusual hour.

Cloud configuration is part of this review. Cloud security posture management (CSPM) checks identity and access settings in your cloud accounts against security requirements on a continuous schedule.

FAQ

Was a Binance private key stolen?

Binance said that it found no evidence that a wallet private key leaked. Its preliminary statement says that the attacker submitted unauthorized withdrawal transactions through a service container. This suggests that the attacker used systems that Binance’s signing infrastructure trusted, not stolen keys. The postmortem will confirm or correct this.

Is EIP-7702 a vulnerability?

No. EIP-7702 is a standard Ethereum feature that lets an account delegate its actions to smart contract code. Public reports do not describe a flaw in EIP-7702 itself. They describe authorizations that Binance’s own systems signed and that skipped its usual approval controls. The weak point was which requests the signing infrastructure accepted.

Can a code scanner detect an attack like this?

Not the first step. A compromised laptop is an endpoint security problem, and a scan of your code will not show it. Scanners and code review find the flaws that make the later steps easier, such as exposed secrets, vulnerable dependencies and missing authorization checks. The business logic of money-movement flows needs manual pentesting.

Test the flows that move money before an attacker does

The practical lesson from the Binance hack: list every flow in your systems that can move money, list every person and service that can start one, and test what an attacker can do with each of those identities. Start with the flows that have the highest limits and the fewest approvals. This table maps each link to the Fluid Attacks technique that tests it:

If your fraud and engineering teams track these risks separately, our post on security and fraud risk shows how to bring them together. You can try our tools with a 21-day free trial or contact us to plan a test of your transaction flows.