On 29 October 2026 an attacker took control of Binance's hot wallet "Binance14", using 50 valid signatures from that wallet's key 1. Binance says the attacker reached an internal wallet signing service, and gives no mechanism 2. A hot wallet is an exchange account kept online so it can pay customers quickly. Part One measured how those signatures worked on the Ethereum blockchain. Part Two asks two other questions: how the attacker reached the signing service, and where the assets went. The first is known only from Binance's self-reported initial report, which describes a tampered software install, a fake job interview and an internal AI tool, and gives no mechanism for the last step 2. We test the one part of it that can be checked against public source code, a file size, and find it consistent with a clean install by our arithmetic, untested on a real machine 1. For the second question, our own measurements from the replies of two public Ethereum data providers follow the assets two hops from the wallets that received them. Before the theft, the attacker's fuel money that we traced came through a mixer. After it, at the addresses we followed, we saw speed, fresh addresses and waiting, and no mixer on our incomplete list 1. We compute no dollar values. Sources are read through 12 November 2026.

• The route is Binance's account alone. A tampered install in June, a fake recruiter in September, an internal AI tool on 20 October, and on 29 October "unauthorized access to an internal wallet signing service", with no mechanism given 2.
• One checkable detail checks out on paper. Binance's 3,344-byte pyenv file matches a clean install under /opt/homebrew, by our arithmetic on public source. We have not tested a real install 1.
• Attribution. The FBI names North Korea. Three tracing vendors agree. North Korea denies it 49101117.
• Before the theft, the payments we traced into the attacker's account came through Tornado Cash 120.
• After the theft, 700,000,000 USDT left the first receiving address within nine minutes, and on 12 November about 214,720 ETH sat at two fresh addresses that had never sent a transaction 1.
• Not established. Where the assets went past the addresses we followed, and whether a mixer was used later.

• Endpoint and detection teams. By Binance's account, the route began on developers' own computers, with a tampered install and a take-home "assignment" 2.
• Reverse engineers. A published byte count is a small, checkable fact. It does not make a good hunting rule 1.
• Security leaders evaluating AI tools. Binance says the attacker "used an internal AI tool to gain control over" two engineers' machines, and gives no mechanism 2.
• Tracing and compliance teams. The stolen assets moved by speed and fresh addresses, not, as far as we followed them, through a mixer 1.
• Anyone reading the attribution. The FBI, three vendors who sell tracing, and a denial are not three independent confirmations 49101117.

"We" is hwtn.io's research pipeline. AI models read the sources, ran the measurements and drafted this text. Three AI models from three different labs fact-checked the text it was split from, and a person, the author, made the rulings.

We decoded the transactions ourselves from the replies of two public Ethereum data providers 1. A node is a computer running Ethereum's software with a copy of the shared record. A provider answers questions through an endpoint that may sit in front of several nodes or shared infrastructure, so two providers are not proven to be two independent nodes. We followed the attacker's funding, the two receiving addresses and the two USDT hop addresses to 12 November 2026 1. An address is the public identifier of an account on the chain, a string beginning 0x. We used no explorer for these values, except where a Blockscout read is cited. An explorer is a website that indexes the chain for searching. We computed no dollar values, so every USD figure here belongs to the party named beside it1. (If you see a dollar sign, it isn't ours.) We also measured the size of one source-code file at a published version 1.

The admission rule is short. A factual point appears only if it rests on a primary source, a legitimate secondary source marked for what it is, or two weak sources that do not derive from each other. Our own readings stay in, labeled as readings. The claim register at the end gives each claim's status.

Binance's 3 November report is the victim's own account, and it calls itself "our initial report" 2. Our copy is text saved on 11 November 2026, not compared with the live page. We have read no later Binance statement. Chain times are UTC. Binance gives no time zone for its reported deployment interval of 17:15 to 19:56.

A reading note. This is Part Two of two, and each part is meant to stand alone. If a term is new, it is in bold where it first appears and again in the glossary at the end. The long strings beginning 0x are addresses and transaction IDs. They are there so anyone can check our work. You are allowed to skip them.

Part One measured the theft itself on Ethereum. You need five facts from it here, and a little vocabulary to carry them. A smart contract is a program stored on the chain. Under EIP-7702, a 2025 change to Ethereum, an ordinary key-controlled account can sign a short authorization letting it run a contract's code as its own. That arrangement is called a delegation3. At 20:20:59 UTC on 29 October, one transaction carried 50 such authorizations, every one carrying a valid signature from Binance 14's key, and one took effect 1. Binance 14 then ran the attacker's sweeper, a contract for moving everything out of an account, until Binance cleared it 3 hours 49 minutes 36 seconds later 1. The assets went to two receiving addresses, the attacker's first destinations, of which 0x5227f603…

2f8c

took most 1. A token issuer can blacklist an address, which freezes the issuer's tokens there. Tether did so to that address at 21:01:35 1.

One party tells the story of how the attacker reached the signing service, and that party is the victim. Only one detail of the story can be checked against public code. Everything attributed to Binance here is self-reported. Binance does not say how each event led to the next, so we do not treat the series as an established chain of cause and effect 2. Four dated events follow. Read them as a list of things Binance says happened, in order, and no more than that.

June 2026. Engineer A "downloaded a tampered Homebrew installation". Homebrew is a popular tool for installing software on Macs. Binance says it "detected the anomaly, replaced the device, and rotated all related credentials", and that his role "was exposed to the hacker" 2. Palo Alto Networks, a security vendor, goes further and states without hedging that the engineer clicked a poisoned search ad that delivered MacSync Stealer, a password-stealing program. Binance's report links to a write-up of that chain without saying it applies 132.

September 2026. A fake recruiter approached Engineer B through "a legitimate job-hunting platform" and, after two interviews, he ran an "assignment" on his work computer2. Fortune reports that Binance executives named LinkedIn 16. Binance does not say whether June's exposure led to September's approach. We ask.

20 October. The attacker "used an internal AI tool to gain control over" Engineers A and C, and found a container deployment token on A's computer 2. A container deployment token is a credential that lets someone launch software on a company's servers. A hypothesis, and only that: if the tool held standing access to engineers' machines, it acted as a privileged go-between. Binance gives no mechanism.

29 October. "between 17:15 and 19:56", a container was deployed from C's computer with A's credentials 2. Then: "The attacker exploited unauthorized access to an internal wallet signing service to initiate transactions outside the normal withdrawal process" 2. A signing service is the internal system that produces the cryptographic signatures a company's wallets need. Again, Binance gives no mechanism.

The pyenv trace. This is the one detail we can check, so it gets the slow treatment. pyenv is a tool developers use to manage versions of the Python programming language. Its main program is a short script at libexec/pyenv. When Homebrew installs it, Homebrew writes its own install location, the install prefix, into the file. The prefix is /opt/homebrew on Apple Silicon (M-series) Macs and /usr/local on older Intel Macs. Binance's September account lists pyenv file operations on Engineer B's work computer. A file .../libexec/pyenv of 3,344 bytes was deleted and replaced by a 3,414-byte file, 70 bytes longer, which was created as /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv_ and renamed into place 2. The Cellar is the folder where Homebrew keeps installed programs. The report shortens the deleted file's path, and we take it to be the same Cellar directory.

Now the arithmetic, which is short. libexec/pyenv at version 2.8.0 is 3,341 bytes, and Homebrew's recipe for 2.8.0, its install instructions for pyenv (commit bf0434b5e824, one recorded change in the recipe's history), replaces the file's one /usr/local with the install prefix 156. /opt/homebrew is three characters longer, so that adds 3 bytes. Does Binance's number match? By our arithmetic, yes: a clean Homebrew install of pyenv 2.8.0 on an Apple Silicon Mac would be 3,344 bytes, matching Binance's figure. We have not tested a real install 1. pyenv 2.8.0 was released on 13 July 2026, and Homebrew carried it until 18 July 18. Homebrew's documented install records include no per-file fingerprints that would show a later change to the file 7. The short version: by our arithmetic, the deleted file was the size an ordinary install would produce. That is consistent with it being untouched. It is not proof.

Binance calls the malware "0-day malware" without defining the phrase. A zero-day usually means a flaw or tool unknown to defenders when it is first used. Binance says its endpoint protection, the security software on employees' computers, did not detect the malware at the time. That is a statement about detection. It does not establish whether the malware or any exploited vulnerability was previously unknown 2. Binance also reports that it "detected and prevented 57 suspected North Korea-linked cyber threat cases" in 2026, a count with no denominator 2. (Fifty-seven of how many? The report doesn't say.) It lists remediation steps. StepSecurity, a security vendor, notes "These remediation steps have not yet been independently verified", and we found no verification 212.

By Binance's account the route ran through developers' own machines, and the one detail we could check against public code, a byte count, is consistent with a clean install, not proof of one.

Attribution. The FBI's alert of 31 October 2026, as reported by The Record and BleepingComputer, says North Korea "was responsible for the theft of more than $6 billion USD in virtual assets from cryptocurrency exchange Binance, on or about October 29, 2026", and calls the activity "TraderTraitor" 41415. Binance's report, as published on 3 November, relays the FBI and makes no attribution of its own 2. TRM Labs, Chainalysis and Elliptic, which sell tracing services, each attribute the theft to North Korea 91011. Elliptic hedges: its page, as read on 12 November 2026, says the FBI named a group "which Elliptic has already assessed as the likely culprit" 11. North Korea denies involvement and calls the claims "fabrication", according to Reuters citing KCNA, North Korea's state news agency, read in a syndicated copy, and SBS, read in machine translation 1718.

Tracing means following assets from address to address on the public chain. Each step from one address to the next is a hop. Follow the money, the advice goes, and it never says how far. We followed the attacker's funding backwards and the stolen assets forwards, to a limited depth.

Funding. Every Ethereum transaction pays a small fee in ETH, often called gas money, so the attacker's account needed ETH before it could act. A mixer is a service that pools many people's deposits, so that a withdrawal cannot easily be linked to the deposit that funded it. Tornado Cash is one. On 28 and 29 October the attacker's account received three payments of about 0.098 ETH, each from contract 0x12D66f87A04A9E220743712cE6d9bB1B5616B8Fc in a call to 0xd90e2f925DA726b50C4Ed8D0Fb90Ad053324F31b, and 1.082218 ETH from a second account, itself paid by that contract and by 0x47CE0C6eD5B0Ce3d3A51fdb1C52DC66a7c3c2936 through the same route 1. Tornado Cash's own documentation lists those addresses as its 0.1 ETH pool, router and 1 ETH pool 20. A pool holds deposits of one fixed size, and the router is the contract users call to reach the pools. The designation, or sanctions listing, that the US Treasury's sanctions office (OFAC) issued on 8 August 2022 listed all three 21, and Treasury lifted it on 21 March 2025 22. Maborak had labeled two of the payments as Tornado Cash withdrawals 19. The table below lists every rise in the two funding accounts' ETH balances that we traced before the theft.

Data: Hawthorne's on-chain measurements 1: the payments into the attacker's two accounts, as measured 12 November 2026.

The first receiving address. It did not dawdle. 0x5227f603…2f8c sent on 700,000,000 USDT within nine minutes of the first sweep, in two transfers, 500,000,000 at 20:30:11 and

200,000,000 at 20:33:23, both before Tether's blacklist 123. USDT is Tether's stablecoin, a token designed to hold the value of one US dollar. Each transfer went to an address that had never sent a transaction, and each of those was sent 0.5 ETH a minute or two before its USDT 1. What stayed at the receiving address is frozen: on 12 November 2026 it held 1,175,464,712.88 USDT and exactly 823,000,000 USDC, Circle's stablecoin 1.

Nearly all the ETH it sent went to two more fresh addresses: 197,460 ETH to 0x8532fa14… 43d4, of which 195,460 at 20:38:47 on 29 October, and 17,260.1 ETH to 0x03b0ee5d…20ea on 30 October 1. On 12 November neither had ever sent a transaction, and they held 197,460.0169 and 17,260.1065 ETH, 214,720.12 ETH together 1. That is more than the 172,624.4046 ETH that the attacker's five sweeps took from Binance 14 directly 1. Where did the extra come from? The likeliest source of the difference is ETH the attacker got by selling other stolen tokens. That is our reading, and we did not measure the other sources1.

The receiving address sent 729 transactions, the last at 08:17:59 on 31 October. Of those, 655 fell between 01:00 and 04:00 UTC on 30 October, and 598 were calls with swap-router selectors to five contracts 1. That sentence needs three definitions. A decentralized exchange is a set of smart contracts that swaps one token for another with no company in the middle, and a router is the contract you call to make a swap. A function selector is the first four bytes of a call's input, naming the function called, the way a menu number names a dish without saying what is in it. A selector shows which function was named, not what the call did. Our reading is that these calls sold the other stolen tokens for ETH. We have not checked the contracts' code or traced the calls to confirm it.

Counted by the hour each was sent, the address's 729 transactions show the burst.

Data: Hawthorne's on-chain measurements 1: the receiving address's 729 transactions, counted by hour, as measured 12 November 2026.

The two hop addresses. 0x9749292d…c762, which received the 500,000,000 USDT, sent 11 transactions, all on 29 October, including 175,000,000 USDT to one further address and 122,310 ETH to another 1. 0x0ddf0480…697e, which received the 200,000,000 USDT, sent 6, including 190,000,000 USDT and 3,552 ETH to a single further address 1. On 12 November each held under 0.001 USDT 1. How either came to hold ETH is not measured. Neither sent a swap for those amounts, and we traced neither the spenders they approved nor the ETH arriving. A token holder can approve another address to spend its tokens, and that address is then an approved spender. Chainalysis, a tracing vendor, describes a stablecoin-to-ETH swap 10. We measured none at these addresses.

The second receiving address. 0xa97bf783…8d10 received the ETH of the last two sweeps, sent 1,318 transactions, 1,147 of them calls with swap-router selectors to four contracts, and passed on 11,137.5332 ETH, nearly all to four addresses. It held no ETH on 12 November 1.

The diagram below also shows a third source wallet. It is the one Part One describes from another publisher's label, Binance 16, which sent the first receiving address 55,739,800.50 USDT at 20:24:47 1.

Data: the rows above restate figures given in this essay, from Hawthorne's on-chain walks 1 of four addresses, as measured 12 November 2026.

Mixing (our reading). As far as we followed things, the mixer was for the gas money. Before the theft, all of the attacker's gas money that we traced came through a mixer: four payments from the 0.1 ETH pool and one from the 1 ETH pool, to two accounts 120. The 1.0 ETH that reached the second account at 16:47:23 has no payer traced, so it counts neither for nor against this reading 1. And after the theft? Our list of mixer contracts has eleven entries and is not complete. None of the eleven appears at any address we followed 1. What appears instead is speed, hop addresses funded with gas beforehand, round-amount splits, apparent exchange sales, and parking, assets left untouched at fresh addresses. We followed two hops for USDT and one for ETH, to 12 November. "No mixer seen" describes these addresses in this window, not the funds' later path, and a check against eleven known contracts is weak evidence of absence. Eleven is what we had.

As far as we followed them, the gas money came through a mixer, and what moved the stolen assets was speed, fresh addresses and waiting.

A byte count is not a hunting rule. Our reading: a "not 3,344 bytes" rule would flag clean installs under other prefixes, such as 3,341 bytes under /usr/local1.

Self-reported is not established. The June, September, 20 October and 29 October events are Binance's account alone. Vendor write-ups that restate it are not independent of it 21213.

Three vendors are not three witnesses. TRM Labs, Chainalysis and Elliptic each attribute the theft to North Korea, after or alongside the FBI. They sell tracing services, and we have not established how far their attributions rest on the same evidence 91011.

A selector is not a swap. Our "sales" reading rests on function names, not traced calls 1.

Our recommendations are afterwit, the wisdom that arrives after it was needed, and none has been tested:

• Treat a developer's take-home "assignment" from an outside contact as untrusted code, and run it away from work credentials. This follows Binance's September account 2.
• Hypothetically, and only if the deployment token was not bound to one device, which Binance does not say, binding it could have stopped its replay from Engineer C's computer, but not its use through Engineer A's own compromised computer 2.
• Do not hunt on a single published byte count. Compare against a clean install with the same prefix 1.

• How the attacker went from the 29 October deployment to the signing service. Binance's own logs, or a fuller Binance report.
• Whether June's exposure led to September's approach. Binance's investigation records.
• What the internal AI tool could do, and with whose permissions. Binance's description of the tool's access.
• Whether a clean Apple Silicon install is 3,344 bytes. One install. Not done.
• Where the assets went beyond the addresses we followed, and whether a mixer was used later. Walks of the next addresses, a trace of the hop addresses' approved spenders, and a complete, sourced list of mixer contracts. We have done none of these.
• Whether the 598 and 1,147 router calls were sales, and what they sold. Traces of the calls and the token transfers they produced.

Each claim names the result that would disprove it, and you are welcome to go find one. Claims not marked as readings are measurements.

• FC1 (reading). A clean Homebrew pyenv 2.8.0 under /opt/homebrew has a 3,344-byte libexec/pyenv156. Disproof: an install at that recipe revision gives another size.
• FC2. At block 26,399,863, 0x8532fa14…43d4 and 0x03b0ee5d…20ea held 197,460.0169 and 17,260.1065 ETH and had never sent a transaction 1. Disproof: for either address at that block, a node returns a balance differing at the four decimal places given, or a transaction the address sent. A nonzero transaction counter alone is not enough, because an EIP-7702 authorization that takes effect also raises its signer's counter 3.
• FC3 (reading, not established). Through 12 November 2026, neither receiving address and neither USDT hop address sent a transaction to a mixer contract. What we measured is narrower: no transaction from those four addresses to any of the eleven contracts on our incomplete list 1. Disproof: of the measurement, one such transaction to a listed contract. Of the reading, one to any documented mixer contract. Surviving both would not show that no mixer was used later or by another route.
• FC4. The first receiving address sent 700,000,000 USDT in two transfers, at 20:30:11 and 20:33:23 on 29 October, both before Tether's blacklist at 21:01:35 123. Disproof: a node shows a different amount or time for either transfer, or a blacklist event earlier than either.

• One interested source for the intrusion. June, September, 20 October and the signing service are Binance's account alone, in a report it calls initial 2. Vendor analyses restating it are not independent of it 1213.
• An untested byte count. Our 3,344-byte figure is arithmetic on source code, not a measured install 1.
• The assets' path. We followed both receiving addresses and the two USDT hop addresses to 12 November 2026 1, not the addresses those passed funds to, or the small gas recipients. The walks do not list plain ETH arriving.
• Sales not traced. We read swap-router calls by their selectors only.
• What a chain cannot show. Who owns an address, or who directed a transaction.
• One measurer. The measurements come from one set of scripts, cross-checked against a second data provider, not a second analyst 1. A second provider is not a second opinion, and may not even be a second, independent node. The evidence folder has no public address. (We know how that sounds.) A Blockscout read during fact-checking confirmed the receiving address's two USDT transfers out 23. The rest has not been independently reproduced.
• Checking. Code confirmed 62 of the 73 excerpts behind the v6 fact-check rulings word for word against the pages. No automated check has covered every reference. This Part Two text has not yet been fact-checked as a separate essay.
• Sources. The cited vendors sell related services. Chainalysis and Elliptic have revised their pages 1011. We did not open the KCNA original 1718.
• Held back. Points that met no admission test are absent by decision.
• Shelf life. Sources are read through 12 November 2026, and we have read no Binance statement after its 3 November report. A fuller Binance report would supersede parts of this essay. We would like to read it.

Every term below is also defined where it first appears.

• Address. The public identifier of an account on the chain.
• Afterwit. The wisdom that arrives after it was needed. Our word for our recommendations.
• Approve; approved spender. A token holder can let another address spend its tokens. That address is an approved spender.
• Authorization; delegation (EIP-7702). A signed message letting an ordinary account run a contract's code as its own. The resulting arrangement is a delegation.
• Blacklist. A token issuer's freeze. The token's contract refuses to move tokens from a listed address.
• Commit. One recorded change in a software project's history.
• Container deployment token. A credential that lets someone launch software on a company's servers.
• Decentralized exchange; router. Contracts that swap one token for another. The router is the one you call.
• Endpoint protection. Security software on employees' computers.
• Explorer. A website that indexes the chain for searching, such as Blockscout.
• Function selector. The first four bytes of a call's input, naming the function called.
• Hop. One step from one address to the next when following assets.
• Homebrew; Cellar; install prefix. Homebrew installs software on Macs. The Cellar is its folder of installed programs. The install prefix is its top folder, /opt/homebrew on Apple Silicon Macs and /usr/local on Intel Macs.
• Hot wallet. An exchange account kept online so it can pay customers quickly.
• Mixer. A service that pools deposits so withdrawals cannot easily be linked to them. Tornado Cash is one.
• Node; data provider. A node is a computer running Ethereum's software with a copy of the chain. A data provider answers questions about the chain through an endpoint that may front several nodes.
• Parking. Leaving assets untouched at fresh addresses.
• OFAC. The US Treasury's Office of Foreign Assets Control, which imposes sanctions.
• Pool (Tornado Cash). A contract holding deposits of one fixed size. The router is the contract users call to reach the pools.
• pyenv. A tool for managing versions of the Python programming language.
• Signing service. An internal system that produces the cryptographic signatures a company's wallets need.
• Smart contract. A program stored on the chain that runs when called.
• Stablecoin. A token designed to hold the value of one US dollar. USDT is Tether's and USDC is Circle's.
• Sweeper. A contract built to move everything out of an account.
• Zero-day ("0-day"). Usually, a flaw or tool unknown to defenders when it is first used. Binance does not define its use.

libexec/pyenv

at tag v2.8.0. https://raw.githubusercontent.com/pyenv/pyenv/v2.8.0/libexec/pyenv (accessed 2026-11-11; measured 2026-11-12). Primary: source code at a tag.

bf0434b5e824

(pyenv 2.8.0). https://raw.githubusercontent.com/Homebrew/homebrew-core/bf0434b5e824/Formula/p/pyenv.rb (accessed 2026-11-12). Primary: source code at a pinned revision.

general/tornado-cash-smart-contracts.md

; title not captured. https://github.com/tornadocash/docs (archived copy read; accessed 2026-11-12). Primary: the project's own documentation of its contract addresses.

"Measured" means read or computed by us from node data on 12 November 2026. It is our own provenance label, and apart from the Blockscout read described under Limits, no second party has reproduced the values. "Stated" means the named party says it and we have not verified it. "Our reading" is editorial.