Binance - Rekt

On October 28, CZ warned his followers never to open email links or attachments, not even from people they trust.

The next evening, Binance hot wallets were drained across 11 blockchains, with Elliptic estimating the theft at $6.43 billion, most of it gone in about twenty minutes, according to TRM Labs.

That is more than four times Bybit, the record North Korea set just twenty months earlier.

The FBI has already pinned this one on the same TraderTraitor crew.

Binance's first account of the suspected entry point fit into a single sentence: A compromised DevOps engineer's laptop may have given an attacker access to a service container that submitted unauthorized withdrawals.

Its November 3 report tells a longer story: A fake job interview, an internal AI tool turned into a springboard, and credentials stolen from one engineer used to deploy a container from another engineer’s computer.

Binance says the attacker gained unauthorized access to its internal wallet-signing service and used it to initiate transactions outside the normal withdrawal process.

It previously said it had found no evidence of a wallet private-key leak.

About $2.85 billion was frozen or intercepted, and Binance says it has replenished most of the affected assets and set aside enough to cover the loss.

Binance has now described a route to its signing service.

Who told the signer it was allowed to say yes?

The chain broke the news before Binance did.

At 20:32 UTC on October 29, Spreek raised the alarm: A Binance wallet appeared to have been drained into a new EOA, with the contract call funded through Tornado Cash.

Eight minutes later, Officer’s Notes posted the transaction:
0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3

That single transaction had moved 167,464 ETH, 1.615 billion USDT and dozens of other tokens from the hot wallet Etherscan labels Binance 14 to one receiving address.

Receiving Address:
0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c

By 20:46 UTC, dogetoshi put the running total near $3.5 billion across multiple chains.

Other chains had gone first. Binance's November 3 report says five of its hot wallets sent 233.46 million XRP to one attacker-controlled address between 20:05 and 20:09 UTC, followed by about 970,500 SOL and 44.2 million OP from its Solana and Optimism hot wallets.

Binance says an internal alert concerning large-volume transfers triggered an investigation.

At 21:15 UTC, CZ said it did look like a hack. He thanked Tether and Circle for their quick freezes and said that, as a shareholder, he expected all user funds to be covered.

The issuers then put numbers to their response. At 21:18, Circle's Jeremy Allaire said more than $800 million in USDC had been frozen in coordination with law enforcement, and seven minutes later Tether's Paolo Ardoino put its freeze at more than 1.567 billion USDT.

In a post at 21:29 UTC, Binance acknowledged "reports of a potential security issue".

At 21:42 UTC, Watcher.Guru circulated an early itemized estimate: $1.45 billion in BTC, $875 million in ETH, $1.57 billion in USDT, $823 million in USDC, and hundreds of millions more across other assets.

At 22:15 UTC, Binance said withdrawals would resume once the security issue was fully resolved.

Translation: Withdrawals were off.

At 02:23 UTC on October 30, Binance published its estimate: Approximately $6.3 billion affected, about $3 billion frozen on-chain, and all losses to be covered from SAFU and company funds.

Its preliminary explanation was brief: A compromised DevOps engineer's laptop may have given an attacker access to a service container that submitted unauthorized withdrawals. Binance said it had found no evidence of a wallet private-key leak.

At that stage, the chain had shown what had left. Binance had offered a possible entry point, but not the path from access to authorization. It would not describe that route until its November 3 report.

Access to a withdrawal service is not the same as authority to move the funds.

What turned that access into a permission slip?

Permission Slip

Binance offered its explanation in chapters.

Its initial explanation named a laptop and a service container.

In an October 30 written statement, co-CEO Richard Teng said the attacker "did not simply use one engineer's permissions."

In a later video, Teng said the investigation had “uncovered additional points of breach.” He also described “a self-destruct mechanism that destroyed tooling and traces as they went, making it more difficult for us to trace and investigate.”

In the same video, Teng said: “The attacker used a known multi-signature protocol EIP-7702, to obtain on-chain execution approval over a hot wallet.”

EIP-7702 is not a multisignature protocol. It allows an externally owned Ethereum account to delegate code execution, without itself requiring a threshold of signatures to authorize that delegation.

The specification warns: “The code specified by an authorization has unrestricted access to the account and must always be closely audited by the wallet.”

Teng’s acknowledgment was therefore consequential: “That delegation did not pass through our normal approval controls.”

On November 3, Binance published its initial findings. In Binance's account, the laptop was one stop on a longer route.

Binance now says a fake recruitment interview led an engineer to download a malicious assignment onto his work computer. From that foothold, the attacker used an internal AI tool to gain control over two other engineers, then logged onto one engineer’s computer and used credentials stolen from the other, a Wallet DevOps engineer, to deploy a container and trigger a malicious script.

Three engineers’ computers and credentials were implicated. That does not mean three people independently fell for phishing, or approved the theft. Binance describes one compromised endpoint becoming a route into other people's permissions.

The DevOps engineer, Engineer A in Binance’s report, had already downloaded a tampered Homebrew installation in June after searching for a popular AI coding tool. Binance says its security team detected the anomaly, replaced the device and rotated all related credentials. The report says the incident exposed the engineer’s role and colleagues on the wallet infrastructure team; it does not establish that the June compromise persisted into October.

The September approach came with a cast of characters. Software Engineer B was contacted through a legitimate job-hunting platform by someone posing as a project director. During the first-round video interview, a purported HR representative shared a social media account, including personal photos and videos, in order to build trust.

In the second round, held in a popular social chat app with someone claiming to be the CEO of a fictitious company, Engineer B was instructed to download an “assignment” containing a malicious code repository onto his work computer. The malicious code executed during setup.

Binance says the malware replaced a legitimate development-tool component with a malicious version to execute commands and communicate with an attacker-controlled external server. Its published command sequence identifies the replaced component as pyenv under /opt/homebrew/Cellar/pyenv/2.8.0/libexec/.

The malware was not detected by the endpoint protection tools in place at the time.

Binance calls it “0-day malware.” But the report names no zero-day vulnerability and offers no evidence that one was exploited.

By October 20, Binance says, the attacker was using the internal AI tool to extend access beyond Engineer B. The next discovery was a token on Engineer A’s computer granting permission to deploy containers.

The AI tool’s role remains unclear. Binance says the attacker used it to “gain control over” two other engineers, but does not explain what access that involved or how the tool enabled it.

The fake interview supplied the foothold; the internal AI tool, in Binance’s account, supplied the bridge. By October 29, stolen credentials had enabled a container deployment from another engineer’s computer. Binance says the attacker also obtained unauthorized access to its wallet signing service, using it to initiate transfers and establish malicious EIP-7702 delegations.

The critical gap is how that deployment led to access to the signing service, and why the service signed those requests. Binance’s report does not explain that step.

Binance’s November 3 report does not identify any of the three engineers as participants in the hot wallet’s MPC signing arrangement. It describes their compromised computers and credentials, but does not specify who or what held the signing shares.

The report dates Engineer B’s compromise to September and says the attacker used his computer as a springboard on October 20.

The new report counts 57 suspected North Korea-linked cases detected and prevented in 2026. It does not say when Binance discovered Engineer B’s compromise.

TRM Lab’s analysis says Binance wallets across multiple chains sent funds to attacker-controlled addresses through validly signed transfers, despite using different key types and signing schemes.

TRM assessed that the most likely explanation was that the attacker gained the ability to make Binance’s hot wallet signing system “sign transactions of its choosing across chains.”

Binance's report now says much the same about its own signing service.

Elliptic assessed that the on-chain evidence pointed to abuse of Binance’s own signing systems, rather than theft of its private keys.

Blockaid separately described the Ethereum transaction carrying 50 EIP-7702 authorizations, only one of which matched Binance 14’s live nonce. Its post did not establish how the attacker obtained those signatures.

Bitcoin marks the limit of the EIP-7702 explanation. TRM puts Binance’s Bitcoin outflows at approximately 18,270 BTC.

The receiving address’s transaction history records multiple transfers from a wallet labeled “Binance 4”:
bc1q0mtc2f5agpkvlq6hhahmfr3hlr55kyfjhl2mnm

EIP-7702 changes how Ethereum accounts execute code. It cannot authorize a native Bitcoin transfer. The Ethereum delegation explains how one wallet was turned into a persistent sweeper; it does not explain how the attacker obtained valid signatures to move Binance’s bitcoin.

In its October 30 update, Binance said it had found no evidence of a wallet private-key leak.

A valid signature alone does not establish that a private key leaked: The attacker could instead have induced Binance’s own systems to sign the transaction.

Binance’s account names the rooms the attacker passed through. It has not explained why the signing service opened the final door.

The November 3 report does not explain why credentials taken from Engineer A worked from Engineer C’s machine, or what identity and permissions the deployed container received. It does not describe the checks between that deployment and access to the wallet-signing service. Nor does it specify which signing checks applied to the malicious EIP-7702 authorizations, or how the attacker obtained signing access across multiple chains.

Binance says some technical details will remain confidential and that it is engaging security firms to review its findings. The report names no reviewing firms and includes no completed independent assessment.

The container deployment is one step in the account. It does not explain which requests the signing service would accept, or why.

Binance says the malicious on-chain authorizations operated independently of its normal withdrawal infrastructure.

How did one delegation keep Binance 14 working for the attacker after withdrawals were suspended?

The Ventriloquist

Binance 14 was taken over through EIP-7702. That was enough to keep it talking for nearly four hours.

Since Ethereum's Pectra upgrade in May 2025, an ordinary wallet can sign a short authorization saying, in effect: my account now runs the code at this address.

The signed payload identifies the chain ID, the address of the code to execute and the account nonce; the submitted authorization also carries the signature.

Once the delegation is installed, calls to the account execute the delegated code in that account’s context. The account keeps its address and can still originate signed transactions. The delegation persists until a valid replacement or clearing authorization is processed on-chain.

The operator wallet began with modest funding. According to an on-chain reconstruction by Limited Supply, it received three Tornado Cash withdrawals of about 0.1 ETH each, starting October 28.

Operator Wallet: 0x7C8601d4645b93cea45F71e118A729332e6B5CA0

On October 29, the same wallet deployed a first sweeper contract in the early hours, then ran rehearsals on its own wallets in the afternoon using type-4 transactions carrying multiple authorizations.

At 15:59 UTC, about four hours before the drain, it deployed the final sweeper:
0x63e842B054Bd624a465454D533C33F573e9c6fAe

The contract is unverified on Etherscan.

banteg published a Solidity reconstruction and matching-build results reporting a byte-for-byte match to the deployed executable runtime, excluding compiler metadata.

The reconstruction hard-codes one authorized caller for its privileged functions, the Operator Wallet:
0x7C8601d4645b93cea45F71e118A729332e6B5CA0

The target was Binance 14:
0x28C6c06298d514Db089934071355E5743bf21d60

Binance 14 was sending several withdrawals a minute, so its nonce kept moving. An authorization signed for the current count could go stale before it landed.

At 20:20:59 UTC, in block 26,300,753, the operator sent one type-4 transaction carrying 50 authorizations signed by Binance 14, spanning consecutive nonces 18,914,775 through 18,914,824 and pointing to the same sweeper.

Binance's November 3 report calls this step "50 signing transactions," submitted to manipulate the account nonce and establish the delegation.

The on-chain transaction shows one type-4 transaction carrying 50 signed EIP-7702 authorizations from Binance 14.

Delegation Transaction:
0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b

The published reconstruction links the incident to reported access to an internal Binance service, but that account does not establish exactly how the 50 authorization signatures were obtained.

The on-chain record identifies Binance 14 as the account that signed the authorizations; it does not identify the internal system that produced those signatures.

Binance 14 was now delegated to the sweeper’s code.

Three minutes and 24 seconds later, at 20:24:23 UTC, the operator sent a separate transaction to Binance 14, triggering the sweep.

One transaction moved 167,464 ETH, 1.615 billion USDT, 62.6 million RLUSD and roughly 60 other tokens to the receiving wallet.

Receiving Wallet: 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c

Main Sweep: 0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3

The reconstructed code shows how the sweep behaves. It queries each supplied token’s balance and attempts to transfer the full balance when it is greater than zero. Failed balance queries and reverted transfer calls emit failure events rather than explicitly reverting the entire batch, allowing the loop to continue to the next token.

The main sweep itself logged one such failure: A SweepItemFailed event for a token whose transfer call reverted, emitted from Binance 14’s own address, while 63 other token transfers went through.

When instructed to include native ETH, sweep attempts to transfer the portion of the ETH balance exceeding 1 ETH, leaving 1 ETH behind if the transfer succeeds. That retention rule applies to sweep, not to the separate withdrawETH function. The reconstruction does not explain why the 1 ETH is retained.

The sweeper also exposed callExecute, restricted to the authorized operator. When running in Binance 14’s context, it could call another account’s execute(address,uint256,bytes) function with Binance 14 as the caller.

Binance's report describes the delegation as granting "partial execution rights" over Binance 14.

The EIP-7702 authorization itself specifies no spending limits; account-level spending limits must be implemented by the delegated code or permission systems built on top of it.

In banteg’s reconstruction, the authorized operator could initiate token sweeps, withdraw specified amounts of ETH or tokens, and call another account’s execute(address,uint256,bytes) function, subject to that account’s own checks.

According to Limited Supply, Binance 14 was the owner of the smart-contract wallet Binance Hot Wallet 34:
0xEe7aE85f2Fe2239E27D9c1E23fFFe168D63b4055

Readers can check the ownership relationship under Contract → Read as Proxy → getNativeOwner. The result shown is Binance 14’s address:
0x28C6c06298d514Db089934071355E5743bf21d60

Limited Supply’s on-chain reconstruction, “One signature, four hours, $6 billion: What the chain shows about the Binance hot-wallet drain,” describes Hot Wallet 34 accepting calls from its owner, Binance 14. The malicious delegation let the operator make those calls through Binance 14 itself, so Hot Wallet 34 still saw its trusted owner’s address as the caller.

The same reconstruction reports transfers of 780 million USDC at 20:41:23 UTC and 43 million USDC at 20:59:47 UTC to the attacker’s receiving wallet.

The delegation changed Binance 14’s behavior, without changing the address Hot Wallet 34 trusted.

According to Limited Supply, Binance 14’s malicious delegation remained active until 00:10:35 UTC on October 30: 3 hours, 49 minutes and 36 seconds after it was installed.

The delegation remained active after the main sweep. Limited Supply's reconstruction identifies the following additional fund-moving transactions from Binance 14.

At 21:04 UTC, approximately 1,700 ETH, 3.9 million USDT and additional tokens were swept from Binance 14.

Sweep Transaction:
0x31c4c9fe287d54fb9d3b79980477a8c793a11f774b98d0a9a92de1dad888a91d

At 21:44 UTC, another sweep moved approximately 200 million USDT and 370 ETH, plus additional tokens.

Sweep Transaction:
0x55ba4dabc41b468e580751373ad31acdee6f5ba398682df2c93e5a8340870556

At 22:39 UTC, dozens of altcoins, including POL, GRT and SKY, were swept to a second receiving wallet.

Sweep Transaction:
0x4a4aed833556814c16fe176fc8abc70ce124eadc73da3bcdf42a67ef44f9ad6b

Second receiving wallet, which received both this sweep and the final ETH sweep below:
0xA97bF7836F8A08F9Ed91D41453D371493FAE8d10

At 23:55:47 UTC, 2,961.99 ETH arrived in Binance 14. Limited Supply's reconstruction links that deposit to a sweep of approximately 2,961.9 ETH to that same second receiving wallet one minute later.

Binance's report calls it the final unauthorized transfer and says the outgoing transaction had been broadcast earlier, remained pending and finalized at 23:56 UTC; it does not give the initial broadcast time. Binance says it observed no further unauthorized transfers.

Incoming ETH Deposit:
0xc1f0fdb94fb909e3f12aa345e81c05d4adb0ea2d3243e844920d62a2936f4ae0

Final Sweep Transaction:
0x4395d51dc3f3c51230329efc3548f74edbced353ff3f795c517cc57fa650f89b

Binance says it suspended withdrawals as a containment measure, but that doing so, and shutting down hot-wallet services, did not invalidate the existing on-chain authorizations. The installed delegation remained effective independently of its normal withdrawal infrastructure. Clearing it required a separate on-chain transaction.

The withdrawal system was paused. The on-chain authority remained.

Tether blacklisted Binance 14 for USDT at 22:06 UTC.

Circle later blacklisted it for USDC at 23:53.

Binance 14 still holds approximately $1.35 million USDT, alongside other tokens, bringing its displayed multichain token holdings to approximately $2.18 million across 231 tokens.

Activity continued until the delegation was removed.

Between the attack and the fix, Binance’s own system signed 94 more transactions from Binance 14 - withdrawals and smart-account operations - according to Limited Supply’s reconstruction. During that period, at least 133 direct ETH deposits totaling about 5,181 ETH came in from outside addresses, alongside token deposits.

Binance 14’s delegation was cleared in this successful transaction, which set its EIP-7702 delegation to the zero address.

Delegation-clearing Transaction:
0xafbf94c92a8d749988411669fa14d4f8866d9b4420b4ebd299f28e958dac7209

The reported delegation duration was 3 hours, 49 minutes and 36 seconds. That is the duration of this Ethereum permission, not evidence of how long the attacker had access to Binance's internal signing systems.

Binance says the hot wallet’s use of Multi-Party Computation (MPC) meant there was no single private key that could be used to immediately revoke the malicious EIP-7702 authorizations. Its team therefore developed and executed a specialized procedure to revoke them, which required additional time.

EIP-7702 requires a valid authorization signed for the account and targeting the zero address to be processed on-chain to clear its delegation; it does not prescribe how an MPC signing system must generate that signature.

By Binance’s account, the attacker had used its internal wallet signing service to establish the malicious EIP-7702 authorizations earlier that evening. Binance attributes the additional time needed to revoke them to its MPC setup, but does not describe the specialized procedure or explain why its existing signing infrastructure could not produce the clearing authorization.

Binance says it is reviewing its incident response process, signing-policy coverage and hot-wallet controls.

The outflows were not limited to Ethereum. Binance also reports transfers of BTC, XRP, SOL and OP to attacker-controlled addresses.

The EIP-7702 delegation gave an attacker-controlled smart contract partial execution rights over Binance 14. It was not the mechanism behind every outflow in the incident: Binance also reports transfers of BTC, XRP, SOL and OP to attacker-controlled addresses, describing unauthorized access to its internal wallet signing service as the means used to initiate transactions outside the normal withdrawal process.

Binance’s November 3 report says five of its hot wallets sent 233.46 million XRP to an attacker-controlled address between 20:05 and 20:09. It also reports transfers of approximately 970,500 SOL and 44.2 million OP from hot wallets on Solana and Optimism, and 18,270 BTC from a Bitcoin hot wallet, to attacker-controlled addresses. Binance says the attacker exploited unauthorized access to an internal wallet signing service to initiate transactions outside the normal withdrawal process.

On Ethereum, Binance 16 followed the initial Binance 14 sweep by just 24 seconds. According to Blockaid, it sent 28,005.6 ETH, 55.7 million USDT, 25.9 million RLUSD, 84.5 WBTC and five other tokens to the same collection address.

Binance 16 Wallet:
0xDFd5293D8e347dFe59E90eFd55b2956a1343963d

ETH Transfer Transaction:
0x51f263fa50966df6bbd7f8c6e6e99e3791c94444f7c4343b2fef1ee2d62fd39f

USDT Transfer Transaction:
0xd4e08d3ef0cb02a75922913c61984fbf7fe4bbc4b95324735ef27f908fd6c49c

RLUSD Transfer Transaction:
0x2e1001627db976a77c5ce2feddef516f2c729b1de101c25d0d5af7699e5ffeb3

WBTC Transfer Transaction:
0x2c45d7874dd60a5f1fa6e400933378efbc96b66abb988b8e3ed9bc010e6f260b

On Arbitrum, Blockaid’s fund-flow tracker places the transfers between 20:30 and 20:33 UTC on October 29. Four Binance hot wallets sent approximately 74.56 million ARB and 8,426 ETH to the same collection address.

Arbitrum Receiving Address:
0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c

On Avalanche, Blockaid’s tracker places the transfers between 20:33 and 20:35 UTC. Four Binance hot wallets sent approximately 1.81 million AVAX and 8.41 million USDT to the same address, consistent with the totals in Blockaid’s written reconstruction.

Avalanche Receiving Address:
0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c

Blockaid distinguishes those transfers from the delegation-based attack on Binance 14: “None of these wallets carried code. Each transfer was an ordinary transaction signed by the wallet’s own key, placed between routine withdrawals.” The EIP-7702 delegation was one mechanism in the incident, not an explanation for every outflow.

But some of the stolen assets could still be stopped. Blockaid reports that Tether and Circle froze about $1.8 billion in the main collection address within 40 minutes of the initial sweep.

Who moves faster, the attacker or the blacklist?

Beat the Blacklist

Taking the money was one operation. Turning it into assets without an issuer's freeze button was another.

Elliptic estimates the theft at $6.43 billion, including $3.46 billion in stablecoins, 54% of the haul.

That gave issuers a chance to stop much of the money before the attacker could convert it into ETH, TRX or bitcoin, assets beyond their blacklist controls.

Circle froze all $823 million of the stolen USDC before any could be swapped, according to Elliptic.

On Ethereum, Tether's freeze arrived 37 minutes after the stolen USDT reached the attacker's wallet.

Before the freezes landed, the attacker swapped 434 million USDT for ETH on decentralized exchanges and another 234 million USDT for TRX on Tron.

Elliptic estimates that approximately $786 million in stablecoins were converted, before the freezes landed.

Speed had a price. TRM Labs traced about 325 million USDT sold through UniswapX and other intent-based contracts for roughly 122,300 ETH. That implied a price near $2,650 per ETH while ether traded around $2,300 to $2,350.

The attacker paid more than 10% above the prevailing ETH price to escape dollars that could be frozen.

Not every escape required a sale.

Not every escape required a sale. According to Aave, between 20:58 and 21:01 UTC on October 29, a wallet in the exploiter’s cluster supplied 60 million USDT to Aave V3’s Ethereum Core market and borrowed 19,762 WETH, worth approximately $44.6 million at the time.

Aave Borrowing Wallet:
0x8d53903625b8e839b9DF4bd28B0EFb1CD6b8639A

The stablecoins became collateral; borrowed WETH came out. Aave initially reported that the position was over-collateralized and did not put suppliers at risk.

Aave’s guardian multisigs subsequently froze new supplies and borrowing across the affected V3 and V4 markets, while repayments, withdrawals and liquidations remained available. The freeze restricted further activity; it did not seize the attacker’s funds.

The borrowing route also carried market risk: Elliptic reports that part of the position was liquidated on November 4 after ETH rose, with a liquidator repaying about 9,900 ETH worth of debt and taking approximately 24 million USDT in collateral.

The response stopped a substantial share of the haul. Elliptic puts the total frozen or seized at approximately $2.85 billion, or 44%, compared with roughly 3% after the Bybit theft.

Binance's November 3 report also gives $2.85 billion, describing the assets as frozen or intercepted and making the figure subject to reconciliation and market prices.

But frozen is not the same as returned. Issuer blacklists prevent transfers; emergency network action can move assets out of an attacker's hands.

TRM reports that the Arbitrum Security Council used its emergency powers to move 8,426 ETH and 74.6 million ARB, approximately $30 million, out of the attacker's reach.

Those are different forms of containment, not interchangeable evidence that Binance has recovered the money.

Replacing customer assets is another matter. Binance says it will absorb the financial impact and has set aside more than 100% of the funds required to cover the loss.

Its November 3 report says 98% of impacted token assets had been replenished as of October 31, with purchases of the remaining, less liquid assets still underway.

Those are Binance's reported replenishment figures, not proceeds recovered from the attacker.

Then came the part that could take months.

In the first three and a half days, Elliptic counted approximately 12,000 wallets across 11 blockchains and more than 40,000 transactions, roughly one new wallet every 25 seconds.

Tron became the main early laundering route, with the attacker’s wallets making around 1,300 transactions in an hour at the peak on October 31. Funds were split across new addresses and bridged onto other chains.

The speed prompted speculation about AI agents. Elliptic says the evidence instead points to conventional automation: Fixed timing, set amounts, blind retries and new tactics introduced in steps hours apart. It says nothing it has observed shows an AI agent making decisions.

Chainalysis separately identified repeated sequences in which addresses received exactly 1 TRX, then additional funds, before forwarding them, sometimes back to addresses used earlier.

Coincidentally, Chainalysis disclosed its own security incident on October 30, the same day it published its Binance investigation, and later reported exposed user credentials and tokens, along with service shutdowns; it said the incident was unrelated to the Binance theft.

The FBI attributed the theft to North Korea's TraderTraitor activity on October 31.

Kim Yo Jong, the sister of North Korean leader Kim Jong Un, rejected the FBI’s attribution in a statement carried by KCNA, saying: “It is a grave political provocation against the DPRK that the U.S. misleads the international public opinion as if all the cyber crimes in different parts of the world are our deeds.” She also suggested U.S. involvement, without presenting evidence, citing what she described as Washington’s plans to confiscate stolen cryptocurrency and use it as a strategic reserve.

Elliptic reports that approximately $16 million reached addresses also holding proceeds of September's Bitget exploit.

But attribution of the theft does not identify every subsequent custodian: Elliptic cautions that some funds being laundered may already have passed to money-laundering networks, something the chain alone cannot establish.

As of Elliptic's November 5 update at 09:15 UTC, about $3.35 billion remained in theft-linked addresses.

The original 18,270 stolen BTC had been split across 19 addresses and had not moved since.

Other assets were converging on bitcoin: Approximately 900 BTC, worth $72 million, had been accumulated through conversions of stolen SOL, Tron assets and ETH.

Smaller amounts had entered bitcoin coinjoins and the Privacy Cash pool on Ethereum and Solana.

Conversion was not cash-out.

Elliptic assesses that only a negligible amount had likely been cashed out. Most of what had happened was conversion: the funds had changed assets but remained on public blockchains in addresses linked to the theft. Turning them into spendable money still required a counterparty, such as a centralized exchange or an over-the-counter broker.

Elliptic expects the ETH to be swapped for bitcoin in many small transactions, then cashed out through OTC brokers over a period of months.

The blacklist stopped much of the stablecoin escape. The next contest is at the cash-out points.

Who is standing at the door?

A fake job interview, an internal AI tool and a colleague's deployment credentials: That is the route Binance now describes into its wallet-signing service.

The theft, which the FBI attributes to North Korea's TraderTraitor activity, took an estimated $6.43 billion from Binance across 11 blockchains, according to Elliptic.

Binance's November 3 report describes a compromise spanning three engineers' machines and credentials. It also acknowledges that suspending withdrawals and shutting down hot-wallet services did not invalidate the malicious on-chain authorizations.

Binance 14's delegation was not cleared until 00:10 UTC the following morning.

It is still Binance's account. The company says it is engaging independent cybersecurity experts to validate its findings, while keeping some technical details confidential.

Its published explanation does not detail what signing-policy checks applied to the attacker’s requests. Binance attributes the revocation delay to its MPC setup, but does not describe the specialized procedure or explain why one had to be developed.

The financial response is further along than the public explanation.

Binance reports approximately $2.85 billion frozen or intercepted and says it had replenished 98% of impacted token assets as of October 31, while setting aside more than 100% of the funds required to cover the loss.

But replacement is not recovery: Elliptic's November 5 update still places approximately $3.35 billion in theft-linked addresses.

Some of the entry points Binance describes were familiar. Engineer A downloaded a tampered Homebrew installer after searching for an AI coding tool.

Engineer B downloaded a stranger's interview "assignment" onto his work computer, where malicious code executed during setup.

Those were the openings; the unanswered question is which controls stood between that access and the authority to move billions.

A valid signature can satisfy the account's cryptographic checks without establishing that the request reflected its owner's intent.

Binance says the attacker used stolen deployment credentials to launch the attack.

It has not yet explained, in comparable detail, the controls between that access and the signatures that moved the money.

Somewhere, another engineer is being told they’ve made the shortlist.

Whose vault is at the end of that interview?

REKT sirve como plataforma pública para autores anónimos, nos deslindamos de la responsabilidad por las opiniones y contenidos alojados en REKT.

dona (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C

aviso legal:

REKT no es responsable ni culpable de ninguna manera por cualquier Contenido publicado en nuestro Sitio Web o en conexión con nuestros Servicios, sin importar si fueron publicados o causados por Autores ANÓN de nuestro Sitio Web, o por REKT. Aunque determinamos reglas para la conducta y publicaciones de los Autores ANÓN, no controlamos y no somos responsables por cualquier contenido ofensivo, inapropiado, obsceno, ilegal o de cualquier forma objetable, que se pudiera encontrar en nuestro Sitio Web o Servicios. REKT no es responsable por la conducta, en línea o fuera de línea, de cualquier usuario de nuestro Sitio Web o Servicios.