The $6.3 Billion Hack Started With a Job Interview. It Ended With the Company’s Own AI.
Binance’s account of the October 29 crypto theft has changed. It was not, as the first explanation suggested, one compromised laptop and a quick move against the company’s wallets. Co-CEO Richard Teng says attackers spent months building access, using familiar social-engineering tricks before moving through internal systems.
The job interview looked completely ordinary. That was the point. Photograph via Unsplash.
Four months from first foothold to stolen funds
In June, according to Binance’s security report as described by CNBC, an attacker set up a fake version of a developer tool. A Binance Wallet DevOps engineer, searching for a popular AI coding tool, downloaded the tampered Homebrew installation.
Binance detected suspicious activity, replaced the device and rotated credentials. But the company says the engineer’s role and colleagues on the wallet-infrastructure team had already been exposed. That detail matters: the June response addressed the compromised device and credentials, but the attackers had learned something about the people and access around the wallet system.
The search detail deserves attention of its own. A security engineer searched for a developer tool and encountered a tampered version. The public account does not spell out exactly how the search results were manipulated. But “download the official tool” is incomplete advice if the path that appears to lead to it can be abused. Organizations should treat the search and download process for developer tools as part of their software supply chain. Verify publishers and signatures, and use trusted internal repositories where practical.
That is the same basic playbook as the fake Claude Code extension in Cursor we covered recently: familiar names and trusted software channels make useful cover for targeting developers. The packaging differs. The target class does not. More background is in our blog coverage.
In September, attackers posed as recruiters and conducted a series of fake interviews with another engineer. The process ended with a coding exercise containing hidden malware designed to evade detection. This was not an exotic exploit chain. It was a fake download, a fake recruiter and a rigged coding test.
From there, Teng said, the attackers “moved violently through our internal AI tools” and obtained access that breached the system authorizing wallet transactions. That is the line companies deploying internal AI tools should sit with. The reported role of those tools was as a path through the organization’s infrastructure. It does not mean an AI model independently decided to authorize a theft. It means an internal tool’s connections and permissions helped attackers move toward systems that mattered.
The blast radius of an AI tool is the sum of what it can touch. If an assistant or agent can reach deployment credentials, signing systems or authorization workflows, then its access needs to be scoped and monitored like privileged access. Calling it an AI tool does not make those permissions less consequential.
On October 29, attackers made their move. The theft is widely reported at approximately $6.3 billion in digital assets. Binance has said it replenished 98% of $6.34 billion in affected assets, pledged to cover customer losses and temporarily restricted some withdrawals. The distinction matters: the $6.34 billion figure is the amount Binance says it has replenished or is replenishing, not a precise measure of what was taken in a single transfer.
The FBI linked the attack to North Korea’s TraderTraitor group. Teng did not make that attribution himself, but acknowledged the FBI’s assessment. Binance and industry partners, including Tether, Circle and Ripple, have frozen about $3 billion in assets, while some funds continue to move through laundering channels. Coinbase blocked transfers to compromised wallets and offered assistance.
Binance says it rebuilt the affected wallet system and internal AI tool, replaced devices, decommissioned credentials and tokens tied to the engineers, expanded device scans and brought in an independent expert to review the response.
Credit where it is due: Binance says it detected the June compromise, replaced the device, rotated credentials, rebuilt systems and replenished 98% of the affected assets. That is a serious response. It does not erase the structural problem. If a wallet-transaction authorization system is reachable through internal AI tooling, the issue is bigger than one employee’s laptop or one patch. It is an architecture question.
The other lesson is time. The reported path runs from June to October. Four months of preparation preceded the withdrawal. But this was not simply a case of every alert being missed: Binance says it detected suspicious activity in June. The harder question is whether a response that replaces a device and rotates credentials also investigates what an attacker may have learned, which relationships were exposed and what access paths remain. A clean endpoint does not automatically mean a clean environment.
When the security tool delivers the backdoor
A second supply-chain incident offers the same uncomfortable lesson from a different direction. On November 2, an attacker used compromised credentials to access the update infrastructure for cPGuard, a Linux security tool, and distributed a malicious script through its own update channel. OPSSHIELD says versions 5.88.12 through 5.88.19 were affected.
The security tool’s own update channel delivered the backdoor. Photograph via Unsplash.
The script installed a backdoor shell and collected files including /etc/shadow, /etc/passwd, root’s MariaDB or MySQL configuration, root’s shell history, and root’s SSH authorization and known-hosts files. It uploaded collected data to an OPSSHIELD licensing server using a compromised account. The company says its preliminary investigation indicates the attacker retrieved 32 collected files, each corresponding to a customer server. That is a preliminary retrieval estimate, not a count of every potentially affected machine.
OPSSHIELD says it detected the attack within 12 hours, secured the account, cleared infrastructure credentials and stopped further distribution. Version 5.88.25 removes the known backdoor and staged files. But updating is not the whole response: credentials copied before cleanup may still work. Admins whose systems installed an affected version should update to 5.88.25 or later, then rotate root and local passwords, database credentials, cloud keys and tokens, and SSH private keys under /root/.ssh. OPSSHIELD’s security advisory includes the update-history check and full instructions.
One question remains open: OPSSHIELD says it is releasing another update to remove its support-access keys from customer servers as a precaution. Its advisory does not say whether a support-access private key was exposed. That uncertainty is another reason not to treat the software update as the end of incident response.
A security product’s update channel is a target precisely because the machines that need security are configured to trust it. The cPGuard servers were running a security tool, and that tool delivered the backdoor. The architecture is familiar from the Cursor incident: trust in a recognized product or brand becomes the distribution route.
Backdoors can arrive before the device does
Google says it and industry partners disrupted XCPE, a botnet that had enrolled more than 1.3 million Android set-top boxes. Google attributes the backdoor to Videostrong Technology, an Android device manufacturer, and says the malware was built into firmware and used to load modules for ad fraud, proxy networks and other activity. In this case, the risk did not begin with a user installing the wrong app. It shipped with the device. Google’s technical disclosure says the backdoor could reinstall after a reboot, making an ordinary app removal insufficient.
Separately, attackers are exploiting the critical Node-RED flaw CVE-2026-58115, which can let an unauthenticated remote user create flows and run commands on a vulnerable server. If you run Node-RED, check whether it is exposed, review unexpected flows and apply the vendor’s fix.
Trust is the attack surface
Across these incidents, attackers used a search result, a job interview, a security product’s update channel and firmware. The victims were not necessarily careless. They trusted ordinary processes that had become attack paths, and those paths were not all treated as part of the security perimeter.
For IT and security teams, the checklist is short:
- Treat AI developer-tool downloads as supply-chain risk. Verify publisher signatures and checksums, and do not rely on a search result alone.
- Scope internal AI agents like privileged accounts if they can reach authorization, payment or infrastructure systems. Log what they access and what they do.
- If you run cPGuard, update to 5.88.25 or later and rotate the credentials the script may have collected. Updating removes the known backdoor, not the exposure.
- If you run Node-RED, patch CVE-2026-58115 and confirm the interface is not exposed unnecessarily.
- Audit pre-installed firmware on Android TV and IoT devices in your fleet. If you cannot establish firmware integrity, treat the device as untrusted.
The lesson is not that every download, interview, update or AI tool is dangerous. It is that trust without verification creates a route through systems that may never have been designed to withstand it.
For more skeptical technology coverage, visit TechTime Radio with Nathan Mumm, browse the episodes, listen live, or read more on the TechTime blog.