What Dark Web Monitoring Can and Cannot Tell You

Dark web monitoring is good at one job: telling you that a key to your business is loose. It is much weaker at telling you how the key got out, or whether it still fits the lock.

Knowing where that line sits decides what you do in the first hour after an alert.

Old Passwords, New Logins

In April 2024, Mandiant received threat intelligence about database records that turned out to come from a company's Snowflake account. By June, Mandiant and Snowflake had notified about 165 organizations that their data might be exposed.

Mandiant found no evidence that Snowflake's own systems were breached; the attackers logged in. Every incident Mandiant responded to traced back to stolen customer credentials, mostly taken by malware that copies the passwords and cookies saved in a web browser and sends them to whoever runs it. The infected machines were outside Snowflake, and in several cases they were contractors' laptops that were also used for gaming and pirated downloads.

The surprise was the age of the data. The earliest infection Mandiant linked to a stolen login dated back to November 2020, roughly three and a half years before the attacks. The credentials were, in Mandiant's words, "still valid, in some cases years after they were stolen." Nobody had changed them, and the accounts didn't require multi-factor authentication (MFA), so a username and password were all it took.

At least 79.7% of the accounts the attackers used had been exposed before the campaign began. Exposed credentials like these are the kind of data dark web monitoring looks for.

What a Finding Can Tell You

A dark-web finding is an indicator of compromise: a clue that something, somewhere, has been breached, before you know what. Read that way, it tells you three useful things.

Something Upstream Is Compromised

When a staff login on your domain turns up, the usual explanations are an infected device that person uses, or a password they reused on another site that was breached. Neither lives on your servers, and both are worth finding.

For a hosting company the stakes are higher. Picture a support agent whose browser holds a saved login to your billing and admin system. If their home laptop picks up password-stealing malware, that one machine can open a door to every customer you host. Mandiant made the same point about contractors: one infected laptop can give an attacker access to several organizations at once.

It's Intelligence You Can Hand On

Your customers' domains can show up in the same data. A finding on a customer's domain is something you can tell them before an attacker uses it, and you're the company they'd expect to hear it from.

It goes one level further down. If the customer runs an online store or an app, some leaked logins may belong to the customer's own users. Those people need a password reset, and only your customer can ask them for one.

A Forum Mention Can Come Before the Attack

Leaked passwords are usually old news. A post on a criminal forum that names your company can sit earlier in the chain.

Some of those posts come from initial access brokers: people who get into a company's systems, or buy the logins to do it, and then sell the way in to someone else, often a ransomware crew. If the post is selling access, there may still be time before a buyer uses it.

Intel 471 measured that window. Between June 2024 and May 2025 it logged 4,878 access offers and found at least 70 possible links between those offers and companies that later appeared on ransomware leak sites, where gangs post the names of the companies they've hit. The average gap between offer and leak-site post was about 19 days, and gaps ranged from zero to 100 days. Three of the brokers it profiled focused mainly on logins for RDWeb, Microsoft's browser-based remote desktop portal. Intel 471 calls these possible correlations, since it can't prove each offer led to each attack.

A leak-site post comes after the break-in, so the real window is shorter than those numbers, and sometimes there's none. Not every mention is an access sale, either. Some are about data already stolen and sold, or about someone else's leak with your domain in it. What the post offers decides how fast you move.

What It Can't Tell You

The same data has blind spots, and they are worth knowing before you lean on it.

How the Credential Got Out

A leaked record usually names the site the login was for and the date it was indexed. For a staff address on your domain, that's often their account on some other website. What it can't tell you is whether that website was breached, or malware on someone's laptop took the login from their browser. The record looks the same either way, and the fixes differ: a breached site needs a password reset, while an infected laptop has to be cleaned first. Either way, it's best to rotate your password and ensure MFA is enabled.

When It Leaked, or Whether It's New

Stolen data gets repackaged and posted again. When security researcher Troy Hunt checked a large batch of logins stolen from infected computers in 2025, 96% of the 109 million email addresses in it were already in the breach database he runs. He also pointed out that a login in a batch like this often means a device was infected, with no data on when. A "new" finding can be an old leak in a new wrapper.

Whether It Still Works

Monitoring sees a credential; it can't try it, and shouldn't. Snowflake showed that the age of a password tells you little about whether it still works.

A new password may not be enough on its own, either. Password-stealing malware also takes session cookies, the token a site gives your browser after you've signed in and passed MFA. Replaying one lets an attacker carry on that session with no password and no MFA prompt until it expires or is revoked. In Microsoft Entra ID, a user who selects Yes on the "Stay signed in?" prompt gets a persistent cookie that remembers both sign-in factors, and Microsoft's default sign-in frequency is a rolling window of 90 days.

What It Hasn't Seen

Monitoring can only report what its data source has collected. Private sales, closed chats and logs that haven't been indexed yet stay invisible. In Intel 471's sample, 12 companies were claimed by ransomware groups before any access offer for them showed up. An empty report means only that nothing was found.

AegisWhite's dark web domain monitoring has these limits too. It checks each domain on a schedule against data from a specialist breach-intelligence provider. We don't run our own crawlers, so our coverage is that provider's coverage.

For staff logins we keep a one-way fingerprint of the password, never the password itself, so a login that comes back with the same password is flagged as previously seen. Logins linked to your staff are graded Critical, and any new forum mention is graded High. Hosts can resell it under their own brand, with their name on the alert emails. Forum mentions are listed in the portal and are not emailed. AegisWhite never contacts your customers.

How to Use This

These steps work with or without a monitoring service.

1. Assume the Password Still Works

Change it on every account where it was used, from a device you know is clean, and turn on MFA. On your own servers, check that SSH doesn't accept passwords at all, so a leaked one can't open a shell:

sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication) '

You want no on both lines. If your sshd_config has Match blocks, run it again with -C user=NAME,addr=IP to see what those users get. If any line says yes, make sure key-based login works for every admin before you switch passwords off.

2. End the Sessions Too

After the reset, use the service's "sign out everywhere" or revoke-sessions control, so a stolen cookie stops working.

3. Clean the Device Before You Trust It Again

For a staff finding, find the machines that person signs in from, home laptop included. If password-stealing malware is still running there, the new password goes the same way as the old one.

4. Tell the Customer in Plain Words

Say what was found, what it usually means and what to do. A template:

We found two logins for @example.com in leaked data indexed this week. This usually means a computer or another website was compromised. Please change these passwords, turn on two-step sign-in and sign out of other sessions. If any belong to your own users, ask them to reset too.

5. Check Every Door That Faces the Internet

If someone is selling a way in, rotate passwords for remote access and admin panels first (VPN, remote desktop, SSH, control panels), review recent logins, and list what each server listens on:

sudo ss -tulnp

Anything bound to 0.0.0.0, [::] or * listens on every interface. The -u adds UDP, where WireGuard and OpenVPN listen by default. Whether the internet can actually reach a port depends on your firewall, so check from outside as well.

The Door It Fits

Dark web monitoring tells you a key is loose. Which door it fits, and whether you've changed the lock since, are questions only you can answer. In the Snowflake attacks, a key stolen in 2020 still fit in 2024.

Curious what's already out there for your domain? Run the free exposure check. It looks up a domain, email address or username in leaked credential records, with no account needed.