Binance traces its wallet attack to a fake interview: what miners should check about payout custody
Source report: 2026-11-03 · Editorial analysis published: 2026-11-04
The November 3 preliminary report explains why pausing exchange withdrawals did not revoke malicious on-chain permissions. Replenished backing, recovered assets and usable mining proceeds are different measures.
A new account of how the attack reached wallet operations
Binance published its preliminary investigation on November 3 into the October 29 security incident. It describes a chain from fake recruitment and compromised developer tools to unauthorized access to an internal wallet signing service. For miners sending pool proceeds to an exchange, the report makes a practical issue clearer: producing coins, receiving an exchange credit and having money available for bills are separate stages.
The exchange estimates approximately USD 6.34 billion in affected assets and USD 2.85 billion frozen or intercepted. Those are Binance's figures, subject to reconciliation and market-price movements. The company says it will bear the losses, has set aside more than the amount required and had replenished 98% of impacted token assets as of October 31, while still purchasing less-liquid assets.
Replenishing backing with company resources is different from recovering stolen coins. Nor is a replenishment percentage a live measure of withdrawal availability for every customer and network. The report remains preliminary and further independent review is planned. This article covers that new investigation, separate from the earlier reports on the pause and phased withdrawal restart.
From a believable job interview to privileged access
According to Binance, a June incident involved a tampered Homebrew installation downloaded while an engineer was seeking an AI coding tool. The company says it replaced the device and rotated related credentials, but information about wallet-team roles was exposed. That episode is one part of the timeline, not a claim that every later stage happened on the same day or computer.
In September, another engineer was approached through a legitimate recruiting platform. A staged interview process built credibility before a supposed assignment required downloading a malicious code repository to a work computer. Binance says code executed during setup. The useful warning for a rig operator is that a project can run code before its advertised application ever opens.
The report says the compromised computer and an internal AI tool were used to reach other engineers on October 20. A stolen container-deployment credential then helped reach wallet signing operations on October 29. This is an account of access moving between systems; it is not evidence that an AI model independently decided to steal money or that a miner's ordinary GPU workload caused the breach.
Why the withdrawal switch could not cancel every permission
Binance says the attacker used unauthorized signing-service access to initiate transfers outside its normal withdrawal process, including a transfer of 18,270 BTC. In the Ethereum portion, the attacker used EIP-7702, a mechanism that lets an account delegate execution to code. This Ethereum authorization mechanism should not be confused with Bitcoin's protocol or described as a flaw in SHA-256 mining.
An everyday comparison is a service account with a standing permission: closing the office's request counter does not automatically cancel a permission already granted elsewhere. Binance says malicious delegations existed on-chain and could operate independently of its normal withdrawal infrastructure. Halting the exchange service and revoking a blockchain authorization were therefore different containment tasks.
The company also says its multi-party computation wallet, or MPC, did not have a single private key available for immediate revocation, requiring a specialized procedure. It reports a final unauthorized ETH transfer finalizing at 23:56 UTC from a previously broadcast transaction, and a further authorization clearing the Binance14 delegation at 00:10 UTC on October 30. These are the company's timeline, not a claim that transaction broadcast and final settlement happen simultaneously.
What changes for a miner managing proceeds
A pool's unpaid balance, a payment broadcast to an address, an exchange deposit credit and funds usable for an electricity invoice should be tracked separately. A pool can finish its job while an exchange still limits access to a particular asset-network pair. That interruption affects the operator's cash schedule even if the ASIC continues submitting accepted work without a technical fault.
Check the payout destination currently configured in the pool and the actual coin and network supported by the receiving service. Do not assume that a shared ticker makes different networks interchangeable. A payout address displayed in a pool is also different from the credentials that can change it. Monitoring access, payout-setting permissions and withdrawal permissions deserve separate attention.
An operator can review how long proceeds remain with a third party and which funds are needed for near-term expenses. Moving to self-custody changes the responsibility rather than removing it: backups, key control and correct transfer details still matter. The report does not establish one universally suitable balance, transfer size or custody arrangement for every household or hosting business.
Review the systems around the wallet as well
Binance says it rebuilt affected wallet and internal AI environments, replaced affected devices, decommissioned engineers' credentials and strengthened monitoring and wallet controls. It is engaging independent cybersecurity reviewers. Those remediation statements describe work reported by the company; they do not constitute a completed independent audit or a guarantee that no future incident can occur.
For a smaller mining operation, the relevant question is which everyday computer can reach pool settings, exchange sessions, remote-management credentials or wallet secrets. An interview task, unofficial miner package or copied setup command can be consequential if executed on that machine. Review software origin and access scope before running it; a familiar chat profile or working utility does not establish that the surrounding installation is trustworthy.
No account access, transfer or mining-software execution was needed for this report. The source is Binance's November 3 initial account and the public Ethereum specification. Keep operational decisions tied to the service's current asset-and-network status and your own verified payment records. A newly explained attack path is useful evidence for reviewing access, but it is not proof that every mining payout route is now open or that all stolen assets have returned.
Source: Binance ↗ · Ethereum EIP-7702 specification ↗
Mining calculator ↗
