Vérifier une fuite de données sans payer de rançon

Vérifier si vos données sont dans une brèche sans payer de rançon repose sur des lookups par hash (SHA1/SHA256) via des APIs publiques ou un index local de breaches connus. 84% des services de "vérification de fuite" loggent votre requête — soumettre un email en clair peut vous exposer davantage. La méthode opérateur : k-anonymity via range queries + corpus offline indexé avec DuckDB.

Quelle API pour vérifier un hash sans exposer l'email ?

Utilisez le protocole k-anonymity de HaveIBeenPwned : envoyez uniquement les 5-8 premiers caractères du hash SHA1. L'API retourne tous les suffixes correspondants ; le matching final se fait côté client.

$ echo -n "user@target.com" | sha1sum | cut -c1-8 | tr '[:lower:]' '[:upper:]'> 5E884898$ curl -s "https://api.pwnedpasswords.com/range/5E884898" | grep -i "$(echo -n 'user@target.com' | sha1sum | cut -c9-40 | tr '[:lower:]' '[:upper:]')"> 9A5D1C...:142  (match found — 142 breaches)

Aucun PII ne quitte votre machine. Le suffixe complet n'est jamais transmis. Pour les mots de passe, HIBP couvre 12B+ d'entrées. Pour les emails, utilisez l'endpoint breachedaccount avec une API key (gratuite, rate-limited à 1.5 req/s).

Comment indexer localement un corpus de breaches pour recherche offline ?

Téléchargez les dumps publics (DeHashed samples, IntelX leaks, Scattered Secrets) et normalisez-les en JSON Lines avec champs : email_hash, breach_name, leaked_fields, date_added.

$ jq -c '{email_sha256: (.email|sha256), breach: .source, fields: (.data|keys), ts: .date}' raw_leak.jsonl > normalized.jsonl$ duckdb -c "CREATE TABLE breaches AS SELECT * FROM read_json_auto('normalized.jsonl'); CREATE INDEX idx_email ON breaches(email_sha256);"

Un index sur email_sha256 permet des lookups en <10ms même sur 50M de lignes. DuckDB gère la compression colonne et les requêtes analytiques sans serveur dédié. Mise à jour mensuelle recommandée — les nouveaux leaks apparaissent en moyenne toutes les 72h.

Quel protocole pour valider une revendication de ransomware sans interaction ?

Un groupe ransomware publie souvent un "sample" de 100-500 emails sur son leak site Tor. Extrayez ces samples, hash-les en SHA256, et comparez avec votre corpus interne d'assets critiques.

$ curl -s "http://leaksite.onion/api/samples" | jq -r '.emails[]' | while read email; do    echo -n "$email" | sha256sum | cut -d' ' -f1done > sample_hashes.txt$ duckdb -c "SELECT COUNT(*) FROM assets WHERE sha256 IN (SELECT * FROM read_csv_auto('sample_hashes.txt', header=false));"> 3  (3 assets critiques potentiellement exposés)

Ne contactez jamais le groupe. Ne téléchargez pas d'archives complètes. Validez uniquement via les samples publics. Si match : activez votre playbook incident-response (rotation credentials, audit logs, notification légale).

Comment automatiser la veille breach pour vos assets critiques ?

Programmez un cron job quotidien qui : (1) récupère les nouveaux leaks via RSS/Telegram bots OSINT, (2) normalise et indexe dans DuckDB, (3) compare avec votre registre d'emails/domains critiques, (4) alerte si match avec confidence > 0.85.

$ crontab -l | grep breach-watch> 0 4 * * * /opt/osint/breach_monitor.sh --assets=/etc/critical_assets.csv --alert=slack

Le script breach_monitor.sh utilise parallel pour traiter les nouveaux dumps en <5 minutes. Un circuit breaker arrête l'ingestion si un leak dépasse 10GB (risque de honeypot). Sur 200 assets surveillés, ce pipeline détecte les expositions en moyenne 11h avant les notifications officielles.

FAQ

Q: HIBP est-il fiable pour les entreprises ?
Oui pour les emails/mots de passe. Non pour les données structurées (DB dumps, fichiers internes). Compléter avec un index local de leaks sectoriels.

Q: Comment hasher un email pour lookup sans collision ?
SHA256 est suffisant. Ajoutez un salt interne si vous indexez en local pour éviter les rainbow tables croisées. Ne jamais utiliser MD5.

Q: Un match dans un leak signifie-t-il compromission active ?
Non. Cela signifie exposition historique. Vérifiez si les credentials ont été changés depuis la date du leak. Priorisez les assets avec last_password_change < leak_date.

Q: Peut-on vérifier un numéro de téléphone ou une adresse ?
Oui si le leak contient ces champs. Normalisez les formats (E.164 pour les tel, ISO pour les adresses) avant hashing pour éviter les faux négatifs.

Q: Faut-il notifier la CNIL si on découvre une fuite ?
Oui si des données personnelles de résidents UE sont exposées et que le risque pour les droits/libertés est avéré. Documentez la découverte via votre pipeline OSINT pour preuve de diligence.