AI Autopsy: How to Avoid Becoming the Next Binance

Most companies are not cryptocurrency exchanges. Nor do they have to repeatedly bat away the wily efforts of persistent state actors. But they do face a risk landscape increasingly characterised by sophisticated social engineering, zero-day threats, supply chain complexity, compromised credentials, and exposure through DevOps environments. That makes the Binance heist worthy of analysis.

It might be an extreme example of what can go wrong when adversaries gain the upper hand. Most CISOs can only hope their organisation doesn’t experience an attack that costs $6.3bn (£4.7bn). But the lessons it teaches are important.

Binance under fire

The attack has been attributed by the FBI to North Korea’s TraderTraitor group, which will surprise no one. The hermit nation has targeted financial institutions and crypto businesses relentlessly over the past few years, stealing billions to fund its missile and nuclear programmes. According to Binance, the crypto exchange has already detected and prevented 57 suspected North Korean attacks this year. The events of October 29 are a sober reminder that your adversaries only need to get lucky once.

The firm said in an initial findings write-up this week that an attacker gained unauthorised access to an internal wallet signing service, and was therefore able to initiate transactions “outside the normal withdrawal process”. In just four minutes, five Binance hot wallets sent over 233 million XRP to an attacker-controlled address. Outflows of SOL, OP and Bitcoin followed.

But how did it happen?

Months in the making

The story goes back to June 2026, when a wallet DevOps engineer (Engineer A) clicked a malicious search ad and unwittingly downloaded a tampered version of Homebrew, a third-party package manager for macOS. He did so in order to install an AI coding tool. Although Binance “detected the anomaly, replaced the device, and rotated all related credentials”, the engineer’s cover was blown. His role and his colleagues were, from that moment, known to TraderTraitor.

“Employee guidance should adapt to where ‘risk drift’ could emerge” Paul Crichard

The next stage of the attack came in September, when another software engineer (Engineer B) at the firm was approached through a legitimate job-hunting site by an individual posing as a project director. The engineer’s profile referenced his work at Binance.

During a first-round, live video interview with an ‘HR representative’, the interviewer apparently shared a social media account with the engineer that included personal photos and videos to build trust. At the end of the second interview, held in a “popular social chat app”, the engineer was asked to download an assignment containing a malicious code repository to his work PC.

This code, described as “zero-day malware”, executed during setup and took several steps to evade detection. These included replacing a legitimate component with a malicious version to execute commands and communicate with an attacker-controlled server. The attacker also reportedly tried to remove traces of the compromise to make forensics more challenging.

Fast forward to October 20 and the hackers used an internal AI tool on Engineer B’s hijacked machine to compromise Engineer A’s computer, and that of another wallet software engineer (Engineer C). They promptly discovered that Engineer A had a “container deployment permission token” on his computer. On October 29, they logged into Engineer C’s computer and used Engineer A’s token to deploy a container, triggering a malicious script that launched the attack.

Tackling the “risk drift” challenge

Mimecast field CISO, Paul Crichard, argues that the incident highlights the challenge of “risk drift” – when employees stray beyond the confines of established best practice. “CISOs will now be reflecting on whether their organisation could spot instances of risk drift before an attacker can capitalise,” he tells Assured Intelligence.

In practice, education and awareness guidance “should adapt to where such behaviour could emerge”, Crichard adds. In light of Binance’s experience, it means keeping personal activity off work devices, blocking downloads of unapproved software, and limiting disclosure of work-related details online.

“Crucially, this can’t just mean putting more barriers in employees’ way. If a developer needs new technology to do their job, there needs to be a fast, secure route to request and access it,” he continues. “Security teams should aim to be the best route and supporter for adopting new technology, giving them the opportunity to put appropriate guardrails around its use rather than leaving employees to find their own workarounds.”

When something doesn’t look right

Experts Assured Intelligence spoke to agree that Binance’s endpoint security and anomaly detection weren’t up to par. Netwrix CTO, Avesta Hojjati, points to the dev team as a common thread running through the breach.

“Watching for the long play is important” John Bruggeman

“The important questions are how access was obtained, what authority it exposed, and which controls stood between that access and the ability to move assets,” he tells Assured Intelligence. “Strong authentication, system integrity checks and monitoring for unusual behaviour should reinforce those controls rather than be treated as isolated safeguards. A compromised endpoint shouldn’t become an unrestricted route to an organisation’s most valuable assets.”

The key to effective anomaly detection is identifying when individual users or agents act in ways that are unusual for them, “rather than simply looking for activity that is unusual across the organisation”, adds Mimecast’s Crichard. “Moving Bitcoin may be perfectly normal within Binance, for example, but that activity coming from a developer account should stand out,” he says.

“Watching for the long play” is also important, argues John Bruggeman, vCISO at IT services firm CBTS. That means joining the dots between the initial June attack and the suspicious activity in October that led directly to the heist.

“Binance’s own response includes adding enhanced AI-based behavioural anomaly detection after the fact, which tells you it didn’t have strong enough visibility into unusual access patterns and lateral movement,” he tells Assured Intelligence. “I’m not saying catching TraderTraitor is easy; it’s not. But if I have to protect billions, I am going to spend millions to protect against this kind of long-term attack.”

Protecting the crown jewels

Yet despite its sophistication, the attack also relied on some basic security missteps from Binance. Container deployment permission tokens should have been frequently rotated, issued just in time and scoped to a specific action, says Bruggeman. “Zero Trust is the architectural principal that would have limited the damage,” he says. Mimecast’s Crichard agrees, arguing that “access should become more restricted as developers move closer to live data and production systems, with privileged access granted in a controlled way only when required”.

“A compromised endpoint shouldn’t become an unrestricted route to your most valuable assets” Avesta Hojjati

Binance also failed to enforce proper segregation of duties. “Developers with access to production is bad policy, bad process, and a bad idea,” argues CBTS’s Bruggeman. “This incident is essentially a textbook case for why standing access to production from an endpoint is dangerous.” He says production and wallet-signing systems should have been reachable only through a brokered access system like a PAM tool – annoying for the developers but appropriate given what was at stake.

Responding and recovering

Stairwell CTO Mike Wiacek argues that the Binance hack shows how carefully incident responders need to tread. The balance between preserving evidence and restoring operations is a fine one.

“CISOs should ask whether their responders could still examine [a malicious] file after it has been deleted or the workstation rebuilt. A path in a log won’t establish what the file contained,” he tells Assured Intelligence. “Before rebuilding affected systems, responders need to consider what evidence they could lose and preserve what they’ll need to investigate. That evidence helps establish what happened, which systems were affected, and whether containment needs to cover more machines.”

CISOs should also ensure containment covers any attacker access that may survive device rebuild or service shutdown, focusing on stolen deployment tokens, active sessions, and delegated permissions.

“Have the system owners walk through how each form of access would be revoked and how responders would verify the result,” he concludes. “Before declaring an incident contained, the CISO needs to know which systems have evidence of involvement, which response actions have been verified, and which questions remain open.”

There are indeed still questions to answer about the attack. But all the experts Assured Intelligence spoke to praised Binance for the transparency and speed with which it shared initial findings. Information sharing of this sort is the best way to ensure more organisations don’t suffer the same fate.