A fake interview, a tampered developer tool, and months of internal movement inside Binance now sit at the center of an industry-wide argument over how an attack reached the exchange’s wallet signing service and led to a theft involving 63 billion in assets.
Binance’s preliminary report, released on Nov. 3, laid out an attack path that started in June 2026. The findings are still under investigation, and the company said they remain subject to independent review. Even so, the report has already prompted a sharper question from security practitioners and exchange operators: once an employee is deceived and a workstation is compromised, what controls are supposed to stop the damage from spreading?
Binance’s timeline runs from a software download to unauthorized wallet signing access
According to Binance, the preparation phase can be traced back to June 2026. That month, wallet operations engineer A downloaded a tampered Homebrew installer through a search engine while trying to install an AI coding tool. Binance said its security team detected the anomaly, replaced the device, and rotated related credentials, but information tied to the engineer’s role and to colleagues on the wallet infrastructure team had already been exposed.
In September, software engineer B was targeted through a fake hiring process. Binance said the attackers approached B through a legitimate job platform, staged interviews with people posing as human resources staff and the CEO of a fictitious company, and built trust through video calls and shared social profiles. During the process, B was persuaded to download a code repository containing malicious code onto a work computer, which led to the device being compromised.
On Oct. 20, UTC, the attackers used B’s compromised machine and an internal AI tool to gain further control over the devices of engineers A and C. They then discovered a container deployment permission token on A’s computer. On Oct. 29, UTC, the attackers logged into C’s computer, used credentials stolen from A to deploy containers and run malicious scripts, and then moved assets through unauthorized access to an internal wallet signing service.
Binance said those transactions took place outside its normal withdrawal flow. On Ethereum, the attackers used EIP-7702 to set code delegations for affected hot wallets to contracts under their control. Because those on-chain delegations operated independently from the exchange’s standard withdrawal system, pausing withdrawals was not enough to stop every unauthorized transfer. Additional transactions were needed to revoke the malicious delegations.
That sequence has become the basis for the broader debate. The entry points look familiar: a software download, a fake interview, a compromised endpoint. The harder question is what happened after that, and why the attack was still able to reach deployment permissions and a wallet signing service.
Two readings emerged after the report
One camp argued that the incident exposed avoidable failures in internal discipline. The attack vectors were not new, and the fact that employee endpoints could still become a bridge to sensitive systems raised questions about device segregation, production access, and transaction verification.
The other camp warned against treating the attack as unsophisticated simply because the initial lure was common. In that view, the real issue is the attacker’s ability to collect intelligence over time, move laterally, cross internal boundaries, and study how funds are moved inside an exchange.
Those positions are not identical, but they meet at the same point: the industry is now asking what defenses remain once a single employee and a single machine are lost.
Yang Haipo: the missing piece was discipline, not advanced technology
CoinEx founder Yang Haipo, known on X as @yhaiyang, said the incident exposed at least three failures that should have been preventable: inadequate separation between development and operations environments, a lack of effective second-layer verification for production actions, and no meaningful independent verification by signing participants.
He argued that staff with production access should use dedicated devices, while coding, chat, and web browsing should happen on separate machines. Production actions, he said, should not be completed with a single key alone and should include extra checks such as hardware security keys so that one leaked credential does not immediately compromise production access.
He was also critical of the signing process. If each participant simply trusts an upstream request without independently verifying the transaction, he said, then even a multi-party signing setup can behave little differently from a single signer. His conclusion was blunt: these controls do not require especially complex technology; what was missing was discipline.
At the same time, Binance has not disclosed its full authentication and signing rules, so that criticism remains an interpretation rather than a confirmed finding. The report also does not equate MPC with an on-chain multisig structure.
0xTodd: the fake interview angle was not new
Nothing Research partner 0xTodd, or @0xTodd on X, said after reading the report that the entry point looked less sophisticated than he had expected. In his reading, one employee installed a fake developer tool while downloading AI software, and another was drawn into a targeted fake interview that ended with malicious code being downloaded to a work machine.
He was especially skeptical of the fake interview stage, saying similar phishing tactics had repeatedly appeared on X before.
Still, his view that the attack did not use a 0-day vulnerability should not be treated as a conclusion of the investigation. Binance described the program involved as “0-day malware” and said endpoint protection tools did not detect it at the time, but the report did not say whether a specific zero-day vulnerability had been exploited.
YQ: smart contract audits do not cover the whole workflow
AltLayer founder YQ, known as @yq_acc, focused on operations endpoints and high-privilege access. He said devices used for critical actions should be isolated from everyday environments and paired with IP whitelists. Access to high-privilege systems such as clusters, he added, should be logged and approved by multiple responsible parties. Even in remote work settings, key access should still go through multi-person approval.
His point was that this kind of attack sits outside the normal scope of smart contract audits and routine blockchain security work. Defenders need to understand the full workflow linking employee endpoints, internal tools, and production clusters. They need to know what normal looks like, and they need to spot abnormal paths.
That shifts the focus away from contract code alone and toward the organization itself: how systems connect and what permissions employees hold can determine how far an attacker gets.
Liufuyao and He Yi: reduce the blast radius of a single mistake
Crypto commentator Liufuyao, known as @0xLiufuyao, said employees with access to core systems in the crypto industry should face security requirements at least as strict as those in traditional finance and payment institutions. He called for limits on non-work activity on work computers, along with least privilege, separation of duties, temporary credentials, and regular security training.
His argument was straightforward. Social engineering is hard to eliminate completely, and human behavior remains variable, so the practical goal is to reduce the impact of any one individual mistake.
Binance co-founder and co-CEO He Yi replied that Binance already requires mandatory security and risk-control training for all staff. She said banning non-work use of work computers is a basic rule at the company and that employees had previously been dismissed for violating it. She also said Binance monitors downloads and had detected some earlier social engineering attacks through that mechanism. The company is now tightening standards further and reinforcing segregation across different layers.
Sisi: the responsibility lies with Binance
Sisi, who leads Binance’s Chinese community, said responsibility for the incident lies with Binance and should not be pinned on a single engineer or a single technical standard.
Responding to questions about how one work computer could touch multiple permissions, Sisi said Binance already had mechanisms including multi-party secure computation signing, withdrawal risk controls, and permission segregation. Even so, the months-long attack exposed gaps in those defenses. She said the attackers moved step by step through a fake recruitment process, a tampered developer tool, and malware, then used an internal AI tool as a bridge for deeper penetration.
On remediation, Sisi said that as of Nov. 3 all intrusion points mentioned in the report had been closed. The affected wallet systems and internal AI tool had been rebuilt, related devices had been replaced, credentials and tokens had been invalidated, permissions had been tightened, and device scanning and anomaly detection had been strengthened.
She added that Binance had hired an independent third-party security firm to conduct a review and planned to publish the findings. The company also said it was willing to share indicators tied to the attack with other exchanges and take part in industry-wide joint defense efforts.
CZ: the complexity of the attack is not an excuse
Binance founder Changpeng Zhao, or CZ, said a theft on this scale means there was a serious security failure. No platform can guarantee it will never be breached, he said, but that cannot serve as an excuse.
Zhao acknowledged that some of the details were embarrassing and said the public explanation simplified what had been a long-running attack against many employees and systems. Even so, he said disclosing those details could still help the broader industry learn from the incident. As a shareholder, he said he expects Binance to be transparent, take responsibility, listen to criticism, and make substantive improvements.
Cos and Luis: the first social engineering step is only part of the story
SlowMist founder Cos, known as @evilcos, said outside observers may be too quick to reduce the incident to a few engineers making basic mistakes. Once an organization is actually under attack, he said, the picture can include manipulation of human trust, intelligence gathering, malware evasion, abuse of trust chains, lateral poisoning, cloud-environment penetration, and bypassing risk controls.
He described the event as an APT, or advanced persistent threat, process and said the industry should not fixate on the initial social engineering lure while ignoring the attacker’s ability to keep advancing inside the target. The specific techniques he listed were his own analysis and should not be read as confirmed elements of this case.
BitsLab co-founder Luis, known as @0xyilu, made a similar point. He said it is a mistake to conclude from the public report alone that the attackers were technically weak. Social engineering remains common, he said, but the overall capability of attackers has changed and should not be judged by older assumptions.
On controls such as bastion hosts, dynamic multi-factor authentication, and screen locking, Luis said a locked screen does not stop malware already running in the background. Once an endpoint is controlled, attackers may steal tokens or authenticated sessions, which means later actions may no longer trigger login verification. Legitimate deployment permissions can also be abused. His point was not that basic controls are useless, but that they are not a cure-all for multi-stage attacks. Those comments were his analysis of possible mechanisms, not confirmation that each one occurred in this incident.
He also noted that, based on the report, deployment permissions and wallet signing service access originally belonged to different personnel, suggesting some degree of segregation. The attackers, however, crossed those boundaries by controlling devices and stealing credentials. In his view, the compromise of the internal AI tool, and the continued control of B’s device as a pivot point, deserve close attention.
Luis added that security is deeply asymmetric. Even strong organizations have weak points, and the cost of attack and defense can differ sharply. AI may also broaden access to offensive capability, making that asymmetry more severe. He closed with a warning to the industry: “Being weak is not the obstacle to survival; arrogance is.”
The central question remains unresolved
The timeline disclosed by Binance stretches from June 2026 to Oct. 29, UTC, and includes a tampered developer tool, a fake interview, an internal AI tool, a stolen deployment token, and unauthorized access to a wallet signing service. The people commenting on the case disagree on emphasis, but not on the core issue.
Once an employee is deceived and an endpoint is compromised, can an exchange’s internal segregation, approval process, and independent transaction verification still stop the attack from expanding?
For now, the details of Binance’s exact permission setup, signing verification, and control execution remain matters for the ongoing investigation and the promised independent review.
