Three Crypto Attacks, One Credential Playbook

Tl;DR

$6.34 billion in crypto assets affected: On October 29, 2026, Binance suffered an attack the FBI attributed to the DPRK, with attackers moving from compromised engineering workstations to the systems responsible for signing wallet transactions.
Binance, BitGet and a third company, one pattern: After initial access, attackers relied on legitimate credentials and permissions to move laterally toward production systems; only the initial access vector changed.
44% of compromised machines held more than 10 secrets: Developer environments are prime targets for credential theft; what limits the blast radius is knowing where your credentials live, what they access, and how quickly you can revoke them.

On October 29, 2026, Binance suffered an attack affecting approximately $6.34 billion in crypto assets. The company recently published its initial investigation findings, explaining how the attackers moved from compromised engineering workstations to the systems responsible for signing wallet transactions. The FBI has attributed the attack to the Democratic People's Republic of Korea (DPRK), identifying the activity as TraderTraitor.

Since September, at least three cryptocurrency companies have experienced attacks with striking similarities:

Binance: Approximately $6.34 billion in assets were affected, with $2.85 billion frozen or intercepted as of November 3.
BitGet: $388 million in losses after attackers exploited a vulnerability in a third-party security product.
A third company: GitGuardian worked on an incident that has not been publicly disclosed. No financial impact has been reported.

The three cases share a common pattern: after initial access, attackers relied on legitimate credentials and permissions to move laterally toward production systems.

Only the initial access vector changes

The three cases started with different initial access vectors. In Binance's case, the attacker used two separate approaches over several months.

June 2026: A malicious Homebrew installer. A Wallet DevOps engineer downloaded a tampered Homebrew installation while attempting to install an AI coding tool. The installer was distributed through a search-engine-based attack. Binance detected the compromise, replaced the engineer's device, and rotated the associated credentials. However, the attacker had already learned information about the engineer's role and colleagues within the wallet infrastructure team.
September 2026: A fake recruitment process. The attacker approached a second Binance software engineer through a legitimate job-hunting platform, posing as a recruiter for a fictitious company. After two interviews designed to establish trust, the engineer was asked to download a coding assignment containing malicious software. The malware executed during setup, replacing a legitimate development tool component with a malicious version and establishing communication with an attacker-controlled server.

This second technique resembles the well-documented Contagious Interview social engineering campaigns associated with DPRK threat actors. In Binance's case, the malware also used obfuscation and evasion techniques that prevented endpoint protection from detecting it at the time.

In the publicly documented BitGet case, attackers exploited a zero-day vulnerability in a third-party security product to compromise internal management infrastructure. In the third, undisclosed case, attackers compromised a developer workstation through a software supply-chain attack.

While the techniques varied, the objective was similar: steal credentials that provide access to other systems. In two of the three cases, attackers started with developer workstations.

How compromised credentials enable lateral movement

Developer environments are prime targets for credential theft. As we documented in the State of Secrets Sprawl report, our analysis of the 2025 Shai-Hulud incidents found that 44% of compromised machines held more than 10 secrets, while 5% held more than 100.

These credentials can provide access far beyond the compromised machine, including code-hosting platforms, cloud infrastructure, and production systems. Once stolen, they allow attackers to move laterally using legitimate identities and permissions.

Binance: moved from an engineer to wallet infrastructure

Binance's report provides a partial account of how the attacker moved laterally after compromising the second software engineer.

On October 20, the attacker used the compromised workstation and an internal AI tool to gain control over two additional engineers: one in Wallet DevOps and another in Wallet Software Engineering.

Binance doesn't disclose how the internal AI tool was exploited. One possible scenario, although not confirmed in this case, involves poisoning shared AI agent tooling:

A compromised laptop contains an authentication token for an internal code-hosting platform, such as GitLab. The token has write access to a repository containing shared plugins for an AI coding agent.
The attacker uses those credentials to push a malicious version of a shared plugin.
Other engineers using the same plugin set start their AI agents, which retrieve the updated plugin.
When the plugin is installed or invoked, the malicious code executes and compromises additional environments.

This resembles worm behavior observed in recent open-source supply-chain attacks, but within a corporate environment.

Lateral movement through a poisoned AI agent plugin

What Binance does confirm is that the subsequent compromised endpoints contained additional credentials, including a container deployment permission token on the Wallet DevOps engineer's computer.

On October 29, the attacker accessed the Wallet Software Engineer's workstation, used credentials stolen from the Wallet DevOps engineer to deploy a container, and executed a malicious script. The attack ultimately gave them unauthorized access to Binance's internal wallet-signing service.

BitGet: followed a similar path through security infrastructure

The BitGet compromise followed a comparable pattern, although it began inside security infrastructure rather than on a developer workstation. According to the investigation findings published by BitGet, the attack involved several stages:

Initial access and credential theft. The attacker exploited a zero-day vulnerability in a third-party security product. The compromised system held credentials to a database instance, which the attacker used to access sensitive information.
Lateral movement through a compromised identity. Using a compromised user identity, the attacker connected to a second system and established a command-and-control tunnel.
Production access. The second system, a management service, had permissions to deploy software packages to production containers, including those used by the wallet-signing backend.

The available reports don't establish how the attacker moved from the first compromised security product to the second. One possibility involves collecting delegated authentication tokens or password hashes from the compromised database and reusing them on the second system, although this remains unconfirmed.

The attack shows how stolen credentials can give attackers a path from compromised internal systems to critical production infrastructure.

Third incident: detected and blocked

The third incident followed a similar pattern. Attackers compromised a developer workstation through a software supply-chain attack, then moved laterally into corporate code-hosting infrastructure.

As with Binance's June compromise, the malicious activity was quickly identified and blocked. GitGuardian's secrets detection and identity mapping capabilities were used during incident remediation.

Three attacks, one recurring credential problem

As these three cases show, stolen credentials can enable lateral movement after an initial compromise, whether attackers enter through developer workstations or other infrastructure.

With so many ways for attackers to gain an initial foothold, defense-in-depth hardening has never been more important. For years, security teams have focused on segmentation, least privilege, and reducing exposure. Those measures remain essential, but hardening must also account for the credentials that connect these systems.

The Binance compromise highlights three priorities for strengthening that approach.

Know which credentials live on which laptop, harden endpoints with local vaults and access controls, identify compromised credentials and revoke access

1. Detection is key

Early detection is critical to reducing the blast radius of a compromise. EDR and similar endpoint security solutions are important, but they should not be the only detection component. As the Binance case shows, endpoint detection can fail, leaving attackers free to move through legitimate credentials.

Honeytokens offer a complementary detection mechanism: decoy authentication tokens that trigger an alert when someone attempts to use them. Placed in repositories, configuration files, or other environments where attackers search for credentials, they can provide an early warning of unauthorized activity, even when the initial compromise goes undetected.

2. Least privilege at the enterprise scale

Least privilege is the oldest advice in the book, and it's still the right one. At the enterprise scale, reducing the privileges of as many identities as possible makes an attacker's job harder. The fewer systems a compromised identity can access, the more additional access an attacker may need to reach critical assets. Each additional step creates another opportunity for detection.

In the Binance compromise, attackers moved through two additional engineering workstations before obtaining the credentials needed to reach wallet infrastructure. Reducing the privileges of those identities, or better protecting the credentials on their machines, could have made that progression harder.

The problem is that you cannot reduce the privileges of an identity you have never seen or don't understand. Least privilege at enterprise scale requires knowing where credentials live, what they unlock, and where they are used.

3. Start where the secrets are

Two of these attacks involved compromised developer workstations, and for good reason: that's where the secrets are. BitGet's initial compromise targeted security infrastructure, but the same risk applies wherever privileged credentials are stored.

Our State of Secrets Sprawl report shows developer machines holding a dense collection of credentials, from .env files and cloud configuration under ~/.aws to MCP and AI agent configs and shell history. In practice, the patient-zero laptop is a credential store.

Knowing which credentials live on which laptop, and what they unlock, turns a least-privilege policy into a concrete list of permissions to reduce and credentials to protect. Building this view before an attack helps teams prioritize endpoint hardening, whether through local vaults, tighter access controls, or additional security layers.

During an incident, that same visibility helps investigators identify which credentials may have been compromised, what systems they expose, and which access needs to be revoked.

Know your secrets better than the attacker does

Three companies, three different front doors, one familiar playbook. Whether attackers compromised developer workstations or security infrastructure, they used credentials and legitimate access to move between systems. They didn't need a new exploit at every step. They reused access that was already there.

That's the common thread between Binance and the two other incidents. Perimeter security and endpoint detection will fail from time to time. What limits the blast radius is knowing where your credentials live, what they unlock, and how quickly you can revoke them.

Build that map before the next attack. It could be the difference between containing a compromise and watching it reach production.

Book a demo