Compiled & Written by: KarenZ, Foresight News

In June, a Binance wallet engineer searched for AI programming tools on a search engine and downloaded a tampered software package; months later, another engineer participated in an online interview and, at the request of the interviewer, downloaded a coding assignment; another month passed, and attackers were able to control both individuals' computers using internal AI tools and obtain credentials to access core infrastructure.

This is not a cybersecurity movie, but an attack path recreated in a preliminary investigation report on a security incident released by Binance on November 3, which occurred on October 29.

This incident involved approximately $6.34 billion in digital assets. Binance stated that the attackers gained unauthorized access to internal wallet signing services to initiate transactions outside of normal withdrawal processes. The Federal Bureau of Investigation (FBI) attributed this incident to North Korea.

However, focusing solely on the eventual asset transfer overlooks the most concerning aspect of this attack: the attackers did not suddenly breach Binance on October 29 but had been looking for entry points for months, gradually infecting employees' devices, gaining internal access, and using corporate tools to approach wallet infrastructure.

Binance refers to this process as a multi-stage attack and clearly states that it is not an isolated system breach or a simple phishing attack.

From the supply chain attack in June, to the fake recruitment in September, and in October leveraging internal AI tools to expand access, attackers successfully completed a combined infiltration targeting personnel, devices, software, and privilege systems.

This attack chain has also sounded the alarm for the entire cryptocurrency industry: when a trading platform's core asset security is linked to the development tools, AI applications, and internal privilege systems that employees use daily, attackers may not need to break down the strongest door first.

Sometimes, all it takes is for an employee to download a seemingly normal software package.

June: Starting with a Tampered Homebrew Installation Package

The attack preparation process disclosed by Binance can be traced back to June 2026.

At that time, an engineer from the wallet DevOps team (Engineer A) searched for a popular AI programming tool on a search engine and downloaded a tampered Homebrew installation package.

Homebrew is a common package management tool that allows developers to quickly install various development software and tools.

However, if the installation package has been maliciously altered, the originally normal software installation process can become a channel for malicious code to enter a computer. This type of attack is called a supply chain attack.

Unlike traditional phishing attacks, supply chain attacks do not necessarily require directly stealing user passwords; instead, they embed malicious code within software, tools, or update processes that users trust, causing users to execute the malicious program while normally using the software.

For developers, this kind of risk is particularly alarming. Their work computers usually have various third-party tools installed and may also store access credentials for code repositories, cloud services, and internal infrastructure.

Binance stated that its security team detected anomalies at the time and proactively replaced Engineer A's device while rotating all related credentials.

However, the attackers had already interacted with this engineer's work role and relevant personnel in the wallet infrastructure team.

In other words, even if the device was replaced and credentials rotated, the attackers could continue searching for other entry points, trying to approach the same team.

September: A Fake Recruitment That Allowed Malicious Code into Work Computers

In September, the attackers targeted another software engineer (Engineer B), employing a more deceptive social engineering attack.

Engineer B openly shared his career experience, including his time working at Binance, on a legitimate job platform. Subsequently, a person claiming to be a Project Director from a certain company contacted him and invited him for an interview.

The entire recruitment process was designed to be quite complete.

The first interview was conducted by someone claiming to be from HR, with both parties communicating via real-time video. To build trust, the other party shared a social media account containing personal photos and videos.

After the first round, the attackers continued to advance the process.

The second-round interview was moved to a popular social chat application. Near the end, the other party requested Engineer B to download a code repository called "Assignment" and run it on his work computer.

For software engineers, downloading code, configuring development environments, and completing technical tests are normal recruitment steps.

However, this code repository actually contained malicious code. According to Binance, the attackers used code obfuscation and evasion techniques, including replacing components of legitimate development tools with malicious versions, allowing them to execute commands and establish communication with external servers controlled by the attackers.

Binance described it as zero-day malware, which was not detected by endpoint security protection tools at the time. The attackers also attempted to hide malicious activities, eliminate relevant traces, and increase the difficulty of subsequent detection and investigation.

• Binance even publicly disclosed the specific operations of the malicious script on Engineer B's computer's pyenv tool:
• Create a new pyenv_ file;
• Replace the original legitimate pyenv component with a malicious version;
• Delete the original legitimate file;
• Rename the malicious file to pyenv;
• Delete the original command entry, recreate symbolic links, and launch zsh.

Pyenv is a common Python version management tool. By replacing its legitimate components, the attackers allowed the malicious program to disguise itself as a normal development tool, thus executing commands and connecting to external servers.

The stealth of this attack lies in the fact that users may still be able to use familiar development commands normally, unaware that the underlying program has been replaced.

A seemingly ordinary technical interview thus became the entry for the attackers into the employees' work computers.

October 20: Internal AI Tools Involved in the Attack Chain

If the first two stages addressed how to enter employees' devices, then the events on October 20 meant that the attackers began to expand within the Binance wallet team.

Binance disclosed that the attackers utilized the already compromised Engineer B's computer and an internal AI tool of Binance to further control Engineer A's and another wallet software engineer C's computers.

Binance did not disclose the specific name of this AI tool, nor did it specify what functionality the attackers leveraged from it. Therefore, it cannot be concluded that the AI model itself contained vulnerabilities or simplistically classified as a prompt injection attack.

However, it can be confirmed that the internal AI tool was included in the attackers' path to expand their access.

As AI tools enter the enterprise, they may connect to code repositories, knowledge bases, development environments, and other internal services. The access permissions, authentication mechanisms, and operation records possessed by the tools thus become part of the enterprise security system.

This incident also exposed another critical issue.

Binance stated that the attackers quickly discovered that Engineer A's computer stored a Container Deployment Permission Token.

A container is a relatively independent software runtime environment where development teams can package applications and their dependencies to deploy to servers or the cloud.

The Container Deployment Permission Token can be understood as a pass to call relevant deployment capabilities. It is not the wallet private key, but possessing the authority to access key internal environments may become an entry point to further approach core systems.

At this point, the attackers were not only controlling employees' devices but had also found credentials that could connect to internal deployment systems.

October 29: From Employee Computers to Wallet Signing Service

On October 29, the attack entered its final phase.

According to Binance, between 17:15 and 19:56 (UTC) on that day, the attackers logged into Engineer C's computer, deployed a container using credentials stolen from Engineer A, and triggered a malicious script, officially launching the attack.

Subsequently, the attackers leveraged unauthorized access to the Binance internal wallet signing service to initiate transactions outside the normal withdrawal process.

Binance stated that this incident involved approximately $6.34 billion in digital assets. The attackers also exploited the Ethereum EIP-7702 authorization mechanism, enabling a smart contract controlled by the attackers to gain partial execution permission to Binance's hot wallets.

57 Suspected North Korean Attack Attempts: The Crypto Industry Needs to Reassess Internal Security Boundaries

Binance also disclosed in its report that since 2026, its security team has detected and prevented 57 suspected cyber threat incidents related to North Korea.

These attack attempts involved fake recruitment interviews, malware disguised as popular development tools, tampered software packages and browser extensions, fake video conferencing applications, and credential theft or deploying remote access malware through social engineering, among other methods. The FBI had previously issued a statement attributing this Binance incident to North Korea and referred to the related malicious cyber activities as TraderTraitor.

This indicates that attacks on cryptocurrency enterprises are no longer merely about finding smart contract vulnerabilities or stealing user private keys. Attackers are also continuously studying internal personnel, software environments, and privilege systems.

For exchanges, traditional security perimeters need to further extend to the internal realm.

Employee devices require stricter isolation and monitoring; development tools and software packages need source validation; internal AI tools should adhere to the principle of least privilege; and credentials such as container deployment tokens should not be stored long-term on ordinary employee devices.

More importantly, even if employee accounts and devices are compromised, attackers should not easily move laterally from one work environment to the wallet signing system.

This incident is not a simple story of vulnerabilities existing in EIP-7702 or the AI tools themselves, but a combined attack involving personnel, devices, software, and privileges.

In the past, the cryptocurrency industry was most concerned about private key theft; now, a more pressing question is: even if private keys are not leaked, can attackers control internal processes to have the system execute unauthorized operations?

This may be the most important security lesson the Binance incident leaves for the entire industry.

Regarding follow-up measures and rectifications, Binance stated that it has hired independent third-party cybersecurity experts to conduct a comprehensive review of the incident and will increase investment in AI security detection, endpoint protection, developer environment security, and abnormal behavior monitoring. At the same time, Binance is establishing a security research fund and collaborating with leading AI companies, industry participants, and security firms to launch a special program focused on AI security in blockchain environments.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。