Chainalysis took five days to go from no sign of exposed credentials to confirming every user's hash and token

On 30 October, Chainalysis told customers that an external actor using what it called "offensive agentic techniques" had accessed identity data belonging to users of its platform: user IDs, full names, email addresses and organisational role labels. The company's incident notice, as reported by The Block, said there was no sign that plaintext passwords, MFA secrets or session tokens had been reached.

At 23:00 on 4 November, US Eastern time, the same page admitted that on Monday 2 November the company had discovered that every user's name, username, password hash and live token had been exposed.

The customer base explains why that revision matters. According to BleepingComputer, Chainalysis sells to law enforcement, government agencies, financial institutions, insurers and crypto businesses. Exchanges and banks rely on its KYT (Know Your Transaction) product for anti-money-laundering screening, often wired into their own systems through an API. Anyone acting on the first notice would have warned staff and switched on two-factor authentication. Acting on the last one meant rotating every API credential and assuming that someone else might have been driving the integrations.

How much has Chainalysis said about the way in?

Very little, and what there is needs separating from the speculation around it. Chainalysis has named two elements without explaining either in technical terms.

What does the company mean by offensive agentic techniques?

Chainalysis has not defined the phrase, which usually describes AI agents that chain actions on their own: reconnaissance, access attempts, lateral movement across internal tools. Nor has the company said which vulnerability or credential was used, which systems were reached or how long the intruder stayed.

A Cloud Security Alliance research note, produced with AI assistance and not formally reviewed by the CSA, says it is unknown whether the attacker used an open-source framework or bespoke tooling. It also treats reports of a credential-stuffing entry point as unconfirmed.

In October Microsoft tied the open-source ARTEX framework to Storm-0940 and the ConnectWise intrusion, which we examined in our piece on Storm-0940, ARTEX and ConnectWise. The Hacker News places Chainalysis among recent AI-assisted attacks, while noting that it is unclear who is behind it.

What is the on-path attack Chainalysis describes?

On the morning of 4 November, Chainalysis blamed the exposure of a subset of passwords on an "on-path attack", meaning an attacker positioned between users and the service and able to read traffic in transit. BleepingComputer describes it as a man-in-the-middle (MITM) attack. The company has not said where the interception took place, only that the vector has been contained and remediated.

It has not disclosed how passwords were hashed either. As The Register notes, without that detail nobody outside Chainalysis can judge how quickly the stolen hashes might fall. Customers are better off working on the assumption that the attacker holds the passwords.

How did the scope grow from one update to the next?

The incident page gained dated entries over nine days. Taken in order, they show the scope widening and the response at each stage:

• 30 October: Chainalysis reports an intrusion detected in October affecting IDs, names, emails and roles, with no indication that plaintext passwords, MFA secrets or session tokens were reached, and advises users to enable two-factor authentication.
• 2 November: it takes Reactor, its investigations platform, and Data Solutions, its threat data service, offline as a precaution while outside specialists assess security.
• 4 November, 09:50: it says an on-path attack has exposed some passwords, locks the affected accounts and requires resets.
• 4 November, 10:30: after abnormal activity, it pulls KYT (interface and API), its other address screening products and the login page. Password resets stop working for a while.
• 4 November, 23:00: it confirms that on Monday 2 November it found names, usernames, password hashes and live tokens for all users exposed, and starts contacting customers whose KYT accounts appear to have been accessed without authorisation.
• 6 and 7 November: it brings KYT and address screening back in phases, after asking each customer for trusted IP addresses for an allowlist and requiring password resets and API key rotation. Reactor follows on the 7th.

Two things stand out. The first is the gap between discovery and disclosure: by the company's own late entry on the 4th, the full exposure had been known since Monday, yet the Wednesday morning entry still referred to a subset of passwords. Chainalysis may have wanted to confirm the scope before announcing it. Whatever the reason, customers spent two days acting on a notice that no longer described the incident.

The second is that exposure may have turned into use, since Chainalysis refers to KYT accounts that appear to have been accessed without permission. It maintains that it has no evidence that investigations data was accessed or that its attribution data was tampered with.

Why does the customer see so little of this?

The exposed credentials did not live in customers' corporate directories. They were platform accounts and tokens issued by Chainalysis (it has not said what kind), stored and checked on its infrastructure; as a precaution it also requires API keys to be rotated. No Entra ID or Okta log would have recorded a stolen token or key being used against KYT. Federated sign-in, had it been in place, a point not yet addressed, would only have shed light on password logins.

API keys make it worse. At a bank or an exchange, the KYT integration often runs on a server that submits transactions for screening automatically, using a credential generated long ago by someone who may since have moved on. These are non-human identities, and many organisations have never logged them with a named owner and an expiry date. Traffic from a stolen but valid token looks much like the legitimate integration's. The party able to tell them apart is the provider, which is exactly who spotted the abnormal activity.

The ConnectWise incident mentioned above followed the same pattern. In its Cloud Backup (SkyKick) service, starting from one compromised application credential, Huntress saw successful sign-ins to more than 300 Microsoft 365 tenants, and customers were similarly reliant on whatever the provider published.

Which checks sit with the customer alone?

Most of the telemetry belongs to the provider, yet several checks are entirely in the customer's hands and should not wait for the next update:

• An inventory of accounts and API credentials: who held a platform login and in which role, which integrations call the API, where those credentials are stored and who can rotate them.
• Rotation that reaches every copy. Chainalysis requires every user to reset passwords and rotate API credentials; the same should apply to copies held in configuration-management tools, test environments or reconciliation scripts.
• Password reuse. Chainalysis asks users to change any password repeated elsewhere. Internally, that means watching VPN, email and single sign-on attempts aimed at those particular people, because cracked hashes tend to resurface as compromised credentials in later campaigns.
• Egress logs. Proxy or firewall records show which internal systems called the API and how often, though not any use from someone else's infrastructure. For that, ask the provider for per-credential activity going back to October.
• Screening outcomes. If a KYT account was used without authorisation, compliance teams should review closed alerts, rule changes and transactions submitted over the period, even though Chainalysis has not described what the intruder did with those accounts.
• Impersonation of the provider. The exposed names and roles identify each customer's compliance and investigations analysts, obvious targets for vishing and for fake emails carrying "reconnection" instructions, arriving at the very moment Chainalysis is emailing genuine ones.

A password reset falls short while session tokens issued before the reset remain valid. ANSSI's report on the French tax authority showed this plainly, as we covered in "A password reset does not end open sessions".

Can credential exposure monitoring get ahead of the provider's notice?

Partly. Monitoring of exposed credentials and information continuously scans infostealer logs, access markets, forums, Telegram channels and dump sites for an organisation's domains, corporate email addresses, tokens and critical providers. It cannot see what the attacker keeps unpublished, such as Chainalysis's hashes, but it does pick up signals that tend to surround a breach of this kind:

• Credentials of staff with access to the provider's platform in infostealer logs, a common way into SaaS breaches.
• Listings selling access or data that mention the provider or its customers.
• Corporate email addresses and passwords in combo lists, used to test reuse against the VPN or email.
• Lookalike domains of the provider, registered to send fake reconnection instructions.

Infostealer logs matter more than they seem. According to the Verizon 2025 DBIR executive summary, 54% of the ransomware victims analysed had their domains in credential dumps, and 46% of compromised systems holding corporate logins were not managed by the company.

Monitoring does not replace the provider's notice or credential rotation, and it only adds value when each finding is verified before it becomes an alert. Hard2bit provides it as an annual service within its threat intelligence service, with alerts that include context and a recommended action.

What should be agreed with a provider before the next incident?

Chainalysis reopened its services with IP allowlisting, compulsory password resets and credential rotation. Several of those controls could have been running beforehand had the contract and the configuration provided for them, and settling such decisions in advance is much of what third-party risk management is for.

For financial entities under DORA, Article 30 of Regulation (EU) 2022/2554 requires contracts with ICT providers to include assistance when an incident related to the service occurs, either at no additional cost or at a cost set in advance. Where the service supports critical or important functions, the contract must also set notice periods and the provider's reporting obligations.

A screening tool embedded in an anti-money-laundering process is a likely candidate for that classification, although the call rests with each entity and belongs in the register of information that DORA requires. Outside finance, the NIS2 Directive lists supply-chain security among the risk-management measures in Article 21.

Four questions belong in the next review of critical providers:

• Does the service support federated sign-in with our identity provider, and do we use it? With local accounts, password policy, MFA and session revocation are in the provider's hands.
• Can we restrict API credentials by source IP and give them an expiry date now?
• Through which channel and how quickly will the provider tell us, and who on our side receives that message out of hours?
• Have we ever tested a procedure for rotating every credential tied to one provider within a few hours?

Alongside them sits an internal rule: a supplier's breach notice should get a named owner in the incident response procedure, someone who rereads it at every update until formal closure and reopens decisions whenever the scope shifts. We have already shown that three in four breach notices do not say how the attacker got in. Chainalysis exposes a further limitation: the announced scope can grow within days.

Which details has Chainalysis still not explained?

Several. As of 9 November, Chainalysis has not explained the initial entry point, where the interception happened, which hashing algorithm protected the passwords, how long the exposed tokens remain valid or what kind they were, and it has not attributed the attack. Nor has it said how many KYT accounts were accessed without authorisation, and its latest update, on 7 November, does not confirm that Data Solutions is back.

The 30 October notice was consistent with what was known that day; decisions built on it were overtaken five days later. The customer's share of the work lies elsewhere: an inventory of integrations, the ability to rotate credentials without improvising and a person assigned to watch the notice. Organisations that already had that inventory could spend the week rotating credentials. The rest had to start by finding out which ones they had.

Sources and attribution: this analysis draws on Chainalysis's public updates between 30 October and 7 November 2026 and on reporting by BleepingComputer, The Register, The Hacker News and The Block, reflecting information available on 9 November 2026. The company disclosed the incident itself. The terms "offensive agentic techniques" and "on-path attack" are its own; the entry point and attribution remain unclear, so these details may change.

Disclaimer: the checks and contract terms suggested here are for guidance only and should be adapted to each organisation's agreements and environment. The references to DORA and NIS2 are for information only and do not constitute legal advice.