Most ransomware intrusions today don’t start with a fresh exploit. They start with a credential that was already stolen, already in someone else’s hands, and already on sale. Mandiant’s M-Trends 2026 reports that “prior compromise was the top confirmed initial infection vector for ransomware-related incidents, nearly doubling from the prior year to 30%.” That makes dark web monitoring for stolen credentials less of a “nice to have” and more of a question every CISO is now being asked: are we watching the place these credentials end up.
The scale is the part that catches most security teams off-guard. SpyCloud’s 2026 Annual Identity Exposure Report found that “SpyCloud recaptured over 642.4 million exposed credentials from 13.2 million infostealer malware infections in 2025.” At roughly 50 exposed credentials per infection, the supply available to attackers has been industrialised, and breach-notification emails arrive far too late to be the primary signal.
This post walks through what actually happens between the moment a credential is stolen and the moment it’s used, and what a credible monitoring service should be observing at each step. The focus is the practical buyer question: what is a service catching that a one-time dark web scan is not.
How Infostealers Turn One Device Into a Corporate Breach
Most stolen corporate credentials today arrive through an infostealer infection on a single device — frequently a personal laptop, a contractor machine, or a family member’s PC where the employee saved their work password in the browser. The malware runs once, harvests stored credentials, browser autofill, session cookies, and authentication tokens, and uploads the contents to a criminal log marketplace.
A common buyer question follows: does dark web monitoring work if credentials come from a personal device. The honest answer is yes — infostealers infect personal and contractor devices as readily as corporate endpoints, so monitoring that only tracks corporate network events misses the majority of infostealer-sourced exposure.
Hudson Rock, which maintains one of the larger infostealer telemetry datasets in the industry, frames the chain plainly in its 2026 trends note: “Compromised credentials of legitimate employees are being used to take over business infrastructure.” The team at CTDefense sees the same pattern in client engagements. Corporate VPN, SSO portal, and cloud-console logins all show up in stealer logs, often weeks before any internal alert fires.
This is also where the ransomware initial access vector starts. Stolen credentials sit alongside other identity-driven entry routes the team has covered, including vishing campaigns aimed at help desks and SOCs. Once a credential is in a log, it’s no longer “potentially exposed” — it’s already in the hands of whoever buys that log next.
The 48-Hour Window: From Infection to IAB Auction
Speed matters more than most buyers expect. A common question is: how fast do stolen credentials appear on the dark web. In the team’s experience, credentials harvested by an infostealer typically appear in underground channels within 24–48 hours of infection, before most breach-notification systems fire.
The aggregation chain is well-understood. Logs are uploaded to dedicated stealer marketplaces and Telegram channels, sorted by domain, country, and credential type. From there, brokers extract credentials of interest — corporate VPN portals, RDP gateways, cloud admin panels, finance and HR systems — and resell them onward. What a broker eventually advertises for a mid-market victim — typically Finance, Healthcare, or Technology — is rarely a generic combolist drop. It’s a curated package: working credentials, session cookies where available, sometimes a confirmed login screenshot.
Infostealer log monitoring is the layer that catches the credential while it is still in this aggregation phase, before it has been bought, repackaged, and listed for access. That window is short, but it’s the window in which a forced password rotation, an SSO session revocation, and a sweep on the affected device still meaningfully change the outcome.
The Hudson Rock team has shown how granular this telemetry can get: “Using our database of 30+ million infected computers, we identified machines belonging to Mujtaba and Mohsin Raza.” That is the same database structure a credible monitoring service queries on the defensive side, to identify which of an organisation’s employees, contractors, or third parties have an infected device producing live credential exposure.
What a Credible Service Actually Monitors
A “free dark web scan” generally checks a credential against a static list of known historical breaches, which is useful for noticing that an old password has been published and not much else. A credible service is doing something different: continuous credential leak detection against live underground feeds.
The team at CTDefense uses the following list as a working definition of what dark web monitoring should cover for a corporate buyer:
- Stealer log marketplaces. The primary feed for fresh infostealer-derived credentials, sorted by infected machine. Coverage here determines whether the service catches the 24–48-hour window or only the historical leftovers.
- Combolist drops. Aggregated credential lists circulating on forums and Telegram. Lower fidelity than stealer logs but useful for credential-stuffing exposure against SaaS portals.
- Telegram and Discord criminal channels. Increasingly the venue where access is advertised, especially for mid-market victims that don’t reach the larger forum markets.
- Initial access broker listings on underground forums. The curated, monetised tier — listings for particular sectors, geographies, and access types. Continuous coverage here is what gives an organisation lead time before a ransomware affiliate completes the purchase.
- Session cookie and authentication-token markets. A relatively new category that most legacy monitoring tools do not cover, and one of the most dangerous gaps for organisations relying on MFA alone.
Beyond the feeds themselves, the analyst layer is what turns a list of strings into a usable signal. A raw credential matched against a corporate domain is not yet an alert. It has to be triaged: is this a real corporate identity, was the device a managed asset or a personal one, is the session token still valid, what systems would this credential reach. Dark web monitoring is one of the few security domains where the analyst’s interpretation of the signal is at least as load-bearing as the feed itself.
Why Session Cookies Matter as Much as Passwords
The session-token category is worth its own section because most buyers do not realise how mature it has become. SpyCloud’s 2026 figure on this is striking: “SpyCloud recaptured 8.6 billion stolen cookies and session artifacts exposed through malware infections.”
A stolen session cookie does not need a password and does not need a second factor. The attacker imports the cookie into a browser session and is logged in as the user, past the SSO flow, past the MFA prompt, past the conditional access policy. Session cookie theft MFA bypass is now the path of least resistance for several active ransomware affiliate groups, particularly against cloud-hosted SaaS estates and cloud admin consoles.
This is also the cleanest line between dark web monitoring for stolen credentials and an EDR-only posture. An EDR agent on the endpoint that originally got infected may have caught the malware. An EDR agent on the corporate workstation watching the resulting logged-in session sees a legitimate authenticated user. CTDefense has written separately about why EDR alone doesn’t close the credential-theft gap, and the session-cookie story is the single sharpest example of the pattern.
Five Questions to Ask Before You Buy Dark Web Monitoring
The buyers the team speaks with most often are CISOs and IT directors at 200–2,000-employee organisations in Finance, Healthcare, and Technology, frequently triggered by a peer breach or a cyber-insurance renewal asking whether monitoring is in place. The following five questions tend to surface whether a service is doing the work.
- What feeds are you watching, and how fresh are they. A specific answer — stealer marketplaces, named Telegram channels, named forums, session-cookie markets — is the right answer. “We monitor the dark web” is not an answer.
- How quickly does a fresh exposure reach me. The useful target is hours, not days. A weekly digest is not enough when the IAB auction window is 24–48 hours.
- Are you covering session cookies and authentication tokens, not just username and password pairs. If the service only checks credential pairs, the MFA-bypass category is a blind spot.
- What do alerts look like when a third-party or contractor device is the source. Real coverage includes infected devices outside the corporate perimeter, with enough context to drive remediation against the right party.
- Who is triaging the signal, and what do they hand you. A raw feed of matches is not a service. The analyst layer — confirming the identity, scoping the impact, recommending the response — is the difference between a tool and a control.
A useful related question buyers raise: what is the difference between a dark web scan and dark web monitoring. A one-time scan checks known breach databases; continuous monitoring watches live stealer log feeds, Telegram channels, and IAB forums in real time and alerts before credentials are weaponised.
Where CTDefense Fits
CTDefense Dark Web Monitoring is built around this picture of the credential supply chain. The service combines continuous coverage of stealer log marketplaces, IAB forums, criminal Telegram and Discord channels, and session-cookie markets with a human analyst layer that scopes each finding to the client’s actual identity surface — corporate accounts, third-party access, executive exposure, and contractor devices included.
The team is not going to claim complete coverage of every underground space. Nobody honestly can, and the markets shift faster than any single feed keeps up with. What the service does commit to is the part that matters operationally: catching exposed credentials inside the window where rotation and session revocation still close the gap, and giving an analyst-written brief that a small security team can act on without building the threat-intelligence function from scratch.
Organisations in Finance, Healthcare, and Technology that have already hardened their endpoint and identity stack, and that are now looking at the gap between an infostealer infection on a personal device and a ransomware actor logging into a corporate VPN, are the ones for whom this layer makes the most direct sense. Similar organisations are encouraged to take a close look at where their credentials might already be circulating, and at the speed at which their current tooling would surface that signal. The credentials are already on sale. The question is whether anyone on the defensive side is watching the same channels the buyers are.