Responsible publication

Why we publish at all

When a threat actor claims to hold data from an Indian organisation, the people who most need to know are the defenders at that organisation, its customers, and the wider sector. Silence does not protect them; it only delays their response. So we publish that a claim was made, with the evidence we hold and an explicit statement of how far we have been able to verify it.

A claim is published as a claim

The distinction that matters most on this platform is between a claim was made and a breach occurred. Threat actors exaggerate, recycle old data, and fabricate. A listing on a leak site is evidence that someone made a claim — nothing more — until it is corroborated.

Every report carries a verification label and a confidence level, and both can change as we learn more. See how we verify for what each label means.

What we never publish

• Stolen data. We do not host, mirror, link to, or redistribute any breached dataset, database dump, or credential list — in whole or in part.
• Working routes to stolen data. No leak-site URLs, onion addresses, mirrors, torrent identifiers, or download instructions.
• Seller contact details. No handles, channels, wallet addresses, or negotiation routes that would help someone buy stolen data.
• Personal data of individuals. No names, contact details, identifiers, card or account numbers, or credentials belonging to people affected by an incident.
• Exploitation detail that helps an attacker more than a defender. We describe the class of weakness so defenders can act. We do not publish a recipe.

Screenshots and evidence

Screenshot evidence is central to showing that a claim exists, and it is also the easiest way to leak personal data by accident. So the original capture is treated as a chain-of-custody artefact and is never published. What appears on a public report is a separate, redacted derivative that a second reviewer has explicitly approved for publication.

Approval is the whole control. An unapproved image is not reachable from the public internet, and withdrawing approval removes it immediately. See source and evidence handling for the detail.

Naming organisations

We name an organisation when a claim specifically identifies it and the identification is supported by the evidence we hold. We do not name an organisation on the strength of a threat actor’s assertion alone where that assertion is vague, inconsistent, or contradicted by what we can observe.

Where an organisation has responded to us, we say so, and we record its position — including a denial. If you represent a named organisation, use the affected organisation route; those messages are prioritised.

Harm review before publication

Before a report is published, the reviewer — who is never its author — considers whether publishing it creates harm that outweighs its value to defenders: harm to identifiable individuals, harm from an unverified accusation, and harm from operational detail. Where the balance is wrong, the report is held or reduced in scope rather than published.

Getting it wrong

We will sometimes be wrong. When that happens we correct the record in place, keep the history visible, and say what changed. Serious errors are retracted rather than quietly edited. See corrections and retractions.

Security research

If you have found a vulnerability in ThreatBharat itself, please report it to security@threatbharat.com rather than testing against other users’ data. See acceptable use.