Binance’s October 29, 2026 hack, estimated at around $6.3 billion, exposes a particularly troubling infiltration method. The attackers allegedly did not begin by breaking the cryptographic protections securing the wallets. Instead, they reportedly compromised engineers’ computers, exploited their professional access and then hijacked internal mechanisms used to authorize transactions.
On November 3, Binance detailed an operation that had been prepared over several months. A first engineer installed compromised software in June. A second was lured in September by a fake recruitment process. The attackers then allegedly used an internal artificial-intelligence tool to move through the company’s systems before stealing credentials and carrying out the attack.
In brief
- Binance describes a multi-stage infiltration that began before the October 29 theft.
- The hijacking of authorizations does not, by itself, demonstrate that private keys were leaked.
- Security controls must separate workstations, deployments and signing decisions.
1. Binance was infiltrated over several months
June 2026: compromised software opens the first door
The attack began several months before the cryptocurrency theft. It shows why crypto wallet security also depends on the systems used to prepare transactions.
The incident warrants a detailed technical analysis. How can a simple job interview compromise a platform safeguarding billions of dollars? What role did AI actually play? Why did the security systems not stop the transfers immediately? And, above all, what safeguards could prevent a compromised workstation from turning into a financial catastrophe?
According to CoinDesk’s account of the briefing, Binance said the attackers hijacked its internal access. In its official October 30 statement, the platform said it had found no evidence that private keys had been leaked.
In June 2026, a Binance engineer was looking for an artificial-intelligence-related tool. As part of that search, the engineer installed a compromised software component associated with Homebrew.
Homebrew is a widely used package manager for macOS and Linux. It allows developers to install software, libraries and programming tools from a terminal without manually downloading and configuring each application.
For example, a command such as brew install followed by the name of a piece of software requests its installation.
The problem does not necessarily originate with Homebrew itself. Attackers can hijack a tool’s distribution chain, offer a malicious package or manipulate the source from which a program is retrieved.
In Binance’s case, publicly available information indicates that the engineer installed an altered component. It is not enough to establish that Homebrew’s official infrastructure was hacked.
Binance said it detected the malware and replaced the computer. By then, however, the attackers had already obtained useful information about the engineer’s role and colleagues working on cryptocurrency wallets.
This is a crucial distinction in cybersecurity. Removing malware does not erase information the attacker has already collected.
An attacker may retain information about an organization’s structure, employee names, internal tools, deployment processes or relationships between different teams. That information can be used to prepare a more targeted attack.
September: a fake recruitment process lures in a second engineer
A few months later, another software engineer received a professional offer through a legitimate recruitment platform.
The contact introduced himself as a company’s project director. Someone posing as a human-resources manager arranged a video interview. The fake recruiter also shared a social-media profile featuring personal photographs.
The aim was to build a credible relationship.
A second interview was then arranged with someone presented as the company’s chief executive.
After the discussion, the candidate was asked to download a code repository containing a technical exercise.
This is common practice in technology recruitment. Candidates may be asked to review a project, fix bugs, write tests or develop a feature.
The attackers exploited precisely that habit.
The repository contained malware that Binance said evaded the protections on the employee’s work computer. CoinDesk’s account uses the term “zero-day malware.” That wording alone does not identify a specific vulnerability or CVE number. The publicly available material reviewed does not detail how the workstation’s protection was bypassed.
The trap worked because the engineer believed he was completing a legitimate professional exercise. He was not trying to bypass Binance’s security; he was responding to a request that looked like a routine stage of a recruitment process.
This is known as social engineering: manipulating a person into carrying out an action that facilitates an intrusion.
October: the attackers use AI to move through the systems
On October 20, according to Binance’s head of security, the attackers used the computer compromised during the fake recruitment process and an internal AI tool to access the systems of two engineers working on wallets.
This detail is particularly important.
This was not simply a public chatbot that the attackers asked how to steal cryptocurrency. The reported information points to the use of an internal tool as part of an intrusion that was already under way.
Depending on its permissions, an AI assistant integrated into a professional environment may be able to inspect code, search files, interact with development tools or perform certain operations.
If the computer running that assistant is compromised, its capabilities may become useful to the attacker.
However, Binance has not publicly detailed every command executed by the AI tool or demonstrated that it made malicious decisions autonomously.
It would therefore be incorrect to claim that AI hacked Binance on its own. The attackers remained responsible for the operation; AI allegedly served as an instrument that helped them advance.
October 29: the theft is carried out
On October 29, the attackers moved to the financial phase.
According to Binance, they used a compromised computer and credentials stolen from another engineer to deploy a computing container and execute a malicious script.
A container is a software environment that runs an application together with its dependencies. It is widely used to deploy IT services reproducibly.
At a company such as Binance, some internal services communicate with the infrastructure that manages transactions and wallets.
At 20:05 UTC, funds began leaving the wallets. The attackers notably exploited an Ethereum feature called EIP-7702 to hijack execution authorizations for an Internet-connected wallet.
According to the explanation reported by CoinDesk, transfers linked to this mechanism were not fully contained until around 00:10 UTC on October 30.
Timeline of the intrusion, according to Binance
- June 2026: First engineer compromised by altered software.
- September 2026: Second engineer lured by a fake recruitment process.
- October 20: Movement into the wallet team’s systems with the help of an internal AI tool.
- October 29: Stolen credentials used and malicious script deployed.
- October 29–30: Unauthorized transfers, incident containment and asset-freezing operations.
- November 3: Binance publishes a more detailed timeline of the attack.
2. How the attackers bypassed wallet security
Stealing a deployment token is not the same as stealing a private key
Understanding this attack requires distinguishing between three elements that are often conflated: professional credentials, deployment tokens and crypto wallet private keys.
A private key is a cryptographic secret used to sign transactions. Depending on the wallet’s type and operating rules, whoever controls it may authorize the transfer of funds.
A deployment token is different. It authenticates a user or service with IT infrastructure to perform certain operations, such as publishing a new application version, launching a container or updating a service.
Such a token can be extremely sensitive when the service it accesses is involved in processing financial transactions.
Imagine a bank with a vault protected by several keys. Employees may not have direct access to those keys. They may nevertheless use a computer system that prepares operations, requests authorizations and sends instructions to the vault.
If an attacker manages to manipulate that system, they may try to make it prepare or approve a fraudulent operation.
That is the risk illustrated by the Binance incident.
The published information describes the use of stolen credentials to deploy a container and execute a malicious script. It does not yet make it possible to fully reconstruct the precise role of each token in the exploitation chain.
One misleading simplification should therefore be avoided: stealing a deployment token does not automatically amount to authorization to empty a wallet.
For the attack to succeed, other conditions must be present, including excessive privileges, a weakness in transaction validation or the compromise of trusted components.
Why MPC is not enough to validate legitimate intent
Binance uses multiparty computation mechanisms, known as MPC, to protect certain cryptographic operations.
The principle is to distribute the signing process among several parties, as explained by the NIST in its work on threshold cryptography. It should not be confused with a multisignature system using several distinct keys.
Rather than storing a complete private key on a single computer, the system allows several components to participate in producing a valid signature without necessarily reconstructing the key in one place.
This is an important safeguard.
But it does not solve every problem.
If an attacker compromises the components that decide which transactions should be signed, they may try to make a system approve fraudulent operations even though its cryptographic keys remain protected.
The signature may then be technically valid, while the transaction does not reflect any legitimate intent.
In Binance’s case, the attack also exploited a particular feature of Ethereum.
EIP-7702: a legitimate feature put to malicious use
EIP-7702 is an Ethereum protocol upgrade introduced with the Pectra upgrade in May 2025.
The EIP-7702 specification allows conventional Ethereum accounts to delegate execution to smart-contract code through a signed authorization. That delegation persists until it is changed or revoked; it does not automatically expire at the end of the transaction.
A smart contract is a program executed on the blockchain. It can automatically enforce rules, transfer assets or interact with other contracts.
The feature has legitimate uses, including improving user experience and account management. These developments are part of the evolution of smart wallets and account abstraction.
The attackers nevertheless exploited the mechanism to obtain execution rights over a Binance hot wallet.
A hot wallet, or online wallet, remains connected to Internet-accessible systems so it can process deposits and withdrawals quickly.
In its on-chain analysis of the attack, TRM Labs described several EIP-7702 authorizations that had been signed in advance so that one could be used at the appropriate time.
Why prepare several authorizations?
On Ethereum, an account’s transactions use a counter called a nonce. Among other things, this mechanism helps prevent certain transactions from being reused.
For a highly active wallet, the counter changes rapidly.
Preparing several authorizations corresponding to different possible nonce values allows an attacker to adapt to the wallet’s counter at the time of exploitation.
According to TRM Labs, the attackers had prepared 50 authorizations covering a sequence of nonce values. One of them could be used.
The mechanism then allowed them to hijack the wallet’s execution and transfer its assets.
This does not mean that EIP-7702 is itself a security flaw. It is a feature whose authorizations must be protected particularly carefully.
Why stopping withdrawals was not immediately enough
When a crypto platform detects a hack, its first response is generally to suspend withdrawals.
That measure normally prevents users and malicious actors from requesting new transfers through the usual interfaces.
However, not every blockchain operation necessarily passes through those interfaces.
If an attacker has already obtained valid authorizations or hijacked a component capable of signing transactions, they may sometimes continue to act directly on the blockchain.
This was one of the difficulties Binance faced.
CoinDesk reported that revoking the malicious authorization on Ethereum was complicated by the MPC architecture used to protect signatures. Containing the mechanism therefore took several hours. Hypernative’s independent analysis also places the revocation at around 00:10 UTC on October 30.
One clarification is necessary: Binance’s first communications referred to stopping outflows after withdrawals were suspended. Later technical explanations revealed a more complex situation involving EIP-7702 authorizations. These statements should be considered in chronological context rather than treated as one definitive technical account.
The financial scale of the attack
Figures communicated as of November 3, 2026
$6.3B
Approximate value of the assets affected
$2.85B
Assets frozen according to Binance
98%
Affected tokens reconstructed, according to the company
10
Blockchains tracked within TRM Labs’ scope
Figures reported by Binance and specialist media. Freezing assets does not necessarily mean they have been definitively recovered.
Binance said user losses would be covered and that the affected assets had largely been reconstructed using company funds.
Three financial operations must be distinguished.
The first is freezing cryptocurrency. Some stablecoin issuers can block tokens under their control when a transaction is linked to fraudulent activity.
The second is the actual recovery of assets. This may require legal proceedings, international cooperation or the involvement of other platforms.
The third is reimbursing users or replenishing reserves with the company’s own funds.
A platform can therefore protect its customers from a financial loss without recovering the cryptocurrency that was initially stolen.
Who is behind the attack?
In an alert published on October 31, the FBI attributed the operation to North Korea and referred to the activity as TraderTraitor.
Companies specializing in blockchain transaction analysis also identified similarities with the methods of the TraderTraitor group, which is associated with North Korean operations.
Pyongyang disputes the attribution.
Attributing a cyberattack generally relies on a combination of indicators: infrastructure used, malware, infiltration methods, fund movements and similarities with previous operations.
It should not be confused with a definitive judicial identification of every participant.
3. How to reduce the risk of another attack of this kind
The most important lesson from the incident is that a company can have excellent cryptography and still remain vulnerable to an attack targeting its employees and development tools.
Preventing a comparable operation requires strengthening several layers of security at the same time.
1. Isolate engineers’ computers
The first problem is the possibility of using a sensitive work computer to install or run code from an external source.
In a financial organization, not every computer should have the same rights.
A developer working on ordinary applications may need to install libraries and run external projects. An engineer working on wallet-signing infrastructure should operate in a far more restrictive environment.
Protection can rely on separating two workstations or environments.
Development workstation
Testing, recruitment, external software
Critical environment
Signing, deployments, wallets
Unapproved files and programs should not be able to move freely from the first environment to the second.
In practice, this separation can be achieved with dedicated machines, secure virtual desktops or isolated administrative environments.
The principle is simple: a computer used to test an unknown project must never have direct access to the privileges needed to modify critical financial infrastructure.
Even if malware infects the first workstation, the attacker should encounter another independent barrier.
2. Secure Homebrew installations and dependencies
Banning all external tools would be difficult to reconcile with developers’ work. Their origin and execution must therefore be controlled, in line with the NIST SSDF framework for secure software development.
A company such as Binance should notably implement the following measures:
- Allow only approved software repositories and registries.
- Verify the integrity and, where possible, the signatures of downloaded packages.
- Use an internal mirror to distribute validated software.
- Review installation scripts, particularly those run with elevated privileges.
- Block the direct installation of unknown programs on sensitive workstations.
- Analyze software dependencies and monitor their updates.
Organizations should also avoid a dangerous practice: downloading a script from the Internet and immediately running it with user or administrator privileges.
An apparently harmless script may install another program, collect credentials or establish communication with a server controlled by the attacker.
Controls must also cover code-editor extensions, Python libraries, npm packages and AI tools intended for developers.
Software supply-chain security is not limited to major applications. It sometimes begins with a dependency installed in a matter of seconds.
3. Neutralize fake job interviews
The attack on the second engineer shows that recruitment procedures are also an attack surface.
Companies should train employees to recognize suspicious signals without assuming that training alone is enough.
A credible video interview does not guarantee that a company is authentic. A recruiter may present fake professional profiles, use stolen identities or create a convincing website.
For employees in sensitive roles, external recruitment exercises should be carried out in an isolated environment.
The engineer could download, inspect and run the project in a disposable virtual machine with no professional secrets and no connection to internal systems.
The environment should be destroyed after the exercise.
However, a virtual machine is not an absolute safeguard. Its configuration, network access, shared folders and hypervisor vulnerabilities must also be controlled.
A particularly useful organizational rule would be to treat every technical exercise received from an external recruiter as untrusted code, even when the interview appears legitimate.
4. Protect deployment tokens
This is probably one of the most important measures for preventing a cyber intrusion from turning into a financial theft.
A deployment token should never provide access to more resources than a specific task requires.
This is the principle of least privilege.
A token intended to deploy a monitoring application should not be able to modify a transaction-signing service.
Organizations should also favor short-lived credentials generated for a specific operation over permanent secrets stored on engineers’ computers.
Recommended measures include strong authentication, automatic credential rotation, centralized secret vaults and detailed logging of every use.
For critical operations, tokens should be tied to a verifiable service identity and a specific context.
For example, a token authorized to publish a version from an approved deployment pipeline should not be freely reusable from an engineer’s personal computer.
Even if the token is stolen, it becomes far less useful to the attacker.
5. Prevent unauthorized deployments
A company holding billions of dollars in cryptocurrency should not allow a single compromised workstation to modify the behavior of its critical financial services.
Sensitive deployments must go through an independent validation process.
This may include mandatory code review, signed software artifacts, approval by several managers and automated verification of changes before they reach production.
It is also possible to prohibit the execution of containers whose images do not come from an approved internal registry.
An admission policy can verify that a container has a valid signature and corresponds to an authorized version.
These controls are particularly useful against attacks based on stolen credentials.
The attacker may succeed in authenticating without being able to deploy any program they choose.
6. Separate signing authorizations from IT operations
MPC and multisignature mechanisms must be accompanied by independent validation of transaction content.
The question is not only whether a transaction has a valid cryptographic signature.
It is also necessary to verify whether the transaction is authorized under the company’s financial rules.
A robust system should check destination addresses, amounts, transfer limits, transaction types and changes to wallet permissions.
In Ethereum’s case, EIP-7702 authorizations require specific controls.
A corporate wallet could, for example, prohibit by default any delegation to an unapproved contract.
Changes to signing authorizations should require validation separate from the one used for ordinary withdrawals.
In other words, a service capable of preparing a payment should not be able to freely change the rules determining who is allowed to authorize that payment.
This is a fundamental separation.
7. Govern artificial-intelligence agents
The alleged use of an internal AI tool in the Binance attack opens a new area of cybersecurity work.
Modern coding assistants can access files, query code repositories and sometimes run commands or use external services.
Their capabilities are useful to developers. They can also amplify the consequences of a compromise.
Organizations should therefore avoid giving AI agents permanent, broad permissions.
An agent should access only the resources required for the task at hand.
Running sensitive commands, accessing secrets and carrying out deployments should be subject to additional controls.
Human approval can be useful, provided it is genuinely independent and gives the person enough information to understand what they are authorizing.
Instructions contained in external files, code repositories or documents accessed by the AI should also be treated as untrusted data.
This protects against prompt injections described by OWASP, in which malicious content attempts to make an assistant act against its user’s intentions. This does not mean that a prompt injection was demonstrated in the Binance incident; here, it is a general defensive recommendation.
Finally, agents’ actions must be logged and monitored. An agent that begins accessing unusual secrets, exploring resources unrelated to its mission or preparing sensitive deployments should trigger an alert.
AI must never become a way to bypass the security rules that apply to human users.
8. Prepare a genuinely effective emergency shutdown
The Binance incident highlights an additional difficulty: suspending withdrawals on a platform may not be enough to neutralize all authorizations already present on the blockchain.
Companies must prepare emergency procedures suited to each type of wallet.
For Ethereum, this notably means knowing how to quickly detect and revoke suspicious EIP-7702 delegations when the account configuration allows revocation.
Teams must also have the means to isolate compromised services, revoke credentials, suspend deployments and prevent the creation of new transactions.
These procedures should not be improvised during an attack.
Regular exercises can simulate the compromise of an engineer, the theft of a deployment token or the takeover of a signing service.
The goal is to measure how long the organization takes to detect, understand and contain the incident.
For a platform moving billions of dollars, a few minutes can represent substantial losses.
9. Detect attacks before the first transfers
One of the most concerning aspects of the incident is how long the operation was prepared.
Several months elapsed between the first reported compromise in June and the theft on October 29.
Effective monitoring must therefore go beyond financial transactions.
It must also identify unusual behavior on engineers’ computers, attempts to access sensitive systems and changes to permissions.
Security logs may reveal connections at unusual times, unexpected deployments or the use of credentials from unauthorized environments.
Behavioral analysis, potentially assisted by AI, can help identify these anomalies.
But it must be combined with human verification and response procedures.
Binance has said it intends to strengthen its AI-assisted detection capabilities, work with independent experts and develop new security research initiatives. These remain commitments announced by the company, whose effectiveness will still need to be assessed.
10. What precautions should Binance users take?
Ordinary customers cannot directly prevent an attack on a platform’s internal infrastructure. They can nevertheless reduce their exposure.
Two-factor authentication, preferably with a physical security key or a passkey, remains important for protecting their own account.
Users should also use a unique password, enable login alerts and regularly check authorized devices.
For significant amounts intended to be held for a long period, a personal hardware wallet can reduce dependence on the security of a centralized platform. However, this solution requires strict protection of the recovery phrase and carries its own risks.
Users should also beware of messages claiming to help hacking victims. After a widely reported incident, fake support services, as seen in cases linked to Coinbase, may try to steal credentials or recovery phrases.
No legitimate support service should ask a user to disclose their secret phrase.
What Binance still needs to demonstrate
The October 29 hack is not merely a story about malware, AI or fake recruitment. It exposes the risks of an architecture in which compromising several development tools can ultimately affect the mechanisms protecting financial assets.
The use of multiple engineers, distributed cryptographic authorizations and security tools did not prevent the operation.
That does not make these safeguards useless. Their effectiveness depends on their independence. If several security controls can be manipulated through the same chain of compromise, accumulating them does not guarantee genuine separation of risk.
Binance’s priority now is to document precisely the permissions that were hijacked, the components that were compromised, the signing mechanisms that were exploited and the controls that did not work as intended.
The platform says it has largely reconstructed the affected assets. This is an important financial response for users. On its own, however, it does not prove that the vulnerabilities enabling the attack have been eliminated.
No company can guarantee that it will never be breached again. It can, however, design its systems so that an infected computer, a fake job interview or a stolen token is not enough to compromise billions of dollars.
It is this ability to contain an incident, more than its reimbursement promises, that will determine how Binance’s future security should be judged.
The facts concerning the intrusion are based notably on Binance’s statements reported during its briefing and on the analyses cited. The recommendations are a defensive analysis; BrefCrypto has not audited their actual implementation by Binance.
