Dark Web Monitoring: What It Actually Watches, and What to Do With an Alert

Dark web monitoring is usually sold as a service that watches criminals on your behalf. What it actually is, when it works, is narrower and more useful than that: a subscription to a set of data sources that record stolen identity material, matched against the identifiers you own, with an alerting layer that tells you when your accounts or your people appear in them. The value is almost entirely in what happens in the twenty minutes after the alert, not in the watching.

That distinction matters because the market is crowded with products that scan the same recycled datasets and describe them in increasingly dramatic language. A buyer who understands where the records come from, how old they are, and what an alert can and cannot prove will get more defence for a fraction of the price of one who buys the biggest logo. This guide is about the mechanics: the sources, the failure modes, the triage order, the response that actually closes the exposure, and the procurement questions that separate a monitoring service from a subscription to a feed of old news.

What these services actually watch

Underneath the branding, a monitoring service does four things. It collects material from criminal and semi-public sources. It parses that material into records with fields - email, username, password, hash, cookie, host, timestamp, malware family. It matches those records against the identifiers a customer has proved they own: domains, email addresses, employee lists, brand names, IP ranges, API keys. And it delivers matches as alerts, ideally with enough context to act.

Everything that distinguishes one provider from another sits in the second and third steps. Collection is a commodity: the same stolen logs are resold to everybody. Parsing quality determines whether you receive a usable record or a wall of noise. Matching determines whether you learn that your finance director's laptop was infected, or that somebody with a similar name appears in a 2019 breach that has been circulating for seven years.

The sources fall into four classes, and it is worth knowing which ones a provider actually covers, because they behave differently.

Breach dumps and combolists. Databases stolen from services, then traded, merged and resold. They are historical by nature; a breach announced this month typically contains credentials harvested months or years earlier. Combolists are aggregations of many dumps, deduplicated by criminals with varying competence, and heavily recycled - SpyCloud's 2026 Identity Exposure Report found that 51% of records in the combolists it analysed overlapped with infostealer logs it had already seen, which is a polite way of saying that a large share of what is sold as new is old material in a new wrapper.

Infostealer logs. The output of malware families that harvest saved passwords, cookies, session tokens, autofill data, cryptocurrency wallets and, increasingly, API keys and OAuth tokens from the local configuration of developer tools. This is the class that matters most in 2026, because the material is fresh, it is machine-generated, and it includes the artefacts that let an attacker skip authentication entirely rather than guess a password.

Marketplace and broker listings. Initial access brokers advertising footholds, card shops selling payment data, account shops selling streaming and cloud logins, and forums where access to a specific company is offered. Coverage here is partial by design: no provider sees every market, and the markets that matter move.

Leak sites and extortion channels. The publication pages of ransomware groups and the channels where data is advertised. Monitoring these is closer to journalism than to security - useful for situational awareness and for confirming a claim, mostly retrospective for defence.

Why infostealer logs became the whole product

Five years ago a monitoring subscription was mostly a breach-notification service. Today the value sits in stealer logs, and the reason is arithmetic. In 2025 SpyCloud recaptured 13.2 million infostealer infections exposing 642.4 million credentials and 8.6 billion cookies and session artefacts, from a datalake that has grown to 65.7 billion distinct identity records. The same analysis found 5.3 billion credential pairs circulating in criminal sources and that four in ten corporate users had reused a password that had already been exposed.

Two of those numbers deserve a second look. The 8.6 billion cookies are the reason a password reset alone does not close an incident: a stolen session cookie can be replayed to reach an authenticated session without any password being presented, which is why every serious stealer-log response begins with session revocation and ends with a password change, not the other way round. And the reuse figure is the reason a personal breach becomes a corporate one - the streaming account compromised in 2021 is the same password protecting the VPN in 2026.

The ransomware link is now measured rather than asserted. Verizon's 2026 Data Breach Investigations Report found that 73% of ransomware victims had an infostealer infection or credential leak in the year before the attack, and that for half of those the credential event happened within 95 days of the ransomware. A mid-sized organisation in that dataset had a median of seven credential-leak events a year; a large one had twenty. That is the case for monitoring in one sentence: the precursor is visible, on average, months before the impact, and it is visible in exactly the data these services collect.

There is a caveat that belongs next to those figures. SpyCloud and its competitors are selling the collection they measure, so their numbers describe their own visibility. The trend is corroborated independently by the DBIR's methodology, but a buyer should treat vendor percentages as directional and ask for the methodology rather than the headline.

What an alert does not tell you

The failure mode of this product category is not silence; it is an alert that is read as more than it is. A monitoring alert records that an identifier of yours appeared in a dataset. It does not record that anyone used it, that the account is still reachable, that the password is current, or who took it.

Four questions decide what an alert is worth, and a provider that does not help you answer them has shipped you a screenshot.

How old is the record? Breach data is dated by the source incident, not by the date it appeared for sale. A record surfaced today from a 2017 dump is a historical fact with no operational urgency, unless the password is still in use somewhere. The best providers carry the source incident date and the malware infection timestamp, and those two fields are the difference between a scheduled rotation and a 2am call.

Is the credential plaintext or hashed? A plaintext password is directly usable. A hash may be crackable in minutes or may be unusable. Alerts that do not distinguish the two produce unnecessary resets and, worse, train the recipient to ignore the channel.

What else was in the log? A stealer entry for a corporate user that contains cookies, a session token and an API key is a live incident. The same email address appearing in a combolist with an old password is housekeeping. Same vendor, opposite urgency, and the only way to tell them apart is the artefact detail.

Is the identifier actually yours? Lookalike domains, shared first names, and addresses that were once aliases produce matches that are not exposures. Manual review of the first matches is the only way to calibrate; automating the pipeline before the matches have been reviewed is how a monitoring programme generates its own denial-of-service.

False positives, and why the reset reflex is dangerous

The combolist recycling measured at 51% has a direct operational consequence: a large share of alerts describe credentials that were exposed years ago and have been resold repeatedly since. A programme that forces a password reset on every alert will reset the same passwords every quarter, generate helpdesk load, and teach staff that the security team panics.

The better pattern is a decision tree rather than a reflex. If the record is from an infostealer log with a recent infection timestamp, treat it as a live compromise: revoke sessions, reset, re-enrol MFA, hunt for the infected device. If the record is a hashed credential from an old breach and the user's current password is different, log it, confirm the password has been rotated since the incident date, and close it. If the account is not one you control - a personal mailbox used for corporate correspondence - the action is a conversation about separating identities, not a forced reset you cannot enforce.

There is a second false-positive class that vendors rarely discuss: the alert that is real but unactionable, because the exposure is at a third party. A supplier whose credentials appear in a stealer log is a supply-chain risk, and the useful output is a vendor-risk record with a date, not an internal ticket that nobody can close.

Triage: what to check in the first twenty minutes

The order matters, and the commonest mistake is doing it in the wrong one. This is the sequence we use, and it holds whether the alert arrives from a commercial feed or from a free service.

Confirm the artefact class. Determine whether you are looking at a breach record, a combolist entry, or an infostealer log with cookies. The class determines everything that follows. If the provider gives you a domain, a username and a password but no artefact list, ask for the raw record before you act.

Identify the device, not just the account. An infostealer log means malware ran somewhere. Resetting the password on a machine that is still infected resets it straight into the stealer's next upload. Before remediation, get the hostname and the infection timestamp from the log if available, and locate the endpoint.

Revoke sessions, then change the password. In Microsoft 365 and Google Workspace this means revoking refresh tokens and signing out all sessions, not simply changing the password. A stolen cookie survives a password change; it does not survive a token revocation.

Check the persistence the attacker would have left. Mailbox forwarding rules, delegate access, OAuth application grants, MFA method registrations, recovery email and phone changes, and application passwords. An account taken over for a week will usually have at least one of these, and removing the password without checking them leaves the attacker a way back in.

Check the blast radius. The same password, the same cookie jar and the same browser profile usually cover several services. Sweep the whole identity provider for the same session, and check the password manager for shared credentials.

Decide whether this is an incident. If there is evidence of use - a login from an unexpected location, a mailbox rule you did not create, an invoice drafted and not sent - the monitoring alert has become an incident response and should be run as one, with preservation of logs before remediation.

Session tokens: why the password is the least important secret now

A session cookie is a bearer credential. Whoever holds it is treated as you by the application, without presenting a password or a second factor. Stealers harvest the cookie stores of every browser on the machine, which is why 8.6 billion cookies appeared in the 2025 recapture figures, and why incident responders now look for token replay before they look for a password spray.

Two defensive consequences follow. First, the response to a stealer alert must include token revocation across the identity provider, and the check must be explicit rather than assumed: changing a password in most systems does not invalidate existing refresh tokens. Second, session lifetime is a control. Short-lived sessions, conditional access policies that bind tokens to a device, and re-authentication for sensitive actions all reduce the value of a stolen cookie, and they cost less than the average incident.

The same logic has now extended to machine credentials. SpyCloud recorded 6.2 million credentials and authentication tokens for AI tools in 2025, and reported stealer families specifically harvesting configuration files from AI coding assistants and code editors. For a development team that means the exposure register has to include API keys, model provider tokens and repository credentials, not just the human directory.

What an organisation can monitor, and what it cannot

Coverage is a scoping decision, and the useful way to make it is to list the identifiers you are prepared to act on. Monitoring an identifier you cannot remediate produces reports, not security.

Corporate identities. The email domain, plus the aliases and shared mailboxes that staff actually use. This is the baseline and it is cheap: a verified domain search on a public breach service covers the historical breach class for nothing, which is a sensible starting point before buying anything.

Employee personal addresses. The highest-value coverage, and the most sensitive. Most stealer infections happen on personal devices and personal accounts that are then used for work. Covering them requires a lawful basis and a clear policy: what is collected, who sees it, what happens when an employee's personal account appears, and whether the employee is told. In the EU and the UK this is employee monitoring and needs the works council or staff consultation process, a data protection impact assessment where the scale justifies it, and a retention rule for the records themselves.

Executives and finance. A narrower list with a faster SLA. The pattern that costs the most money is a compromised finance mailbox used to redirect a payment, and the tell is usually a mailbox rule rather than a password.

Customers. Credential-stuffing exposure of your own customer base is a fraud and reputational risk, and a monitoring service can tell you when your users' credentials appear elsewhere. Acting on it needs care: notifying a customer that their password was in a breach is a legitimate security communication, but the notification has to be accurate about which service was breached.

Brand and impersonation. Typosquatted domains, lookalike social profiles, phishing kits that clone your login page, and mobile apps using your name. This is a different data class with a different remediation path - takedown rather than reset - and it is the part of the service most often missing from a cheap subscription.

Source code and keys. Repository leaks, exposed secrets in public commits, and stealer-captured developer tokens. The remediation is rotation, and it needs an owner who can rotate within hours.

What no subscription covers is the private conversation. No commercial service reads a criminal's encrypted chat in real time, and any vendor implying otherwise is selling fantasy. Attribution, when it exists at all, comes from law enforcement, from the artefacts inside a log, or from an investigation with legal process behind it.

The lawful and ethical limits of watching criminal markets

Every monitoring service sits close to a legal line, and the difference between a reputable provider and a reckless one is usually visible in how it describes its own collection.

Buying from criminals. A provider that purchases credentials directly from a seller is funding the market it is monitoring, and in several jurisdictions the transaction itself is an offence. The defensible model is collection from material that is already circulating publicly or semi-publicly - pasted data, public leak sites, logs posted to open channels - and from law-enforcement and researcher sharing arrangements. Ask how the data was obtained, in writing, and be suspicious of a provider that treats the question as naive.

Handling other people's data. A breach record contains personal data about your employees, your customers, or sometimes people who have nothing to do with you. Holding it needs a lawful basis, minimisation, a retention period and access control. A spreadsheet of employee passwords emailed around a company is itself a reportable incident waiting to happen; store the alert metadata and the action taken, not the credential.

Employee monitoring boundaries. In the EU, monitoring personal accounts of staff is a monitoring measure subject to proportionality, transparency and, in many member states, consultation with employee representatives. The workable design is opt-in where possible, aggregate reporting to the employer, and individual notification to the employee - which is also the design that keeps staff reporting exposures instead of hiding them.

Do not become the investigator. Nothing in a monitoring subscription authorises contacting a seller, buying access to a forum, or attempting to identify a criminal. Attribution work of that kind requires law enforcement or a properly scoped investigation with written authority, and a well-meaning employee who starts messaging a marketplace is creating legal exposure for the employer.

Know when to refer. If an alert indicates an active intrusion, the sequence is containment, preservation, then notification to the police or the relevant cybercrime unit, and to your insurer if you carry cyber cover. Insurers increasingly ask for evidence of monitoring as a condition of cover, and a dated alert record is exactly that evidence.

Twelve questions to ask before you sign

The sales conversation is usually about breadth. The questions that decide whether the service works are about latency, freshness and remediation.

One. Which source classes do you cover - breach dumps, combolists, infostealer logs, marketplaces, leak sites - and what proportion of your alerts came from each in the last quarter? Two. Do you supply the malware infection timestamp and the source incident date on every record? Three. Do infostealer alerts include the artefact list - cookies, tokens, keys - or only the credential? Four. What is your median time from a log appearing in the wild to an alert reaching me, and can you evidence it? Five. Can you revoke sessions or force a password reset through an integration, or do I do everything by hand? Six. How do you retract an alert you got wrong, and how quickly? Seven. What is your false-positive rate, measured how? Eight. Do you cover personal email addresses of staff, and what does the contract say about the lawful basis and the data flow? Nine. Do you do brand and impersonation takedowns, in which jurisdictions, with what success rate? Ten. Where is the data stored, for how long, and can I get it deleted? Eleven. What happens at renewal if I leave - do I keep the historical record? Twelve. Who do I call at 3am, and is that included?

The last question separates a feed from a service. A monitoring product without a response path is an expensive way to learn bad news late.

Metrics that show whether it is working

Monitoring programmes fail quietly. The dashboard stays green because nobody defined what green means. Five measures are enough to tell whether the subscription is doing anything.

Coverage. The share of the identity population you can actually match: corporate addresses, plus whatever proportion of staff have opted into personal coverage. A programme covering 40% of the directory is a 40% programme, however large the contract.

Freshness. The median age of a record at the moment it reached you. If most alerts describe incidents older than a year, you are buying archive access, not early warning, and the price should reflect that.

Actionable rate. The share of alerts that resulted in a defined action - a revocation, a reset, an endpoint hunt, a vendor notification. This is the number that exposes a noisy feed, and the one vendors rarely volunteer.

Time to revoke. Median minutes from alert to session revocation. This is the only metric that maps directly onto the attacker's window, and it is the one to put in front of a board.

Rework. How often the same credential triggers a second alert after you closed it. High rework means the closure was cosmetic - usually a password reset without a session revocation, or a device that was never cleaned.

Build, buy or hybrid

The build option is more viable than the market suggests, and a hybrid is usually optimal. Three components can be run in-house at negligible cost.

Verified domain search on a public breach service. Free for the domain owner, gives the historical breach class, and covers the bulk of the "old password still in use" alerts. It will not tell you about stealer logs, and it will not tell you about personal addresses, but it is the correct first step and it takes an afternoon.

Canary credentials. Plant unique addresses and credentials in places an attacker would find them - a document share, a wiki page, a service account note - and alert on any use. This detects both credential harvesting and the internal reconnaissance that precedes it, and it costs nothing but discipline.

Honeytoken documents and API keys. The same idea applied to files and machine credentials: a document with a tracking pixel or a key that only exists to be stolen. Any interaction is a high-confidence signal that something is wrong, with no false positives by construction.

What cannot sensibly be built in-house is stealer-log collection at scale, because it requires continuous presence in criminal distribution channels, and the parsing is where the expertise lives. That is the part worth buying - and it is worth buying specifically, rather than as an opaque bundle that also charges for the breach searches you could run yourself.

A thirty-day plan that fits a real budget

Days one to three: establish the identifier list. Every address the company owns, every alias, the executive and finance lists, the domains and the brand terms. Prove ownership of the primary domain on a public breach service and start there. Write down who is allowed to receive what.

Days four to ten: fix the response path before the feed. Decide who receives alerts, who may revoke sessions, who may reset a password, and what the escalation is when the affected account belongs to an executive. Write the triage tree from the section above into a one-page runbook and rehearse it on a synthetic alert. A feed switched on before the runbook exists produces panic, not response.

Days eleven to twenty: select coverage. Buy stealer-log coverage for the corporate directory and, if the lawful basis and the consultation allow it, for opted-in personal addresses. Skip the parts you can do in-house. Add brand monitoring only if someone owns the takedown work.

Days twenty-one to twenty-five: close the structural gaps. Session lifetime, conditional access, MFA method restrictions, OAuth consent policy, mailbox rule alerting. These reduce the value of every credential that will ever be stolen from you, and they cost configuration time rather than licence fees.

Days twenty-six to thirty: measure and report. Baseline coverage, freshness and time to revoke, then report monthly. The first month's numbers are the argument for next year's budget, and they are also the only way to notice that the service has stopped delivering value.

Free checks worth doing today

Four things cost nothing and close real exposure. Search your domain on a public breach notification service and review the historical records against current policy. Check whether your identity provider enforces session revocation on password change - most do not by default. Audit mailbox forwarding rules and OAuth grants across the tenant, because that is where a taken-over account leaves its door open. And confirm that MFA is enforced for every account that can approve a payment, change a bank detail, or create a mailbox rule, in that order of priority.

None of these require a subscription, and all four reduce the damage from the exposure that a subscription will eventually surface.

What it cannot do, stated plainly

Four limits are worth writing into the procurement file, because each one is routinely overstated in a sales deck.

It does not prevent exposure. Monitoring tells you that something was stolen. It does not stop the infostealer, the phishing kit or the reused password. Endpoint protection, patching, phishing-resistant authentication and a password manager do that, and a programme that buys monitoring instead of those is buying a smoke alarm and removing the extinguishers.

It does not prove an incident. An alert is a data point, not a finding. Whether an account was used, and by whom, comes from logs, from the identity provider's sign-in history, and from endpoint artefacts. Insurers and regulators ask what happened, and the answer has to come from investigation, not from a feed.

It does not cover what was never digitised. Insider theft that never touched a criminal market, a copied spreadsheet, a photographed screen and a verbally passed password are all invisible to this class of service. Those cases need investigation work - interviews, access review, device forensics - which is why monitoring belongs beside an investigative capability rather than replacing it.

It does not give you attribution. The identity of a seller, an operator or an affiliate is a law-enforcement question. Private providers can preserve and structure evidence, and in some cases they can support a case; they cannot arrest anyone, and a report that implies otherwise is overreach.

Where monitoring fits in a security programme

The useful mental model is a loop rather than a product. Prevention reduces how often credentials are stolen. Detection - and this is the only place monitoring sits - shortens the time between theft and knowledge. Response converts knowledge into revocation and remediation before the credential is used. Recovery deals with the cases where it was used anyway.

Organisations that get value from this spend most of their effort on the third step. The feed is the easy part; the runbook, the authority to revoke, and the on-call rotation are what turn an alert into a closed exposure. That is also why an outsourced monitoring service that hands you a portal and nothing else tends to be cancelled at the first renewal.

For businesses that want the detection layer without building a security operations function, the practical arrangement is a managed service with a defined escalation path: alerts triaged by the provider, an agreed action list for the routine classes, and a named human to call for the ones that involve tokens or finance. Our vulnerability assessment service covers the exposure surface that feeds these alerts, and the guide to dark web risks covers what is actually traded and why it is priced the way it is.

If an alert has turned into something larger - a mailbox rule you did not create, a payment that moved, a laptop that was infected - the next step is investigation rather than more monitoring. The incident response planning guide sets out the first hours, the email security guide covers the mailbox controls that limit the damage, and digital forensics covers evidence preservation when the outcome may be a claim, a dismissal or a police report. For staff-side measures - the phishing-resistant authentication and the training that reduces how often a log has your domain in it - see the security awareness programme guide. To have the exposure reviewed and the response path built, the contact form reaches an analyst directly.

The insider and supplier cases monitoring will miss

Two of the more expensive scenarios in practice never appear in a monitoring feed, and it is worth knowing why so that expectations are set before the first renewal.

The insider. An employee who copies a customer list, photographs a pricing model or emails a spreadsheet to a personal account generates no criminal-market record, because the data never reaches a market. What catches that case is access logging, data-loss prevention with real alerting, egress monitoring and an investigation with a lawful collection plan. The monitoring subscription contributes at most a data point - the same person's corporate credentials appearing in a public dump after they left - which is suggestive and never sufficient.

The supplier. A vendor whose credentials appear in a stealer log is a supply-chain exposure you cannot remediate directly. The useful actions are a vendor-risk record with the date and the artefact class, a contractual right to be told about incidents within a stated period, and a decision about whether that vendor's access to your systems should be narrowed. Most supplier contracts contain none of that, which is why the alert tends to produce a meeting rather than a change.

Both cases argue for the same design: monitoring is the cheap outer ring, and it only pays off where there is an investigative capability behind it. Our corporate espionage investigation guide covers the insider route in the detail it deserves.

Insurance, contracts and the paper trail

Cyber insurers have moved from asking whether a company has monitoring to asking what it does with the alerts. The questions on a proposal form now typically include the identity provider in use, whether MFA is enforced, whether sessions are revoked on password change, and whether the insured subscribes to a threat-intelligence or dark web service. A dated record of alerts, actions and closure times is the evidence that answers them, and it is worth keeping for that reason alone.

Three contractual points are worth negotiating. First, notification: a provider should commit to a maximum time from ingestion to alert, not a target. Second, retraction: a provider that has never issued a false alert is either not measuring or not telling you, and the contract should say what happens when one is withdrawn. Third, exit: historical alerts are your evidence, and you should be entitled to an export of them at the end of the term, in a format you can read without the vendor's portal.

On the regulatory side, an exposure alert is not automatically a personal data breach requiring notification. It becomes one when there is unauthorised access to personal data you control, and the assessment is the same as in any other incident: what data, whose, what risk. The mistake to avoid is treating a monitoring alert as a reportable event by default, which produces notifications that were not required and, in some jurisdictions, liability for having made them carelessly.

Five buying mistakes that cost more than the subscription

Buying coverage before a runbook. The feed arrives, the first alert goes to a shared inbox nobody owns, and the exposure is closed three weeks later by an attacker rather than by you. The runbook costs a day and decides whether the licence was worth anything.

Buying the bundle. Most vendors price one product that includes breach search, brand monitoring and stealer coverage. If you would not act on two of the three, you are paying for dashboards. Buy the class you will remediate, and run the free domain search for the rest.

Counting alerts as value. A provider that sends ten thousand matches a month is not more thorough than one that sends forty; it has a matching problem. Ask for the actionable rate, and check the first month's alerts by hand.

Covering addresses nobody can reset. Personal Gmail accounts of contractors, shared mailboxes, legacy aliases for departed staff. Every alert on an identifier you cannot act on is a ticket that closes with a note. Scope to the population you can remediate, and add the rest only when the process exists.

Skipping token revocation. The single most common failure after a stealer alert is a password reset that leaves the attacker's session alive. If the only change you make after reading this guide is to test whether your tenant revokes sessions on password change, and to fix it if it does not, the time was well spent.