The Binance $6.3 Billion Heist Retrospective: When Employees Become the Weakest 0day

Compiled & Written by: KarenZ, Foresight News

In June, a Binance wallet engineer searched for an AI coding tool on a search engine and downloaded a tampered software package; a few months later, another engineer attended an online interview and, at the interviewer's request, downloaded a coding assignment; a month after that, attackers were already able to use internal AI tools to control both individuals' computers and find the credentials leading to core infrastructure.

This is not a cybersecurity movie, but rather an attack path reconstructed by Binance in its preliminary investigation report on the October 29 security incident, published on November 3.

The incident involved approximately $6.34 billion in digital assets. Binance stated that attackers exploited unauthorized access to an internal wallet signing service to initiate transactions outside the normal withdrawal process. The U.S. Federal Bureau of Investigation (FBI) attributed the incident to North Korea.

But if one focuses only on the asset transfer that ultimately occurred, it is easy to overlook the most alarming part of this attack: the attackers did not suddenly break into Binance on October 29. Rather, they began searching for entry points months earlier, gradually infecting employee devices, gaining internal access, and then using enterprise internal tools to move closer to the wallet infrastructure.

Binance described this process as a multi-stage campaign and explicitly stated that it was not an isolated system intrusion, nor a simple phishing attack.

From the supply chain attack in June, to the fake recruitment in September, to the use of internal AI tools in October to expand access, the attackers effectively completed a combined infiltration targeting personnel, devices, software, and the permissions system.

This attack chain also serves as a wake-up call for the entire crypto industry: when the security of an exchange's core assets is connected to the development tools, AI applications, and internal permission systems that employees use daily, attackers may not need to breach the strongest door first.

Sometimes, all it takes is getting one employee to download a software package that looks perfectly normal.

June: It Started with a Tampered Homebrew Package

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

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

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

But if an installation package is maliciously tampered with, the normally benign software installation process can become a channel for malicious code to enter a computer. This type of attack is known as a supply chain attack.

Unlike traditional phishing attacks, supply chain attacks do not necessarily require directly tricking users out of their passwords. Instead, they hide malicious code within software, tools, or update processes that users trust, causing users to execute malicious programs while using software normally.

For developers, this type of risk is particularly worth guarding against. Their work computers typically have numerous 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 the anomaly at the time and proactively replaced Engineer A's device while rotating all related credentials.

But the attackers had already come into contact with this engineer's work role and his associates on the wallet infrastructure team.

In other words, even though the device was replaced and credentials were rotated, the attackers could still continue looking for other entry points to try to get closer to the same team.

September: A Fake Recruitment That Let Malicious Code into a Work Computer

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

Engineer B had publicly listed his professional experience on a legitimate job platform, including his work at Binance. Subsequently, a person claiming to be a Project Director at a certain company proactively contacted him and invited him to an interview.

The entire recruitment process was designed to be quite elaborate.

The first round of interviews was conducted by a person claiming to be an HR representative, with both parties communicating via live video. To build trust, the other party also shared a social media account containing personal photos and videos.

After the first round ended, the attackers continued to push the process forward.

The second round of interviews moved to a popular social chat app. Near the end, the other party asked Engineer B to download a code repository called "Assignment" and run it on his work computer.

For software engineers, downloading code, configuring a development environment, and completing technical tests is a normal part of the recruitment process.

But this code repository actually contained malicious code. According to Binance's disclosure, the attackers used code obfuscation and detection evasion techniques, including replacing components of legitimate development tools with malicious versions capable of executing commands and establishing communication with attacker-controlled external servers.

Binance described it as 0-day malware that was not detected by endpoint security protection tools at the time. The attackers also attempted to hide malicious activity and erase related traces, increasing the difficulty of subsequent detection and investigation.

• Binance even disclosed the specific operations the malicious script performed on the pyenv tool on Engineer B's computer:
• Created a new pyenv_ file;
• Replaced the originally legitimate pyenv component with a malicious version;
• Deleted the original legitimate file;
• Renamed the malicious file to pyenv;
• Deleted the original command entry point, recreated the symbolic link, and launched zsh.

pyenv is a common Python version management tool. By replacing its legitimate components, the attackers made the malicious program masquerade as a normal development tool to execute commands and connect to external servers.

The stealthiness of this type of attack lies in the fact that users may still be able to use familiar development commands normally without knowing that the underlying program has been replaced.

A seemingly ordinary technical interview thus became the entry point for attackers to get into an employee's work computer.

October 20: Internal AI Tools Drawn into the Attack Chain

If the first two stages were about how to get into employee devices, then what happened on October 20 meant the attackers began expanding within Binance's wallet team.

Binance disclosed that the attackers used the already compromised computer of Engineer B, along with an internal Binance AI tool, to further take control of the computers of Engineer A and another wallet software engineer, Engineer C.

Binance did not disclose the specific name of this AI tool, nor did it explain which of its features the attackers exploited. Therefore, it cannot be concluded that the AI model itself had a vulnerability, nor should it be simply attributed to a prompt injection attack.

What can be confirmed, however, is that the internal AI tool was incorporated into the attackers' path to expanding access.

As AI tools enter enterprises, they may become connected to code repositories, knowledge bases, development environments, and other internal services. The access permissions, authentication mechanisms, and operation logs that these tools possess 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 isolated software runtime environment in which development teams can package applications and their dependencies for deployment to servers or the cloud.

A container deployment permission token can be understood as a pass to invoke the relevant deployment capabilities. It is not a wallet private key, but if it carries permission to access critical internal environments, it could become an entry point for getting closer to core systems.

At this point, the attackers had not only taken control of employee devices but had also found permission credentials capable of connecting to internal deployment systems.

October 29: From Employee Computers to the Wallet Signing Service

On October 29, the attack entered its final stage.

According to Binance's disclosure, between 17:15 and 19:56 (UTC) that day, the attackers logged into Engineer C's computer, used credentials previously stolen from Engineer A to deploy a container, and triggered a malicious script to formally launch the attack.

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

Binance stated that the incident involved approximately $6.34 billion in digital assets. The attackers also exploited the Ethereum EIP-7702 authorization mechanism to grant an attacker-controlled smart contract partial execution permissions over Binance's hot wallets.

57 Suspected North Korean Attack Attempts: The Crypto Industry Needs to Re-examine Internal Security Boundaries

In its report, Binance also disclosed that since 2026, its security team has detected and blocked 57 cyber threat incidents suspected to be 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 social engineering tactics to steal credentials or deploy remote access malware. A previously issued FBI advisory also attributed the Binance incident to North Korea and referred to the related malicious cyber activity as TraderTraitor.

This means that attacks targeting crypto companies have long moved beyond simply looking for smart contract vulnerabilities or stealing user private keys. Attackers are also continuously studying enterprise internal personnel, software environments, and permission systems.

For exchanges, traditional security defenses need to extend further inward.

Employee devices need stricter isolation and monitoring; development tools and software packages need source verification; internal AI tools should follow 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 be able to easily move laterally from a work environment to the wallet signing system.

This incident is not a simple story of vulnerabilities in EIP-7702 or AI tools themselves, but a combined attack revolving around personnel, devices, software, and permissions.

In the past, the crypto industry's greatest fear was private key theft; now, a more alarming question is: even if private keys are not leaked, can attackers force the system to execute operations it should not perform by taking control of internal processes?

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

Regarding follow-up measures and remediation, Binance stated that it has engaged 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 behavioral anomaly monitoring. Meanwhile, Binance is establishing a security research fund and working with leading AI companies, industry participants, and security firms to launch a specialized initiative focused on AI security in blockchain environments.