How did the Binance hack start?

In June 2026 a Wallet DevOps engineer installed a tampered Homebrew version of a popular AI coding tool after clicking a search result. Binance replaced the device and rotated credentials, but the attacker had already gathered intelligence on the team.

How was the second engineer compromised?

In September an engineer was approached by someone posing as a project director at a fictitious company, and was asked to set up a take home assignment repository on a work computer. The setup step ran malicious code that replaced the real pyenv with a trojanised copy.

What role did the internal AI tool play?

On 20 October the attacker used an internal Binance AI tool to gain control of two other engineers' computers. Binance has not explained how, but the tool acted as the lateral movement path between machines.

How much was stolen from Binance?

TRM Labs valued the outflows at roughly USD 6.36 billion across ten blockchains. Binance puts its figure at about USD 6.34 billion, with about USD 2.85 billion frozen or intercepted.

What was the crypto specific part of the attack?

On Ethereum the attacker used EIP 7702 and had the signing service produce 50 authorizations for 50 consecutive nonces, so one would still be valid when it landed and the hot wallet would run the attacker's sweeper contract.

The $6.3 Billion Binance Hack Was a Developer Laptop Hack, Not a Crypto Hack

04 Nov 2026 Cyber

The $6.3 Billion Binance Hack Started on Developer Laptops, Not the Blockchain

By Andrew Baker · Group CIO, Capitec Bank · 4 November 2026

The short version for executives

If you only read one part of this post, make it this list, and then ask your teams to show you the evidence behind each item rather than a slide that says it’s covered.

Any developer laptop with a path to money moving systems belongs in your top tier of endpoints, next to your administrator workstations.
Get standing deployment and cloud credentials off developer machines; issue them when needed, for a short time, tied to the device.
Don’t let anyone run interview code, take home tests or unknown repositories on a corporate machine, and give engineers a safe disposable environment for that instead.
Hand out developer tools, AI coding assistants included, from an approved internal catalogue so nobody has to go searching the web for them.
When a developer is compromised, treat it as an intelligence breach about the whole team, not a laptop to reimage.
Govern internal AI tools that can act across users or machines as privileged infrastructure, because that’s what they are.
Scan every pull request for malicious intent, especially the ones agents wrote, independently of the summary attached to it, and make any production change or API call from a developer’s laptop stand out.
Make every payment file and system originated payment reconcile to a control total it didn’t produce itself, and watch file sizes, transaction counts and gross flows for anomalies.
Run the payment injection scenarios in section 4 for real.

1. What actually happened, step by step

Most of what follows comes from Binance’s initial findings, published on X on 3 November 2026, along with on chain analysis from TRM Labs and a write up by SafeDep that works directly from Binance’s report. Where Binance hasn’t explained something, I’ll say so rather than guess.

A word on how solid the evidence is, because it varies. The size, timing and mechanics of the withdrawals sit on public blockchains, and independent analysts like TRM have traced them directly, so anyone can check that part. The story of what happened inside Binance, from the Homebrew install to the deployment token, comes from Binance’s own initial report, published while the investigation is still running, and from journalists reporting on it. It’s detailed and it hangs together, but nobody outside Binance has verified it yet, and some details may change once the external reviews Binance has commissioned come back.

It started in June 2026. An engineer on Binance’s Wallet DevOps team, whom Binance calls Engineer A, went looking for a popular AI coding tool, clicked through a search result to a tampered Homebrew installation, and installed it. Binance’s security team spotted the anomaly, replaced the laptop and rotated the credentials, which is what almost any security team would do, and normally that’s where the ticket gets closed. The trouble is that the attacker had already learned who Engineer A was, what they worked on and who else was on the wallet infrastructure team. The laptop was clean again, but you can’t rotate what someone already knows about your organisation.

The second move came in September, and it looks a lot like the North Korean campaign the security industry calls Contagious Interview, although Binance itself doesn’t name it. Engineer B, a software engineer whose profile on a recruitment platform mentioned Binance, was approached by someone claiming to be a project director at a company that turned out not to exist. There was a video call with an “HR representative”, who shared a personal social media account to seem more credible, and then a conversation in a chat app with the made up company’s “CEO”. After that, Engineer B was asked to download a take home assignment and set it up, and did it on their work computer. The setup step ran the attacker’s code.

What that code did is the reason nothing raised an alarm. According to the file operations Binance published, laid out clearly by SafeDep, it created a staging file next to the real pyenv in /opt/homebrew/Cellar/pyenv/2.8.0/libexec/, wrote 3,414 bytes of malicious content into it, deleted the real 3,344 byte pyenv, renamed its own copy into place and recreated the symlink in /opt/homebrew/bin. The logged in user owns /opt/homebrew, so it never needed a password prompt or any extra privilege. What was left behind was a doctored copy of a tool developers use all the time, quietly running commands and talking to the attacker’s server, and Binance says its endpoint security tooling didn’t catch it.

For anyone rolling out AI internally, the third move on 20 October is the one to pay attention to. Working from Engineer B’s laptop, the attacker used an internal Binance AI tool to take control of the computers of Engineer A and a wallet software engineer, Engineer C, according to Binance’s report. Binance hasn’t said how the tool made that possible, so the actual weakness isn’t public, but the tool was clearly part of how the attacker moved between machines. On Engineer A’s laptop they found a container deployment token.

The last step was on 29 October. Between 17:15 and 19:56 UTC the attacker logged on to Engineer C’s computer, deployed a container with Engineer A’s token and ran a script that reached Binance’s internal wallet signing service. From 20:05 UTC that service started producing valid signatures for whatever transactions the attacker wanted, across chains with different key types and signing schemes.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#1e293b','primaryTextColor':'#ffffff','primaryBorderColor':'#f59e0b','lineColor':'#f59e0b','fontSize':'15px'}}}%%
flowchart TD
  A["June 2026<br/>Engineer A searches for an AI coding tool<br/>installs a tampered Homebrew"] --> B["Binance detects it<br/>device replaced, credentials rotated<br/>attacker keeps the team map"]
  B --> C["September 2026<br/>Engineer B approached on a recruitment platform<br/>take home repo runs on the work laptop"]
  C --> D["pyenv silently replaced<br/>attacker gets command execution<br/>endpoint tooling stays quiet"]
  D --> E["20 October<br/>internal AI tool used to reach<br/>Engineers A and C"]
  E --> F["Container deployment token<br/>found on Engineer A's machine"]
  F --> G["29 October, 17:15 to 19:56 UTC<br/>log on to Engineer C's machine<br/>deploy container, run script"]
  G --> H["Wallet signing service signs<br/>attacker transactions on ten chains"]
  H --> I["20:05 UTC onward<br/>about USD 6.3 billion leaves hot wallets"]
  classDef stage fill:#1e293b,stroke:#f59e0b,stroke-width:2px,color:#ffffff;
  classDef money fill:#7f1d1d,stroke:#fca5a5,stroke-width:2px,color:#ffffff;
  class A,B,C,D,E,F,G stage;
  class H,I money;

2. What was crypto specific, and what wasn’t

TRM Labs traced the outflows across ten blockchains and valued them at roughly USD 6.36 billion, pricing each asset at the moment it was taken, while Binance puts the figure at about USD 6.34 billion. The freeze numbers are messier, partly because they’ve moved every day and partly because frozen, intercepted and recovered mean different things. TRM counted about USD 2.7 billion frozen on chain as of 00:30 UTC on 30 October, most of it stablecoins locked by their issuers, and Binance’s 3 November report says about USD 2.85 billion has been frozen or intercepted. Frozen isn’t the same as recovered, since getting the money back is its own legal and operational process, and I haven’t seen a published figure for what has actually been returned.

{
  "type": "bar",
  "data": {
    "labels": ["Ethereum", "Bitcoin", "Tron", "XRP Ledger", "Solana", "Arbitrum, Optimism, Base", "Avalanche", "Polygon"],
    "datasets": [{
      "label": "USD millions taken, valued at time of transfer (TRM Labs)",
      "data": [3790, 1470, 628, 296, 96, 39, 28, 10],
      "backgroundColor": "#f59e0b",
      "borderColor": "#fbbf24",
      "borderWidth": 1
    }]
  },
  "options": {
    "indexAxis": "y",
    "plugins": {
      "legend": { "labels": { "color": "#e5e7eb" } },
      "title": { "display": true, "text": "Binance hack outflows by chain", "color": "#e5e7eb" }
    },
    "scales": {
      "x": { "ticks": { "color": "#e5e7eb" }, "grid": { "color": "#374151" } },
      "y": { "ticks": { "color": "#e5e7eb" }, "grid": { "color": "#374151" } }
    }
  }
}

The properly crypto specific part was the endgame on Ethereum, and it’s clever. EIP-7702 lets an ordinary wallet hand its behaviour over to a smart contract by signing an authorization, but each authorization only works at the exact transaction count, the nonce, that the wallet has reached when it executes. A busy exchange hot wallet moves its nonce forward with every customer withdrawal, so the attacker had the signing service produce 50 authorizations covering 50 consecutive nonces, which made it very likely one would still be valid when the transaction landed. One was. The hot wallet started running the attacker’s sweeper contract, and three minutes and 24 seconds later it sent 167,464 ETH and 63 other tokens, including about 1.6 billion USDT, to the attacker in a single transaction. Then it kept sweeping new deposits until 23:56 UTC, because pausing withdrawals inside Binance did nothing to a permission that now lived on chain, and because the wallet used multi party computation there was no single private key Binance could grab to revoke it quickly. The delegation was finally cleared at 00:10 UTC on 30 October.

Crypto specialists are right that all of this mattered enormously to the size of the loss. Finality, permissions that persist on chain, and the fact that nobody can reverse a confirmed transfer made the cash out faster and the damage harder to undo. But those things decided how much was lost and how quickly. They had nothing to do with whether the attacker got in, or whether they reached the system that decides when money moves.

3. The signing service wasn’t compromised. Its authority was.

If I had to boil this incident down to one idea, it would be this one. By Binance’s account, the attackers didn’t steal private keys and the signing service didn’t malfunction. It received requests from a container deployed with a legitimate token, along a path it had been designed to trust, and it signed them. As far as anyone knows the service and its cryptography were sound, and it still carried out the attacker’s instructions, because the attacker had taken over the things that call it rather than the thing itself.

The lesson I’d take into any financial institution is that a valid signature proves an authorised system signed something; it doesn’t prove that the something was legitimate. We mix those two ideas up all the time, in payment gateways, HSMs, deployment pipelines, privileged AI agents and most of the other systems we rely on to decide whether something should happen. Hardening developer laptops matters, but the harder question is whether your most trusted systems can tell the difference between an instruction the business actually intended and one that only looks legitimate because it came in through a legitimate door.

Take the words “wallet” and “chain” out and the attack reads exactly the same against a bank. The bank’s version of the wallet signing service is whatever produces an instruction the outside world will act on: the payment hub that sends clearing files, the gateway that formats and signs messages to correspondent banks, the HSM backed service that signs bulk payment batches, or the treasury system that releases large transfers. We’ve seen this movie before, too. North Korea was behind the 2016 Bangladesh Bank theft, where attackers inside the bank’s environment sent fraudulent SWIFT instructions and got USD 81 million out. The target hasn’t changed since then; the way in has, and now it runs through the people who build, deploy and operate those systems.

Where banks and crypto exchanges really differ is in what happens after the breach. A bank has settlement windows, recall procedures, correspondent banks with their own controls, and fraud monitoring tuned to notice customer payments that look badly out of place. Whether any of that watches the payments the bank’s own systems generate is another matter, and it’s what the next section is about. It’s also worth remembering that people watching the chain spotted the Binance outflows within minutes. What nobody spotted was four months of preparation on laptops.

4. Run the scenario against your own payment flows

The most useful thing a leadership team can do with Binance’s report is run it rather than just read it. Find the system in your institution that plays the role of the wallet signing service, which for most banks is the pipeline that turns internal payment instructions into files or messages the outside world will honour, and ask a very plain question. If somebody slipped a million extra payment lines into one of your payment files sitting in an S3 bucket, or into a file passing through your managed file transfer platform on its way to a clearing house or a correspondent, would you process those payments, or would something notice the file was wrong before the money left?

My hunch, and I’d be happy for anyone who tests it to prove me wrong, is that a fair number of financial institutions would process them. I don’t have an industry survey to back that up, which is exactly why I think it’s worth testing instead of assuming. Payment file pipelines are built to be reliable, not suspicious. They check that the file is well formed, that the account numbers validate, that it came from the right system on the right schedule and that it carries the right signature, and every one of those checks passes if the attacker is sitting inside the system that writes the file, holds the token for the service that signs it, or can write to the bucket where it waits to be collected.

These are the scenarios I’d walk through, and I’d want the engineers who build the pipelines in the room, not just the people who own the controls on paper.

4.1 The volume injection

An attacker appends thousands of lines to a legitimate bulk payment or salary file after it’s generated but before it’s signed or collected. Does anything check the line count and total value against what the business actually approved, using a control total that a different system produced and sent along a different path? Or does the file, in effect, vouch for itself?

4.2 The value inflation

This time the attacker leaves the line count alone and changes the amounts and beneficiaries on a handful of existing lines. Are you watching the spread of transaction sizes within a file and across the day, so that a batch that usually carries payments in the thousands suddenly carrying a few in the hundreds of millions gets noticed? Or does the check stop at a per transaction limit that was set high on purpose to allow for legitimate large payments?

4.3 The gross flow test

Forget individual files for a moment and look at the whole institution. Do you have anomaly detection on gross movements, meaning the total value going out through each channel, correspondent, currency and hour, compared with what’s normal for that day of the week and that point in the month? If outbound flow through one channel doubled between eight and nine on a Thursday evening, who would find out, how long would it take them, and would they be allowed to stop it?

4.4 The trusted path

Finally, suppose the attacker never touches a file at all and instead deploys a container, the way they did at Binance, that calls your payment initiation API with valid service credentials. Does your monitoring treat payments your own systems originate with the same suspicion it applies to customer payments, or does it trust them because they came from inside? In most institutions fraud tooling grew up around customers, cards and channels rather than around the bank’s own engineering estate, which is why this is the scenario I’d test first.

If any of these ends with “we’d probably hear about it from the correspondent bank, or from reconciliation the next morning”, then the safety net is thinner than it looks.

4.5 Where detection is likely to be hardest

My working assumption is that spotting unusual values is harder in corporate and investment banking than in retail. To be clear, that’s a point about how hard detection is, not about overall risk, because real exposure also depends on authorisation controls, segregation of duties, settlement arrangements and transaction monitoring, and those vary hugely from one institution to the next. Retail flows are mostly millions of small, regular payments, so one enormous outbound payment tends to stick out. Corporate and investment banking is the opposite: very large, lumpy, irregular payments are the normal business, host to host files from corporate clients routinely carry huge totals, and a payment in the hundreds of millions is a Tuesday rather than an alert, which is much the same thing that made Binance’s hot wallets so hard to defend. Retail banks shouldn’t relax, though, since their high volume bulk processing is where the volume injection scenario lives, and a few thousand extra lines in a file of several million are easy to miss. I’d treat both of these as hypotheses to test, not conclusions.

4.6 The money ends up on the same rails anyway

The fact that fiat payments can be traced and recalled is a real advantage, but it only lasts while the money stays inside the regulated payment system, and any attacker is going to move it out as fast as they can. The laundering machinery North Korea has built over the past decade runs on crypto: over the counter brokers, stablecoin conversion, mixers, bridges and peel chains like the one TRM watched the stolen Binance Bitcoin go through. The Bangladesh Bank money in 2016 went through casinos in the Philippines, but I’d expect the proceeds of a similar bank theft today to be converted into crypto as quickly as the mule network allows, and from there to follow much the same route out as the Binance funds, just with a bank rather than an exchange as the starting point. So my argument to anyone running an institution that moves billions of dollars, euros, pounds or rand is that the risk Binance carried is your risk too. What differs is whether you find the attacker on a developer’s laptop in June or in your payment files in October.

5. Why developer machines are so hard to watch

We’ve mostly treated developer laptops as ordinary corporate endpoints, even though they’re often the one place where source code, cloud credentials, deployment tokens, SSH keys, internal AI tool sessions and chat access to every other engineer all sit together. North Korea seems to have noticed. Binance says it detected and blocked 57 suspected North Korea linked attacks in 2026, many of them using fake recruitment and malicious software. The USD 1.5 billion Bybit theft in February 2025, which the FBI pinned on the same TraderTraitor group, also started with a compromised developer machine, that time at Safe, the wallet software provider Bybit depended on.

Watching these machines properly is hard. On an ordinary day a developer’s laptop looks like malware to any simple rule, because developers run code from the internet all the time, package installs execute scripts, build tools spawn shells and open outbound connections, and people run containers, tunnels, debuggers and scripts they wrote that morning. The Binance implant was designed to blend into all of that. It replaced a version manager the developer had installed themselves, in a folder the developer owns, with a file almost exactly the same size, so any baseline asking whether pyenv normally runs on this machine gets the answer yes. The campaign was also spread over four months and three machines, and the June foothold was found and cleaned up, so a detection model that looks at one device at a time sees a series of events that each look either contained or harmless. You only see the shape of it if you connect a cleaned up compromise in June with a recruiter approaching a teammate in September and an odd container deployment in October.

Internal AI tools make this harder still. Binance has confirmed an internal AI tool was used to move between machines but hasn’t said how, so I’m not going to pretend I know the mechanism. The general point doesn’t depend on it, though: any tool that can act across users, machines or systems on engineers’ behalf has broad legitimate access and believable traffic patterns by design, which is exactly what an attacker wants to borrow. Binance rebuilt the tool and its access controls as part of its clean up, which suggests it saw it the same way.

6. Agentic masking: when the volume of legitimate change hides the malicious change

Nothing in Binance’s report says the attackers smuggled code in through a pull request, and I’m not suggesting they did. But they did work through the engineering workflow, and that workflow is changing under our feet in a way that will make the next version of this attack easier to hide.

Think back to what a code change used to look like. A developer checked in one or two files and wrote the commit message themselves, having read every line before a reviewer read the diff again. The size of the change was a control in its own right, because there wasn’t much for anything strange to hide behind.

These days it’s completely normal for a developer working with an AI coding agent to open a pull request touching 25 files, with a description the agent wrote, summarising changes the developer may only have skimmed. The reviewer, under the same pressure to ship, often reads the summary, glances at the parts that look important and approves it. More and more often an AI review tool has already commented on the diff, which feels like a second pair of eyes but is usually checking quality, style and obvious bugs rather than intent. I’ve started calling this agentic masking, where the sheer volume of plausible, machine generated, legitimate change becomes cover for a small amount of change that isn’t legitimate at all.

Now picture an attacker who controls a developer’s laptop, the agent running on it, or the material that agent reads. They don’t need a dramatic backdoor. One line in file 19 of 25 that copies a credential to a logging endpoint will do, or a dependency nudged to a malicious release, a validation check that quietly stops rejecting one particular account, or a configuration change that opens up a network rule. Any of those can be described in the generated summary as a routine refactor, and any of them is easy to skim past alongside 24 files of real work. If the attacker can influence what the agent writes, through a poisoned repository, a malicious prompt hidden in a file the agent reads or a tampered tool on the laptop, they get their change written, summarised and defended by the very system the reviewer is leaning on.

The answer isn’t to stop using agents. It’s to build what I think of as an equal and opposite muscle: if agents multiply what a developer can produce, the organisation needs scanning and supervision pointing the other way, asking of every change what it actually does rather than what its summary says it does. I see three parts to that.

The first is the code itself. Every pull request, and especially every one an agent wrote, should go past something whose only job is to look for malicious intent: new outbound network calls, new places where secrets are read or logged, changes to authentication, authorisation, validation or payment logic, new or changed dependencies, obfuscated or encoded strings, and changes to build and deployment configuration. Those findings should reach the reviewer separately from the generated summary so the summary can’t frame them, and anything touching sensitive paths like payment logic or signing should go to a named human owner, however small it looks.

The second is systems access. Every API call, deployment and production change made from a developer’s laptop should stand out. In a well run estate a developer’s machine should hardly ever talk to production directly, so when it does somebody should see it, tied to a person, a device and a reason. Anything changed or tampered with in production outside the pipeline should be treated as an incident until proven otherwise, which means constantly comparing what’s running with what the pipeline actually built and deployed, and alerting on any difference.

The third is supervision. Someone needs the overall picture of what each developer, and each developer’s agents, are doing across code, access and systems, and how that compares with what they normally do. An engineer whose pull requests suddenly start touching payment validation, whose laptop starts calling production APIs late at night, or whose agent starts reading repositories it has never looked at before is showing precisely the kind of drift that could have joined up Binance’s four months.

I think this is the start of a new category of security tooling. Endpoint detection and response showed us what processes do on a machine, and financial institutions now need to see what engineers and their agents write, merge, deploy, call and change across the whole delivery path, connected over months and judged on intent rather than syntax. Bits of this exist today in code scanning, cloud security and identity tools, but very little of it is joined up, and almost none of it was built for a world where one developer with an agent can produce more change in a day than a whole team used to manage in a week.

7. A quick triage script for Homebrew tampering

If you have developers on Macs, the script below is a rough triage aid for the kind of tampering Binance described, and I want to be honest that it isn’t an integrity verifier: anything running as the user can also change files, timestamps and any baseline kept on the same machine, so a dependable control needs trusted hashes held off the laptop and compared centrally. Baseline mode records SHA-256 hashes of every Homebrew executable on a freshly built machine, and compare mode checks a developer’s machine against it, which works best if your fleet runs pinned package versions. Heuristics mode lists bin symlinks that point outside the Homebrew prefix and recently changed executables, so a person can check them against your change history.

cat > brew-triage.sh << 'EOF'
#!/usr/bin/env bash
# Heuristic triage for tampered Homebrew tools on macOS.
# Not an integrity verifier: code running as the user can alter files,
# timestamps and any baseline stored on the same machine.
# Usage:
#   ./brew-triage.sh baseline > brew-baseline.txt   # on a known good machine
#   ./brew-triage.sh compare brew-baseline.txt      # on the machine under review
#   ./brew-triage.sh heuristics                     # when no baseline exists
set -uo pipefail

PREFIX="$(brew --prefix)"
CELLAR="$(brew --cellar)"

# Portable symlink resolution (older macOS readlink has no -f)
resolve() {
  local p="$1" n=0 t
  while [ -L "$p" ] && [ "$n" -lt 40 ]; do
    t="$(readlink "$p")"
    case "$t" in
      /*) p="$t" ;;
      *)  p="$(cd "$(dirname "$p")" && pwd -P)/$t" ;;
    esac
    n=$((n + 1))
  done
  printf '%s/%s\n' "$(cd "$(dirname "$p")" 2>/dev/null && pwd -P)" "$(basename "$p")"
}

manifest() {
  find "$CELLAR" -type f -perm -u+x -print0 2>/dev/null \
    | xargs -0 shasum -a 256 2>/dev/null \
    | sed "s|$CELLAR/||" | sort -k2
}

case "${1:-heuristics}" in
  baseline)
    manifest
    ;;
  compare)
    [ -f "${2:-}" ] || { echo "usage: $0 compare <baseline file>"; exit 1; }
    diff <(sort -k2 "$2") <(manifest) | grep '^[<>]' \
      | sed -e 's/^</BASELINE:/' -e 's/^>/THIS MACHINE:/'
    ;;
  heuristics)
    echo "== Symlinks in $PREFIX/bin resolving outside $PREFIX"
    for entry in "$PREFIX"/bin/*; do
      [ -L "$entry" ] || { echo "NOT A SYMLINK: $entry"; continue; }
      target="$(resolve "$entry")"
      case "$target" in
        "$PREFIX"/*) ;;
        *) echo "OUTSIDE PREFIX: $entry -> $target" ;;
      esac
    done
    echo "== Cellar executables with metadata changed in the last 30 days"
    find "$CELLAR" -type f -perm -u+x -ctime -30 -print 2>/dev/null
    ;;
  *)
    echo "usage: $0 baseline | compare <file> | heuristics"
    exit 1
    ;;
esac
EOF
chmod +x brew-triage.sh

Against the Binance pattern, compare mode would have flagged a hash mismatch on libexec/pyenv as long as the baseline itself could be trusted, and heuristics mode would have listed it among recently changed files, alongside any legitimate upgrades. The better long term fix, which I come back to below, is to stop developers owning the folders their trusted tools run from.

8. What organisations with software developers should actually do

None of this is exotic. Most of it comes down to deciding that developer machines, and the systems they can eventually reach, deserve the same seriousness we already give to production.

8.1 Treat the developer laptop as production adjacent infrastructure

For every engineer’s machine, ask what a patient attacker could reach from it within a week. If the honest answer includes a route to anything that moves money, signs instructions or deploys next to those systems, that laptop belongs in your top tier of protection. Contractor and personal machines with the same reach need the same controls or need to lose the access, especially since Binance’s first statement couldn’t say whether the laptop belonged to an employee or a contractor, and an attacker doesn’t care either way.

8.2 Get standing credentials off developer machines

The key piece in the Binance chain was a container deployment token sitting on an engineer’s laptop. Deployment credentials, cloud keys and access to anything near payments should be issued when a specific change needs them, expire quickly, be tied to a hardware backed device identity where your platform supports it, and never be left lying around on disk.

8.3 Never run interview code or unknown repositories on corporate machines

Make this a clear, published rule and give people a realistic alternative, such as a disposable cloud development environment or an isolated virtual machine with no corporate credentials, no single sign on session and no route into internal systems, where any outside repository gets opened first, including anything from a recruiter. Don’t pretend your engineers aren’t looking at other jobs. Some of them are, the attackers know it, and that’s why they go after people whose profiles name their employer. Make it safe and normal to report a dodgy recruiter approach, and treat those reports as threat intelligence.

8.4 Control the toolchain instead of letting people search for it

Engineer A was compromised while searching for an AI coding tool, which is currently one of the most searched for and most impersonated kinds of software around. Publish an approved catalogue of developer tools, including the AI assistants you’re happy for people to use, and push them out through device management or an internal mirror so nobody needs to search. Route package installs through a proxy that can block known malicious and freshly published packages, and where you can, take trusted toolchain folders out of user ownership so malware running as the developer can’t quietly swap them out.

8.5 Treat a cleaned up developer compromise as an intelligence breach

When Binance replaced Engineer A’s laptop it fixed the laptop, but the attacker kept the map of the wallet team. If an engineer who works on money moving systems is compromised, raise monitoring on the whole team for months rather than days, warn them they’re likely to be approached, and review what the team can reach between them. Here, the second wave came three months after the first incident was closed.

8.6 Build detection that understands developers and remembers for months

Detection on developer machines has to understand process lineage, like an install step spawning a shell that opens an outbound connection, along with file integrity for trusted tools checked against baselines kept off the laptop, new persistence, and credentials being used from a machine that has never used them before. Your security operations team also needs a way to connect events across devices and across months, so that a June incident, a September recruiter approach and an October deployment from an unusual machine read as one story rather than three separate tickets.

8.7 Put internal AI tools inside your privileged access model

If an internal AI tool can read, act or run things across more than one person’s machine or account, govern it by what it can actually do rather than treating it as a chat app. Scope it per user and per task, stop it acting for one engineer with another engineer’s access, log everything it does somewhere your security team can search, and include it in threat modelling and red team exercises.

8.8 Make deployment into sensitive environments a two key operation

One engineer’s token was enough to deploy a container that could talk to the signing service. Environments that can reach payment or signing services should only accept artefacts your pipeline built and signed, enforced at admission time, with a second person approving the change, and no interactive human session should be able to deploy straight into them.

8.9 Make the money service distrust its own callers

Whatever service authorises value should apply its own rules regardless of who’s calling: velocity and value limits, outright rejection of instruction types that should never appear (TRM specifically recommends rejecting unexpected EIP-7702 authorizations and treating a request for many authorizations across a range of nonces as a sign of compromise), and signing authority split by tier and destination so that one compromised caller can’t get valid signatures for everything at once. Then practise the emergency stop. How quickly could you freeze outbound release, invalidate signing keys and alert your correspondents, and have you ever actually tried?

8.10 Make payment files prove themselves against something they didn’t produce

Before release, every payment file and system originated payment should reconcile to a control total of line count and value that came from a different system, travelled by a different path, and can’t be written by the engineers or credentials that produce the file. Add anomaly detection on file size, transaction counts, the spread of values and gross outbound movement by channel, currency and hour, apply it to payments your own systems generate as well as customer payments, and give the people watching it the authority to hold a release. Then run the section 4 scenarios for real, with a red team injecting into a non production pipeline.

8.11 Build the equal and opposite muscle for agentic development

Put the three controls from section 6 in place: intent scanning on every pull request, reported separately from the generated summary; alerts on any production change or API call from a developer’s laptop; and somebody whose job is watching how each developer’s and each agent’s behaviour changes over time. Then test it the way you’d test the payment flows, by having a red team try to land a malicious line inside a big, agent generated pull request and seeing who catches it.

9. The battlefield has moved

I don’t think the lesson from Binance is that crypto is uniquely unsafe, even though its finality made the losses bigger and faster. The lesson is that the most capable financially motivated attackers in the world no longer need to break the systems that move money. They borrow the authority of the people and systems allowed to ask for it, by way of the engineers who build those systems, the recruitment processes those engineers go through, the tools they search for and the agents we’re now handing them, and they’re patient enough to look exactly like a developer doing their job.

Most financial institutions have put a great deal into protecting keys, perimeters and production. The ones that come through the next few years in good shape will be the ones that stop treating a valid signature, a valid token or a valid file as proof that somebody meant it, and that teach their most trusted systems to question instructions arriving through trusted paths.

Sources

Binance, Initial Findings and Response Update, published on X, 3 November 2026: https://x.com/binance/status/2117626126214504729
TRM Labs, North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History: https://www.trmlabs.com/resources/blog/north-korea-steals-usd-6-36-billion-from-binance-in-the-largest-hack-in-history
SafeDep, Binance Hack: How Attackers Stole $6.34 Billion Through Developer Laptops: https://safedep.io/blog/binance-hack-developer-supply-chain-attack-path
Security Affairs, Binance Hack: How Fake Job Interviews and AI Abuse Led to a $6.34 Billion Attack: https://securityaffairs.com/202369/cyber-crime/binance-hack-how-fake-job-interviews-and-ai-abuse-led-to-a-6-34-billion-attack.html
Finance Magnates via CoinSpectator, Binance Hack Began with Fake Job Interviews, Ended with $6.3 Billion Stolen: https://coinspectator.com/mainstream/2026/11/03/binance-hack-began-with-fake-job-interviews-ended-with-6-3-billion-stolen/
Unite.AI, Binance Details Fake Job Interviews and AI Tool Compromise in Hack: https://www.unite.ai/binance-details-fake-job-interviews-and-ai-tool-compromise-in-hack/
Jamf, Binance attack: how DPRK targets developer laptops: https://www.jamf.com/blog/binance-attack-dprk-developer-laptop-security/