A Binance fake job interview was one stage of the campaign behind the 29 October 2026 theft of about USD 6.34 billion in digital assets. Binance describes the sequence in its own initial report, posted on its X account on 3 November 2026. The report says this was a multi-stage campaign, not a single isolated breach or a simple phishing incident.
This deep-dive follows the chain in the order Binance gives it, from a tampered developer tool in June to the container that launched the attack on 29 October. It then maps what a defender can watch for at each step. We keep to what the report states and use its own confidence words. Binance says some technical details stay confidential and that its findings will be subject to further independent review.
- Tampered Homebrew installJune 2026: a Wallet DevOps engineer searches for an AI coding tool; Binance replaces the device and rotates credentialsTechnique T1195.002 (MITRE ATT&CK, opens in a new tab)
- Fake recruiter contactSeptember: a software engineer is approached on a job-hunting platform, then goes through a video interview and a chat-app interviewTechnique T1566.003 (MITRE ATT&CK, opens in a new tab)
- “Assignment” runs on a work laptopMalicious repository code runs during setup and swaps a development tool componentTechnique T1204.002 (MITRE ATT&CK, opens in a new tab)
- Internal AI tool as springboard20 October: control of two more engineers’ systems, and a container deployment token is foundTechnique T1078 (MITRE ATT&CK, opens in a new tab)
- Container deployed with stolen access29 October, 17:15 to 19:56 (the report gives no time zone): logon to a colleague’s computer, container deployed, malicious script launchedTechnique T1610 (MITRE ATT&CK, opens in a new tab)
- Wallet signing service abusedTransfers outside the normal withdrawal process, then an EIP-7702 delegation over a hot wallet
Binance names no ATT&CK techniques in the report. The identifiers in this diagram are our own mapping of its description to ATT&CK, so treat them as a starting point for your detection tagging.
How Did the Binance Fake Job Interview Work?
In September, Binance says, a software engineer it calls Engineer B was contacted through a legitimate job-hunting platform. The sender posed as a Project Director, and Engineer B’s profile on that platform referenced his experience at Binance. That detail is Binance’s own, and in our reading it shows why a public profile that names a crypto exchange is a targeting signal.
The purported Project Director arranged two interviews. In the first, a purported HR representative held a live video call and shared a social media account with personal photos and videos to build trust. Binance calls this more advanced and deceptive than the social engineering approaches it had seen before.
The second interview ran in a popular social chat app, with a person claiming to be the CEO of a fictitious company. Near the end, Engineer B was told to download an “assignment” containing a malicious code repository onto his work computer.
The lure used the normal shape of a developer hiring process: a recruiter, an HR screen, a coding task. Our social engineering glossary entry explains why a task that looks routine lowers a target’s guard.
What Did the Assignment Do on the Laptop?
Binance says the repository contained malicious code that executed during the setup process and started a series of unauthorized activities. The malware used obfuscation and evasion techniques. It replaced a legitimate development tool component with a malicious version, which ran commands and set up communication with an attacker-controlled external server.
Binance also says this was zero-day malware that the endpoint protection tools did not detect at the time. The attacker took steps to hide the activity and remove traces, which made detection and investigation harder.
The step listing in the report points to the pyenv version manager. It shows a replacement file being built, the valid one deleted, the new one renamed into its place, a symlink created and a shell started. Our reading is that a version manager sits in the path of many developer commands, so swapping it is a convenient place to run code. Binance does not say this.
Where Did the Tampered Homebrew Install Fit In?
The earlier stage was in June 2026. Binance says Engineer A from its Wallet DevOps team found a popular AI coding tool through a search engine and downloaded a tampered Homebrew installation to install it. Our page on compromising the software supply chain describes the technique family.
Binance’s security team detected the anomaly, replaced the device and rotated all related credentials as a proactive step. However, the report says Engineer A’s role and his colleagues on the wallet infrastructure team were exposed to the attacker.
Binance does not say that the June exposure led to the September approach; the report lists the two stages separately. Binance also says it detected and prevented 57 suspected North Korea-linked cyber threat cases during 2026. It lists fraudulent job interviews, malicious software disguised as developer tools, compromised packages and browser extensions, fake video conferencing applications and social engineering campaigns among the techniques.
How Did an Internal AI Tool Become a Springboard?
On 20 October, Binance says, the attacker used Engineer B’s compromised computer and an internal AI tool. That gave control over Engineer A and a second wallet engineer, Engineer C. The attacker then found a container deployment permission token on Engineer A’s computer.
The report does not say how the tool was reached or what it could do. It does say that Binance rebuilt the affected internal AI tool and its access controls afterwards. We treat an internal AI tool as a privileged system in this chain, because by Binance’s account it let one compromised laptop reach two other engineers.
What Happened on 29 October?
Binance says that on 29 October, between 17:15 and 19:56 (the report gives no time zone), the attacker logged onto Engineer C’s computer. Using credentials stolen from Engineer A, the attacker deployed a container and triggered a malicious script. Binance describes the result as unauthorized access to an internal wallet signing service, used to start transactions outside the normal withdrawal process.
Between 20:05 and 20:09 UTC, five hot wallets sent 233.46 million XRP to an attacker-controlled address. Hot wallets on Solana and Optimism sent about 970,500 SOL and 44.2 million OP. An internal alert on large-volume transfers then started the investigation, and a hot wallet sent 18,270 BTC.
The attacker then used the signing service for Ethereum’s EIP-7702 authorization mechanism, which lets an account delegate certain execution rights to a smart contract. Binance says this gave an attacker-controlled contract partial execution rights over a hot wallet. We trace the on-chain side in our Binance security incident analysis.
Suspending withdrawals did not stop it. Binance says the attackers submitted 50 signing transactions to manipulate the account nonce and set up malicious delegation authorizations, which kept working independently of Binance’s withdrawal infrastructure.
Because the hot wallet used multi-party computation, no single private key could revoke them at once, so the team built a special procedure. The final unauthorized transfer, 2,961.9 ETH, finalised at 23:56 UTC. At 00:10 UTC on 30 October Binance cleared the delegation code from its Binance14 hot wallet.
How Do You Detect This Chain Before the Wallet Step?
Detection should follow the chain, because the wallet step comes last and only after several quiet stages. The list below is our guidance, built on the stages in Binance’s report, and not a list of Binance’s own controls.
- Recruitment contact. Tell staff that a coding “assignment” from a recruiter is never run on a work computer. Give them one place to report approaches from job platforms, and watch for recruiters who ask for a move to a chat app.
- Developer tools. Install package managers and AI coding tools only from the vendor’s own address, not from a search result. Alert when a package manager’s own files are modified or replaced and a shell starts from the same setup script.
- Internal AI tools. Treat them as privileged systems. Log what each session does, limit the credentials a tool can reach, and alert when a session drives access to another person’s computer.
- Deployment tokens. Keep container deployment tokens off laptops and make them short-lived. Alert on a deployment started from a workstation outside the usual change process, or on a logon to a colleague’s computer.
- Signing and delegation. Cover every signing path with policy. Watch for EIP-7702 delegations on hot wallets, and write down a revocation procedure before you need it, since Binance says MPC meant no single key could revoke them.
Binance says it has tightened device controls and wallet-service risk controls and expanded AI-based behavioural anomaly detection. It has also run enhanced security scans across all employee devices and decommissioned the credentials and tokens tied to the affected engineers.
Who Does Binance Say Is Responsible?
The report states that the latest information released by the FBI indicates North Korea (the DPRK) is responsible for the incident. Binance does not name a group in the report. Our incident page records the FBI’s 31 October alert, which names the activity TraderTraitor, and our TraderTraitor profile covers that group’s earlier thefts.
Binance says it will absorb the financial impact, and its report says 98% of the impacted token assets were replenished as of 31 October. Its Recovery Update #7 on 4 November also gives approximately 98%. The company says it is still buying the remaining, less liquid assets.
What Should Teams With Wallet or Deployment Access Do Now?
Start with the people, not the wallet. List who holds deployment tokens, signing permissions or access to internal AI tools, and check what a public profile or job-site page says about them. Our DevOps lessons post, what the October attacks teach DevOps teams, goes through the wider controls. Our analysis of how the Binance hack spread on Telegram and X shows what the public conversation looked like in the first hours.
Then test the chain on your own side: could one developer laptop, through one internal tool, reach another engineer’s machine and a token that deploys code? Binance’s report suggests that is the question to answer. We will update this post if Binance publishes a fuller report after the independent review.