Which of your credentials are already in a stealer log?
An employee installs a cracked utility at home. Forty seconds later every saved password and session cookie on that machine is in an archive, and within the hour that archive is in a subscription channel with a few hundred paying readers. Nothing on your perimeter fired. This is the surface the platform was built to watch first.
The four places the current answer runs out
The alert arrives after the login
Impossible-travel and anomaly rules fire on the attempt. By definition that is the moment the credential is already being used, which makes your earliest signal the attacker's first success.
Password resets do not revoke sessions
Most identity stacks do not bind session validity to password state. The reset is auditable, fast, and against a stolen cookie frequently irrelevant for days.
Combolists bury the signal that matters
Feeds that count recycled records inflate your exposure dashboard while telling you nothing new. One primary stealer record is worth ten thousand of them, and most tooling cannot tell you which you are looking at.
The infected device is not yours
The laptop was personal, the network was home, the install was a game crack. There is no endpoint agent on it and there never will be, so the only place the compromise is visible is the market it was sold into.
How the credential became a session
Each era did not replace the last; it stacked on top. Your controls have to cover all three, and most were designed for the first.
THREAT EVOLUTION
EACH ERA STACKED ON THE LAST
2012-2018
Credentials at rest
Breach dumps and combolists: months-old inventory, recycled and resold. Rotation policies and breach-list lookups were a proportionate answer, because the data aged faster than it moved.
2019-2023
Credentials in motion
Infostealers industrialize. Traffer teams push infections on quota, clouds of logs ship fresh output daily, and the record reaching the market is hours old rather than years. Rotation is now racing the pipeline.
YOU ARE HERE
2024-2026
Sessions on demand
The cookie is the product. A stolen session walks past MFA without ever meeting a password prompt, so the reset that closed the front door leaves the side one open until the token expires on its own schedule.
Next
Non-human identity
The same logs already carry API keys, CI tokens and service-account secrets scraped from developer machines. There is no human to call, no password to reset, and no MFA to bypass, because there was never a login.
Four plays, and the window each one runs in
Every play names the module that does the work. Nothing here is a capability we describe without shipping.
The record is indexed at the drop, not at the door
Stealer logs are collected from the channels they are first distributed in, and indexed on arrival. The record is therefore searchable while the batch is still being packaged for resale, which is the only window where a reset is preventive rather than cosmetic. Finding it is a query you run, not a message that arrives.
SHERLOGCookies as first-class records
Session cookies are a searchable dataset of their own, matched by domain the same way credentials are, and each row carries its host, its path, its expiry and the log it came out of. Your response runbook gets the second half of the incident: revoke the sessions as well as the password.
SHERLOGRead the channel the batch shipped in
A stealer batch is announced, sampled and subscribed to before it is resold, and that traffic runs on Telegram rather than on a forum. The channel corpus is indexed full-text as its own searchable body, so the announcement and the subscription pitch can be read, which is how a routine daily dump is told apart from a batch someone assembled around your domain.
TELEPATHYWork out who is shopping for you
When a record touching your domain family surfaces, the same domain often appears in access-broker chatter. The Jabber room corpus is searchable full-text, so running your domain against it is what separates bulk spray from someone shopping for you specifically. It is a second query against a second corpus, not a link drawn for you.
JABBERNAUTA morning inside the exploitation window
A stealer batch drops in a Telegram channel. The victim is a contractor's personal laptop; nothing in your estate has any idea.
The batch is parsed and indexed. Nobody is woken and nothing is sent: from this moment the records are simply there to be found.
The standing morning query on your domain family returns three records that were not there yesterday. One carries fourteen cookies for your SSO portal, four of which have not reached their expiry.
Your analyst resets the password and revokes the sessions in the same runbook step. The listing goes on sale at 11:00 to a buyer who finds a dead account.
The move, stated plainly
No customer logos and no invented percentages: we have not deployed long enough to have honest ones. What we can state is what the workflow becomes.
You learn from the failed-login spike
You learn from the corpus the log landed in, on the morning after the theft rather than after the first attempt
Remediation is a password reset
Remediation is a reset plus a session revocation, because you know the cookies exist
Exposure counts are inflated by recycled dumps
Every record carries its type, so the recycled half can be excluded from the query
Credential exposure, honestly answered
The other four
Ransomware early warning
The ransom note is the last message in the thread. We read the earlier ones.
Vulnerability triage
Your backlog is sorted by severity. The attacker's is sorted by price.
Brand & executive exposure
Your executives are discussed in channels they cannot open, in languages your feed does not read.
Fraud & abuse
The chargeback is the symptom. The breach that caused it happened somewhere upstream.
Your competitors will learn about the leak from the invoice.
Learn about it from the log batch.
NDA-friendly briefings · global coverage · no slideware