Deconstructing the Binance Exploit

How One Signed EIP-7702 Delegation Led to Billions in Outflows, and the Fireblocks Controls That Cut the Same Attack Path

On October 29, 2026, attackers drained Binance hot wallets across multiple blockchains. Estimates of gross outflows run from $3.3B to $6.3B, including roughly $450M in ETH and billions in USDT and USDC. Either end of that range exceeds the $1.5B Bybit hack of February 2025. The first sweep landed within minutes and activity continued for over an hour. Binance has not published a verified figure, and roughly $2.8B was frozen by stablecoin issuers and others.

The attack path points to a structural risk common across Web3 infrastructure: signing authority reachable from privileged engineering machines without a second cryptographic boundary.

October has been a significant month for the cyber world, with several major vulnerabilities disclosed, including php2shell, HTTP2Shell, the eMudhra certificate authority compromise and other major events. As AI expands attacker capabilities and likely accelerates vulnerability discovery, this pace will not slow down. Enhanced tools and vulnerabilities like these are how attackers get a first foothold on engineering machines, which is exactly where the Binance attack started. Crypto is one of the most targeted sectors, and often the first to be hit, because the payoff is direct and fast. Crypto platforms, and any company entering digital asset markets, need a security posture built to withstand the wave of incidents coming in the months ahead.

The Attack Flow: How the Exploit Unfolded

Binance’s preliminary investigation points to a compromised DevOps engineer’s laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions, The exchange has since found additional points of breach but claims there is no evidence private keys leaked. Reports attribute the attack to the North Korean Lazarus Group same as the 2025 Bybit hack. The reported sequence was:

1. DevOps Machine Compromise: Per Binance’s preliminary findings, the attacker gained persistent access to a workstation with deployment access and signing capabilities.
2. EIP-7702 Delegation Injection: The attacker used Ethereum’s EIP-7702 standard to set a new authorization, not to compromise an existing EIP-7702 contract. An authorization is a signed message that assigns a contract’s code to an externally owned account (EOA), so that code runs whenever the wallet is called. This one delegated a primary hot wallet address (Binance 14) to a malicious contract.
3. Automated Fund Execution: Within three minutes of the delegation, an attacker-controlled contract called the hot wallet, which ran the malicious code and transferred out 167,464 ETH and $1.615B in USDT. The attacker then drained 780M USDC from secondary hot wallets.
4. Preparation & Persistence: The attacker prepared in advance: a contract deployed earlier that day, funding through Tornado Cash, and a rehearsal on test wallets. One transaction carried 50 authorizations, so at least one would be valid when processed. The delegation let one attacker-controlled address drain the wallet, including new deposits, and the attacker reused that access more than an hour later. The 780M USDC came from Hot Wallet 34, also owned by Binance 14. Binance 16 was also targeted. Activity spanned Ethereum, Arbitrum and Avalanche. The reported Bitcoin and Tron movements cannot be explained by EIP-7702.
5. Dispersal & Laundering: Chainalysis reported laundering patterns it had not seen before, with stolen funds circulating repeatedly among addresses and often returning to wallets used earlier, which may point to automation. It also saw the funds commingle with proceeds of last month’s Bitget exploit, which was already attributed to North Korean actors.

Securing the Path from Developer Machine to Signing Authority

A primary takeaway from this incident is that no single developer or DevOps machine should ever possess unilateral authority to deploy or alter wallet permissions.

To prevent a compromised endpoint from escalating into a total treasury breach, organizations must implement strict pipeline segregation:

• Dedicated, Enclave-Backed Deployment Machines: Move deployment authority off local developer laptops. Code compilation, signing, and contract deployment should execute exclusively inside isolated build environments (such as AWS Nitro Enclaves or confidential VMs).
• Mandatory Multi-Party Approvals: Enforce mandatory code and script reviews for all operational deployments. Any script or transaction modifying wallet delegation, proxy targets, or permission structures must require multi-admin cryptographic sign-off before hitting production.
• Workstation Hardening & Least-Privilege Scoping: Lock down DevOps endpoints with zero-trust network access (ZTNA), strict application whitelisting to managed devices only, and hardware-backed credential storage (e.g., KMS/HSM) to ensure raw keys or tokens cannot be extracted even if a machine is compromised.
• Developer Supply-Chain: North Korean groups go after developers directly: fake job interviews with coding tests, malicious npm packages, VS Code extensions. Ensure strong focus on developer-controls such as extension and package allowlists, a holding period on newly published packages, and running untrusted code in sandboxes.
• Keys Unreachable from Endpoints: Hot-wallet keys should live in MPC/HSM-backed custody and never be usable from a developer machine. EIP-7702 requires a valid signature from the wallet’s own key, so treat any signature produced outside your signing platform as an incident.
• Control Who Can Request a Signature, Not Just Where Keys Live: The signing layer should check every request on its own terms and never trust a request just because of where it came from.

Mitigating Exploit Blast Radius with Fireblocks Architecture

Relying solely on endpoint security is insufficient against persistent threat actors. A true defense-in-depth framework assumes that endpoints will eventually be compromised and places strict architectural barriers to stop lateral movement. Every safeguard below depends on correct configuration: policies, quorums, allowlists, balance caps, access restrictions and role scopes.

Fireblocks Security Posture Management (FSPM) continuously monitors workspace configuration and surfaces misconfigurations, risky policies and excessive permissions, with severity ratings and remediation guidance, so you can use it to find gaps against each control in this post.

Leaked Credentials / Compromised API

• IP Whitelisting: API calls and console access are restricted strictly to pre-approved CIDR ranges. API keys used outside those ranges are automatically blocked.

Privilege Escalation & Unauthorized Actions

• Policy & Governance Engine: Enforces granular, cryptographically backed policies. Even if credentials are stolen, policies restrict destination addresses, limit transaction amounts, and require multi-user admin quorums for high-risk operations. For EIP-7702, the control has to sit on the authorization itself, because a wallet delegated to a malicious contract can be drained with no further signature. A policy that restricts raw signing and allows only transfer operations closes that path, and a wallet upgrade limits delegation to the audited Fireblocks EIP-7702 contract only.
• Co-signer Callback (Trust but Verify): Each signing request goes to your own server, where logic you build can approve or reject it before it is signed. Policy rules set what is allowed; your callback adds an independent check to prevent unauthorized transactions.

Separation of Duties and Wallet Segregation

• Cold Treasury & Warm Withdrawal Tiering: To prevent a single point of failure, separate wallets by function. Keep most assets in cold treasury vaults (air-gapped, with multi-user quorum approvals). On the hot side, run a warm wallet as the withdrawal pool and fund it with only the minimum it needs. Structure the flow in two steps: rebalancing from cold to warm is manual and quorum-approved, and payouts from the warm wallet to withdrawal pools are programmatic, from a low-exposure wallet. A compromised automation path can then reach only the funds in that pool, which stay bounded by hard balance caps, strict rate limits and restricted permission sets.
• Hot-Wallet Balance Caps: Tie balance caps to daily withdrawal volume and cap any automatic top-off as well. A hot wallet that refills itself from other wallets with no volume limit lets an attacker keep draining it. One receiving address collected an estimated $3.52B within 40 minutes of the Binance sweep.
• Least-Privilege Access for Users and API Keys: Give each API key the minimum permissions its operation needs, and back that with a policy that blocks it from doing more. A stolen key then carries only a narrow scope, and anything outside it is rejected by policy.

Real-Time Threat Detection & Risk Exposure Management

In rapid-fire exploits like EIP-7702 delegation attacks, early detection and automated responses are vital to containing the damage. Fireblocks provides real-time visibility into unauthorized signature attempts and state changes:

• Audit Log Notifications: Operational state changes in your workspace generate audit log notifications and automated alerts to security teams. Connect them to your own SIEM so these events land alongside the rest of your security telemetry.
• Uninitiated Transaction Detection (“Transaction Not Broadcast”): If a compromised workstation or external actor signs an unauthorized payload that violates policy rules, Fireblocks flags the anomaly instantly. The transaction is flagged as suspicious while alerting SecOps to the exact device and credential source attempting the execution.
• Automated Fail-Close Safeguards: Integrated transaction scanning and real-time threat detection simulate transactions before signing. If anomalous contract calls or unlimited spending approvals are detected, the system automatically closes execution pathways to protect the remaining assets.

The Fireblocks EIP-7702 Contract & Governance Safeguards

Disclaimer: The Binance exploit involved authorizing a malicious contract, not compromising an existing EIP-7702 contract. Fireblocks’ EIP-7702 architecture is unrelated, audited, and protected by strict policy controls.

Fireblocks uses EIP-7702 account abstraction to add smart contract logic to EOAs. Controlled delegation enables Universal Gasless transfers routed via verified relayers without requiring native gas tokens.

The underlying smart contract architecture is audited and verified. Built-in protections control delegation and raw signing flows:

• Wallet Upgrade Limits Delegation: A wallet upgrade limits delegation to the audited Fireblocks EIP-7702 contract only, which prevents a malicious contract from taking over the wallet.
• Raw Signing Policy: Because raw signing of delegation payloads carries inherent risk, create a policy that restricts raw signing and allows only transfer operations.
• Typed Message Signing Block: Fireblocks also blocks typed message signing that bypasses Fireblocks policy into the contract.

Conclusion

The Binance exploit shows that security cannot rest on perimeter defenses or implicit trust in internal developer tooling. Protecting institutional assets requires treating every endpoint or server as a possible point of compromise, separating operational roles, enforcing strict policy quorums, and leveraging real-time transaction clarity to catch unauthorized signatures before they are sent to the blockchain. These controls only work when configured correctly, so verify them continuously, not just at setup.