Binance fake job interviews were one part of a broader social-engineering campaign that the exchange says led to its October security breach and the loss of approximately $6.34 billion in digital assets. In a detailed initial incident report, Binance said attackers spent months building access through malicious software, compromised employee devices, internal AI tooling and an advanced transaction-authorization method.
The disclosure adds important context to Binance’s earlier explanation that a wallet-infrastructure environment had been compromised. Rather than describing one employee mistake or a single technical failure, Binance says the attackers moved through several stages before reaching systems connected to hot-wallet signing operations.
The exchange says it has absorbed the financial impact rather than passing losses to users, replenished most affected token assets and rebuilt systems touched by the attack. But it has also acknowledged that its report is preliminary, with further independent review still underway.
Source : Binance Official Announcement
Binance Fake Job Interviews Were Part of a Longer Campaign
Binance says the operation started months before the October 29 attack. Its report describes an initial supply-chain compromise in June, followed by a recruitment-based social-engineering campaign in September and a later move through internal systems in October.
According to the exchange, a Wallet DevOps engineer downloaded a tampered Homebrew installation while attempting to install a popular AI coding tool found through an online search. Binance said it detected the anomaly, replaced the affected device and rotated related credentials.
However, Binance says the earlier compromise exposed information about the engineer’s role and associated wallet-infrastructure colleagues. That background knowledge may have helped attackers identify more valuable targets later in the campaign.
In September, Binance says another software engineer was contacted through a legitimate job-hunting platform by someone posing as a project director. The recruiter arranged an initial interview with an apparent HR representative, followed by a second interview with someone presented as the CEO of a fictitious company.
Binance says the attackers used real-looking social-media profiles, including personal images and videos, to build trust. Near the end of the second interview, the engineer was asked to download a coding “assignment” onto a work computer.
That assignment allegedly contained a malicious code repository. Binance says the malware used obfuscation and evasion techniques, including replacing a legitimate development-tool component with a malicious version that could run commands and communicate with an attacker-controlled server.
From a Compromised Device to Wallet Operations
The fake interview was not, by itself, the final step that led to the theft. Binance says the attackers later used the compromised computer and an internal AI tool as a springboard to gain control over additional engineers’ systems.
On October 20, according to Binance’s initial findings, attackers used the previously compromised device and the internal AI tool to gain control over the Wallet DevOps engineer and another wallet software engineer. Binance says they then discovered a container-deployment permission token on one of the compromised systems.
By October 29, the attackers had allegedly reached wallet-signing operations. Binance says that between 17:15 and 19:56 UTC, they accessed another engineer’s computer, used stolen credentials connected to the Wallet DevOps environment, deployed a container and triggered a malicious script.
The first identified unauthorized transfers began shortly after, at 20:05 UTC. Binance says the attackers accessed an internal wallet-signing service and initiated transactions outside its normal withdrawal process.
This is a crucial distinction. Binance has not said that the incident was simply a private-key theft. Instead, its account describes attackers gaining the ability to authorize transactions through compromised internal systems.
As Bitnxt noted in its initial Binance security incident report, protecting wallet keys and protecting the systems that send instructions to signing services are different security challenges. A key can remain undisclosed while an attacker still finds a way to make a signing system approve unauthorized activity.
EIP-7702 Made Containment More Complicated
Binance says the attackers also used Ethereum’s EIP-7702 authorization mechanism after gaining access to the signing service. The mechanism can allow an account to delegate defined execution rights to a smart contract without directly exposing its private key.
According to Binance, attackers used this feature to give an attacker-controlled smart contract partial execution rights over a Binance hot wallet. That meant stopping normal exchange withdrawals did not automatically stop every unauthorized transfer.
Binance says it needed additional technical steps to revoke the onchain permissions. The exchange said the use of multi-party computation, or MPC, added complexity because there was no single private key that could simply be used to immediately cancel the authorization.
The final unauthorized transfer, involving 2,961.9 ETH, was finalized at 23:56 UTC on October 29, Binance said. At 00:10 UTC on October 30, the exchange says it cleared the malicious delegation code through a new authorization sent to the zero address.
For readers, the main lesson is that a visible exchange freeze and an onchain permission revocation are not always the same thing. An exchange can pause its normal withdrawal interface, but an authorization already established on a blockchain may require a separate response.
Bitnxt’s Binance recovery and withdrawals update explains why restoring customer access is only one part of the recovery process. Containment, replenishment, forensic investigation and safe service restoration each answer different questions.
What Binance Says It Has Changed
Binance says it has rebuilt the affected wallet system in a new environment and rebuilt the internal AI tool and its access controls. It also says it replaced affected devices, decommissioned credentials and tokens tied to impacted engineers, conducted enhanced scans across employee devices and strengthened wallet-service risk controls.
The exchange has also said it is increasing investment in AI-enabled threat detection, developer-environment security, endpoint protection and behavioral anomaly monitoring. It plans to engage independent third-party cybersecurity experts to review the incident, validate its findings and recommend further improvements.
These are important steps, but they should be evaluated as remediation commitments rather than proof that every risk has disappeared. Binance has stated that some technical details will remain confidential to avoid providing attackers with a roadmap for future attempts.
The exchange says that, as of October 31, 98% of affected token assets had been replenished and that it had set aside more than the amount needed to cover the loss. Binance also said approximately $2.85 billion in digital assets had been frozen or intercepted, subject to reconciliation and market-price changes.
Those figures should be read carefully. Replenished assets are replacement funds Binance says it has provided; they are not necessarily the original stolen assets. Likewise, frozen assets are not automatically the same as funds fully recovered and returned.
Bitnxt Take: The Human Layer Remains a Critical Attack Surface
From Bitnxt’s view, the fake interview disclosure is significant because it shows how sophisticated crypto attacks increasingly blend technical exploitation with patient social engineering.
The attacker did not need to begin by breaking directly into a hot wallet. Binance’s account describes a much longer route: target people with credible recruitment outreach, compromise a development environment, move through internal systems and eventually exploit an authorization path connected to wallet operations.
That makes this a warning for both exchanges and individual developers. Security controls need to account for malicious coding assignments, fake developer tools, impersonated recruiters, compromised software packages and employee devices that appear normal at first glance.
It also reinforces why exchange users should distinguish between hot-wallet exposure, cold-storage practices and the wider security controls that govern access to funds. Bitnxt’s guide to hot wallets versus cold wallets explains that cold storage can reduce online exposure, but no custody model is secure without strong authorization and operational controls.
The broader industry takeaway is simple: the biggest threats do not always look like obvious hacks. Sometimes they arrive as a promising job offer, a familiar-looking developer tool or a routine coding task.
