The Binance $6.3B theft: how a fake job interview, a tampered Homebrew install and an internal AI tool reached the hot wallets

Short answer. On 29 October 2026, attackers drained about USD 6.34 billion in digital assets from Binance hot wallets across roughly ten blockchains in a few hours. Binance's initial findings, published on 3 November, trace the theft back five months. It started with a tampered Homebrew install on a Wallet DevOps engineer's laptop in June. A second engineer then ran a malicious "coding assignment" from a fake job interview in September. On 20 October the attackers used an internal AI tool to take control of two more engineers' machines. On the day of the theft they used a stolen container deployment token to reach an internal wallet signing service. The FBI attributes the theft to TraderTraitor, a North Korean state-backed group. Binance said on 12 November that it had finished covering the affected assets itself.

On the day of the theft Binance said it had "found no evidence of any wallet private key leak" (CoinDesk). The attackers got Binance's own signing systems to sign for them. The wallets did what they were built to do; the weak point was a set of developer laptops with enough access to ask them.

At a glance

• What happened. Unauthorised withdrawals from Binance hot wallets on 29 October 2026, starting at 20:05 UTC. Binance puts the impact at about USD 6.34 billion. Blockchain analytics firm Elliptic counts USD 6.43 billion across 11 blockchains and calls it "almost certainly the single largest known theft of any kind."
• Who. The FBI, with the US Secret Service and IRS Criminal Investigation, attributed it to North Korea's TraderTraitor in alerts over the weekend of 31 October and 1 November (The Record, BleepingComputer). North Korea has rejected the attribution (SecurityWeek).
• How. A tampered Homebrew install (June), a fake recruitment process with a malicious repository (September), an internal AI tool used to take over two more engineers' machines (20 October), then a stolen container deployment token and an internal wallet signing service (29 October). On Ethereum, the attacker used EIP-7702 delegation to give its own contract "partial execution rights" over a hot wallet.
• Why the pause did not stop it. Binance says "suspending withdrawals alone could not stop all unauthorized asset movements." The EIP-7702 delegation lived on-chain, and with multi-party computation there was no single key to revoke it quickly. It was cleared at 00:10 UTC on 30 October.
• Frozen and seized. Binance reports about USD 2.85 billion frozen or intercepted. The US Department of Justice said on 12 November that it had court authorisation to seize or restrain more than USD 1.2 billion.
• Who paid. Binance. It says it set aside more than 100% of the funds needed, covered affected assets valued at about USD 6.34 billion, and announced on 12 November that coverage was complete (DigitalToday, Cryptoticker).

What Binance has confirmed

Binance's report, "29 October 2026 Binance Security Incident: Initial Findings and Response Update," is the primary account, and it is unusually specific for a post-mortem published five days after the event. Here it is in the order the attacker worked.

June 2026: a tampered Homebrew install

According to the report, a Wallet DevOps engineer, Engineer A, downloaded a tampered Homebrew installation while trying to install a popular AI coding tool he had looked up on a search engine (The Hacker News has the same account). Binance does not name the tool.

The device was replaced and credentials were rotated. But the report concedes that "Engineer A's role and his related colleagues on our wallet infrastructure team was exposed to the hacker." Credentials can be rotated. An org chart cannot.

September 2026: the fake interview

A software engineer, Engineer B, was approached on a legitimate job platform by someone posing as a "Project Director." The first interview round was a video call with a supposed HR representative who shared a social media account full of personal photos and videos to build trust. The second round took place on a chat app with someone claiming to be the CEO of a company that does not exist.

Engineer B was then told to download an "assignment" containing a malicious code repository. Binance says the script deleted the legitimate pyenv file at /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv (3,344 bytes) and renamed a 3,414 byte malicious copy into its place, then created a new symlink and spawned a zsh shell. The malware used "sophisticated obfuscation and evasion techniques," talked to an attacker-controlled server, and the attacker removed traces of the compromise. The report states plainly: "The 0-day malware was not detected by the endpoint security protection tools at the time."

For developers who use it, pyenv sits in front of every python command they run. Replacing its main script gives an attacker code execution every working day, inside a directory few people ever open.

20 October: the internal AI tool

On 20 October, the attacker used Engineer B's compromised computer and "an internal AI tool" to gain control over two wallet engineers' machines, Engineer A and a third engineer, Software Engineer C. Binance does not explain how the AI tool was used or what access it held.

In Binance's words: "The attacker soon discovered Wallet DevOps Engineer A had a container deployment permission token on his computer."

29 October: container, signing service, drain

Between 17:15 and 19:56 UTC on 29 October, the attacker logged onto Engineer C's computer, used credentials taken from Engineer A, deployed a container, and ran a malicious script. The report says "The attacker exploited unauthorized access to an internal wallet signing service" to start transactions outside the normal withdrawal process.

At 20:05 UTC, five Binance hot wallets sent 233.46 million XRP to an attacker address. Binance received an internal alert about large transfers and began investigating. Outflows Binance lists include about 970,500 SOL, 44.2 million OP and 18,270 BTC, and on Ethereum, the abuse of EIP-7702 described below. The last unauthorised transfer, 2,961.9 ETH, settled at 23:56 UTC. At 00:10 UTC on 30 October, Binance signed a new authorisation from the hot wallet it calls Binance14 to the zero address, clearing the delegation.

The report also says something exchanges rarely write: "This should not have happened." Binance apologises "for the concern, disruption and uncertainty it caused our users, partners and the wider industry."

How EIP-7702 turned signing access into standing access

Most of the chains were drained the ordinary way. The attacker's container could ask the signing service for transactions, and the signing service signed them. On Ethereum, something more durable happened.

EIP-7702 lets a normal Ethereum account (an externally owned account, or EOA) delegate its behaviour to smart contract code. The owner signs an authorisation naming a contract; the protocol writes a delegation indicator (0xef0100 followed by the contract address) into the account, and calls to the account then run that contract's code in the account's context. The specification is direct about the risk: "The code specified by an authorization has unrestricted access to the account." It also says a poorly written delegate can "allow a malicious actor to take near complete control over a signer's EOA."

Crucially, the delegation persists after the transaction that set it. It stays until the account signs a new authorisation, for example one pointing to the zero address, which resets the account to a plain EOA.

Here is how that played out, according to Binance and Elliptic's on-chain analysis:

1. Preparation. Elliptic traced three 0.1 ETH withdrawals from Tornado Cash on 28 and 29 October to fund the attacker. A "sweeper" contract was deployed at 15:59 UTC on 29 October, and Elliptic says the technique was rehearsed on another wallet hours earlier.
2. Delegation. At 20:20 UTC, one transaction carried 50 authorisations signed with the key of hot wallet Binance 14, delegating control to the sweeper. Binance's report says the attackers "submitted 50 signing transactions to manipulate the account nonce" while setting up the delegation.
3. Sweep. About three and a half minutes later the sweeper emptied 167,464 ETH and 63 tokens, including about 1.6 billion USDT, according to Elliptic.
4. Persistence. Elliptic says the delegated rights were then used to pull 823 million USDC from another Binance wallet, and new deposits arriving at the delegated wallet were swept four more times, the last at 23:56 UTC.

Withdrawals were already suspended by then. It did not help, because the delegation did not depend on Binance's withdrawal pipeline. To revoke it, the hot wallet had to sign a new authorisation, and that wallet used multi-party computation. As the report puts it, "Because the hot wallet used Multi-Party Computation (MPC), there was no single private key" that could be used to revoke it right away. Binance "developed and executed a specialized procedure to revoke these authorizations," which finished at 00:10 UTC.

MPC is a sound design that removes the single key an intruder can copy. The trade-off is that the property that makes a key hard to steal also makes an emergency signature slow to produce. If an attacker can make your signing system sign something that keeps working after you stop signing, your kill switch has to be a signature too, and it has to be ready before you need it.

Co-CEO Richard Teng said in a 30 October video, as reported by Elliptic, that the delegation "did not pass through our normal approval controls" and that the attack "was not carried out by one person." Elliptic also reports him saying the attacker used a self-destruct mechanism that removed tooling and traces. Binance's earliest statement on 29 October, quoted by CoinDesk, said the incident "may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions," and that "We have found no evidence of any wallet private key leak."

Timeline

The numbers, and why they differ

Different parties counted at different moments, with different prices and scopes.

To put the size in context, Elliptic notes the theft is more than four times the 2025 Bybit theft. CoinDesk, citing DefiLlama, put Binance's assets at about USD 144 billion before the hack, so the loss was around 4% of the exchange's holdings. Painful, but not fatal, and that explains most of what happened next.

Elliptic breaks the loss down by asset. On Ethereum, about USD 3.80 billion across 186 tokens, including 1.9 billion USDT and 823 million USDC. On Bitcoin, 18,270 BTC worth about USD 1.48 billion. On Tron, 612.7 million USDT. Those four categories made up 74% of the theft.

Laundering, freezes and the limits of both

The asset mix decided how much could be stopped. Stablecoins have issuers who can freeze addresses. Native coins do not.

According to Elliptic, Tether froze the attacker's main Ethereum wallet within about 37 minutes of the USDT arriving, locking 1.18 billion USDT, and froze four more addresses within 17 minutes. Circle froze 823 million USDC in the same wallet three minutes after that. Ripple, World Liberty Financial, Paxos and First Digital froze further stablecoins. Arbitrum's Security Council moved assets out of reach, and Optimism governance moved 44 million OP. Nothing on Bitcoin, the XRP Ledger, Solana or NEAR could be frozen, because those native assets have no issuer to act.

The attacker knew this and moved fast. Elliptic says about USD 786 million in stablecoins was converted to ETH and TRX before freezes landed. On Ethereum, 434 million USDT was swapped for 160,451 ETH, at an implied loss of 12% to 26% against the market price. One wallet deposited 59.9 million USDT on Aave and borrowed 19,762 ETH against it. On Tron, 234 million USDT was swapped for TRX, and the TRX was pushed across at least six bridges. The 18,270 BTC was split through a peel chain into 19 addresses, most holding about 1,000 BTC.

The laundering looks scripted. Elliptic counted 1,113 TRX transfers from the main Tron laundering wallet between 30 October and 1 November, with a median gap of 90 seconds, along with randomised amounts and new wallets each funded with exactly 0.5 ETH. SecurityWeek reported that Elliptic later found the funds moved through about 12,000 wallets on 11 chains in under four days, with automation but no sign of AI agents making decisions.

The FBI asked exchanges and other virtual asset service providers to "block transactions with or derived from addresses TraderTraitor actors are using to launder these stolen assets," and said the actors were converting stolen assets "primarily into Ethereum (ETH)" (The Record). BleepingComputer counted 628 addresses in the FBI list: 608 Ethereum, 19 Bitcoin and one Solana.

On 12 November, the Department of Justice said it had "already obtained court-authorization to seize or restrain in excess of $1.2 billion" and that the actors "continue to launder such assets through various cryptocurrency bridges, mixers, and exchanges." As Cryptoticker notes, frozen does not mean repaid: those funds stay blocked until courts rule.

The takeaway reaches beyond crypto. Recovery depends on whether a third party has a lever to pull. Where one existed, about 44% of the loot was stopped within hours. Where none existed, the money moved freely. Prevention is the only control that works on every asset.

How Binance paid users back

Binance said from the first day that customers would not carry the loss. The Binance team wrote on 31 October that "Binance will bear the financial losses from this asset theft, not users" (Binance Square). Coverage was reported in stages: about 80% in an earlier update, then about 90% on 31 October (Bernama), then about 95% (BleepingComputer). Binance's 3 November report put replenished token assets at 98% as of 31 October. The percentages were not measured the same way: some referred to token assets, others to the financial impact. The last few percent took longest because they were thinly traded tokens that had to be bought slowly.

On 12 November Binance posted that it "has completed coverage of assets impacted in the security incident," as reported by Cryptoticker and DigitalToday. The money came from three places:

• part of the Secure Asset Fund for Users (SAFU), an emergency reserve that usually holds about USD 1 billion and that Binance says it will top back up,
• part of the futures insurance fund above its required minimum,
• company funds.

Binance has not said how much came from each.

A new proof-of-reserves snapshot taken on 12 November covered 198 assets, up from 10 on 31 October. DigitalToday reports reserve ratios of 100.05% for BTC, 100.02% for ETH and 104.34% for USDT. The zero-knowledge proof that lets customers check that their own balance is included was still being generated, an estimated 40 to 50 hours of computation, at the time of writing.

Two more facts help explain how Binance absorbed the loss. Bloomberg Law reported, citing a person familiar with the matter, that Binance "hasn't been able to obtain cyber insurance." Lawyers quoted in the same piece noted that war or state-backed exclusions could become an issue if a policy did exist. Cryptoticker also relays a secondhand report that co-CEO Yi He said this year's revenue would fully cover the loss. In other words, the balance sheet was the insurance.

Very few companies can write a USD 6.3 billion cheque. "We will make customers whole" is a financial plan, not a security control.

Who TraderTraitor is

TraderTraitor is the FBI's name for a North Korean state-backed cluster that goes after cryptocurrency companies. GitHub notes that Microsoft tracks the same activity as Jade Sleet. Some coverage places it under the broader Lazarus umbrella, and early in the Binance case on-chain investigator ZachXBT pointed to Lazarus as the likely attacker (CoinDesk).

Its public record, read in order, shows one playbook getting sharper.

2022: trojanized trading apps and recruiting lures

The first joint advisory, CISA AA22-108A from April 2022, defined TraderTraitor as "a series of malicious applications" built with Node.js and Electron, posing as crypto trading or price prediction tools. It said "Intrusions begin with a large number of spearphishing messages sent to employees of cryptocurrency companies," often in system administration or software development and IT operations (DevOps) roles, and that the messages "mimic a recruitment effort and offer high-paying jobs." Once inside, the actors moved laterally and initiated fraudulent blockchain transactions, with post-compromise activity at times completed within a week.

2023: poisoned npm packages in collaboration invites

In July 2023, GitHub published a security alert about a campaign it linked with high confidence to Jade Sleet and TraderTraitor. The actors posed as developers or recruiters on GitHub, LinkedIn, Slack and Telegram, invited targets to collaborate on a repository, and persuaded them to clone and run it. The repositories pulled in malicious npm packages that downloaded second-stage malware. GitHub noted that the actor often published the malicious packages only when sending the invitation, which kept them away from scrutiny. Targets were often tied to blockchain, crypto or online gambling. No GitHub or npm systems were compromised.

2024: a "pre-employment test" at a wallet software vendor

In December 2024 the FBI and Japan's National Police Agency attributed the late May 2024 theft of 4,502.9 BTC, about USD 308 million, from DMM Bitcoin to TraderTraitor. As SecurityWeek reported, an actor posing as a LinkedIn recruiter approached an employee at Ginco, a Japanese enterprise wallet software company, in March 2024 and sent a malicious Python script as a pre-employment test. "The victim copied the Python code to their personal GitHub page and was subsequently compromised," the FBI said. Two months later, stolen session cookie data let the attackers impersonate the employee inside Ginco's systems and work their way to DMM Bitcoin.

2025: a developer laptop at a wallet provider

In February 2025 the FBI attributed the theft of about USD 1.5 billion from Bybit to TraderTraitor. The entry point was not Bybit itself. According to the statement from Safe, the multisig wallet provider Bybit used, as reported by The Hacker News, a Safe developer's macOS laptop was compromised on 4 February 2025 after the developer downloaded a Docker project. The attackers hijacked AWS session tokens to get around MFA and planted malicious JavaScript in the wallet's web interface, which changed what Bybit's signers approved.

2026: Binance

Elliptic's attribution reasoning for Binance rests on links to the Bitget theft, which ZachXBT first flagged, services shared with earlier thefts, the scale, and the method: long preparation, targeting of staff, and getting the victim's own signing systems to do the work. The Record reports that, according to the FBI, the same group took nearly USD 300 million from KelpDAO in April 2026, and that Bitget reported losses of more than USD 387 million to North Korean hackers in October. Those figures are as reported.

Every row starts with a person who writes code or runs infrastructure. Every row ends with the victim's own systems authorising the theft.

A related but separate campaign: FaceStealer

On 12 November the FBI also published a FLASH alert on a scheme it calls FaceStealer. It names different North Korean actors (including Sapphire Sleet, APT38 and BlueNoroff), so it is not part of the Binance attack. The strategy is the same, and it is aimed at developers.

The alert describes fake Zoom, Teams and Google Meet sessions on look-alike domains, reached through hijacked Telegram, LinkedIn, Slack and Discord accounts. The attackers play secretly recorded webcam video of the target's real contacts, fake an audio problem, and talk the target into running a "fix" in their terminal. The FBI says the scheme has stolen more than USD 400 million in 18 months and seized more than 900 recorded victim videos. It also says the actors lured a maintainer of "a significant open-source JavaScript library" with tens of millions of weekly downloads into a fake Teams call, infected his machine, and used his access "to create malicious dependencies," a near miss stopped by quick detection. Several attempts targeted npm maintainers and, recently, maintainers of Rust crates.

If your company ships software, those last two sentences are about you.

What is still unknown

Binance's report is detailed, but it is labelled initial. These questions remain open as of 13 November:

• The internal AI tool. What was it, what permissions or integrations did it hold, and how exactly did it give the attacker control of two other engineers' machines? Binance has not said.
• The first-stage Homebrew lure. Binance does not name the AI coding tool or say how the tampered installer reached the search results.
• The assignment repository. Its language, package ecosystem and execution trigger have not been published.
• The signing service controls. Why a token held on an engineer's laptop could deploy a container that reached the signing service, and why 50 EIP-7702 authorisations were signed without the normal approvals, are not explained in detail. Binance says it has rebuilt the wallet system, the AI tool and their access controls.
• The full post-incident report. Binance is engaging independent third-party experts for a full review.

Lessons for exchanges and custodians

Treat "who can ask the signer" as the real key. The industry has spent a decade protecting private keys with hardware security modules and MPC. Binance says it found no evidence its keys leaked; the attacker reached a service that could request signatures. Map every identity, human or service, that can submit a signing request, and treat each of those credentials with the same care as key material. In this case that list included a container deployment token on a laptop.

Policy has to live inside the signer. If the signer signs whatever a trusted caller sends, any compromised caller is a compromised wallet. Signing services should evaluate the transaction itself: destination allowlists, value and velocity limits, and explicit denial of high-risk transaction types such as EIP-7702 authorisations, approvals and contract upgrades unless they arrive with an out-of-band approval from separate people.

Pre-build your on-chain kill switch. Pausing withdrawals does not undo approvals, delegations or allowances already on-chain. For every hot wallet, know which permissions it can grant and keep a tested procedure to revoke each one under incident conditions. With MPC, that means rehearsing an emergency signing ceremony until it takes minutes, not hours.

Watch your own wallets for state changes, not just transfers. An EIP-7702 delegation shows up as a change in the account's code. Alerting on any code change or approval to an unknown contract catches the setup step. Binance's internal alert fired on volume. Volume is the last signal you get.

Hold less hot. Billions sat in hot wallets on many chains at once. Size hot balances to expected outflows over a short window, with top-ups from colder storage under separate controls.

Plan for the money you cannot freeze. About 44% of the loss was frozen, almost all of it stablecoins. Know which holdings have an issuer you can call at 20:30 UTC, and keep those contacts current.

Lessons for fintechs and any company with privileged engineering access

If your engineers can deploy to production, push to a package registry, approve payments or touch customer data, the same chain applies with a different prize at the end.

Developer endpoints are production

Three laptops were the path here, and one held a container deployment token with enough reach to touch the signing service. Long-lived cloud tokens, kubeconfigs and registry credentials sit on developer machines everywhere because it is convenient. The fix is to make the laptop a place where access is requested, not stored: short-lived credentials issued just in time, bound to a device, and scoped to one task, with production-adjacent deploys requiring a second person.

Package managers and dev tools are an attack surface

The first compromise came through Homebrew; the second replaced a pyenv script. Neither was in an application's dependency tree. Both were developer tooling running with the developer's full rights. A supply chain programme that only scans application dependencies misses the tools developers use to build them. Pin the sources developers can install tooling from, prefer internal mirrors, and check the integrity of common tool directories on engineering machines.

Hiring is an initial access vector

TraderTraitor has run recruitment lures since at least 2022, and the Binance target was approached on a legitimate job platform. Engineers open to new roles will run take-home assignments. Make it a rule, backed by tooling, that outside code runs on a work machine only inside a disposable sandbox, and make that easy.

Internal AI tools are now part of your attack path

Few public incident reports have said that an internal AI tool helped an attacker move laterally. We do not know the mechanism here, but we know the category. Internal assistants and agents often hold broad read access, chat and ticketing integrations, and sometimes the ability to act on other machines. Inventory them. Give each one its own identity and least-privilege scope. Log every action they take on behalf of a user, and alert when an assistant is used to reach a machine or system its user does not normally touch.

Rotation does not undo reconnaissance

Binance replaced the device and rotated credentials after the June compromise. The attacker still knew who worked on the wallet team, and used that knowledge months later. After any engineering endpoint compromise, assume the org chart and team context are known, and raise monitoring on the colleagues around the victim, not only on the victim.

Fix it without waiting for upstream

None of this needs a vendor patch or a new standard. Teams can do the following today.

1. Find standing production credentials on engineering laptops. Inventory long-lived cloud keys, admin kubeconfigs, registry tokens and deployment tokens on developer machines. Replace them with short-lived, just-in-time credentials from your identity provider. Start with anyone who can deploy to a namespace that holds signing, payments or customer data.

2. Require two people for anything that can reach a signer. Container deploys into the signing environment, signing policy changes and any request that grants on-chain permissions need a second approver on a separate device.

3. Check for unexpected EIP-7702 delegations and approvals on every hot wallet. A delegated EOA has code that starts with the delegation prefix 0xef0100. With Foundry's cast you can check an address quickly:

# Prints 0x for a plain EOA. A value starting with 0xef0100 means the account is delegated.
cast code 0xYourHotWalletAddress --rpc-url "$ETH_RPC_URL"

Run it on a schedule for every hot wallet on every EVM chain you use, and alert on any change. Do the same for token allowances.

4. Write and rehearse the revocation runbook. For each hot wallet, document how to revoke a delegation (sign a new authorisation to the zero address), how to revoke token approvals, and who holds the MPC shares or approvals needed to do it at 3 a.m. Time a drill. Binance cleared the delegation 14 minutes after the last unauthorised transfer, but about four hours after the first XRP outflow.

5. Put a sandbox rule on outside code. No take-home assignments, collaboration invites or "quick fix" scripts from outside the company run on work machines. Give engineers a disposable VM or cloud dev environment with no corporate credentials for that.

6. Turn off install scripts by default for untrusted code. For npm, that is one line:

npm config set ignore-scripts true

For Python, install from hashed, pinned requirements in CI:

pip install --require-hashes -r requirements.txt

Allow exceptions per project, deliberately, rather than by default.

7. Lock down where developer tools come from. Publish an approved list of sources for Homebrew taps, installers and AI coding tools, and tell engineers to install from the vendor's own site or an internal mirror, never from a search result or ad. On macOS fleets, check Homebrew paths for tampering:

brew list --versions
brew doctor
ls -la "$(brew --prefix)/Cellar/pyenv"

Compare file hashes of common tools against known-good versions with your endpoint tooling. The malicious pyenv file in Binance's report was only 70 bytes larger than the real one.

8. Give internal AI tools their own identities and logs. List every internal assistant, agent and automation that can read code, run commands or reach other machines. Scope each one to the least access it needs, route its model traffic through a gateway with policy and logging, and alert on cross-machine actions.

9. Brief engineers on fake interviews and fake meetings this week. Share the FBI's FaceStealer recommendations: join video calls from the official app with an invite code, never run a script or paste a command to "fix" a meeting, and confirm unusual invites through a second channel. Make reporting a recruiter approach safe, so people report early.

10. Block the published laundering addresses. If you run any service that touches crypto, load the FBI's TraderTraitor address list into your screening and block transactions with or derived from those addresses, as the FBI requested.

11. Ask your critical vendors three questions. DMM Bitcoin fell through Ginco and Bybit through Safe, so ask any supplier on the path to your signing, payment or release systems: how do your engineers get production access, how fast can you revoke it, and have you had an engineering endpoint compromise in the last year? Record the answers in your vendor risk file.

How Safeguard helps with this class of problem

Binance investigated and disclosed this attack, and US law enforcement attributed it. Safeguard helps teams reduce the risks it exposes: what developers install, what reaches production, which vendors sit in the chain and what AI tools may do. These capabilities map to the steps above.

Package Firewall. Package Firewall sits between developers, CI and public registries for npm and PyPI and blocks known malicious packages, typosquats and dependency confusion attempts at install time. That is the layer TraderTraitor used in GitHub's 2023 alert, where collaboration repositories pulled in malicious npm dependencies.

SCA, SBOMs and dependency monitoring. Safeguard inventories direct and transitive dependencies across repositories and images, generates SBOMs in SPDX and CycloneDX, and keeps monitoring them as new vulnerabilities and advisories land.

Policies and gates. You can write organisation-wide policies, including from plain English, and enforce them at build, CI and release with actions to block, warn or require approval. Examples that fit this incident: block builds that pull packages from unapproved registries, and require approval before a release reaches an environment tagged as sensitive.

Asset discovery. Asset discovery inventories repositories, images, packages, workloads and vendors, and applies guardrails to what it finds, so the list of systems that can reach a signer or a payment rail starts from what is actually connected.

AI gateway, agent identity and Guard. The AI gateway puts policy and logging in front of model traffic, with guardrails for prompt injection and sensitive data. Agent identity tracks which AI agent holds what access and at what level, which is exactly the inventory the internal AI tool lesson calls for. Guard adds runtime protection on Linux workloads through an eBPF agent or sidecar, inspecting system calls, library calls and network egress, so teams can set rules for what a workload in a sensitive environment may run and where it may connect.

Third-Party Risk Manager. TPRM keeps a vendor directory with risk tiers, lets you request SBOMs and evidence from suppliers, scores each vendor across vulnerability, compliance and operational risk, and monitors them continuously. For suppliers on the path to your signing, payment or release systems, it is where the three vendor questions above get asked, answered and tracked.

Compliance automation. The compliance suite maps controls and collects evidence for SOC 2, ISO/IEC 27001 and GDPR, including access control, change management and vendor oversight, so the controls in this post show up as evidence rather than as promises. Safeguard itself is SOC 2 Type I and Type II audited.

You can see the platform at https://safeguard.sh.

FAQ

What happened in the Binance hack?

On 29 October 2026, attackers used an internal Binance wallet signing service to move about USD 6.34 billion out of Binance hot wallets on roughly ten blockchains. They reached that service after compromising three engineers' computers over five months. Binance says it found no evidence of a private key leak.

How much was stolen from Binance?

Binance puts the impact at about USD 6.34 billion. Elliptic counts USD 6.43 billion on-chain across 11 chains. The FBI and DOJ say "more than $6 billion." The figures differ because of timing, pricing and scope.

Who was behind the Binance hack?

The FBI attributes it to TraderTraitor, a North Korean state-backed group also blamed for the 2025 Bybit and 2024 DMM Bitcoin thefts. North Korea rejects the attribution.

How did the attackers get in?

Through people and their tools: a tampered Homebrew install in June, a fake job interview with a malicious coding assignment in September, an internal AI tool used on 20 October to take over two more machines, and a container deployment token found on one of them.

What is EIP-7702 and why did it matter?

EIP-7702 lets an Ethereum account delegate its behaviour to contract code until the delegation is revoked. The attacker had a hot wallet delegate to its own sweeper contract, which kept pulling funds after withdrawals were paused. Because the wallet used MPC, revoking it took until 00:10 UTC on 30 October.

Did Binance customers lose money?

Binance says no. It covered the loss from part of its SAFU fund, part of its futures insurance fund and company funds, and announced on 12 November that coverage was complete.

How much has been recovered?

About USD 2.85 billion was frozen or intercepted, mostly stablecoins. The DOJ has court authorisation to seize or restrain more than USD 1.2 billion. Native BTC, XRP, SOL and NEAR could not be frozen.

What should companies outside crypto take from this?

Treat developer laptops as production, remove standing production credentials from them, require two people for sensitive deploys, run outside code only in sandboxes, control where developer tools come from, and give internal AI tools scoped identities and logs.

How does Safeguard help with risks like this?

Binance and law enforcement investigated this incident. Safeguard helps teams reduce the same class of risk with Package Firewall, SCA and SBOM monitoring, policies and gates, asset discovery, agent identity, the AI gateway and TPRM. More at https://safeguard.sh.

Sources

• Binance, initial findings and response update, 3 Nov 2026: binance.com
• Binance team update, 31 Oct 2026: Binance Square
• Elliptic analysis, 30 Oct to 1 Nov 2026: elliptic.co
• US Department of Justice, 12 Nov 2026: justice.gov
• FBI FLASH AC-111226-MS, FaceStealer, 12 Nov 2026: ic3.gov
• The Record, 2 Nov 2026: therecord.media
• BleepingComputer, 1 Nov 2026: bleepingcomputer.com
• SecurityWeek, 4 Nov 2026: securityweek.com
• The Hacker News, 3 Nov 2026: thehackernews.com
• CoinDesk, 29 Oct 2026: coindesk.com
• Bernama, 1 Nov 2026: bernama.com
• Bloomberg Law, 3 Nov 2026: bloomberglaw.com
• DigitalToday, 13 Nov 2026: digitaltoday.co.kr
• Cryptoticker, 13 Nov 2026: cryptoticker.io
• CISA AA22-108A, April 2022: cisa.gov
• GitHub security alert, 18 July 2023: github.blog
• SecurityWeek on DMM Bitcoin, 24 Dec 2024: securityweek.com
• FBI PSA on Bybit, 26 Feb 2025: ic3.gov
• The Hacker News on Safe, March 2025: thehackernews.com
• EIP-7702 specification: eips.ethereum.org