Dark web monitoring searches hidden forums, marketplaces, paste sites and leak sites for your company's data, such as credentials, customer records or internal documents. It can give early warning of a breach. It cannot see everything, and an alert is only useful if you already know what you will do about it.
What is the dark web, briefly?
It is the part of the internet reached through special software. The Tor Project explains that Tor routes traffic through relays to protect the user's location, and that sites can be offered as onion services reachable only through Tor. Such services hide where a site is hosted, which is why criminals use them. Plenty of legitimate use exists too.
What can monitoring actually find?
- Credential dumps. Email and password pairs from breaches, often old, sometimes recent.
- Stealer logs. Credentials and session data taken from infected devices.
- Leak site posts. Ransomware groups often name victims and publish samples.
- Sale listings. Offers of access to a company network or database.
- Mentions. Your brand or executives named in planning chatter.
What can it not do?
It cannot search closed groups it cannot join, private messaging channels or anything behind invite and vetting. Coverage claims are hard to verify, so ask for examples of the sources a service watches. It also cannot tell you whether a leaked password is still valid. And finding old data tells you little about how you were breached.
A constructed example
A monitoring service reports that 40 corporate email addresses with passwords appear in a dump. Before acting, the security team asks three questions. Are the passwords current? They check against the identity provider: 6 of the 40 match. Are those accounts protected by MFA? Four are, two are not. Was the data from your systems or from a third party site where people reused work email? It was a third party site. The actions follow: force a reset on the six, enrol the two without MFA, and remind staff not to reuse work passwords.
Why do leaked credentials matter so much?
NIST SP 800-63B says that when a user sets or changes a password, the verifier must compare it with a blocklist of commonly used, expected or compromised values, including passwords from previous breach corpuses. So checking against known leaks is mainstream guidance, not just a product feature. You can do much of that yourself at password creation time.
What does a good alert look like?
A good alert states what was found, where, when it appeared, how it relates to your organization and how confident the provider is. A weak one says "your data was found" and nothing else. Ask for samples during evaluation and run one through your playbook to see whether your team could act on it within a day.
Record each alert and its outcome. After a year, the record shows whether the service found anything you did not already know.
How to check or apply this
- Write the response playbook first: who triages an alert, who resets accounts, who contacts legal.
- Decide what you watch: your domains, executive names, key vendor names, product names.
- Ask any provider which sources it covers and how it verifies findings.
- For credentials, check validity against your own directory before alerting users.
- Require MFA, preferably phishing resistant, so a leaked password alone fails.
- Block known compromised passwords at creation.
- For leak site claims, verify with your own investigation before any public statement. Claims can be false or exaggerated.
- Do not buy data back or contact criminals without legal and law enforcement advice.
Quick check
Do I need to browse the dark web myself?
No, and it is not advisable without training and a safe setup. Use a service, or sector sharing groups, and focus your effort on response.
If monitoring finds nothing, am I safe?
No. It shows only what appears in sources it can see. Keep ordinary controls in place.
Sources
- Tor Project, About Tor
- NIST SP 800-63B, Authentication and Authenticator Management
- CISA, #StopRansomware
Last reviewed: 18 October 2026.
