1 · June 2026Engineer A, Wallet DevOps
A poisoned download, caught, but not forgotten
Engineer A searched the web for a popular AI coding tool and installed a tampered copy of Homebrew, the installer Mac developers use for almost everything. Binance's security team spotted the anomaly, replaced the laptop and rotated every related credential.
The attackers still won something. They now knew who Engineer A was, what the wallet infrastructure team did, and who worked alongside them.
The controlInstall developer tools only from verified sources, and check the signing key against the vendor's own published fingerprint, never against a number someone pastes to you. Treat a caught intrusion as reconnaissance that succeeded: the whole team is now a target.
In my lab BuildingVAULT01, the lab's secrets server, installs HashiCorp's packages only from a source pinned to their signing key, and that key is checked against the fingerprint HashiCorp publishes, not one copied from a guide.
2 · September 2026Engineer B, Software
The job interview that was never a job
Engineer B was approached on a real job-hunting platform by a "Project Director". There was a live video interview with an "HR representative" who shared a personal social media account to build trust, then a second interview with a "CEO" of a company that did not exist.
Near the end, Engineer B was asked to download a take-home "assignment" onto his work computer. The assignment carried the malware.
The controlJob-hunting and personal downloads stay off work devices, as policy, not advice. Any code from outside runs in a throwaway virtual machine first. Staff who touch money systems get specific briefings on the fake-recruiter playbook, which the FBI has warned about for years.
In my lab NextA throwaway analysis VM on the hypervisor, reset from a clean snapshot after every use, so outside code never runs on the admin laptop. The rule behind it: the laptop holds keys, so it never runs strangers' code.
3 · September 2026Engineer B's laptop
A trusted tool, quietly replaced
The malware swapped a real developer tool on the laptop for a look-alike that answered to the attackers. It was new code, so the endpoint protection did not recognise it, and it cleaned up its own traces afterwards.
From that moment the attackers had a quiet, durable foothold inside Binance's engineering network.
The controlWatch the tool paths themselves. File integrity monitoring raises an alert when a binary a developer relies on changes outside a package update. Pair it with detection that looks at behaviour, such as a developer tool opening a connection to an unknown server, rather than only known-bad signatures.
In my lab NextWazuh already watches every enrolled host. The snippet below points its file integrity monitoring at developer tool paths, so a changed binary under /usr/local/bin or /opt becomes an alert, then I attack it to prove the rule fires.
Detection: what to watch forATT&CK T1574 Hijack execution flow · T1070 Indicator removal
- Tool binary changed
- A file inside a package manager's install tree changes when no package manager is running. Homebrew's
/opt/homebrew/Cellar, pyenv's libexec, /usr/local/bin. Legitimate changes come from brew, apt or pip; anything else is suspect. - Delete, then replace
- The same path is deleted and recreated within seconds with a different size or hash. Real upgrades write a new versioned folder; a swap in place is the tell the report describes.
- New or changed symlink
- A link in a tool's
bin directory is added or repointed outside an install. Links are how a fake tool gets called instead of the real one. - Setup step spawns a shell
- A project's install or setup step (
npm install, pip install, make, a setup script) starts an interactive shell or a long-lived background process. Installs fetch and build; they should not leave a shell running. - Developer tool phones home
- A tool that normally works offline, such as a version manager, opens a connection to a host that is not a known package registry. Endpoint network telemetry catches this when signatures do not.
- Files no longer match
- Scheduled checks against the package manager's own records:
dpkg --verify on Debian and Ubuntu, rpm -Va on Red Hat. Any tool file that differs from what was installed gets a ticket.
<!-- Wazuh agent: watch developer tool paths in real time -->
<syscheck>
<directories realtime="yes" check_all="yes">/opt/homebrew/Cellar,/opt/homebrew/bin</directories>
<directories realtime="yes" check_all="yes">/usr/local/bin,/usr/local/lib</directories>
</syscheck>
4 · 20 October 2026Engineers A and C
An internal AI tool became the bridge
From Engineer B's compromised laptop, the attackers used one of Binance's own internal AI tools to reach the computers of Engineer A (Wallet DevOps) and Engineer C (Wallet Software). The company's assistant became the road between machines.
On Engineer A's computer they found the prize: a token that allowed containers to be deployed, sitting on disk.
The controlAn AI tool is an identity, and it needs the same governance as a person: its own account, the narrowest permissions that do its job, no reach across devices it has no business touching, every action logged, and one switch that turns it off.
In my lab BuiltMy AI agent has its own Keycloak identity: a confidential client that gets five-minute tokens and nothing else. Disabling it in one place cut off every token request within a minute, and Keycloak's event log recorded
client_disabled.
Chapter 23, section 11.
5 · 20 to 29 OctoberEngineer A's deployment token
One long-lived key, in the wrong place
The deployment token did not expire, and it worked for whoever held it. Nine days later the attackers logged on to Engineer C's computer and used Engineer A's token from there. Nothing stopped a key being used from a different person's machine.
The controlNo long-lived credentials on laptops. Deployment credentials come from a secrets manager, live for minutes, and are bound to the identity and device that asked for them. A key used from an unexpected device is itself an alert, which is only possible when logs show the real device.
In my lab BuildingVAULT01 exists to retire exactly this: static secrets replaced by short-lived ones issued per request and audited. Already built: since the Tailscale fix, every lab log shows the real connecting device, so "right key, wrong machine" is something Wazuh can see.
Chapter 5.
6 · 29 October, 17:15 to 20:09 UTCThe wallet signing service
Four minutes
Between 17:15 and 19:56 the attackers deployed a container with the stolen token and ran a script that reached the wallet signing service, the system that approves outgoing payments. At 20:05 they began signing transfers outside the normal withdrawal process.
By 20:09, 233.46 million XRP had left five hot wallets. Solana, Optimism and then 18,270 Bitcoin followed. Binance's alert for large transfers fired after the first wave was already gone.
The controlSigning policy that no single token can bypass: limits per transaction and per hour, a second approver above a threshold, and the bulk of funds in cold storage that no online service can sign for. Alerts must fire on the first unusual signature, not on the total.
In my lab BuiltThe same principle at smaller scale: the agent's identity can prove who it is, but what it may do is a separate, narrow policy. Detection rules in Wazuh are written for the first odd event, then tested by running the attack against them.
7 · 29 October, 20:09 to 00:10 UTCContainment
They switched off withdrawals. The theft continued.
Binance suspended withdrawals, worked with partners to freeze tokens, and froze $2.85 billion. But the attackers had used an Ethereum feature called EIP-7702 to give their own smart contract standing rights over a Binance wallet. That permission lived on the blockchain, not in Binance's systems, so Binance's off switch did not reach it.
The wallet used multi-party computation, so there was no single key to cancel the permission with. A special procedure had to be built on the night. The last unauthorised transfer finalised at 23:56. The permission was cleared at 00:10.
The controlDesign the revocation before the incident, and rehearse it. Know exactly what your "stop" button does not stop: standing permissions, tokens already issued, sessions already open. Time to revoke is a metric to measure in a drill, not to discover at 11 pm.
In my lab BuiltThe Keycloak off-switch test taught the same lesson in miniature: disabling the agent blocks every new token at once, but a token already issued stays valid until it expires. That is why its lifetime is five minutes, and why the first question for any system is "how do I revoke, and how long does it take?"
