Updated November 3, 2026, with Binance’s initial incident findings. The investigation is ongoing, and an independent review is planned.
Executive summary
Binance’s November 3 initial findings describe how an attacker used a malicious coding assignment to compromise an engineer’s work computer and eventually reach wallet signing operations. The attacker replaced a developer-tool component, used an internal AI tool to reach other engineers’ computers, and obtained credentials with container deployment permissions. Binance now estimates approximately $6.34 billion in impacted assets.
The FBI has attributed the theft to North Korea’s TraderTraitor activity. Binance has not named the internal AI tool or explained how the attacker used it to reach other machines.
What the FBI disclosed and how the industry can help
The FBI, together with the U.S. Secret Service and IRS Criminal Investigation, has observed TraderTraitor actors converting stolen assets primarily into Ethereum. The agencies expect further laundering through DeFi and instant swap services.
They are asking THORNode operators, RPC node operators, instant exchanges, DeFi services, blockchain analytics firms, and other virtual asset service providers to block transactions involving, or derived from, addresses associated with this activity.
Organizations supporting the response should consult the FBI’s published address list and reporting instructions. Anyone with relevant information can contact an FBI field office or IC3.
What Binance reported on November 3
Binance reports approximately $2.85 billion frozen or intercepted, subject to reconciliation and market prices. It says 98% of impacted token assets had been replenished as of October 31, and that it will absorb the financial impact. Those figures revise the earlier estimates of roughly $3 billion frozen and 90% replenished. Replenishment means Binance has replaced assets; it does not mean the stolen funds have been recovered. Initial findings and response update.
Binance’s November 3 recovery update says selected withdrawals reopened on November 1, with further assets reopening progressively from November 3. Withdrawal availability varies by asset and network.
Binance says it has rebuilt the affected wallet system and internal AI tool, replaced affected devices, decommissioned related credentials and tokens, and expanded device scanning and behavioral detection. These remediation steps have not yet been independently verified.
From a coding assignment to wallet signing
Interview repository
Engineer B runs setup for a malicious coding assignment on a work computer.
Developer tool replaced
A malicious pyenv component executes commands and contacts an external server.
Internal AI tool abused
Attacker reaches engineers A and C. The precise mechanism is undisclosed.
Deployment token found
Engineer A’s computer holds a token with container deployment permission.
Container deployed
From C’s computer, the attacker uses A’s credentials and launches a malicious script.
Unauthorized transactions
Multi-chain transfers; EIP-7702 delegation enables further Ethereum movements.
Earlier exposure · June: Binance detected a tampered Homebrew installation on A’s device and replaced it. Binance says team roles were exposed; continuous access from June is not established.
June: a tampered Homebrew installation
A Wallet DevOps engineer, identified as Engineer A, downloaded a tampered Homebrew installation while trying to install an AI coding tool found through a search engine. Binance says it detected the anomaly, replaced the device, and rotated related credentials. It also says the attacker learned about A’s role and colleagues. The report does not establish uninterrupted access from June to October, or an upstream compromise of the legitimate Homebrew project.
September: a malicious interview assignment
Engineer B was approached through a legitimate recruitment platform. After interviews that included a live video conversation and social-media material used to build trust, B downloaded an assignment repository onto a work computer. Binance says malicious code executed during setup and replaced a legitimate development-tool component. The malware communicated with an attacker-controlled external server and was not detected by the endpoint protection tools in place at the time.
October 20 to 29: access spreads to other engineers and the wallet service
On October 20, the attacker used B’s compromised computer and an internal AI tool to gain control over the computers of A and another wallet engineer, C. The attacker found a container deployment permission token on A’s computer. On October 29, between 17:15 and 19:56 UTC, the attacker accessed C’s computer, used credentials stolen from A, deployed a container, and triggered a malicious script. Binance reports unauthorized access to an internal wallet signing service that initiated transactions outside the normal withdrawal process. Binance’s attack preparation timeline.
Binance has not disclosed the token’s full permissions or lifetime, the container platform, the signing-policy configuration, or a complete set of host indicators. The report does not identify a software zero-day, prompt injection, an MCP exploit, or a named commercial AI coding product as the cause.
How the attacker used the signing service
Protecting private keys is only part of securing a signing service. Teams also need to control who can request a signature and what the service will sign. Binance says the attacker reached its signing service and initiated transactions outside the normal withdrawal process. Those transactions could carry valid signatures without being legitimate withdrawals.
Why stopping withdrawals did not end the Ethereum transfers
Under EIP-7702, a valid authorization can set an account’s execution code to a delegation indicator pointing at a contract. That delegation persists beyond the transaction that installs it. An authorization targeting the zero address clears the account’s delegation code. This behavior requires valid account authorization; EIP-7702 does not grant unauthenticated access to an arbitrary wallet.
Binance says the attacker used the signing service to authorize an attacker-controlled contract and submitted 50 signing transactions associated with nonce manipulation and malicious delegations. Suspending withdrawals did not invalidate permissions already established on-chain. EIP-7702 explains the Ethereum delegation, while the report also describes transfers on Bitcoin, XRP Ledger, Solana, and Optimism. Binance’s account of the asset movements.
Binance reports that its MPC setup required a specialized procedure to revoke the delegation. The last unauthorized transfer, 2,961.9 ETH, finalized at 23:56 UTC on October 29 after having been broadcast earlier. At 00:10 UTC on October 30, Binance cleared the Binance14 wallet’s delegation through a new authorization to the zero address. The later finalization of an earlier broadcast does not, by itself, show that the attacker still had access at 23:56 UTC.
Revoke access on devices, in production, and on-chain
Code and credentials
A compromised device can expose tokens and authenticated sessions.
Contain: isolate devices, preserve evidence, revoke access, rebuild.
Deployment and signing
Stolen credentials can let an attacker create workloads and request signatures.
Contain: disable affected deployment and signing paths; audit workloads.
Persistent delegation
An established EIP-7702 delegation persists outside the withdrawal service.
Contain: use a trusted signing path to revoke delegation and verify chain state.
Two distinct events in Binance’s report · UTC
Last unauthorized ETH transfer finalized. It had been broadcast earlier.
Binance14 delegation cleared with an authorization to the zero address.
TraderTraitor has targeted employee access before
The FBI described a similar recruitment lure in the 2024 DMM Bitcoin theft. An attacker posing as a recruiter sent an employee at wallet software provider Ginco a malicious Python script disguised as a pre-employment test. The employee was subsequently compromised.
TraderTraitor actors later used session information to impersonate the employee and, according to the agencies, likely manipulated a legitimate transaction request. The incident resulted in approximately $308 million in losses. FBI investigation summary.
Both accounts describe malicious code presented as a recruitment assignment. The DMM case shows how a stolen employee session can also affect transaction processing. When reviewing access to high-value systems, include employee devices and sessions alongside the production services themselves.
Developer tooling has become a recurring attack path
StepSecurity has investigated attacks delivered through npm packages, IDE extensions, CLI binaries, and project configuration files. The payloads often target source-control credentials, cloud access, and publishing tokens, or install a backdoor for later use.
Attacks delivered through developer tools
04Nx / s1ngularity
npm packagesA post-install payload stole credentials and attempted to use AI tools to find sensitive files.
Nx Console 18.95.0
VS Code extensionOpening a workspace fetched a credential stealer. The payload also installed a macOS backdoor.
OVHcloud CLI
GitHub release binariesStolen contributor access was used to replace binaries on five existing releases.
Claude Code 2.1.312 / 2.1.313
Tampered Cursor marketplace buildsA trojanized build planted an SSH key, installed persistence, and attempted a reverse tunnel.
The recurring exposure
August 2025: Nx npm packages and AI-assisted reconnaissance
In the s1ngularity attack, compromised Nx packages ran a malicious post-install script. It collected credentials and attempted to use installed AI command-line tools, including Claude and Gemini, to locate sensitive files. Installing a build dependency was enough to start the payload.
May 2026: Nx Console’s VS Code extension
A separate compromise affected Nx Console version 18.95.0. Opening a workspace caused the extension to fetch and execute a credential-stealing payload from an orphan commit in the official Nx repository. The version was available for approximately 11 minutes. The payload also installed a persistent Python backdoor on macOS, so affected machines could remain compromised after the extension was removed from distribution.
October 2026: OVHcloud CLI release binaries
Attackers replaced binaries on five existing OVHcloud CLI releases, then updated checksums to match. OVHcloud’s post-mortem traced the stolen access back to a malicious VS Code extension installed on a contributor’s personal MacBook the previous year. That stolen access was later used to distribute malicious software through existing releases.
October 2026: A trojanized Claude Code extension
Cursor disclosed maliciously modified Claude Code extension builds 2.1.312 and 2.1.313 distributed through its marketplace to macOS and Windows users during the October 29 exposure window. These builds were not developed by Anthropic. The payload installed persistence and attempted to establish an SSH backdoor.
Version numbers alone do not establish exposure: check the download source, installation timing, and host indicators. Removing the extension may leave standalone persistence artifacts behind. Cursor security notice.
June 2026: Miasma planted executable project configuration
Our Miasma investigation documented repository files that launched a credential harvester when an AI coding session started or an IDE opened the project. A source-code review can miss setup hooks and editor configuration that execute with the developer’s permissions. Binance has not linked its incident to Miasma or disclosed that its internal AI tool used those mechanisms.
Use these cases to review your own package, extension, and repository controls. They do not identify the software or malware responsible for Binance’s compromise.
What security teams should check
Based on the disclosed sequence, StepSecurity recommends the following checks for teams whose developers can access production systems.
1. Treat repository setup as privileged code execution
Provide disposable environments for unfamiliar projects, with no production credentials, work SSO sessions, forwarded SSH agents, or mounts into the developer’s home directory. Review install scripts, editor tasks, AI hooks, and executable configuration before trusting a workspace. Treat the assignment as untrusted code even if the recruiter and hosting platform appear legitimate.
2. Hunt for replacement of trusted tools
Binance’s example shows a temporary pyenv_ file replacing /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv, followed by changes to the /opt/homebrew/bin/pyenv link and a zsh process. The published sequence lists 3,344 bytes for the legitimate component and 3,414 bytes for the replacement. Reported file operations.
Use endpoint file and process telemetry to correlate tool replacement, symlink changes, child shells, and outbound connections. Validate files against a trusted copy of the same build. The path, version, or byte count alone is not proof of infection; normal upgrades also replace files. A clean package inventory cannot establish the integrity of an executable modified after installation. Preserve evidence before repair, and avoid executing a suspected tool to test it.
3. Review internal AI tools as systems with execution privileges
Inventory the identities, credentials, connectors, hooks, and machines each internal AI service can reach. Require authorization at each target service and isolate execution contexts between users. Log the initiating user, effective identity, target, and action so responders can reconstruct cross-user activity. These checks apply regardless of how the attacker used Binance’s internal AI tool, which remains undisclosed.
4. Restrict deployment access from developer machines
Map which local credentials can create containers, modify deployment configuration, or reach signing services. Prefer short-lived workload identities, narrowly scoped deployment roles, and an approval path separate from a developer’s interactive session. During an investigation, check both the machine that initiated a deployment and the identity whose token authorized it. Binance says the attacker used C’s computer with A’s credentials.
5. Find access created by the attacker and verify recovery
- Contain and preserve: isolate affected devices and preserve endpoint, identity, AI-tool, deployment, and signing audit logs.
- Revoke from a clean environment: decommission exposed credentials and sessions; include credentials reachable through shared tools.
- Trace follow-on access: review new workloads, role grants, repository writes, publishing activity, and signature requests. Track permissions created by compromised identities even after those identities are disabled.
- Validate recovery: rebuild systems whose integrity cannot be established, check for persistence, and verify downstream revocations. For wallet services, include pending transactions and on-chain delegation state.
Measure the time needed to identify affected machines, the proportion of privileged developer devices under inventory and policy, and the time needed to enumerate and revoke downstream access. Use those measurements in incident exercises to find gaps in inventory, logging, and revocation procedures.
How StepSecurity helps
StepSecurity helps organizations prevent, detect, and respond to supply chain attacks on developer machines. It also provides policies for supported package and extension installations. Use these findings alongside endpoint logs, identity controls, and production access reviews.
StepSecurity Dev Machine Guard
Dev Machine Guard inventories supported IDE extensions, packages, AI tools, and MCP configurations across enrolled machines. The enterprise dashboard checks installed components against StepSecurity threat intelligence and identifies enrolled machines that need investigation.
See the AI components installed across the fleet
Agent plugin inventory adds the installed Claude Code and Codex plugins, their observed sources, versions, enabled state, and bundled components. Repository inventory shows plugins published or enabled by your GitHub repositories. Use these views to find unexpected sources and shared distribution paths. Teams still need to review authorization and isolation between users in the internal service itself.
Identify where developer credentials are stored
Dev Machine Guard’s credential inventory identifies supported credential locations, affected devices, and whether material is stored in plaintext or protected form. It does not transmit credential values, fragments, hashes, or fingerprints. Teams can use the inventory to reduce credential exposure and plan rotation after a machine is compromised. Coverage is limited to supported sources; the inventory does not establish a credential’s validity, effective permissions, or every place a secret may be stored.
Start with the free Community tier
The open-source agent is free to download and run on macOS, Windows, and Linux. Community mode produces local terminal, JSON, or HTML reports. It includes developer-tool inventory, IDE extension scanning, MCP configuration auditing, package-manager configuration checks, and suspicious-file detection. npm and Python package scanning can be enabled explicitly.
Download and run the agent
Download the binary for your operating system and architecture from GitHub Releases. Save it as stepsecurity-dev-machine-guard, or stepsecurity-dev-machine-guard.exe on Windows. From that directory, run:
macOS or Linux
chmod +x ./stepsecurity-dev-machine-guard
./stepsecurity-dev-machine-guard --enable-npm-scan --enable-python-scan --html report.html
Windows PowerShell
.\stepsecurity-dev-machine-guard.exe --enable-npm-scan --enable-python-scan --html report.html
Review the local report
Open report.html in your browser to review the inventory and scan findings. Use --json for structured output. The repository contains the current installation instructions and source code.
Local scans and fleet-wide investigation
Inspect locally
Download and run the agent on macOS, Windows, or Linux.
- Inventory developer toolsIDE extensions, AI tools, and MCP configurations
- Inspect supported artifactsSuspicious files and package-manager configurations
- Include local packagesEnable npm and Python scanning when needed
Respond across devices
Bring enrolled machines into a centralized dashboard.
- Find affected machinesMatch installed components against threat intelligence
- Investigate with contextDevice findings, alerts, and historical reporting
- Apply extension policiesDefine allowed or blocked VS Code extensions and versions
Find affected machines across your organization
The enterprise dashboard brings device inventories together and checks installed components against StepSecurity threat intelligence. When a malicious extension version is disclosed, teams can identify which enrolled machines have it. In the Nx Console incident, Dev Machine Guard coverage identified version 18.95.0.
Find malicious files across machines and repositories
As of November 3, Dev Machine Guard’s Suspicious Files feature is named Malicious Files. It applies StepSecurity-maintained detection rules to supported artifacts and links findings to the device, file path, hash, campaign, and matched conditions. The new Malicious Files for GitHub (Beta) scans repository history across branches, pull requests, and tags for known campaign artifacts.
Malicious setup code and editor or AI-tool configuration may never appear in a dependency manifest. Investigate both the repository that distributes a file and the machines that have it. Detection depends on the enabled rules and scanned artifacts; the public documentation does not establish a match for Binance’s specific pyenv replacement.
Set extension policies
Device Policy lets teams define allowed or blocked VS Code extensions and versions. Teams can use these policies to restrict an extension or version identified in an incident.
Centralized dashboards, policy enforcement, alerting, and historical reporting are enterprise capabilities. Developers can start with the free Community agent today and see what is installed on their own machine.
Secure Registry
Secure Registry evaluates supported package requests at installation time. Enterprise teams can enforce cooldowns and compromised-package blocking for configured developer machines and CI runners, with policy decisions recorded for investigation. Device Policy also supports VS Code extension rules and package-client configuration.
Registry policies apply to requests routed through the registry. They do not cover a downloaded interview repository, an installer obtained elsewhere, or a local executable modified after installation. Use isolated environments for unfamiliar code, approved software sources, and endpoint monitoring to cover those paths.
Threat Center
Threat Center gives enterprise teams incident details, affected components, and remediation guidance. Its exposure view highlights compromised packages found in repositories and indicators observed in Harden-Runner runtime data. Teams can use notifications and the API to receive and act on those findings.
Run the free, open-source Dev Machine Guard agent to review the tools and scan findings on your machine. For centralized inventory, investigation, and supported installation policies across enrolled devices, explore Dev Machine Guard’s enterprise capabilities.
.png)
