The Chainalysis Breach: Reading Three Leaks Back to Their Source

Nov 9, 2026

Chainalysis went from 'non-sensitive data' to every user's password hash and live token in five days. We read its incident page, status page and key-rotation page line by line to work out where an attacker must have stood, what still is not known, and what to do if you are a customer.

Ars Technica's headline on this one reads "Chainalysis says hackers stole credentials and tokens for all of its customers". That is accurate, and it is also the fourth version of the story.

We have tracked the incident on Threat Watch since Chainalysis's first notice, so we went back through every primary source it has published: the incident page, the status page and a key-rotation page that went up on 8 November. This post is what those sources say, what they imply about how the attack worked, and where the public record stops.

Four versions in nine days

On 30 October at about 5:14 p.m. Eastern, Chainalysis said "an external actor using offensive agentic techniques" had reached its "systems and internal tools" earlier in the month. The accessed data was user IDs, full names, email addresses and organisation role labels. The notice said there was no evidence of access to "authentication credentials, or session tokens", and the customer email added "passwords in clear text, MFA secrets" to that list.

On Monday 2 November, according to its later update, the company found that the attacker had seen far more. Reactor and Data Solutions went offline that afternoon "out of an abundance of caution". On 4 November, at 9:50 a.m., an email told some customers that "an 'on-path attack' exposed a subset of customer passwords, including yours".

Forty minutes later KYT, Address Screening and the login page were taken down "due to abnormal activity". At 11 p.m. came the sentence that made the headlines: "names, usernames, password hashes and live tokens for all Chainalysis users were exposed to a malicious actor", and some KYT accounts "appear to have been accessed without authorization".

A first notice that later grows is normal in incident response. Investigators read logs in order of how easy they are to get, and the first statement reflects the first logs. The 30 October wording, "no evidence of", described where the investigation had got to by then. If you consume vendor notices, read the first one as a minimum.

Three leaks, three positions

Chainalysis has not published a root cause. It has published what leaked, and each kind of data lives in a different place. An attacker who has one does not automatically have the others.

Names, emails and role labels. This is directory data. Support consoles, customer-admin tools, CRMs and identity-provider admin views all show it. The first notice says the attacker reached "internal tools", and an internal admin tool is the most likely place to read this data. It is also the least valuable of the three.

Password hashes and live tokens for every user. This data does not appear in a support console. Hashes sit in the authentication store: a user table, an identity provider's database, or its backups. Live tokens sit in a session store, a token table or a cache. "For all users" means the attacker read the whole store or a full copy, not one customer's records. Whatever the entry point was, by 2 November the attacker had reached the identity core of the platform.

Plaintext passwords for a subset. A correctly built system stores no plaintext password, so this data has to be captured as it moves. The password exists in plaintext in three places: the browser, the point where TLS is decrypted (a CDN, load balancer or reverse proxy), and the authentication service that checks it. Chainalysis calls the technique an "on-path attack". The "subset" detail points to an attacker who was in place for a limited time and captured the passwords of whoever logged in during that time. With the access the attacker already had, the likely positions are:

• changing the login page's JavaScript or an edge rule so that submitted credentials are copied somewhere else, the way web skimmers steal card numbers;
• getting into a proxy or ingress that decrypts TLS and logging request bodies;
• changing or reading the logs of the authentication service itself.

A network-level man-in-the-middle against customers' own connections would be a different and much harder attack. Nothing Chainalysis has published points that way.

Taken together, the attacker read the user directory, copied the credential store, and sat on the login path long enough to collect some passwords as users typed them. Chainalysis says the on-path vector "has been contained and remediated". It has not said for how long it was open, which component it was in, what "live tokens" means (web sessions, refresh tokens or API keys), or which algorithm protected the hashes.

The tokens were used

A live token is a login that has already passed the password check and any second factor. Whoever holds one does not need the password or the MFA code. Chainalysis's 30 October email recommended enabling two-factor authentication "if your organization has not yet" done so. That means MFA was optional, and it would not have stopped a stolen token in any case.

Chainalysis found the token exposure on 2 November. On 4 November it saw "abnormal activity" on KYT, its transaction-monitoring product, and said some KYT accounts appeared to have been accessed. Only then did the login page go offline. The status page does not say whether every session was revoked on 2 November. The order of events suggests that some stolen tokens or passwords still worked two days after the exposure was discovered.

The recovery design shows how far Chainalysis trusted its own credentials at that point. Customers came back from 6 November in phases, and only from IP addresses they had registered on an allowlist. On 8 November the key-rotation page said: "Old passwords have been expired", and for KYT and Address Screening, "Any prior API keys will not work with Chainalysis systems." An IP allowlist was the only gate left that the attacker could not have copied.

One login for every product

The status page includes a detail the news coverage left out. At 17:35 UTC on 4 November, Chainalysis invalidated every customer API key for Hexagate, the Web3 security monitoring company it bought in December 2024, and disabled Hexagate login through app.chainalysis.com. Login through app.hexagate.com kept working. The company called it a precaution and said there was "no evidence that API keys were exposed".

So Reactor, KYT, Address Screening and Hexagate all accepted sign-ins from the same login page. A shared login makes life easier for customers. It also means that one compromised credential store reaches every product that uses it, including an acquisition with its own separate login page. Chainalysis's fix on the day was to separate them.

Three days without screening, five without investigations

KYT and Address Screening are what exchanges, payment firms and banks call to check whether a deposit or withdrawal touches a sanctioned or stolen-funds address. They were offline for all customers from 15:22 UTC on 4 November and came back in phases from 6 November, with the status page reporting them back at 19:31 UTC on 7 November. Reactor, the investigations product, was down from 2 to 7 November. As of 8 November the Customer Admin Portal and Training Academy were still unavailable, and the incident page had not reported Data Solutions or Chain (Beta) as restored.

That window came one week after the largest crypto theft on record. About $6.3 billion left Binance on 29 October, and the theft was attributed to North Korea's TraderTraitor. Mercado Bitcoin lost an estimated $40 million or more on 2 November. Stolen funds are laundered in the days after a theft, so this is when exchanges most need screening. Chainalysis says its incident is "not related to the recent crypto theft at Binance", and nothing published links the two. The effect on customers is still real. Every compliance team that relied on KYT should document what it screened between 2 and 7 November and how, and should re-screen anything it registered or released during the outage.

Chainalysis also says it has "no evidence that any investigations data has been accessed or Chainalysis attribution data has been manipulated". The second half of that sentence matters more than it looks. Chainalysis sells attribution: the labels that say which addresses belong to which exchange, mixer or criminal. An attacker who could quietly change those labels could make stolen funds look clean. Confidentiality was the first thing Chainalysis reported on. For a company whose customers act on its labels, integrity matters at least as much.

What "offensive agentic techniques" can and cannot tell us

Chainalysis has not explained the phrase. Its 30 October notice described the incident as "similar to many other tech platforms in recent weeks", and October had several:

• Microsoft reported on 5 November that since August 2026, attackers using the ARTEX agent framework had sent large volumes of GitHub searches for secrets that included target organisations' names. From 28 October they signed in with leaked application credentials. In one case they went from a client secret found on GitHub to copying data out of Azure Key Vault in five minutes, and the agent fixed its own failed API calls about 28 to 80 seconds after each error.
• Microsoft's 21 October report tied a China-aligned group, Storm-0940, to the ConnectWise Cloud Backup compromise using the same framework.
• Nine AI developer platforms disclosed incidents during Black October, and three of them reported signs of an agent swarm.

Several AI-generated search summaries we saw while researching this post claim that Microsoft tied the Chainalysis breach to Storm-0940. Microsoft's post does not mention Chainalysis or any blockchain-analytics company, and we found no primary source that does. On the evidence available, Chainalysis's attacker is unnamed and its entry point is unknown.

What the October incidents show is the speed. An agent that tests a stolen key within minutes and fixes its own errors in under a minute leaves defenders very little time between the first alert and the attacker reaching the identity store. Chainalysis detected the attacker some time in October, found the credential exposure on 2 November and saw the KYT account use on 4 November.

If you are a Chainalysis customer

1. Reset every password at kyt.chainalysis.com or reactor.chainalysis.com, opened by typing the address. Do not use a link in a reset email: your users' names, emails and roles are in the attacker's hands, which is everything a convincing reset phish needs.
2. Replace every API key. Generate new KYT and Address Screening keys under Tools → Developer → API keys, deploy them, and confirm that transaction registration works. Old keys no longer work, so an integration that fails quietly is now a gap in your screening. Rotate Hexagate keys in the Hexagate UI.
3. Re-screen the outage window. Anything registered, released or approved between 2 and 7 November without KYT or Address Screening should be screened again now that the products are back.
4. Audit your own account activity since early October: logins, new users, changed alert rules, changed settings and API calls. Chainalysis is notifying the KYT accounts it believes were accessed. Check your own records instead of waiting for that notice.
5. Turn on two-factor authentication for every user, and change any other account that reused a Chainalysis password.
6. Ask Chainalysis for the per-organisation breakdown of accessed records it said on 30 October it was still compiling, what "live tokens" covered, how long the on-path interception ran, and which hashing algorithm was used.

If you run a SaaS login

The same lessons apply to any multi-product SaaS platform:

• Keep admin tools away from the credential store. A support console that can read names should not also be able to read hashes and session tables. Separate credentials, separate network paths, separate audit logs.
• When the identity store is exposed, revoke every session. Do it the moment you suspect the store was read, not when you see abnormal activity two days later. Bind sessions to a device or key where you can, and keep their lifetime short.
• Watch the login path for changes. A changed script on the login page, a new edge function or a proxy that starts logging request bodies should each raise an alarm. Content Security Policy, subresource integrity and a diff alert on the served login page are cheap to run.
• Put decoy users in the user table. A record that no real person uses, with a password and a token that raise an alarm the moment anyone tries them, tells you a copy of the store is being used. That alarm would have come before the abnormal activity on KYT.
• Plan for the outage before it happens. Chainalysis's customers lost screening for days, so a platform that other companies' controls depend on needs a documented fallback for those customers.

Where the record stops

Chainalysis has not published how the attacker got in or which internal tools it reached. It has not said where the on-path interception sat or for how long, what "live tokens" means, or how passwords were hashed. It has not given the number of affected users and organisations, or named the attacker. We will add the root cause to the Threat Watch record when Chainalysis publishes one. The record's agent brief lets your own coding or security agent check whether this incident touches the integrations it manages.

Frequently asked questions