Chainalysis breach: rotate vendor keys before scope settles

What Chainalysis disclosed, and how the scope grew

On October 30, 2026, Chainalysis said that an external actor using what it called "offensive agentic techniques" had gained unauthorized access. At that point the company described the exposed data as user IDs, names, email addresses and organization role labels. It said no clear-text passwords, MFA secrets or session tokens had been accessed.

That was not the end of it. On November 4, the company said names, usernames, password hashes and live tokens for all Chainalysis users had been exposed to a malicious actor. The same update listed the login portal, Reactor, Data Solutions, the Know Your Transaction (KYT) user interface and API, and other address screening products as offline. Chain (Beta) was listed as offline too. BleepingComputer reports that the company found the broader customer-data exposure on Monday, November 2, and took more systems down after spotting further abnormal activity.

The company also said an on-path attack had exposed a subset of customer passwords in clear text, that the attack vector was contained and remediated, and that accounts in that subset were locked. On November 6, it began restoring KYT and address screening access in phases. Reactor and Data Solutions remained offline with no firm timetable. Chainalysis said the incident was unrelated to the recent Binance theft, and described it as part of an industry-wide rise in AI-driven cyberattacks.

Why the first scope estimate was the wrong number to plan around

The useful lesson here is in the timeline, not the headline. Within about a week, the official description moved from identity metadata to every user's password hash and every live token. If your team had sized its response to the October 30 wording, it would have under-reacted.

Vendors investigate in public, and their scope estimates change as the forensics come in. That is normal, and it is also why you should not wait for a final scope before acting. Plan on the assumption that anything your integration could read or authenticate with may have been exposed, then narrow that down when the vendor's facts are stable.

There is a second point. A password reset does not, by itself, invalidate an API key or token that was copied earlier. Keys are separate credentials, so they need their own rotation. Chainalysis told customers the same thing: once access is restored, all users must reset passwords and rotate API keys, as applicable, before they register transactions again. The Hacker News carried the same customer steps.

Inventory every vendor credential this week

Start with a list, not a rotation. For every third-party service that touches customer data, screening, analytics or compliance, write down four things:

Which API keys and tokens your code, CI and servers hold for it.
Which human logins exist, and whether they go through SSO or a local password.
Where each secret is stored: environment files, CI variables, config repositories, someone's shell history.
Which systems would break if you rotated it today.

A quick search of your own repositories is a good starting point. Something like this, run from the root of each repo, will surface the obvious hits:

rg -n -i "chainalysis|api[_-]?key|access[_-]?token" --glob '!*.lock' .

The search will miss secrets that were pasted into a dashboard and never committed, so check the vendor consoles too. The point is to end the week with a table of credentials and owners, because you cannot rotate what you have not listed.

Chainalysis gave specific instructions for resets. It told affected users to reset through the normal login page, not through links in email, and to reset the same password on any other service where it was reused. Follow that literally. If your team is hit with a reset email during a breach, the safe habit is to open the vendor's site yourself and sign in from there. Expect lookalike reset emails during a breach, which is why the habit matters.

For API keys, rotate every key on your list, and do it one integration at a time. Keeping keys separate per service means one rotation does not take down everything. If the vendor supports IP allowlisting, use it. Chainalysis said customers should send their trusted IP addresses to its support team for an allowlist, and that access would be granted after that step. Ask for the same control on any vendor that offers it. A stolen key that only works from your egress addresses is far less useful to an attacker.

Also treat password reuse as a team problem. A password that was used on the vendor portal and on a personal account is now a second exposure. Reset it everywhere, and move the team to a password manager if it is not already there.

Check the logs for access you did not start

After the reset, look backwards. Chainalysis's first disclosure was on October 30, and its later updates widened the scope, so treat October 30 as the earliest date you care about and review from there.

Look for four things in the vendor's audit or access logs, and in your own logs for calls to the vendor:

Logins from IP addresses or regions your team does not use.
API calls from keys at unusual hours or from unfamiliar user agents.
New users, new API keys, or role changes. The company said organization role labels were part of the first exposure, so role assignments are worth a direct look.
Failed authentication bursts followed by a success, which is the pattern of credential stuffing.

If the vendor does not give you enough detail to answer these questions, say so in writing to their support team and keep the reply. For a regulated business, that record matters as much as the rotation.

What to do this week

Chainalysis has not named the attacker, and it said it had no evidence that investigations data was accessed or that its attribution data was altered. Those are statements from the company, and they may change. Your response should not depend on them changing.

Build the credential table for every vendor that handles your data or your customers' data.
Rotate each API key and password, one integration at a time, using the vendor's normal login page rather than emailed links.
Add IP allowlists where the vendor supports them, and scope each key to the smallest set of actions it needs.
Review vendor and application logs from October 30 onward for unexpected authentication, new keys and role changes.
Put a rotation schedule on the calendar for every vendor key, so the next incident does not start with a search.

The practical rule from this story is simple. Rotate first, because keys and passwords are cheap to replace. Trust the vendor's scope later, because the scope has already changed once in a week.