The official Binance released a preliminary investigation report on the security incident of October 30 on November 3, disclosing the scale of the attack, fund recovery, technical paths, and subsequent security measures.
This was not an ordinary single-point phishing incident, but a multi-stage attack involving social engineering, malware, internal AI tools, terminal devices, wallet signing services, and on-chain authorization mechanisms.
The official report shows:
- The digital assets involved in the incident are valued at approximately $6.34 billion;
- As of October 31, approximately 98% of the affected token assets have been replenished;
- Approximately $2.85 billion of digital assets have been frozen or intercepted;
- Binance stated that it would bear the entire loss of the stolen funds, rather than the users;
- As of November 3, affected wallet systems have been rebuilt in a new environment, and related credentials and devices have also been disposed of or reinforced with scans.
For the market, the value of this report lies not only in disclosing loss figures but also in breaking down a complex attack into multiple analyzable security links: how internal permissions were obtained, why the signing service became a key entry, how the EIP-7702 authorization mechanism was abused, and why additional on-chain operations were still needed to completely revoke permissions after suspending withdrawals.
1. The core of this incident is not the direct theft of private keys
According to the Binance report, the attacker did not simply obtain a wallet private key to transfer assets but gained access to the internal wallet signing service through a multi-stage intrusion and used that permission to bypass the normal withdrawal process to initiate transactions.
This distinction is very important.
Modern trading platforms typically do not place hot wallet private keys directly on ordinary servers but instead use multiparty secure computation, permission layering, signing services, and risk control systems. This reduces the risk of single-point private key leaks but also introduces new security focuses:
- Who can call the signing service;
- Which devices can initiate signing requests;
- Which tokens can deploy containers or access internal tools;
- How the system identifies abnormal transactions;
- How on-chain authorizations can be revoked quickly.
This incident demonstrates that security boundaries are not just “whether the private key is leaked” but also include the combinatorial relationships between identity, devices, credentials, code, deployment permissions, and on-chain authorizations.
2. Attack process: From social engineering to hot wallet transfers
The attack preparation process disclosed by the official presents a long attack chain.
Phase 1: Finding entry points through supply chain and malicious tools
In June 2026, an engineer from the wallet development and operations team downloaded a tampered Homebrew installer. The Binance security team detected anomalies at that time and changed devices and rotated related credentials, but the attacker had already obtained some information from the wallet infrastructure team.
This indicates that development tools and installation packages have become high-value attack surfaces. What seems like a normal programming environment may connect to code repositories, deployment systems, container platforms, and internal AI tools, and once contaminated, subsequent impacts can be amplified step by step.
Phase 2: Implementing social engineering using fake recruitment
In September, another engineer was approached by an attacker impersonating the project director and CEO through a legitimate job platform. The attacker built trust through video interviews, social media life information, and multiple rounds of communication, later requesting the engineer to download an "interview assignment" that included a code repository.
This type of attack is more difficult to recognize than traditional phishing emails because it utilizes a complete interpersonal interaction process. The attacker does not directly ask for a password but rather causes the victim to actively run malicious code.
Phase 3: Entering internal AI tools from terminal devices
On October 20, the attacker, via the infected engineer's device, further controlled the devices of wallet development operations engineers and another wallet software engineer, discovering a token with container deployment permissions.
This is also a very noteworthy aspect of this incident: the internal AI tool itself was not the end target of the attack, but it became a springboard for the attacker to move laterally and expand permissions.
Phase 4: Gaining wallet signing operation capabilities
In the early hours of October 30, the attacker logged into the engineer's device, deployed containers using stolen credentials, and executed malicious scripts, ultimately triggering wallet signing operations.
From the timeline, the attacker completed critical penetration between 01:15 and 03:56, and then transferred large amounts of assets to the attacker-controlled address between 04:05 and 04:09.
3. What assets were specifically transferred?
The Binance report disclosed that the attacker quickly initiated asset transfers across multiple networks:
- Five hot wallets transferred approximately 233.46 million XRP;
- Solana network hot wallet transferred approximately 970,500 SOL;
- Optimism network hot wallet transferred approximately 44.2 million OP;
- Binance hot wallet transferred to the attacker-controlled address 18,270 BTC;
- The final unauthorized 2,961.9 ETH transfer was confirmed at 07:56.
Subsequently, Binance received an internal alert about the large transfer and initiated an investigation, suspended withdrawals, coordinated with partners to freeze assets, and took measures to revoke unauthorized permissions.
Currently, approximately $2.85 billion in assets have been frozen or intercepted, and the specific amount may still be affected by market price changes.
4. The most complex technical aspect: Abuse of EIP-7702 authorization
In this incident, the attacker also abused the Ethereum EIP-7702 authorization mechanism.
EIP-7702 allows accounts to delegate some execution authority to smart contracts without exposing private keys. It was originally designed to expand account capabilities, improve user experience, and support more flexible account abstraction scenarios, but any authorization mechanism must be paired with strict permission boundaries and revocation processes.
In this incident, the attacker established delegated authorization through maliciously signed transactions, allowing the controlled smart contract to obtain part of the affected hot wallet's execution permissions. Afterward, the attacker was able to bypass the normal withdrawal infrastructure of Binance to continue transferring assets.
The official report disclosed that the attacker submitted 50 signed transactions, manipulated the account random number, and established malicious delegated authorizations. Even if Binance paused withdrawals, these already-existing on-chain authorizations would continue to operate independently and would not automatically expire due to the withdrawal system being shut down.
This brings an important security conclusion:
Suspending centralized withdrawal processes does not equate to revoking all on-chain authorizations.
When on-chain authorizations have already taken effect, platforms also need to initiate additional on-chain transactions to revoke or override malicious delegations one by one.
5. Why do MPC wallets also need to design emergency revocation mechanisms?
The Binance report explains that affected hot wallets use multiparty secure computation technology and do not have a single private key that can be directly used to immediately revoke EIP-7702 authorization.
The advantage of MPC is that private keys do not exist in complete form on a single device or node; however, in the event of special authorization anomalies, the system cannot simply “pull out a master private key” to complete the revocation.
This forces the security team to redesign a special revocation process, increasing the time required to control the incident comprehensively.
For wallets and trading platforms, MPC protection, smart contract authorization, and emergency recovery mechanisms must be designed simultaneously. The security system cannot only consider “how normal signatures are completed” but also needs to consider:
- How abnormal signatures can be blocked;
- How authorizations can be quickly frozen;
- How on-chain permissions can be revoked;
- How multiparty computing systems can execute emergency operations;
- How to prevent other on-chain paths from continuing to transfer funds after withdrawals are suspended.
6. What measures has Binance taken?
As of November 3, the measures disclosed by Binance include:
- Rebuilding the affected wallet systems in a new environment;
- Rebuilding affected internal AI tools and strengthening access control;
- Replacing affected devices;
- Disabling credentials and tokens used by relevant engineers;
- Completing enhanced security scans on employee devices;
- Enhancing AI-based behavior anomaly detection capabilities;
- Strengthening risk control for wallet services;
- Tracking and freezing assets in collaboration with law enforcement agencies, blockchain intelligence organizations, and industry partners.
Binance also stated that it will invite independent cybersecurity experts to conduct a comprehensive review and increase investment in AI security, endpoint protection, development environment security, and behavioral anomaly monitoring.
7. What does this incident mean for users?
Binance officials stated that they will bear the entire loss of the stolen funds and not pass it on to users, and as of October 31, 98% of the affected token assets have been replenished.
Users can verify relevant information through the Binance reserve page and follow official updates on independent reviews and the investigation progress.
From the perspective of users' own security habits, this incident also reminds everyone to distinguish between different asset management scenarios:
- Hot wallet on trading platform is managed by the platform responsible for signing systems, permissions, and risk control;
- Self-hosted wallets are managed by users themselves for recovery phrases, private keys, and signature confirmations;
- Smart contract authorizations, once on-chain, may operate independently of normal withdrawal processes;
- The stronger the AI Agent, automation wallets, and account abstraction functions are, the more important the design of permissions becomes.
When using wallets, DeFi, or AI Agents, users should pay attention to the authorization content, transaction objects, limit amounts, and revocation entry points, rather than just looking at whether the product is convenient.
8. From the perspective of data analysis platforms, how to track the follow-up of this incident?
These types of security incidents should not only look at one-time loss figures. More valuable analytical dimensions include:
- The replenishment progress of affected assets;
- The handling speed of the remaining 2% after 98% has been replenished;
- The follow-up attribution of the $2.85 billion frozen assets;
- The abnormal transaction interception rate after the reconstruction of the affected hot wallet systems;
- The permission contraction situation of the wallet signing service;
- The revocation and monitoring mechanisms of EIP-7702 authorization;
- The speed at which the AI behavior detection system identifies anomalies;
- Whether the independent security review discloses new improvement conclusions.
For the industry, it can also further observe whether different platforms will adjust:
- Hot wallet balances and fund diversification strategies;
- The combination method of MPC and smart contract authorization;
- Permission isolation of internal AI tools;
- Security audits of supply chain software and development environments;
- Large transfer warning and automatic suspension mechanisms.
These data are more valuable than simply comparing “which platform has experienced incidents” because they can reflect whether the platform's recovery capabilities and security investments have truly taken effect after the incident.
Conclusion: Security is not a function, but a continuously operating system
The scale and technical complexity of this incident indicate that the security issues of crypto platforms have expanded from "protecting private keys" to protecting a complete system of identities, devices, credentials, code, signing services, smart contract authorizations, and emergency response mechanisms.
The Binance officials have disclosed subsequent measures such as asset replenishment, system reconstruction, permission revocation, AI anomaly detection, and independent security reviews. For the market, the most noteworthy aspect going forward is whether these measures can be verified through continuous data and review results.
For users, transparent disclosure, asset replenishment, and independent reviews are crucial steps in rebuilding trust; for the entire industry, this incident once again demonstrates that the stronger the functions and higher the automation levels, the more critical permission isolation and emergency revocation capabilities become.
Security events deserve to be reviewed, but what truly determines a platform's long-term competitiveness is whether it can implement the review results as verifiable system improvements.
Exclusive benefits for AiCoin users
👉 Use the invitation code SEPRFR9Q when using the Binance wallet to enjoy 10% transaction fee rebate, making meme trading cheaper and more profitable.
🔗 Exclusive link:
https://web3.binance.com/referral?ref=SEPRFR9Q
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
