On October 29, 2026, Binance lost about $6.3 billion. Nobody broke the cryptography, and no consensus bug was involved. The blockchain processed signed transactions exactly as it was designed to. As far as the chain could tell, everything was in order.

That is the part I keep returning to. The chain did what it was told. Everything that failed happened off-chain: people, laptops, credentials, deploy pipelines, and the policy around signing. Those are platform and DevSecOps problems. Most of us run systems shaped like that, whether or not crypto is involved.

This post covers what is publicly known, why a valid signature tells you nothing about intent, and the controls I think platform teams should be building. It ends with a checklist.

1. What happened

Here is the public record so far. I've stuck to points confirmed by the sources linked below.

The size. Binance put the loss at about $6.3 billion, per Reuters. Chainalysis has a slightly higher estimate of about $6.4 billion in its latest findings.

How they got in. Binance's early finding pointed at one engineer's machine. Its November 3 report replaced that story with a broader one. As CoinDesk reports, the campaign was multi-stage and began in June. It used a trojanized tool download and a fake job interview. Two wallet developers' machines were compromised. The attackers then used stolen credentials to deploy a container that ran a malicious script. This was not one laptop and not one engineer's permissions. It was a patient campaign that moved through several layers.

The signatures were valid. The transfers carried valid signatures (CoinDesk, Chainalysis), and Binance says it has found no evidence that a private key leaked. Cointelegraph's coverage frames it the same way: the keys were misused, not broken.

The mechanism. The attacker relied on EIP-7702 delegation. A hot wallet labelled "Binance 14" received 50 authorizations that delegated it to a sweeper contract, according to CoinDesk's breakdown and Blockaid's analysis. EIP-7702 lets an externally owned account point at contract code. Once that delegation exists, the account behaves the way the delegated code says. One permission ended up controlling a lot of money.

The freezes. Stablecoin issuers moved fast. In early reporting, CNBC said Tether had frozen more than $1.5 billion and Circle more than $800 million. Since then, Blockaid and Binance have put the total frozen across issuers at about $3 billion.

Attribution. In an October 31 alert, the FBI attributed the attack to North Korea's TraderTraitor, also known as Lazarus. Chainalysis agrees with that attribution. See also coverage from AP and The Record. Fake job interviews and trojanized developer tools are standard tradecraft for that group, so the entry path fits.

2. Why valid signatures aren't valid intent

A signature proves one thing: whoever controls the key, or a system authorized to use it, approved these bytes. It doesn't tell you whether a human meant to approve them, whether the business would have approved them, or whether the code that requested the signature was the code you shipped.

Most signing setups assume that anything able to reach the signer is trustworthy. That assumption holds only while the path to the signer stays clean. In this incident the path ran through a developer endpoint, then stolen credentials, then a container deploy, then a script, then the signer. All of those links are off-chain, and every one of them is something a platform team owns.

I think of it like this. Cryptography authenticates. It doesn't authorize. Authorization lives in policy, and policy has to sit somewhere the attacker can't simply deploy around. If your only gate is "does this request come from a workload with access to the signer," the attacker's job becomes "get a workload with access to the signer." In practice that means stealing deploy credentials.

EIP-7702 makes the point sharper. A delegation authorization is a signed message that can hand ongoing control of an account to contract code. If your policy treats it like any other low-value message, you have left a door open that is worth far more than any single transfer.

3. Practical controls for platform teams

None of what follows is new. That's my point. The incident used familiar paths, so the defenses are familiar too. What matters is whether they are actually enforced at the layers that count.

Endpoint hardening and EDR for engineers

Engineers' machines are production-adjacent. They hold SSH keys, cloud sessions, kubeconfigs, and repository access. Treat them that way:

  • Run EDR on every engineering endpoint and actually staff the alert triage.
  • Block or sandbox unsigned binaries and tools from unknown sources. A "tool download" sent during a "job interview" should never run on a machine that holds production credentials.
  • Separate the device you browse and take calls on from the one you use for privileged access. Privileged access workstations, or at minimum isolated browser profiles and VMs, shrink the blast radius of a single click.
  • Watch for credential-store access and odd token use on developer machines.

Phishing-resistant MFA

TOTP codes and push approvals get phished and fatigued. Use FIDO2/WebAuthn hardware keys or platform passkeys for SSO, cloud consoles, CI/CD, and anything else that can deploy. Bind sessions to the device where you can.

Short-lived credentials

Stolen credentials only matter while they work. Swap long-lived keys for short-lived ones issued through OIDC federation, so CI gets cloud roles by workload identity, humans get just-in-time elevation, and tokens expire in minutes, not months. Static deploy credentials sitting on a developer laptop are an incident that hasn't been triggered yet.

A signing-service policy engine

This is the control I would put first for anyone holding keys. The signer should never be a dumb oracle. Put a policy engine in front of it that evaluates every request against limits and context before any key material is touched. It should run separately from the workloads that call it, with its own deploy path and its own approvers.

Pseudo policy:

signing_policy: default: deny rules: - name: hot-wallet-withdrawals match: wallet_tier: hot tx_type: transfer require: destination_in_allowlist: true amount_usd_max_per_tx: 250000 velocity: window: 1h amount_usd_max: 2000000 tx_count_max: 200 caller_workload_identity_in: [withdrawal-service-prod] caller_image_digest_in: approved_release_digests on_violation: block_and_page - name: delegation-and-permission-changes match: tx_type: [eip7702_authorization, approve, set_owner, upgrade] require: human_approvals: 2 # distinct people, distinct devices approver_auth: webauthn delegate_target_in_allowlist: true change_ticket_linked: true on_violation: block_and_page - name: anomaly-circuit-breaker match: any: true when: - outflow_usd_15m > 3 * baseline_p99 - new_destinations_15m > 20 action: halt_hot_wallet_signing

Three ideas carry the weight. Default deny. Velocity limits that stop a drain partway even when each individual request looks fine. Treating permission and delegation changes, such as EIP-7702 authorizations, as high-risk operations that need multiple humans, never as routine traffic.

Least privilege and admission control for container deploys

In this incident, stolen credentials were enough to deploy a container running a malicious script. Admission control is where you make "can authenticate to the cluster" different from "can run arbitrary code next to the signer."

Here is a Kyverno policy that only admits signed images from your registry into the signing namespace:

apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: signer-namespace-signed-images-only spec: validationFailureAction: Enforce background: false rules: - name: verify-image-signature match: any: - resources: kinds: [Pod] namespaces: [wallet-signing] verifyImages: - imageReferences: - "registry.example.com/wallet/*" mutateDigest: true verifyDigest: true attestors: - entries: - keyless: issuer: "https://token.actions.githubusercontent.com" subject: "https://github.com/example-org/wallet-service/.github/workflows/release.yml@refs/heads/main" - name: block-other-registries match: any: - resources: kinds: [Pod] namespaces: [wallet-signing] validate: message: "Only images from registry.example.com/wallet are allowed." pattern: spec: containers: - image: "registry.example.com/wallet/*"

This ties what runs to an image built by the release pipeline from main. A human holding stolen kubeconfig can no longer push an ad-hoc image. Pair it with RBAC under which no human identity can create pods in that namespace directly, and with a ban on kubectl exec into signer workloads.

Blast-radius segmentation

Keep hot wallets small. Put signing infrastructure in its own cluster or account with its own identity provider boundaries. Don't let the network path from general workloads to the signer exist at all. Cap hot wallet balances so that the worst case is a bad day and not an existential one. Rebalancing from cold storage should be slow, deliberate, and reviewed by humans.

Detection on anomalous deploys and withdrawals

Your detections should cover both sides of the off-chain path:

  • Deploys: a new image digest in a sensitive namespace, a deploy from outside the pipeline, a deploy by a human identity, a deploy at an unusual hour, or a new service account token mounted somewhere unexpected.
  • Withdrawals: outflow above baseline, a spike in new destinations, any delegation or approval transaction, and patterns that look like a sweep.

Wire these to automatic circuit breakers, not only pages. A detection that waits for someone to wake up is too slow when money moves in minutes.

4. Checklist

  • [ ] EDR on every engineering endpoint, with alerts triaged by a named owner
  • [ ] Policy against running unvetted tools on machines holding production credentials
  • [ ] Privileged access separated from everyday browsing and calls
  • [ ] Phishing-resistant MFA (FIDO2/passkeys) for SSO, cloud, CI/CD, and cluster access
  • [ ] No long-lived deploy credentials; OIDC federation and just-in-time elevation
  • [ ] Signing service behind a default-deny policy engine
  • [ ] Per-transaction limits, destination allowlists, and velocity caps
  • [ ] Delegation and permission changes (including EIP-7702) require multi-party approval
  • [ ] Admission control enforcing signed images from the release pipeline in signer namespaces
  • [ ] No direct human pod creation or exec in signer namespaces
  • [ ] Signing infrastructure segmented in its own cluster or account
  • [ ] Hot wallet balances capped; cold-storage refills reviewed by humans
  • [ ] Detections for out-of-pipeline deploys and new digests in sensitive namespaces
  • [ ] Detections for withdrawal anomalies, with automatic signing halt
  • [ ] Incident runbook covering stablecoin issuer and partner freeze contacts
  • [ ] Hiring and interview processes covered in security awareness (fake recruiters are a known vector)

Closing thoughts

I don't read this incident as a story about blockchains failing. The chain was the one component that behaved exactly as specified. It's a story about trust that leaked from a developer's machine into credentials, from credentials into a deploy, and from a deploy into a signer that didn't ask enough questions. Those layers belong to platform engineering. If you own them, the job is to make sure that something being signed is never enough on its own to show that it was intended.

I wrote shorter takes on LinkedIn and X. More of my writing is on my site.

I lead platform engineering for fintech. See more of my work or how we can work together at Nazmul Ahasan.

Sources