Poisoned Pipeline / Incidents / AS343
A fake interview repository replaced pyenv on an engineer's laptop, and a stolen deployment token reached Binance's wallet signing service
Git / GitHubDeveloper workstationmacOS softwareDocker / containers
Between 20:05 and 23:56 UTC on 29 October 2026, transactions that no
withdrawal request had asked for left Binance's hot wallets. Binance's
initial findings, published on 3 November, put the impact at about
USD 6.34 billion; the FBI's alert of 31 October attributes the theft to
North Korea's TraderTraitor activity and lists the addresses holding
the proceeds. Binance says roughly USD 2.85 billion was frozen or
intercepted, subject to reconciliation and market prices, that 98 per
cent of impacted token assets had been replenished as of 31 October,
and that it will absorb the loss. Selected withdrawals reopened on
1 November. The investigation is continuing and an independent review
is planned.
The attack began on developer laptops, and it began in June. A wallet
DevOps engineer that Binance calls Engineer A searched for an AI coding
tool and installed it through a tampered Homebrew installation; Binance
points to a SANS Internet Storm Center diary for the package detail.
Binance detected the anomaly, replaced the device and rotated related
credentials, and says the attacker had by then learned A's role and the
names of the engineers on the wallet infrastructure team. Nothing
published establishes continuous access from June to October, and
nothing establishes that the Homebrew project itself was compromised
rather than the installation A downloaded.
In September a second engineer, B, was approached on a legitimate
recruitment platform by someone posing as a project director. Two
interviews followed: a video call with an "HR representative" who
shared a personal social-media account to build trust, and a chat with
the "CEO" of a company that does not exist. B was then asked to
download an assignment repository onto a work computer. Malicious code
ran during setup, contacted an attacker-controlled server, and was not
detected by the endpoint protection in place at the time. Binance
publishes the file operations that followed, all in the engineer's own
Homebrew prefix: create /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv_
(3,414 bytes), write the payload into it, delete the real
libexec/pyenv (3,344 bytes), rename the new file over it, delete
/opt/homebrew/bin/pyenv, re-create that symlink, and start a zsh shell.
The malicious pyenv ran the operator's commands and connected out.
Because the logged-in user owns /opt/homebrew, none of this needed a
password prompt, and the name on PATH stayed the same.
On 20 October the attacker used an internal AI tool, running from B's
compromised laptop, to take control of A's computer and that of a third
wallet engineer, C. Binance has not said how the internal tool gave
that access, and the report identifies no software zero-day, no prompt
injection, no MCP exploit and no named commercial AI coding product as
the cause. On A's computer the attacker found a token with container
deployment permission. Between 17:15 and 19:56 UTC on 29 October the
attacker worked from C's computer, used A's credentials to deploy a
container, and triggered a script inside it.
That container reached an internal wallet signing service, which
initiated transactions outside the normal withdrawal process. The
same service signed 50 transactions carrying nonce manipulation and
EIP-7702 delegations to an attacker-controlled contract, and a
delegation set that way survives the transaction that installs it, so
suspending withdrawals did not revoke it. Binance's hot wallets run
multi-party computation, and revoking the delegation needed a
dedicated procedure rather than a fresh signature; Binance cleared it
with a new authorisation to the zero address at 00:10 UTC on
30 October. The last unauthorised transfer, 2,961.9 ETH, finalised at
23:56 UTC on 29 October after being broadcast earlier, which does not
by itself show the attacker still held access at that time. Transfers
also went out on Bitcoin, XRP Ledger, Solana and Optimism.
Binance says it has rebuilt the affected wallet system and the internal
AI tool, replaced the affected devices, decommissioned the related
credentials and tokens, and widened device scanning and behavioural
detection, and that it stopped 57 other suspected North Korea-linked
attempts during 2026 that used fake interviews, fake developer tools,
compromised packages and browser extensions. Binance does not name a
campaign. SafeDep reads the interview sequence as Contagious Interview,
the DPRK-linked pattern it has documented before, and is explicit that
the match is technique rather than attribution.
Mapped techniques
- T0197 Use code from untrusted source
- T0159 Malicious artifact execution
- T0225 Replace a developer tool in a user-writable prefix
- T0153 Compromised developer workstation
- T0155 Cloud workload
- T0226 Reach a signing service through the deployment path
- T0201 Customers compromised
supply-chain Binance engineer workstations, through a recruitment-assignment repository
The assignment repository came from a person outside the
company, over a recruitment platform, with no registry, no
publisher and no provenance behind it. Engineer B ran it on a
work computer as instructed by the interviewer, and code
executed during setup.
The setup step executed the repository's code, which contacted
an attacker-controlled server. Binance says the endpoint
protection then in place did not detect it.
pyenv's libexec/pyenv was replaced with a 3,414-byte copy after
the real 3,344-byte file was deleted, and the /opt/homebrew/bin
symlink was re-created, so the tool on PATH kept its name and
ran the operator's commands on demand. The prefix is owned by
the logged-in user, so none of the six file operations needed
a password.
Three engineers' computers were reached: B's through the
assignment repository, then A's and C's from B's machine
through an internal AI tool. Binance replaced the affected
devices and decommissioned the credentials and tokens in use
on them.
post-supply-chain Binance's wallet signing service and hot wallets
A container was deployed on 29 October between 17:15 and 19:56
UTC using a deployment token taken from Engineer A's laptop,
from Engineer C's computer, and a script inside it was
triggered. The container platform is not named.
The deployed workload reached an internal wallet signing
service, which initiated transfers outside the normal
withdrawal process and signed 50 transactions setting up
EIP-7702 delegations. The signatures were valid; the delegation
outlived the withdrawal freeze and had to be cleared with an
authorisation to the zero address at 00:10 UTC on 30 October,
through a dedicated MPC procedure.
About USD 6.34 billion left the hot wallets; Binance reports
roughly USD 2.85 billion frozen or intercepted and 98 per cent
of impacted token assets replenished as of 31 October, with the
exchange absorbing the loss. Replenishment is not recovery, and
no per-customer count is published.
Framework gaps noted
- How the internal AI tool gave the attacker control of two other engineers' computers is not disclosed. Binance names no mechanism, no zero-day, no prompt injection and no MCP exploit, so no technique is mapped for that pivot.
- How the deployment token was stored on Engineer A's laptop — file, environment variable, or an authenticated session — is not published, which is why T0184 and T0140 are not mapped. The token's full permissions and lifetime, the container platform and the signing policy configuration are all unpublished.
- The June tampered Homebrew installation is described only by reference to a SANS Internet Storm Center diary and by the effect Binance observed. Which package was tampered with, and whether the tampering was upstream or in the copy A downloaded, is not established, so it is recorded here as background rather than as a separate story.
- EIP-7702 delegation is account state that persists after the transaction that installs it, and the catalogue has no technique for "authorisation that outlives the transaction" — the reason suspending withdrawals did not contain the theft. AS341 records a comparable gap for session-scoped approvals.
- Nothing describes the attacker's initial selection of Engineer B, the recruitment platform account, or whether it was a real account that had been taken over. The fake corporate identity behind the second interview is described only as a company that does not exist.
- No host indicators are published beyond the file paths and byte sizes of the pyenv replacement. Binance says the endpoint protection in place did not detect the payload but does not name the product.
- Attribution is the FBI's, at the TraderTraitor level. Binance does not name a campaign, and SafeDep's Contagious Interview match is technique-level. Not merged with AS342, which SafeDep also reads as Contagious Interview, or with AS41.
Sources
- https://www.linkedin.com/pulse/29-october-binance-security-incident-initial-findings-response-modgf/
- https://www.fbi.gov/investigate/cyber/alerts/2026/north-korea-responsible-for-6-billion-binance-attack
- https://www.linkedin.com/pulse/security-incident-recovery-update-6-withdrawals-reopen-more-assets-qwy2c
- https://safedep.io/blog/binance-hack-developer-supply-chain-attack-path
- https://www.stepsecurity.io/blog/binance-hack-developer-machine-security
- https://eips.ethereum.org/EIPS/eip-7702