Full article
Attach a time to every finding
Chainalysis’s November 4 incident update disclosed exposed password hashes and live tokens. Its initial assessment therefore cannot stand as the complete account. This article discusses the notice read on November 6, without treating recovery plans as completed or assuming identical activity across every affected account.
An incident report describes both what investigators know and what remains unresolved. An early absence of evidence is bounded by the investigation at that time. When findings change, an editor should revise the affected explanation, rather than leave a reassuring conclusion intact and merely append a generic investigation notice.
Password changes and session revocation are separate checks
OWASP treats authentication, sessions and access control as connected mechanisms. A service commonly retains an authenticated session instead of requesting the password for every interaction. Changing the password and ending existing sessions must therefore be verified separately. Their relationship depends on implementation, not the wording of a settings button.
Suppose an old browser can still retrieve information after a password change. The change alone would not demonstrate that all prior access has ended. This is a hypothetical example, not a reconstruction of this incident. A recovery check should cover existing sessions, devices and integrations, with evidence for each relevant revocation.
Recovery has operational dependencies
An organization may use one service through both employee accounts and automated jobs. Imagine replacing an integration key without updating the scheduled job that uses it: processing could stop. Keeping the old key indefinitely to avoid disruption could preserve unwanted access. These are dependencies to coordinate, not reasons to skip revocation.
A useful recovery record identifies which service uses each credential, who replaces it, how success is checked and what happens if the replacement fails. Three outcomes need evidence: the new access works, the old access no longer works, and the dependent task resumes. Sending a notification proves none of those outcomes by itself.
Restored connectivity is not a closed investigation
Imagine a login page reopening. That demonstrates the return of a visible function; it does not establish that every data category, entry path and downstream consequence is understood. Our analysis is that operational restoration and investigative findings should be tracked separately, because they answer different questions about availability and what happened.
Useful follow-up reporting distinguishes new evidence, remaining uncertainty and required actions. This article does not identify an attacker, establish individual losses or confirm present service availability. Anyone handling an affected account should verify the applicable recovery arrangements through official channels, rather than infer current instructions from a historical article.