Decoding the Dark Web: what exists beyond the surface

What is actually being sold, and what it means for you

The phrase covers a great deal of loose reporting, so it is worth being precise about what matters to a defender. The criminal marketplaces that affect Indian organisations most directly trade in three things: access, credentials and data.

Access means a foothold in an organisation's estate, sold by one group and used by another. This is why the gap between intrusion and impact is frequently months: the party that got in is not the party that will encrypt you, and the handover takes time. It is also why detection during the quiet period is worth so much more than detection during the loud one.

Credentials means username and password pairs, harvested by infostealer malware from endpoints rather than from breached databases. This distinction matters enormously. Credentials from a stealer log are current, they come with session cookies that bypass multi factor authentication, and they belong to a machine that may still be infected.

Data means the contents of a breach, sold or leaked. For most organisations the relevant risk here is not their own data appearing, but their employees' and customers' credentials from elsewhere being reused against them.

Why credential stuffing works so well against Indian estates

The mechanics are unglamorous. People reuse passwords. Attackers take a corpus of known pairs and try them at scale against login endpoints, at a rate low enough to avoid tripping lockouts and from enough addresses to avoid simple blocking.

Two things make this more effective than most defenders assume. First, session cookies stolen by infostealers sidestep the multi factor control that organisations rely on as their answer to this whole class of attack. A valid session does not need a second factor. Second, the endpoints being attacked are often not the main application: legacy interfaces, mobile APIs and integration endpoints frequently sit behind weaker controls than the front door.

Under the CERT-In Directions, a credential stuffing campaign against your login endpoint is a reportable incident. Most security teams treat it as noise, because from inside a SOC it looks like noise. That is a compliance failure sitting quietly in an alert queue.

What actually reduces this exposure

• Phishing resistant multi factor authentication, which defeats the credential replay but not the stolen session
• Session binding and short session lifetimes, which is what addresses the stolen cookie
• Credential screening against known breach corpora at the point of password setting
• Rate limiting and anomaly detection on every authentication endpoint, not only the primary one
• Monitoring for your own domains in stealer logs, and treating a hit as an infected endpoint rather than a password reset
• An inventory of every authentication endpoint you expose, which most organisations do not have

On dark web monitoring services

A large market exists for telling you that your data has appeared somewhere. Some of it is useful and a good deal of it is not, so it is worth knowing what distinguishes them.

The useful question a monitoring service answers is not has our data leaked, which is nearly always yes for any organisation of size and is not actionable. It is which specific credential, belonging to which specific account, appeared when, and is that account still active.

The action that follows a stealer log hit is not a password reset. It is treating the endpoint as compromised, because the malware that took the password also took everything else on that machine and may still be running. Services that report the credential without prompting that response encourage exactly the wrong remediation.

Be sceptical of volume metrics. A dashboard showing thousands of exposed records is designed to renew a contract. A report naming three active accounts with current credentials is worth acting on.

What to do when your data does appear

The first decision is what kind of exposure it is, because the responses are entirely different.

Credentials from an infostealer log mean an endpoint was compromised. The action is to treat that machine as compromised and investigate it, not to reset the password and move on. The malware that took the credential took everything else on the device and may still be running.

Credentials from a third party breach mean password reuse is your exposure. The action is credential screening at the point of password setting and phishing resistant multi factor authentication, not a mass reset that users will work around.

Access being advertised for sale means somebody is already in. That is an incident, with the six hour CERT-In clock running from the moment you know, and it warrants immediate investigation rather than monitoring.

Your own data appearing in a leak is a breach with notification obligations under the DPDP Act, separate from the CERT-In duty and triggered differently.

Where this fits in a realistic security programme

Monitoring is a detection control, not a preventive one, and it belongs after the basics rather than before them. An organisation without phishing resistant authentication, without an asset inventory and without tested backups should spend the money there first.

Where it earns its place is as an early indicator for organisations that already have those. A stealer log hit naming an active employee account is one of the few signals that reliably precedes an intrusion rather than following it.

Set the response before you buy the service. A feed with no owner and no defined action produces alerts that accumulate, which is worse than no feed because it comes with the impression of coverage.