Dark Web Monitoring
Find out what is being traded about you before it is used
We watch the marketplaces, forums, paste sites, ransomware leak pages and closed channels where stolen corporate data surfaces first — and tell you when yours appears.
dark web/findings/open, newest first
Collection running- Critical
Live session cookies for idp.acme.example in an infostealer log
stealer-log / logs-channel·DWM-40218
- High
Access broker advertising VPN access — sector and region match
forum / auction thread·DWM-40204
- High
Leak-site post names a tier-one supplier, 40 GB claimed
ransomware-dls / mirror·DWM-40191
- Medium
Employee credentials reappeared in a recycled combolist
combolist / paste·DWM-40177
Recycled — no new exposure
Watch list
- Domains
- acme.example + 3 more
- Mail domains
- acme-mail.example
- Brand terms
- Acme, Acme Pay
- IP ranges
- 203.0.113.0/24
- Named people
- Board and finance approvers
Identifiers only. No agent, no credentials, no access to your systems.
Illustrative interface. Findings, domains and references are placeholders written for this page, not real customer data.
Is our data already being traded?
Most organisations find out late, and from someone else. The material that ends up on a leak site or in a broker advert has usually been circulating for weeks in places nobody on your team has an account. We watch those places for your identifiers, and we tell you what we found, where, and what it means.
- Leaked employee and customer credentials, with the breach they came from
- Ransomware leak-site listings naming your organisation or your suppliers
- Access brokers advertising a route into your network
- Source code, documents and database dumps offered for sale
At a glance
- Collection
- Tor, I2P, forums, paste sites, Telegram
- Alerting
- Designed to raise within minutes of a match; collection cadence varies by source
- Enrichment
- Breach origin, inferred credential freshness, exposure age
Coverage
What we watch, layer by layer
“The dark web” is not one place. It is a stack of source classes with different access requirements, different languages and very different half-lives. Here is what we collect from each, and what it gives you.
Tor marketplaces and criminal forums
databases, documents, access
Onion-hosted markets and the long-running Russian- and English-language forums where corporate data is listed, auctioned and vouched for.
- Listing text, asking price, seller handle and reputation history
- Auction threads that track a single victim from advert to sale
- Invite-only and vouched sections, plus I2P mirrors of forums pushed off Tor
Ransomware and extortion leak sites
victim naming, published archives
The victim-shaming sites run by extortion groups, their mirrors, and the channels they use to republish after a takedown or a seizure.
- New victim posts, countdown timers and proof-of-breach samples
- Listings that name a subsidiary, a brand or a supplier rather than your legal entity
- The moment a claim moves from threatened to published
Initial-access-broker adverts
a route into a network
Brokers rarely name the victim. They describe it — sector, country, revenue band, employee count, and the access type they are selling.
- Access type: VPN, RDP, Citrix, webshell, hypervisor or domain admin
- Claimed privilege level, host count and price, captured with the advert
- Matched against your own estate so a vague description becomes a decision
Infostealer logs and bot markets
live credentials and session cookies
Logs from commodity stealer malware, sold in bulk or resold per-machine on bot markets. The freshest and most dangerous class of exposure we handle.
- Corporate credentials saved in a browser, in the clear, with the URL they belong to
- Session and refresh cookies that can be replayed past a password and past MFA
- Machine context: hostname, operating system, locale and installed software
Combolists and historic breach corpora
password reuse and old exposure
The recycled bulk of the criminal economy. Low signal on its own, but essential for judging whether a fresh credential is genuinely new.
- Aggregated combolists, credential-stuffing sets and old third-party breach dumps
- Deduplicated against everything we have already shown you
- Used to mark a finding as recycled instead of raising it again as new
Paste sites and anonymous file hosts
dumps, configs, internal hostnames
Pastes are where a leak is often staged before it is sold, and where fragments of internal infrastructure end up by accident.
- Paste sites and their many clones, captured before short-lived posts expire
- The anonymous file hosts that forum threads link to for the actual archive
- Configuration snippets, internal hostnames and connection strings
Closed Telegram and Discord channels
fresh logs, fraud, insider recruitment
Much of the trade has moved to messaging. Access is the hard part; the content is faster-moving than any forum.
- Logs-as-a-service channels and the bots that sell single-machine access
- Fraud, carding and SIM-swap channels naming banks, retailers and telcos
- Posts recruiting insiders at named employers, including yours
Code, config and document leaks
secrets, source, internal files
Not every leak is criminal. A lot of exposure is a developer mistake that an attacker finds before you do.
- Public repositories, gists, build logs and package registries carrying your secrets
- Internal source code and design documents offered for sale on forums
- API keys and tokens matched to your domains and cloud tenants
Coverage is not a fixed list. Forums get seized, channels get banned and the trade moves. We add and retire sources continuously, and the platform records which source class every finding came from so you can judge it yourself.
Alerts
What you get told, and what to do about it
Every finding arrives with the same three things: what was found, where it came from, and the action we would take. Severity is scored per finding — the levels below are what that type usually lands at.
Session or token exposure
Typically critical- What it means
- A cookie or refresh token for one of your identity or SaaS domains was captured on an infected machine. It can be imported into another browser and replayed — the password and the MFA prompt are already behind it.
- Recommended action
- Revoke sessions and refresh tokens for the account, then read your sign-in logs from the log timestamp forward. Treat the device as compromised, not just the account.
Corporate credential exposure
Typically high- What it means
- A username on one of your domains appeared with a password. We tell you which source class it came from and whether we have seen the pair before, because a stealer log and a ten-year-old dump need different responses.
- Recommended action
- Force a reset on the account, confirm MFA is enrolled and not bypassable, and check whether the same password protects anything else you own.
Network access advertised
Typically critical- What it means
- A broker is selling a route into a network, described by sector, region, size and access type. Brokers seldom name the victim, so we tell you which parts of the description match your estate and which do not.
- Recommended action
- Audit the named access path — VPN, RDP, Citrix, whatever it is. Hunt for the described foothold, rotate service credentials and review third-party accounts.
Ransomware leak-site listing
Typically critical- What it means
- An extortion group has posted a claim naming you, a subsidiary, a brand or a supplier. We capture the post, the claimed volume, any sample files listed and the state of the countdown.
- Recommended action
- Preserve the listing as evidence, confirm what the claim actually covers, and get legal, comms and your incident retainer moving in parallel.
Data set offered for sale
Typically high- What it means
- A database, customer table or document archive attributed to you is listed. Sellers exaggerate, so the alert separates what is proven by the sample from what is only claimed.
- Recommended action
- Verify the sample against your own records before you accept the claim. If it holds, start the regulatory assessment clock the same day.
Source code and secret leak
Typically high- What it means
- Internal code, configuration or a live key surfaced in a paste, a public repository or a forum listing. Keys are the urgent part: they usually still work.
- Recommended action
- Rotate the key first and read the audit log second. Then look for what else the same commit or paste exposed.
Executive and insider chatter
Typically medium- What it means
- A named executive, an approver or your company name appears in a fraud channel, a doxxing post or an insider-recruitment advert. Often the earliest warning you will get of a targeted attempt.
- Recommended action
- Brief the individual directly, tighten out-of-band verification on payment changes, and tell your SOC what to expect in the mailbox.
A finding in full
What a critical session-exposure alert actually looks like
Active session cookies for your identity provider found in an infostealer log
A log posted to a subscription logs channel contains browser cookies for idp.acme.example and vpn.acme.example, captured from an unmanaged Windows host with a corporate mail account signed in.
- Finding ID
- DWM-40218
- Source class
- stealer-log / logs-channel
- Log timestamp
- 2026-02-11 07:42 UTC
- Seen before
- No — first appearance
Evidence · redacted
metadata only, no archive retained
| machine | DESKTOP-K4•••• · Windows 11 23H2 · en-GB · UTC+01 |
|---|---|
| account | j.b••••••@acme.example (matched: corporate mail domain) |
| browser | Chromium profile “Default”, 214 saved logins |
| cookie | idp.acme.example __Host-session expires in 21 days |
| cookie | vpn.acme.example SSOSESSIONID expires in 6 hours |
| creds | 4 corporate · 17 personal · 1 password-manager vault file |
| context | Unmanaged device. Corporate SSO present, no MDM identifier. |
Why this is critical
A stolen session is not a password problem. Whoever imports that cookie arrives already authenticated, so a reset alone changes nothing until the session behind it is killed. The VPN cookie has hours left. The identity-provider cookie has weeks.
Recommended action
- Revoke all sessions and refresh tokens for the account.
- Reset the password and re-enrol MFA from a clean device.
- Review sign-ins from the log timestamp forward, including successful ones.
- Isolate or rebuild the host, and remove its access.
Illustrative example. The identifiers, timings and counts above are placeholders written for this page — not a real finding and not customer data. Redaction shown is how we present credential material by default.
Deep dive
An infostealer log is not an old breach dump
Both arrive as a text file full of credentials, and that is where the similarity ends. Treating a fresh log like a ten-year-old dump is the single most common mistake we see in credential response.
What is inside one
Credentials in the clear
Passwords lifted from the browser store as the user typed them. There is no hash to crack, no rate limit to beat and no lockout to trip. If it worked yesterday it probably works now.
Session and refresh cookies
The part that matters most. A valid session cookie can be imported into another browser and replayed, which lands the buyer inside the account without a password prompt and without an MFA challenge — because both were already satisfied on the infected machine.
The URL list
Every site the credential was saved against, internal ones included. That list is a map of your tooling: the ticketing system, the VPN portal, the admin console, the naming convention you use for internal hosts.
Machine fingerprint
Hostname, operating system and build, locale, timezone, installed software and often the local IP. Enough to tell whether the victim is a managed corporate laptop or a contractor's personal desktop with your SSO signed in on it.
Whatever else was lying around
Logs routinely include a directory listing, a screenshot of the desktop, crypto wallet files and any plaintext note of passwords the user kept locally. Password-manager vault files show up too.
Side by side
| Dimension | Breach dump | Stealer log |
|---|---|---|
| Age of the material | Years old. Often already reset, often already public. | Freshly stolen, and often still being traded while the device is infected. |
| Credential form | Usually a hash, sometimes salted, needs cracking. | Plaintext, exactly as the user typed it. |
| Effect of MFA | MFA still stops the login. | A stolen session can arrive past the MFA prompt. |
| Scope | One breached service. | Every site in the browser — work and personal, mixed. |
| Context supplied | An address and a password. | Host, OS, software, internal URLs, local files. |
| Who buys it | Stuffers running lists at scale. | Access brokers and targeted operators picking victims. |
| Your response window | Reset it, check for reuse, move on. | Same day: revoke sessions, reset, rebuild the host. |
Half-life
A log is worth most to a buyer in its first days, while the cookies are still valid. That is the whole argument for escalating a log match as soon as we have it rather than batching it into a report, and the reason we treat log matches differently from every other kind of credential finding.
What we do with one
Match the accounts against the mail and SSO domains you gave us. Extract the cookie hosts that belong to you and how long each has left. Read the log metadata for an exfiltration date. Mark whether the pair is a first appearance or recycled from a set you have already seen. Then hand you the fields, not the archive.
Response
From alert to action in six steps
The finding is the easy half. This is the playbook we attach to a credential or session exposure, in the order it should be run — and the platform tracks each finding's state so you can see what is still open.
- Step 1Analyst
Validate the finding
Check the account exists and still matters. Read the source class and the first-seen date before anything else: a recycled combolist entry and a freshly captured log are not the same event, and the finding tells you which one you have.
- Step 2IAM
Scope what the exposure reaches
List what that identity can touch — mail, SSO applications, VPN, code, finance approvals. For a session finding, add the cookie hosts we captured. The exposure is the account's blast radius, not the one login it was saved against.
- Step 3Service desk
Force the reset
Reset the password out of band and re-enrol MFA from a device you trust. Do not send the reset link to the mailbox you believe is compromised, and do not let the user set it back to a variant of the leaked one.
- Step 4IAM
Revoke the sessions
The step most often skipped, and the one that decides whether the reset achieved anything. Kill every active session and refresh token for the identity, across the provider and the applications federated to it.
- Step 5SOC
Hunt for reuse and for the device
Search sign-ins from the exfiltration timestamp forward, successes included. Try the leaked password against your own break-glass and service accounts. If a machine name came with the log, find it, and take it off the network.
- Step 60DaySecure
Watch for the re-listing
Stolen material gets resold, repacked and reposted. We keep matching against the same identifiers, and mark a reappearance as recycled rather than raising it again — unless something about it is genuinely new.
Findings can be delivered to your SIEM, your ticket queue or a chat channel, so step one does not have to start in a browser tab. The owner labels above are the usual split — the platform makes no assumption about your team structure.
Limits
What we do not do
Some of this market runs closer to the line than a regulated buyer can afford. These are the four limits we work inside, and they are the same for every customer.
We do not buy stolen data
No purchases, no test buys, no subscriptions paid to a seller to get a sample. Everything we show you was observed where it was posted. If the only way to see something is to fund the person selling it, we do not see it, and we tell you that instead of pretending otherwise.
We do not engage sellers on your behalf
We do not negotiate, bid, pose as a buyer, or open a conversation with a broker or an extortion group in your name. That work belongs to your incident response firm and your legal counsel, who carry the mandate and the insurance for it.
We do not attempt access
We never try a leaked credential against your systems — or anyone else's — to see whether it still works. Validity is inferred from the source, the log metadata and the age of the material. Confirming it is your call, inside your own tenant, in your own logs.
We do not hoard the evidence
Findings are stored as metadata and redacted excerpts: enough to identify and act on the exposure, not a copy of the breach. We do not re-host stolen archives, and we do not hand you a database of your customers' passwords to keep on a shared drive.
One consequence worth stating: we will not compete on finding counts. A recycled combolist can be republished ten times a year, and a vendor that reports each one as a new detection will always show a bigger number than we will.
Questions
Dark web monitoring, answered plainly
The five questions security and procurement teams ask us first.
No. Monitoring runs on identifiers you give us at onboarding: the domains you own, your mail and SSO domains, brand terms, IP ranges and the names of people you want watched. There is no agent to install, no credentials to hand over and no access to your network. Integrations for delivering findings into a SIEM or a ticket queue are optional and read-nothing — they only push our output to you.
A lookup site tells you whether an address appears in a historic breach corpus. That is one of eight source classes we cover, and the least urgent. It will not show you a session cookie lifted from an infected laptop and posted to a logs channel, a broker advertising VPN access into a company that matches your profile, or an extortion group naming your supplier. It also will not deduplicate, date, score or tell you what to do next.
The platform is built to raise a finding within minutes of a match once a source has been collected. The honest caveat is the collection step: a public paste site is polled constantly, while a closed channel or an invite-only forum section is collected on its own cadence, so the end-to-end time depends on where the material lands. Every finding records when we first saw it and, where the source supplies one, when the data was stolen.
That is the main design constraint. Recycled material is matched against everything we have already shown you and marked as recycled rather than raised again as a new exposure. Fresh, first-appearance material and anything with a live session attached is escalated. You can set thresholds per source class if your team wants a different balance.
We observe sources rather than transact in them: no purchases, no engagement with sellers, no attempt to use anything we find. Findings are stored as metadata and redacted excerpts rather than copies of stolen archives, encrypted in transit and at rest, with access restricted to the people who need it. Our security practices are documented in full on the security page, and your own legal and privacy teams are welcome to review them before you sign anything.
Ask us what is already out there.
We run a scoped search on your own identifiers and walk you through whatever comes back — including the finding you would rather not see.
- Your domains, not a demo data set
- No agent, no credentials
- Findings are yours to keep