“Dark web monitoring” suggests analysts browsing hidden marketplaces. The reality for most security teams is less dramatic and more useful. The majority of leaked credentials that matter to an organisation surface first in places that are publicly reachable: paste sites, public messaging channels, open forums and code repositories. Hidden services matter too, but they are one source among several, and they need different access.
This guide covers what to monitor, how to collect it, how to tell a new leak from a recycled one, and the legal and ethical lines that keep a monitoring programme defensible.
Where leaked credentials actually appear
| Source | How it is reached | How long content lasts | Notes |
|---|---|---|---|
| Paste sites | Ordinary web | Often hours to days | High volume, frequent removals |
| Public messaging channels | Ordinary web or client apps | Varies | A major distribution route for combolists |
| Open forums | Ordinary web, sometimes registration | Long | Samples and announcements of larger dumps |
| Code repositories | Ordinary web | Until removed | Leaked keys, tokens and config files |
| Leak and extortion sites | Often onion services only | Long | Usually need a Tor layer |
| Closed forums and markets | Invitation, reputation, payment | Long | Usually better left to a specialist provider |
Two consequences follow. Most of the sources are on the ordinary web, so a large share of monitoring is a collection problem that normal web infrastructure can solve. And the sources that are only reachable over Tor, or only with an invitation, need a different route and usually a different approach.
What residential proxies do and do not reach
Residential proxies route ordinary web requests through consumer connections. They are well suited to the publicly reachable sources above.
They do not reach onion services. Sites that exist only on Tor require a Tor client, and a residential proxy does not replace that. If your programme covers onion-only leak sites, plan a separate Tor layer for them.
For the ordinary web sources, residential exits help in three ways.
Attribution. Monitoring from your corporate address range tells anyone watching exactly who is looking. Threat actors notice, and some change behaviour in response.
Rate limits and geo restrictions. Paste sites and forums throttle repeated requests and some restrict access by region. Distributed, geographically appropriate exits keep collection steady.
Continuity. Paste content disappears quickly, so collection has to be frequent and reliable, not a daily sweep that misses what was posted and removed in between.
The wider case is set out in residential proxies for threat intelligence and OSINT, and the product view on the OSINT with residential proxies page.
Build the watchlist before the collector
Monitoring is only as good as what it looks for. Define the watchlist deliberately:
- Your domains, including legacy, regional and acquired domains, since employee and customer email addresses are the most common match.
- Customer-facing identifiers such as your service’s login domain or app name, which leaks often reference.
- Secret patterns for your own API keys, tokens and connection strings, which have recognisable formats.
- Brand and product names, for announcements of breaches before any data appears.
- Key internal hostnames, which turn up in leaked configuration files.
Keep the list versioned, and review it when the organisation changes. An acquisition nobody added to the watchlist is a blind spot.
Collection cadence follows volatility
Paste content is short-lived, so it needs frequent polling. Forums and repositories change more slowly and can be checked less often. A single cadence for every source either wastes effort on stable sources or misses content on volatile ones.
Keep requests proportionate and back off on errors. The mechanics are in rate limiting and request throttling. With the Shifter gateway, choose an exit region per source where a site restricts by geography:
customer-USERNAME-country-nl:PASSWORDWithout a session identifier the exit rotates per request, which suits independent fetches of many small pages.
New leak or recycled combolist?
Most “new” credential dumps are not new. Combolists are assembled and reassembled from old breaches, reposted under new names, and re-sold. Treating every match as a fresh incident exhausts the response team and teaches everyone to ignore alerts.
Assess freshness before escalating:
- Have you seen this exact credential before? Keep a record of previously matched credentials, stored as salted hashes, not plaintext, and compare against it.
- Does the password still match anything current? A credential whose password was changed long ago is historic, not active.
- Is the source reputable for new material? Some channels mostly repost; some are where breaches first appear.
- Does the dump contain data that did not exist until recently? Recent accounts or recently issued identifiers date a leak reliably.
Triage and response
Once a match is confirmed as relevant, severity depends on what was exposed and what it still unlocks.
| Finding | Typical response |
|---|---|
| Valid-looking credential for an active account without MFA | Force a password reset, revoke sessions, prompt for MFA |
| Credential for an account with MFA enabled | Reset, and watch for second-factor phishing |
| Leaked API key or token | Revoke and rotate immediately, then review usage logs |
| Employee credential for a third-party service | Notify the employee and the service owner |
| Announcement of a breach with no data yet | Escalate to incident response for investigation |
Account takeover often follows credential leaks, and the detection side of that is covered in how fraud teams detect account takeover with residential-IP signals. At password creation, current digital identity guidance recommends checking new passwords against lists of known compromised passwords, which closes part of the gap before any leak is found.
The lines not to cross
A monitoring programme is only defensible if it stays within clear limits. Write these down and have legal review them.
Observe, do not transact. Do not buy stolen data, pay threat actors or trade with them. If a purchase or engagement seems necessary, that decision belongs to legal counsel and, where appropriate, law enforcement.
Never test found credentials against live accounts. Logging in to a service with leaked credentials, including your own customers’ accounts on your own service, can be unauthorised access. Use internal processes to identify affected users and force resets instead.
Minimise what you keep. Store only what is needed to match and respond, hash credentials rather than keeping plaintext, restrict access tightly, and set retention limits. Leaked data is personal data, and your handling of it is subject to the same obligations as any other; see residential proxies and GDPR compliance.
Be careful with personas. Registering accounts on forums under invented identities raises legal and ethical questions that vary by jurisdiction and by the source’s terms. For closed sources, a specialist threat intelligence provider with established access and legal review is usually the better route.
Coordinate internally. Monitoring activity that the security operations team does not know about wastes their time when it shows up in their own alerts.
Measure the programme
Track the number that reflects risk: the time between credentials appearing publicly and your response completing. Alongside it, track matches by source, the share of matches that were recycled, false positives, and sources that went quiet, because a source that stops returning anything has often changed its access, not its content.
For the external side of your exposure, beyond credentials, see continuous external attack surface monitoring.
FAQ
Can residential proxies access the dark web?
Not onion services. Those need a Tor client. Residential proxies are for the publicly reachable sources, which is where most credential leaks first appear.
How often should paste sites be checked?
Often enough to catch content before it is removed. For high-volume paste sources that means minutes, not days.
Should we download entire leaked databases?
Collect only what you need to identify your own exposure, and involve legal counsel before retaining larger datasets. Holding stolen data carries its own obligations and risks.
Is it worth monitoring if we already use a breach notification service?
Often yes. Commercial services cover many sources well, and your own monitoring can target organisation-specific patterns, such as internal hostnames and key formats, that general services do not track.
The bottom line
Credential leak monitoring is mostly an ordinary-web collection problem with a demanding response process attached. Watch paste sites, public channels, forums and repositories on cadences that match how fast each changes, keep onion-only sources on a separate Tor layer or with a specialist provider, and separate new leaks from recycled combolists before escalating.
Respond by what a credential still unlocks, never test found credentials against live accounts, minimise what you keep, and stay on the observing side of every line. Rates for the collection layer are on the pricing page.