Signes qu'une base clients a été extraite

Ce qu'on peut voir

L'exfiltration laisse parfois une trace lourde (un `.sql` de 400 Mo), parfois presque rien (une requête, un HTTPS sortant). Chercher les traces est obligatoire. Conclure « zéro fuite » parce que le scan antivirus est vert, non. Le guide et la page métier s'appuient sur ce constat-là.

On travaille par faisceaux : fichier + log + timing. Un seul indice faible (un pic CPU) ne dit pas « base clients ». Un dump nommé `clients-final.sql` à la racine des uploads, si.

L'injection SQL est une voie classique d'extraction sans fichier déposé. Les signes côté contenu (admins nés, options) parlent d'écriture ; la lecture peut précéder.

Fichiers et dossiers qui parlent

Archives SQL, CSV, `.sql.gz`, dumps phpMyAdmin, copies de `wp_users` dans un thème, backups Updraft téléchargeables, dossiers `tmp` ou `old` publics. Dates de modification dans la fenêtre d'incident. Noms qui n'appartiennent pas à votre routine de sauvegarde.

Un dump n'est pas toujours l'exfiltration réussie : c'est parfois une étape locale. Traitez-le comme un accès aux données + un risque qu'il ait été téléchargé. Regardez les access.log sur cette URL.

Ne « testez » pas le dump en le rouvrant sur un ordi de famille. Isolez, hash, accès restreint. Pièce du constat.

• Fichiers dump / CSV hors routine.
• Codes 200 sur ces URL dans les logs.
• Copies dans les backups web publics.

Journaux SQL et applicatifs

Slow query, general log s'il était allumé, logs d'un WAF, plugins qui journalisent les exports. Des lectures de tables entières, des `INTO OUTFILE` si le moteur le permettait, des appels répétés à l'API REST clients. Vous n'avez pas à reconstruire l'attaque : vous datez et vous bornez les tables.

Beaucoup d'hébergements n'ont pas de general log. Notez-le comme limite. Demandez quand même l'access et l'error. Voir logs justice.

Un Adminer / phpMyAdmin public est à la fois une porte et un signe : qui s'y est connecté, depuis où. Autre chantier, même dossier.

Réseau et volume

Pic de bande sortante inexpliqué, connexions longues vers une IP unique, process PHP qui écrit un fichier puis le sert. Sur mutualisé, les graphes sont grossiers. Un indice, pas une preuve à lui seul.

Un CDN ou un backup distant légitime produit aussi des pics. Croisez le calendrier (sauvegarde 3 h vs pic 15 h un dimanche).

L'absence de graphe (offre sans stats) s'écrit dans le constat. On ne l'invente pas à la baisse.

Comptes et exports « légitimes »

Un employé créé la veille, un profil « shop manager » qui a le droit d'exporter, une clé REST WooCommerce inconnue : l'exfiltration peut passer pour du métier. Inventaire des capacités et des clés (révoquer) dans la même passe que les dumps.

Les crons d'export vers un FTP tiers que plus personne ne connaît. L'attaquant n'a qu'à relire le cron.

Search Console et analytics ne montrent pas une exfiltration SQL. Ils montrent parfois le cloaking. Ne les utilisez pas comme preuve d'absence de fuite.

Ce que l'absence de signe autorise

À écrire : « pas de dump trouvé, pas de log SQL, access sans GET massif sur des exports ». Pas : « aucune exfiltration ». Cette seconde phrase est celle qui se retourne. Le raisonnement de risque (notifier ou non) s'appuie sur l'accès, pas seulement sur le souvenir d'un fichier.

Si un admin étranger a eu la main assez longtemps, l'exfiltration est plausible même sans fichier. C'est inconfortable. C'est honnête. Constater avant de parler.

Les 72 h se décident sur le risque pour les personnes, pas sur la beauté des preuves. Un accès table users + clair se passe de dump.

Pièges d'interprétation

Prendre un backup Updraft légitime pour un dump pirate — ou l'inverse. Comparer les dates et l'emplacement (protégé vs public).

Croire qu'un rançongiciel « n'a pas eu le temps de copier ». Beaucoup copient avant de chiffrer. Absence de note de rançon ≠ absence de copie.

Effacer les dumps « pour que ce soit propre » avant hash et copie hors site. Vous détruisez le volume et la preuve. Isolez, ne jetez pas tout de suite.

Après un signe positif

Bornez les tables, estimez N lignes, lancez reset / sessions si comptes, préparez notification et information. Fermez l'entrée. Interdisez le listing des dossiers, PHP dans uploads, 777. Surveillez les nouvelles archives.

Si le dump a été public, considérez qu'il a été téléchargé. Les access.log donnent un plancher, pas un plafond (caches, bots).

Créer un espace pour le nettoyage ; joignez le chemin du dump et les extraits de logs, pas le dump entier par email.

• Chercher les signes, écrire les absences.
• Ne jamais convertir l'absence en « zéro fuite ».
• Signe + : volume, reset, horloge CNIL.