Binance’s Hot Wallet Used MPC. So How Did Attackers Still Drain It?

On October 29, 2026, Binance suffered a security incident involving roughly 6.34 billion USD in assets (Binance’s figure; TRM Labs puts it at about $6.36 billion). The attackers gained unauthorized access to an internal wallet signing service, initiated transactions outside the normal withdrawal flow, and moved assets out of hot wallets on multiple blockchains.^[1][2]

The affected hot wallets used MPC (secure multi-party computation). In its October 30 announcement, Binance said it had found no evidence that wallet private keys had been compromised.^[3]

So the private keys may never have leaked, yet the assets still left. That leaves an uncomfortable question: if an employee’s laptop, a production server, or even the MPC signing coordinator is compromised, what is left to stop an attacker from moving the funds?

What Happened: From an Engineer’s Laptop to the Wallet Signing Service

According to the preliminary findings Binance published on November 3, this was a multi-stage intrusion that unfolded over several months.^[1]

In June, a wallet operations engineer downloaded a tampered Homebrew installer while setting up an AI coding tool. The security team replaced the device and rotated the relevant credentials, but the identities and roles of some wallet team members had already been exposed.

In September, another engineer ran a project containing malicious code during a fake job interview. Endpoint security tools did not detect the malware at the time.

On October 20, the attackers used the compromised machine and internal AI tools to take over devices belonging to other wallet engineers, and stole container deployment credentials from another wallet operations engineer.

On October 29, the attackers used those stolen credentials to deploy containers and run malicious scripts, and eventually gained unauthorized access to the internal wallet signing service.

Unusual transfers then appeared on XRP, Solana, Optimism, Bitcoin and other networks. TRM Labs’ on-chain analysis found that ten blockchains were affected.^[2]

On Ethereum, the attackers used the same compromised signing service to obtain 50 EIP-7702 authorization signatures in advance, then submitted them in a single on-chain transaction. The authorizations covered a run of consecutive account nonces. One of them matched the account’s nonce and took effect, delegating the hot wallet’s execution logic to a contract the attackers controlled. From that point on, the attackers could keep moving assets through this on-chain permission without touching the normal withdrawal flow.^[1][2]

As of November 3, Binance said about $2.85 billion of the affected assets had been frozen or intercepted.^[1]

Put simply, the attack followed this path:

Compromised employee endpoint → lateral movement inside the network → stolen deployment credentials → unauthorized access to the signing service → assets moved out

There is currently no evidence that the MPC signing algorithm was broken. MPC lets several parties produce a signature together, so the full private key is never stored in one place, which lowers the risk of a single point of key compromise. But the algorithm itself has no way of knowing whether a transaction was properly authorized by the business. If attackers can get enough parties to meet the signing threshold and accept a malicious request, they can produce a valid signature without ever holding the full private key.

Protecting a private key and controlling who gets to use it are two separate security problems.

Binance has not disclosed what checks each MPC signing party performs, so it’s not yet possible to say exactly which link failed. What we do know is that the attackers gained unauthorized access to the internal wallet signing service and got assets out. For institutional wallets, protecting private keys is only part of the job. Signing permissions need to be tightly controlled as well, so that every signature is backed by legitimate authorization.

The attack started on an employee’s computer, and the malware went undetected by endpoint security tools at the time.[1] Against this kind of attack, the first step is stronger endpoint protection and better security awareness among staff:

• Employees shouldn’t download or run developer tools, open-source projects or scripts from unknown sources. Companies should tighten control over software installation, review third-party dependencies, and use antivirus and EDR tools to watch for unusual behavior.
• Internal AI agents should also follow the principle of least privilege, with strict limits on their access to production systems and sensitive credentials, and on their ability to carry out high-risk operations.
• Regular security training, assessments and phishing drills help employees spot fake job offers, malicious projects and supply chain attacks.

Endpoint protection can’t catch everything, though. Once an employee’s computer has been compromised, how do you stop the attacker from moving deeper into the network, picking up more permissions, and eventually taking over the wallet signing service?

Defense in Depth: One Compromised System Shouldn’t Mean Lost Assets

Institutional wallets can’t assume that employee computers, internal networks or production servers will never be breached. What matters is whether an attacker who gets through one layer still has to cross other independent security boundaries before they can get anything signed.

Below we walk through three attack scenarios, each more serious than the last: a compromised employee computer, compromised production deployment access, and attacker control of business systems or even the signing coordinator.

Scenario 1: An employee’s computer is compromised. Don’t let one laptop become a gateway to production.

Taking over one employee’s computer shouldn’t give an attacker access to the whole corporate network and production environment.

The first step is to shrink the network attack surface as much as possible. Public-facing systems should expose only the ports and interfaces they actually need. Internal admin interfaces and production operations entry points generally shouldn’t be reachable from the public internet; they should be accessed through controlled channels, which reduces the risk of core systems being attacked directly. Internal network access should also follow least privilege, granted based on a person’s role, device identity and business need. Ordinary office devices shouldn’t have casual access to production, and developers shouldn’t get admin rights on core production servers by default. Different business systems and security-sensitive zones should each sit behind their own network access boundaries to limit lateral movement.

Second, sensitive permissions need to be kept apart. Development, production deployment, core code authorization and fund operations should each be governed by a separate permission system, so that no single account holds too many critical permissions. Deployment and production access credentials need particular protection. In this incident, the attackers sat on one compromised engineer’s laptop and used credentials stolen from another wallet operations engineer to deploy containers and trigger malicious scripts.^[1]

High-privilege credentials like these shouldn’t sit on everyday office devices for long periods in plaintext or in a directly reusable form. Managed credential storage and on-demand access grants reduce that exposure. Production deployments should also be launched from a controlled environment, so that not just any office device can operate core production systems. On top of that, teams should continuously monitor for unusual logins, cross-system access, changes to sensitive permissions and high-risk operations. When a device or account is found to be compromised, isolate the device, revoke the related credentials and cut off the abnormal access right away. Network isolation and least-privilege controls limit how far an attacker can get from a single compromised account or endpoint, and make it harder to reach critical permissions.

But what if the attacker still manages to steal production deployment credentials and push malicious code into production? How do you stop that code from taking control of core security systems?

Scenario 2: Production deployment access is compromised. Separate the right to deploy from the right to be trusted.

Audited code doesn’t guarantee that the version running in production is the one that was audited. If attackers can swap out a core program and have the malicious version inherit the original’s sensitive business permissions, the audit counts for very little.

That’s why core programs, such as the one that hands out signing computation tasks, need an unbroken chain of trust from development and release through deployment and runtime.

First, reproducible builds should confirm that the released program matches the audited source code. New versions of core programs should also go through independent multi-person review and authorization. Neither the build system nor the deployment team should be able to approve them alone.

For programs that perform critical authorization functions, remote attestation from a trusted execution environment (TEE) can verify the identity of the code actually running and confirm whether that version has been authorized. Only programs that pass this check receive the corresponding sensitive business capabilities.

This way, even if attackers deploy malicious code to production, the unauthorized program fails TEE verification and can’t pose as a trusted program to produce valid transaction authorization results. Keeping production deployment rights separate from trusted program admission means attackers can’t use deployment access alone to replace trusted programs or tamper with core security logic.

Scenario 3: Business systems, or even the signing coordinator, are compromised. Verify authorization and content independently before signing.

Now suppose the attackers control a business server or database and can change transaction amounts, destination addresses, approval records or transaction policies. If the signing system simply trusts this data, it may treat forged transactions as legitimate requests. For critical transactions such as asset transfers, there should be an independent policy verification system that checks transaction authorization, business rules and transaction risk control requirements. This kind of system is usually called a policy engine. It can be built on a TEE so that a compromised business server can’t directly influence the authorization result.

In a TEE-based design, the policy engine checks the relevant authorization signatures on its own, against pre-defined member permissions, approval rules and transaction policies. Once the checks pass, it issues a cryptographically signed trusted report that records the key details of the authorized transaction. The business server can pass transaction requests along, but it can’t forge a valid authorization report just by editing the database or internal API data.

The signing system also needs to know exactly what it is signing.

The EIP-7702 authorizations in the Binance incident weren’t ordinary transfers. They allowed the account to delegate its execution logic to another contract. Once such an authorization takes effect, the attacker can keep moving assets through the delegated contract.[2][4] Similar risks come from token approvals, contract upgrades, permission delegation, and raw hash signatures whose real business purpose can’t be identified.

So the signing system can’t stop at checking the amount and destination address of a regular transfer. It needs to understand what a signature actually does, and put high-risk authorizations behind separate approvals and permission limits. A signing request whose purpose can’t be determined shouldn’t be waved through as if it were an ordinary transfer.

EIP-7702 was only one of the routes the attackers used to move funds. The unusual transfers on Bitcoin, XRP, Solana and other networks didn’t depend on it. Blocking EIP-7702 alone doesn’t fix a compromised signing service.

Even if attackers go on to take over the MPC signing coordinator, that alone shouldn’t give them the final say over signatures.

Before signing, each MPC party should verify the trusted report issued by the policy engine on its own, check the key transaction fields, and rebuild the final message to be signed from the original transaction or authorization data. It shouldn’t rely on the hash the coordinator sends over. If any required signing party fails its checks, it can refuse to sign. This puts MPC’s distributed design to work for distributed verification too, and raises the bar for attackers further.

MPC can also limit unilateral signing power by splitting key shards between the client and the service provider. In a 3-of-3 MPC setup, for example, the client holds one key shard and two independent nodes run by the service provider hold the other two. All three must take part to produce a valid signature, so the service provider can’t sign on its own.

For manual approvals, the client app can also run what-you-see-is-what-you-sign (WYSIWYS) checks, comparing the approval details, the raw transaction data and the final message to be signed on the device itself. Say an approver signs off on sending 100 USDT to address A, and the server later swaps the destination to address B. The client and the other signing parties will catch the change through their own checks.

Automated signing carries a different risk. A client-deployed auto-signing component approves and signs based on pre-authorized business rules. If the client’s business system and the auto-signing component are both compromised, malicious requests could still get valid authorization. The two should therefore be isolated from each other, for example with separate cloud accounts and least-privilege access, and backed by independent transaction policies and limits to reduce the risk of malicious signing.

From trusted programs and trusted admission through to the final signature, every step needs its own independent verification. The signing coordinator can organize the MPC computation, but it should never be the only source of trust for transaction authorization and signing content.

If the Attack Has Already Happened, How Do You Limit the Damage?

Even with several layers of protection in place, you have to plan for the worst case: the attacker already has valid signatures, or has even pushed a malicious authorization through on-chain.

In the Binance incident, suspending normal withdrawals and shutting down the hot wallet service didn’t immediately stop the outflows. The malicious EIP-7702 authorization was already live on-chain and no longer depended on the normal withdrawal flow. Stopping new signing requests doesn’t automatically revoke an on-chain authorization that has already taken effect.

Binance disclosed that because the affected hot wallets used MPC, there was no single complete private key it could use to revoke the authorization directly. The team had to put together a dedicated revocation process on the spot, which slowed the response.[1] This doesn’t mean MPC is inherently hard to work with in an emergency. It shows that institutional wallets need emergency signing and asset recovery capabilities prepared in advance, independent of the normal business flow.

Emergency response has to deal with three different situations:

• Transactions not yet signed: Block new malicious signatures with an emergency signing halt, permission freezes and similar measures.
• Transactions already signed: A valid signature doesn’t become invalid just because the signing service is shut down. How to handle it depends on the specific blockchain and the state of the transaction.
• On-chain authorizations already in effect: These have to be revoked or replaced through a new, valid on-chain operation. Pausing withdrawals won’t take back permissions that have already been granted.

If a wallet is found to be under malicious delegated control, automatic fund sweeping into that address should stop immediately, and it should no longer be issued as a deposit address, so that new funds don’t keep flowing into the compromised wallet.

Beyond stopping losses, you also need to plan for the extreme case where the platform itself can’t operate normally. Institutional wallets should give clients a way to recover their assets that doesn’t depend on the online platform. For example, with complete and valid recovery materials, a client can use an offline tool to recover the wallet’s private key, import it into another wallet, and keep managing or moving assets without needing the original platform to be up and running.[6]

For recovery scenarios that need the service provider’s help, there should be clear processes for identity verification, authorization approval and key shard recovery, tested regularly through drills.

Offline recovery and emergency revocation solve two different problems. The first lets you regain control of assets in an extreme situation. The second shuts down a malicious on-chain authorization that is already live, as fast as possible. One can’t stand in for the other.

Conclusion

In the Binance incident, the attackers used unauthorized access to an internal wallet signing service to move assets out. There is currently no evidence that the MPC cryptography was broken, and Binance has said it has found no evidence that wallet private keys were leaked.[1][3]

The incident shows that private key security is only one part of keeping institutional funds safe. Endpoint security, network access control, separation of staff permissions, trusted code release, trusted admission and independent verification by each MPC party all need their own independent security boundaries.

A compromised employee computer shouldn’t lead straight to the loss of production access. Deployment rights shouldn’t let an attacker replace trusted programs or take over core authorization. And control of the signing coordinator shouldn’t let anyone bypass the independent checks run by each signing party.

Institutional wallets also need an emergency signing halt, on-chain authorization revocation and independent asset recovery ready in advance, to keep the losses from an attack as small as possible.

At its core, defense in depth means no single compromised system or permission should lead directly to the loss of client assets.

Coming soon from Safeheron: API security posture monitoring

Built on behavioral patterns drawn from real-world attacks, the new product detects abnormal API calls and supports alerting and emergency response, adding another layer of protection to the internal network around your asset management systems. Contact us if you’d like an early look.

About Safeheron

Safeheron applies defense in depth across endpoint security, internal access, core program authorization, transaction signing and asset recovery.

At the endpoint and internal access level, Safeheron has deployed endpoint security protection and works through security alerts on an ongoing basis, alongside security awareness training and assessments for staff. Some highly sensitive environments have network access restrictions. Internal system permissions are assigned by job role, and dedicated credential management measures reduce the risk of sensitive credentials being exposed.

At the core program level, admitting a trusted program requires multi-person approval from security, engineering and other key personnel. Trusted admission is independent of production deployment rights, so even operations staff with deployment access can’t authorize a core program on their own. Audited code goes through independent reproducible build verification, multi-party authorization signatures and Intel SGX-based TEE remote attestation, so that critical business capabilities are only granted to authorized, trusted programs.

At the business and signing level, Safeheron uses a TEE-based policy engine to independently verify client authorizations, approval signatures and transaction policies, and to issue trusted reports. The client-side signing component and two isolated cloud nodes complete each 3-of-3 MPC signature together, and every party independently checks the trusted report and transaction data before signing.

For manual approvals, the client app performs WYSIWYS checks. In automated scenarios, the API Co-Signer deployed by the client takes part in MPC signing based on the business authorization result.[5]

For extreme situations, Safeheron provides an open-source offline private key recovery tool. Clients holding complete recovery materials can recover their wallet private keys without the online platform, then import them into another wallet to manage or migrate their assets.[6][7]

Together, these measures combine endpoint protection, permission isolation, trusted code, business authorization, MPC signing and asset recovery to reduce the risk that a single compromised internal system or permission leads to the loss of client assets.

References

[1] Binance, November 3, 2026: 29 October 2026 Binance Security Incident: Initial Findings and Response Update

[2] TRM Labs, October 29, 2026: North Korea Steals USD 6.36 Billion From Binance

[3] Binance, October 30, 2026: Security Incident Update #2

[4] Ethereum Improvement Proposals: EIP-7702: Set Code for EOAs

[5] Safeheron: API Co-Signer

[6] Safeheron: Offline Private Key Recovery

[7] Safeheron GitHub: Offline Recovery Tool