The $6.34B Binance Hack Started With a Job Interview: The Full Chain and 4 Microsoft Locks

On 29 October 2026, about $6.34 billion in assets was hit at Binance. On 3 November, Binance published its initial findings. The story is not about broken encryption or a stolen private key. Attackers made a legitimate system do an illegitimate thing.

This article walks through what happened in plain words, explains the five terms you need, and then maps every step to a Microsoft control I rebuilt in my contoso.com lab.

The Microsoft part is a defensive model, not a claim that Binance uses Microsoft or would have been saved by it. No tool catches everything. Layers do.

What happened, in one paragraph

A fake recruiter gave an engineer a coding test. The test hid malware. From that laptop the attackers reached two more engineers, found a token that could deploy containers, used it to run their own code inside Binance, and that code made Binance's own hot wallets send funds out.

Who got hurt and what it cost

• The exchange: about $6.34B in assets affected. About $2.85B was frozen or intercepted. Binance says 98% of affected tokens were replenished from company funds by 31 October.
• Users: Binance says customer balances are covered. Most companies could not absorb a loss like this.
• The security team: funds left between 20:05 and 23:56 UTC. The bad delegation was cleared at 00:10 UTC on 30 October. That is almost four hours, not "minutes" as early reports said.
• Attribution: the FBI attributed the attack to North Korea.

5 terms in plain words

Step 1: the laptop (June and September)

In June, a wallet engineer installed a tampered Homebrew package while looking for an AI coding tool. Binance caught it and replaced the device, but the attackers had already mapped the team. In September, Engineer B was contacted on a real job site, did two video interviews, and downloaded a coding test to a work laptop. The repo replaced a legitimate pyenv file with a malicious one and contacted the attackers' server. Binance says it was zero-day malware that endpoint security did not flag.

Lock 1: a rule, then Defender for Endpoint

• Strangers' code never runs on a work laptop. Use a throwaway VM with no real credentials.
• Defender for Endpoint looks at behavior chains, not only signatures: editor, then shell, then download, then file swap, then an unknown server.
• Attack disruption can contain a device once an attack is recognized. It does not guarantee a zero-day is caught. That is why the next locks exist.

Step 2: moving sideways (20 October)

From Engineer B's laptop and an internal AI tool, the attackers reached Engineers A and C. Binance has not explained how the AI tool was used. Engineer A's machine held a container deployment token.

Lock 2: Conditional Access, Token Protection, PIM

• Conditional Access: privileged users only from compliant, company-managed devices.
• Token Protection: binds supported sign-in sessions to one device, so a copied token fails elsewhere. It covers supported apps and platforms, not every API token.
• Privileged Identity Management: nobody holds deploy rights all day. Activate for an hour, with a reason and, if needed, an approval.

Step 3: a container gets the right to act for a wallet (29 October)

From Engineer C's machine, using Engineer A's credentials, the attackers deployed a container and ran a script. Using EIP-7702, an attacker contract gained execution rights over a hot wallet. Pausing withdrawals did not stop it, and with MPC there was no single key to revoke.

Lock 3: protect who can ask the key to sign

• Keys or key shares in Key Vault or Managed HSM where the architecture fits. Key Vault is not a drop-in replacement for an MPC wallet.
• Only one managed identity may call sign. RBAC, not shared secrets.
• The application checks what it signs: a new delegation, a new destination or a large amount needs an independent second approval. PIM approves role activation, not individual blockchain transactions.

Step 4: almost four hours of outflow

Funds left from 20:05 UTC (XRP first, then SOL, OP and BTC). The last transfer settled at 23:56.

Lock 4: Sentinel detection plus a tested response

• Send the signing service's audit logs to Log Analytics and Microsoft Sentinel.
• Alert on a new delegation, a new destination or an unusual total value, not only on a count.
• A Logic Apps playbook opens the incident, notifies the SOC in Teams, revokes the deploy token and calls the wallet team's own API to pause signing. Sentinel cannot freeze a blockchain wallet by itself. You build that hook and you test it.

"But the engineer had those rights anyway. Why couldn't he do it?"

This is the most dangerous point of the whole case, so it deserves its own section.

Engineer A could deploy containers, call internal APIs and reach the signing service. He was given those rights to do his job. The attackers did not need his skills or his role. They needed his session. To the system it looked like this:

User: Engineer A Token: valid Permission: authorized Result: access granted 

Nothing in that check asks who is at the keyboard or why.

Knowing how to use a system is not the same as knowing how to exploit it. A DevOps engineer can deploy an app and still have no idea how the hot-wallet signing flow or EIP-7702 delegation works. The attacker's skill was chaining three laptops, one deploy token and one blockchain feature into a theft. A bank teller can reach the transfer system; that does not mean the teller knows how to bypass every control to move billions.

Could an insider have helped? Investigators cannot exclude it, and only evidence settles it: external attack, insider threat, or collusion. A hijacked account is not proof that its owner took part.

One line to keep:

Authentication proves who you are. Authorization decides what you may do. Neither proves that what you do is legitimate.

That gap is exactly why behavior monitoring, process controls and an independent approval exist on top of MFA and antivirus.

Check your own tenant (contoso lab queries)

// 1. Admins signing in from devices that are not compliant (14 days) SigninLogs | where TimeGenerated between (ago(14d) .. now()) | where ResultType == "0" | where UserPrincipalName in~ ("admin1@contoso.com", "devops1@contoso.com") | extend Compliant = tostring(DeviceDetail.isCompliant), Device = tostring(DeviceDetail.displayName) | where Compliant != "true" | summarize SignIns = count() by UserPrincipalName, Device 

// 2. Code editor starts a shell that reaches the internet DeviceProcessEvents | where TimeGenerated between (ago(7d) .. now()) | where InitiatingProcessFileName in~ ("code.exe", "code", "electron") | where FileName in~ ("zsh", "bash", "sh", "powershell.exe", "pwsh.exe", "cmd.exe") | join kind=inner ( DeviceNetworkEvents | where RemoteIPType == "Public" | project DeviceId, NetTime = TimeGenerated, RemoteUrl, RemoteIP, InitiatingProcessId ) on DeviceId, $left.ProcessId == $right.InitiatingProcessId | project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, RemoteUrl, RemoteIP 

// 3. Signing burst by one identity, by count or by value (lab table WalletSigning_CL) WalletSigning_CL | where TimeGenerated between (ago(1h) .. now()) | summarize Requests = count(), TotalAmount = sum(Amount_d), Destinations = dcount(Destination_s) by Identity_s, bin(TimeGenerated, 5m) | where Requests between (10 .. 1000000) or TotalAmount between (1000000 .. 1000000000000) 

WalletSigning_CL is a custom table in my lab, not Binance data. Replace the admin list with your own accounts.

Prevent, detect, respond

A valid account does not make every action valid. Protect the identity and the actions it is allowed to take.

Checklist

• [ ] Written rule: no untrusted code on work devices; throwaway VM provided
• [ ] Defender for Endpoint on every engineer laptop, attack disruption on
• [ ] Conditional Access: privileged roles only from compliant devices
• [ ] Token Protection enabled where supported
• [ ] PIM for deploy and admin roles, with approval on the most sensitive
• [ ] Signing callable by one managed identity; second approval for new delegations or destinations
• [ ] Signing logs in Sentinel; rule on value and destination, not only count
• [ ] Playbook to revoke tokens and pause signing, tested this quarter

Sources

Incident:

• CoinDesk, 3 Nov 2026: https://www.coindesk.com/business/2026/11/03/binance-s-usd6-3-billion-hack-began-with-a-fake-job-interview-exchange-says
• Hackread, 4 Nov 2026: https://hackread.com/binance-hack-fake-job-interviews-hackers-steal-billions/
• Binance initial findings: https://www.linkedin.com/pulse/29-october-binance-security-incident-initial-findings-response-modgf/

Official Microsoft:

• Contagious Interview (Microsoft Security Blog): https://www.microsoft.com/en-us/security/blog/2026/03/11/contagious-interview-malware-delivered-through-fake-developer-job-interviews/
• Require compliant device: https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-compliance
• Token Protection: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection
• Privileged Identity Management: https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
• Key Vault logging: https://learn.microsoft.com/en-us/azure/key-vault/general/logging
• Automatic attack disruption: https://learn.microsoft.com/en-us/defender-xdr/automatic-attack-disruption

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

• ▶️ YouTube (daily Shorts + explainers): CD Security Lab
• 💼 LinkedIn: Cuong Do
• 📘 Facebook: CD Security Lab
• 📸 Instagram: @cdsecuritylab
• 📝 More posts like this: Dev.to

Got a question about your own tenant? Drop it in the comments.