Dark Web Monitoring Guide: Sources, Limits and Response

Stolen credentials, network access and company data are traded openly in criminal markets, and the first sign of a breach is often a listing someone else found. Dark web monitoring watches those markets, forums, leak sites and messaging channels for your organisation's data so you can act before a buyer does. Done well, it is an early warning feed wired to credential, session and secret revocation; done badly, it is a stream of recycled passwords nobody acts on. This guide explains what is monitored, what monitoring cannot see, the legal and safety boundaries, how to triage and respond to findings, what takedown can achieve, and how to evaluate a service. It is for security operations, threat intelligence and identity teams, and for buyers comparing services.

Key takeaways

The value is in the response, not the alert. A finding only matters if it triggers a password reset, session revocation or secret rotation within hours.
Fresh stealer logs and access listings outrank old dumps. The NCSC notes that stealer credentials "are preferred to large breach databases, as they are more recent and used by fewer criminals."
Much of the trade is invisible. Private channels, invite-only forums and sales negotiated in end-to-end encrypted apps are beyond most monitoring.
Never buy back your data. The US Department of Justice warns that "the seller may take the purchaser's payment without producing the promised data," and purchases can carry sanctions and criminal liability.
Non-human credentials leak too. API keys, cloud keys and tokens appear in stealer logs, pastes and dumps, and need rotation, not just a user password reset.

What dark web monitoring covers

The surface web is indexed by search engines; the deep web is everything behind logins or not indexed; the dark web is the small part reachable only through anonymity networks such as Tor, whose onion services hide the server's location. In practice "dark web monitoring" covers all three, because much criminal trade now happens on messaging platforms and ordinary websites as well as onion sites. Europol's Internet Organised Crime Threat Assessment (IOCTA) 2025 sums up the market: "Data has become a commodity for crime," and "Access credentials to remote services, compromised corporate networks, and personal logins are sold in bulk."

Source	What appears there	Value to defenders	Caveats
Credential dumps and combolists	Email and password pairs from past breaches, merged and resold; used for credential stuffing (ATT&CK T1110.004)	Find reused corporate passwords and accounts to reset	Mostly old and recycled; many entries invalid
Infostealer logs	Per-device bundles of saved passwords, session cookies, browser history, files and system details	Highest value: recent, tied to a device, often includes live sessions and NHI secrets	Often from personal or third-party devices you do not manage
Access broker listings	Offers of VPN, RDP, cloud or domain access to a described victim	Possible active intrusion; listings often describe sector, revenue and access type rather than naming you	Hard to attribute; may be exaggerated
Ransomware and extortion leak sites	Victim names, countdowns and published stolen data	Confirms data theft; monitors suppliers and partners	Claims may be false, recycled or about a subsidiary
Forums and marketplaces	Database sales, tooling, recruitment and discussion of targets	Context on who is selling what, and early chatter	Many require vetting; sites appear, vanish and relaunch
Paste and text storage sites	Dumped credentials, configuration files, keys and samples	Fast, public and often easy to get removed	Short-lived; high noise
Telegram and other messaging channels	Bulk log drops, combolists, data sales and leak announcements	Volume and speed; many log sellers distribute here	Private channels and direct negotiation are out of reach

The scale is real. When Genesis Market was disrupted in Operation Cookie Monster (April 2023), the DOJ said it had offered access credentials from over 1.5 million compromised computers and over 80 million account credentials, sold with device "fingerprints" built from identifiers and browser cookies to get past anti-fraud checks. BreachForums, described by the DOJ as "a marketplace for cybercriminals to buy, sell, and trade hacked or stolen data and other contraband," had over 330,000 members and at least 888 datasets holding "over 14 billion individual records of PII." See the Infostealer Threat Guide for how stealer logs are produced and sold.

What monitoring can and cannot see

Every service sees only the sources it can collect lawfully. Ask what is excluded as well as what is covered.

Private negotiation: IOCTA 2025 reporting notes that "end-to-end encrypted (E2EE) communication apps are increasingly being used to negotiate" sales of breached data, and that data brokers are "spreading their activities across multiple platforms." A public advert may be visible; the sale is not.
Access sales before use: MITRE ATT&CK describes Acquire Access (T1650), noting that "initial access broker networks are available to sell access to previously compromised systems," and that much of this "takes place outside the visibility of the target organization." Purchase Technical Data (T1597.002) covers buying credentials "from less-reputable sources such as dark web or cybercrime blackmarkets." ATT&CK lists both as hard to mitigate with preventive controls.
Anonymised victims: broker adverts usually describe a victim by country, sector, revenue band and access level rather than name it, so matching is probabilistic.
Claims versus facts: sellers exaggerate, re-sell old data as new and claim breaches that happened at a supplier. Treat every listing as unverified until you have matched it to your own systems.
Timing: a log may be traded privately for weeks before it reaches a channel a monitor collects. Monitoring shortens, but does not close, the window.

Dark web monitoring therefore complements, and never replaces, prevention and internal detection: MFA, session controls, secret scanning and sign-in monitoring catch what monitoring misses. See the Threat Intelligence Guide.

Legal, ethical and safety boundaries

This section summarises published guidance and is not legal advice; laws differ by country, so involve counsel before any collection programme. The most detailed public guidance is the US DOJ Computer Crime and Intellectual Property Section paper on gathering threat intelligence and purchasing data from illicit sources (February 2020), which covers US federal law only.

Passive collection is the safe zone: the DOJ says "Doing nothing more than passively gathering information from an online forum" is unlikely to be a federal crime without criminal intent.
No unauthorised access: it flags "Accessing a forum in an unauthorized manner, such as by exploiting a vulnerability or by using stolen credentials." In the UK, unauthorised access is an offence under the Computer Misuse Act 1990.
No impersonating real people: "assuming the identity of an actual person without permission could prove legally problematic."
Do not help criminals: "A practitioner must avoid doing anything that furthers the criminal objectives of others on the forums." Aiding and conspiracy liability can arise even without criminal intent.
Do not buy data back: beyond the risk of being scammed, the DOJ notes possible liability under sanctions law if the seller is a designated person. The organisation's policy should forbid purchases outright.
Report crime: information about an ongoing or planned crime "should be promptly reported to law enforcement." Use existing contacts with national police cyber units.
Write rules of engagement: the DOJ recommends you "Involve your legal department in operational planning" and keep documented rules of engagement.

Analyst safety and data handling

Isolation: anyone viewing criminal sources works from isolated, managed research environments, never corporate laptops or personal accounts, and never downloads leaked files onto corporate systems.
Exposure to harmful content: leak sites and forums can expose analysts to disturbing material. Rotate duties, provide welfare support and have a process for reporting illegal content to the authorities.
Personal risk: threat actors retaliate against researchers. Keep analyst identities out of collection activity and public reporting.
Leaked data is still personal data: plaintext passwords and customer records from a leak need minimal access, secure storage and deletion once actioned.

Most organisations should therefore buy collection from a provider that carries this risk under its own documented policies, and keep in-house work to triage and response.

What to watch for

Monitoring is only as good as its watchlist. Keep it owned, reviewed quarterly and limited to terms that produce actions.

Watchlist item	Typical finding	Owner of the response
Corporate email and login domains	Credentials in combolists and stealer logs	Identity team
SSO, VPN, VDI and admin portal URLs	Stealer log entries for those exact URLs, often with session cookies	Identity team and SOC
Cloud account IDs, API key prefixes and internal hostnames	Keys and configuration in pastes, dumps and logs	Platform and secrets owners
Company and brand names, subsidiaries	Leak site claims, access broker listings, impersonation and phishing kits	SOC, incident response and brand teams
Executive and high-risk staff names	Personal data, home addresses and personal account credentials (executive exposure)	Security with HR and the individual
Key suppliers and partners	Leak site listings that may include your data	Third-party risk team
Public IP ranges	Access offers and scanning lists naming your hosts	SOC and network team

Triage: deciding what matters

Classify the finding: combolist entry, stealer log, access listing, leak site claim, paste or chatter.
Check freshness: stealer infection date, first-seen date, and whether it duplicates an earlier finding. Recycled dumps go to a low-priority bulk process.
Match to reality: does the account exist and is it enabled; does the leaked password match the current one (compare hashes through the identity platform) or is the key still active (ask the secret owner)? Never test by signing in with a leaked credential.
Assess privilege: administrator, service account, developer with cloud keys, or executive scores higher.
Look for use: search sign-in, VPN and cloud API logs from the exposure date forward.
Assign and track: every actionable finding becomes a ticket with an owner and a due time.

Responding to findings

NIST SP 800-63B requires that verifiers "SHALL force a change if there is evidence that the authenticator has been compromised," and that new passwords be checked against a blocklist including "Passwords obtained from previous breach corpuses." Monitoring supplies that evidence.

Finding	Response	Target time
Valid credential in a combolist	Force a password change, confirm phishing-resistant MFA, add the password to the blocklist, check for reuse	Within 24 hours
Stealer log with corporate URLs	Revoke identity provider and SaaS sessions and refresh tokens, reset credentials, check MFA methods and OAuth grants, isolate or rebuild the device	Within hours
API key, cloud key or token	Rotate or revoke, review its API activity since exposure, find where it was stored	Within hours
Access broker listing matching you	Treat as a possible intrusion: hunt for the described access, reset privileged and remote access credentials, open an incident	Same day
Leak site listing	Open an incident, verify the data, engage legal on notification duties and law enforcement	Same day
Supplier on a leak site	Ask the supplier what data of yours is affected, rotate shared credentials and integration keys	Within days
Executive personal data	Brief the individual, secure personal accounts, assess physical risk	Within days

For a listing that includes personal data from your systems, GDPR Article 33 sets a 72-hour clock for notifying the supervisory authority after you become aware of a personal data breach. The NCSC adds that "the victim can be liable for not protecting the data, regardless of whether it becomes public on the leak site." See the Incident Response Guide and the Ransomware Response and Recovery Guide.

Where identity fits

Sessions beat passwords: a stealer log with a live session cookie lets a buyer replay a signed-in session (T1550.004 Web Session Cookie) without the password or MFA. Revoke sessions first. See the Token and Session Security Guide.
Non-human secrets: developer machines carry cloud keys, Git tokens and AI service keys. A single log can expose workloads, not just a person. Rotation must reach every secret on the device. See the Leaked Credential Response Playbook and the Secrets Management Guide.
Old credentials stay valid: the Snowflake breach showed infostealer credentials without MFA unlocking customer data warehouses long after the original infections.

Takedown: what is and is not possible

Usually removable: phishing domains and kits impersonating you, fake social media and app store accounts, pastes on mainstream paste sites, and secrets in public code repositories, through abuse reports to registrars, hosts and platforms. Rotate any exposed secret before requesting removal; removal does not undo copying.
Not removable by you: criminal forums, onion leak sites and private channels. Do not attempt to disrupt them yourself.
Law enforcement action: takedowns disrupt markets but data persists. The DOJ noted that BreachForums' predecessor, RaidForums, was seized in February 2022; its BreachForums successor then grew to over 330,000 members. When LockBit was disrupted in February 2024, US and UK authorities seized public-facing sites and administrator servers and obtained decryption keys for victims. After Genesis Market, the FBI provided victim credentials to Have I Been Pwned so people could check whether they were affected.
Takedown services: monitoring providers often bundle brand takedown. Confirm what they remove, how fast, and that they work through legitimate abuse channels only.

See the Phishing Guide for impersonation and phishing site response.

Choosing a service

Options range from free breach notification services and national CERT alerts to commercial threat intelligence platforms. A small organisation with SSO and phishing-resistant MFA gains most from free domain-level breach notifications plus a tested reset and revocation process. A large organisation, or one with many developers and cloud keys, benefits from commercial coverage of stealer logs and access broker markets with API integration. The criteria below are vendor-neutral.

Criterion	What to ask	Red flag
Source coverage	Which source types are covered (stealer logs, broker forums, leak sites, messaging channels), and how coverage is measured	Unverifiable "millions of sources" claims
Collection ethics	Written policy on purchasing, access methods, personas and legal review	Offers to buy back your data
Freshness	Median time from appearance to alert; infection dates on stealer logs	Alerts dominated by old combolists
Context	Stealer log parsing to device, URL, cookie and infection date; deduplication	Raw dumps with no matching to your users
NHI coverage	Detection of API keys, cloud keys and tokens, with prefix matching	Email and password only
Integration	API, SIEM and SOAR connectors, webhook alerts, ticketing	Email-only alerting or PDF reports
Data handling	How leaked passwords and personal data are stored, masked and retained	Plaintext passwords emailed to analysts

Run a proof of concept on your own domains: compare findings against your known incidents and directory, count how many were actionable, and time the alerts.

Rolling out monitoring

Write the response first: agree the runbooks for credential reset, session revocation and secret rotation with identity and platform owners, and test them on test accounts.
Agree rules of engagement: with legal, document collection boundaries, the no-purchase rule and law enforcement contacts.
Build the watchlist: start with domains, SSO and VPN URLs and key prefixes; add executives and suppliers once the core process works.
Pilot with alert-only routing: send findings to a triage queue for four to six weeks, measure actionable rate and false positives, and tune the watchlist.
Automate the safe actions: automatically force password changes and add leaked passwords to the blocklist for matched accounts; keep session revocation and secret rotation behind analyst approval until the false positive rate is known. If automation misfires, revert to alert-only routing and re-enable the affected accounts.
Extend: add supplier monitoring, executive exposure and takedown once core metrics are stable.

Detection and measurement

Metric	What it shows	Target direction
Share of findings that were actionable	Signal quality of the service and watchlist	Rising
Median time from alert to session revocation or reset	Whether response beats the buyer	Hours, not days
Share of exposed NHI secrets rotated within 24 hours	Whether non-human credentials are handled, not just passwords	Towards 100%
Exposed credentials still valid at triage	Strength of MFA, rotation and blocklisting	Falling
Repeat exposures per user or device	Whether root causes were fixed	Falling
Incidents first detected by monitoring	Contribution to early warning	Tracked; review each case

Framework mapping

Framework	Relevant items	Relevance
NIST CSF 2.0	ID.RA-02 cyber threat intelligence is received from information sharing forums and sources; RS.MI incident mitigation	Intelligence intake and response
NIST SP 800-53 Rev. 5	PM-16 Threat Awareness Program; SI-5 Security Alerts, Advisories, and Directives; IA-5 Authenticator Management; IR-4 Incident Handling	Threat awareness, credential changes and incident handling
NIST SP 800-63B	Section 3.1.1.2: breached password blocklists and forced change on evidence of compromise	Acting on leaked passwords
ISO/IEC 27001:2022 Annex A	A.5.7 Threat intelligence; A.5.17 Authentication information; A.5.26 Response to information security incidents	Collection, credential handling and response
MITRE ATT&CK v20	T1597.002 Purchase Technical Data; T1650 Acquire Access; T1110.004 Credential Stuffing; T1550.004 Web Session Cookie	Adversary behaviours that monitoring gives early warning of

Common failure patterns

Alerts without owners: findings land in a shared mailbox and nobody resets anything. Route each finding type to a named team with a due time.
Resetting passwords but not sessions: stealer logs carry live cookies that survive a password change unless sessions are revoked.
Ignoring republished data: old breach data resurfaces. The Cisco Active Directory credentials leak saw hashes from a 2022 breach republished in 2025; any credential not rotated since remains a risk.
Incomplete rotation after a known exposure: the Cloudflare breach began with credentials left unrotated after the Okta breach.
Treating every claim as fact: announcing or paying over an unverified leak site claim. Verify against your own data first.
Analysts browsing criminal sites from corporate devices: legal exposure and malware risk for little gain over a managed service.

Practitioner checklist

Write and test reset, session revocation and secret rotation runbooks before switching monitoring on.
Agree written rules of engagement with legal, including a ban on purchasing data.
Monitor domains, SSO and VPN URLs, cloud account IDs and API key prefixes, not just email addresses.
Prioritise stealer logs and access broker listings over recycled combolists.
Revoke sessions and refresh tokens, not only passwords, for stealer log findings.
Rotate every API key, cloud key and token found, and review its use since exposure.
Block breached passwords at set and reset, as NIST SP 800-63B requires.
Monitor key suppliers on leak sites and know who you will call.
Use isolated environments or a managed service for any viewing of criminal sources.
Report actionable rate and time to revocation monthly.

Dark Web Monitoring Guide