Roughly $6.34 billion in digital assets left Binance hot wallets after attackers spent months on engineer workstations rather than a spoofed workforce login page. According to Binance’s official initial findings published 3 November 2026, a multi-stage campaign that began with fake recruitment interviews and malicious code downloads on work computers produced stolen credentials, a container deployment permission token, and unauthorized use of an internal wallet signing service. The FBI attributes the operation to DPRK-linked TraderTraitor. About $2.85 billion was frozen or intercepted, Binance covered customer losses with SAFU and its own funds, and 98% of tokens were replenished by 31 October.
How fake interviews put malware on engineer laptops
Attackers opened a quieter path months before the drain. In June, tampered Homebrew supply-chain malware for an AI tool reached a Wallet DevOps engineer device. Binance detected and remediated that infection, though role information was exposed. That foothold did not complete the theft, but it showed wallet-adjacent staff were already in scope.
September brought the main social-engineering run. Operators contacted a Binance software engineer on a legitimate job platform while posing as a project director. Video and chat interviews followed, including social-media sharing meant to build trust. The “assignment” was a malicious code repository the engineer was told to download onto a work computer.
Obfuscated malware replaced a legitimate pyenv component, stood up command-and-control, and slipped past endpoint detection tools available at the time. No public detail in the initial findings describes a password harvest or MFA prompt at that moment. The workstation itself became the entry. Once the implant ran with the engineer’s normal tooling rights, interactive login controls were no longer the gate the attackers needed to clear first.
Here the first durable win was code execution on a development machine, delivered through a hiring workflow people are trained to treat as ordinary career traffic.
October: one device, more engineers, a deployment token
On 20 October the attacker used the already-compromised device and an internal AI tool to reach additional wallet engineers’ systems and obtain a container deployment permission token. The report frames that step as endpoint-driven control plus privilege useful for packaging and shipping workloads, not as a fresh remote authentication ceremony against the corporate IdP.
Nine days later the money moved. Between 17:15 and 19:56 UTC on 29 October, the attacker logged into one engineer’s computer, used stolen credentials to deploy a container and a malicious script, and exploited unauthorized access to an internal wallet signing service. Operators authorized 50 malicious EIP-7702 delegations on MPC hot wallets through that service and drained those hot wallets.
Binance has not published, in the initial findings, whether the “stolen credentials” were a password, a reusable secret cached on the box, or another transferable factor. The company also has not named MFA presence, MFA type, or any bypass story on employee accounts. What the timeline does show is credential reuse after endpoint compromise, followed by abuse of a signing path that sits outside ordinary interactive workforce login.
| Stage | What attackers held | How they got it |
|---|---|---|
| June foothold | Role intel on Wallet DevOps path | Tampered Homebrew AI-tool malware |
| September implant | C2 on engineer work PC | Fake job repo replacing pyenv |
| 20 October | Container deployment permission token | Compromised device plus internal AI tool |
| 29 October window | Engineer login plus signing service use | Stolen credentials, container, 50 EIP-7702 delegations |
SSO blast radius is not the story Binance told. The damaging authorization was internal wallet signing power reached after engineer-environment compromise. Once that service accepted the attackers’ transactions, hot-wallet balances moved without another human challenge at the browser.
What the credential step did and did not decide
Stolen engineer credentials still mattered on 29 October. Logging into the engineer’s computer and driving container deploy is classic transferable-secret reuse after malware already owns the desk. Device-bound, non-transferable workforce login factors would shrink that particular reuse path: a private key that never leaves hardware is a poor fit for “use the secret we lifted off the box.”
It does not rewind the earlier stages. Fake-interview malware install, Homebrew supply-chain infection, C2 that endpoint tools missed, theft of a container deployment permission token from a live session environment, and raw authorization against an internal signing service all sit after or beside interactive authentication. No login factor undoes code already running as the engineer, and no second factor on the IdP rewrites a signing API that already accepted 50 malicious EIP-7702 delegations.
Binance’s initial findings leave several identity details open: full independent forensic detail, some technical mechanisms kept confidential, and any precise map of session versus password material. That record does not support “MFA failed” headlines. The documented failure modes are social engineering into developer tooling, endpoint malware, token and credential theft from compromised machines, and unauthorized signing-service access.
Customer impact still landed hard even with fast recovery. Approximately $6.34 billion in digital assets were affected. Roughly $2.85 billion was frozen or intercepted. SAFU plus company funds backstopped users, and 98% of tokens were replenished by 31 October.
Hiring platforms, take-home repos, local dev version managers like pyenv, internal AI assistants that can reach peer engineer systems, container deploy permissions, and MPC hot-wallet signing services formed one continuous path. The signing window ran from 17:15 to 19:56 UTC on 29 October; the implant had been on an engineer work computer since September.
The defensive side of this case is covered in the related article on mfa2point0.com: device-bound login after engineer malware at Binance.
FAQ
How did attackers first get onto Binance engineer systems?
Attackers first reached Binance engineer systems through social engineering and malware, not through a published IdP phishing kit. According to Binance’s 3 November 2026 initial findings, operators posed as a project director on a legitimate job platform in September, ran video and chat interviews, and had a software engineer download a malicious code-repository assignment onto a work computer. Obfuscated malware replaced a pyenv component, established C2, and evaded endpoint detection then in use. A separate June Homebrew supply-chain infection on a Wallet DevOps device was detected earlier and cleaned up after role information exposure.
What happened on 29 October 2026 in the Binance hot wallet breach?
On 29 October 2026 between 17:15 and 19:56 UTC, the attacker logged into one Binance engineer’s computer, used stolen credentials to deploy a container and malicious script, and abused unauthorized access to an internal wallet signing service. Through that service they authorized 50 malicious EIP-7702 delegations on MPC hot wallets and drained those hot wallets. Binance later reported about $6.34 billion in affected digital assets, roughly $2.85 billion frozen or intercepted, and 98% token replenishment by 31 October.
Did MFA get bypassed in the Binance engineer attack?
Binance’s initial findings do not say MFA was bypassed, absent, or present on the affected employee accounts. The report describes stolen credentials used after access to an engineer’s computer, a container deployment permission token taken via compromised devices and internal tooling, and unauthorized wallet signing service use. Without a named factor or login ceremony in the disclosure, claims that “MFA was bypassed” are not supported by the public record.
Who does the FBI link to the Binance 2026 hot wallet drain?
The FBI attributes the Binance campaign to DPRK-linked TraderTraitor, as reflected in Binance’s 3 November 2026 initial findings summary of the investigation. Public technical narrative centers on fake recruitment malware, engineer-device compromise, stolen credentials and deployment permissions, and EIP-7702 abuse against MPC hot wallets rather than on a consumer-app account takeover.
Why didn’t freezing funds fully erase the Binance loss event?
Freezing and interception recovered a large share, about $2.85 billion per Binance’s account, and SAFU plus company capital covered customers while 98% of tokens were restored by 31 October. The operational event still occurred: attackers held enough engineer-environment control and signing authorization to complete 50 malicious EIP-7702 delegations and move hot-wallet value before those controls caught up. Treasury response limited customer harm; it did not prevent the unauthorized signatures.
