On October 29, 2026, Binance detected unauthorized withdrawals totaling roughly $6.3 billion. According to the company's preliminary finding, reported by BleepingComputer and others, the entry point was a compromised laptop belonging to a DevOps engineer, used to reach a service container; no private keys were leaked. Roughly $3 billion was frozen by stablecoin issuers, and TRM Labs and Chainalysis attribute the operation to DPRK's TraderTraitor group. Forensics are ongoing.

We do not know whether that specific machine appears in our data, and this post makes no attribution claim. What we can show is how exposed this access path is. We do not name the people whose machines appear in these logs: they are victims, not suspects, and we publish nothing that identifies them — no usernames, hardware fingerprints or individual timelines. The only literal samples in this post are domain names.

What our data shows

Binance-related exposure in our dataset splits into two populations:

• Customer side: roughly 978,000 infected computers held binance.com account credentials. Their lines recirculate through combo lists in the millions, heavily duplicated — overwhelmingly retail users, so not relevant to this attack class.
• Employee side: 43 infected computers hold binance.com logins. Six are flagged as employee-linked. Dated infections stretch from 2021 to 2026 — four of them in 2026 alone — and nearly half of the logs carry no reliable infection date. 18 stealer-log records include credentials for Binance's corporate SSO portal, spread across at least ten countries; some machines appear in several recirculated collections. Two machines reach into the company's internal *.bnb.internal zone.

The second population is the one that matters here.

What an employee-side log contains

An infostealer log contains everything the malware could take from an infected machine: saved browser credentials, the cookie jar and a system fingerprint. A typical employee-side log holds hundreds to thousands of credentials.

The employee-linked Binance machines in our data show a consistent pattern: credentials for the corporate SSO, both the production Okta portal and its preview environment, where access changes are tested before going live; internal infrastructure endpoints; cloud consoles and CI/CD systems; and in one case a password-manager vault registered to the corporate email address, which would expose every other secret stored in it. The same logs also contain personal mailboxes, shopping and gaming accounts.

The most important endpoints, verbatim from the logs:

airflow.bnb.internal
emr-dw.bnb.internal
prod-devops.bnb.internal
binance.okta.com
binance.oktapreview.com

Workflow-orchestration servers, a data-warehouse front-end, an internal devops portal and the corporate SSO.

Two more facts are worth stating. In the logs we examined in detail, the stolen cookies contained no live sessions for internal systems, so the exposure is passwords and a map of internal infrastructure, not hijackable sessions. On the other hand, the logs do not expire: copies from this set resurfaced in separate criminal collections within weeks of the infection. Logs are re-sold and re-bundled for years — a 2021 infection is still circulating in 2026.

Where this leaves us

None of these machines is linked to the October theft. The infections predate it, none contained live internal sessions, and TraderTraitor is known for bespoke tooling rather than commodity stealers. The data still shows that credentials matching the profile Binance described — employee machines with access to internal systems — were available in criminal marketplaces, in quantity, long before the incident. The same is true for effectively every large organization we monitor.

Employee-side exposure is the multiplier here. A stolen customer password compromises one account; an infected employee machine can carry SSO credentials, cloud consoles, CI/CD systems and a map of internal infrastructure, and the owner's privileges decide how much damage that allows. According to the reporting, the attackers needed no stolen keys because they reached systems that already held the authority to move funds.

What to do about it

1. People with production access need hardened, dedicated machines; everyday laptops should not hold standing access to deployment systems.
2. MFA does not stop session and token theft. Keep token lifetimes short and revoke sessions globally on any infection signal.
3. Put privileged access behind a broker with just-in-time elevation instead of credentials stored on endpoints.
4. Monitor stealer logs for your corporate domains and SSO portals. On a hit: revoke sessions, rotate credentials, reimage the machine. Treat old infections as live risk, because logs recirculate for years.

Want to know if credentials from your organization are circulating in stealer logs? Enter your domain below to find out: