Base DAVID, Floride : 200 000 permis via un compte policier

Deux versions, deux corrections

La version officielle (un compte, des identifiants mal stockés) et celle des attaquants (une faille de réinitialisation, plusieurs comptes, une énumération massive) n'appellent pas les mêmes remèdes. Un identifiant volé sur un téléphone personnel se traite par la MFA et des règles sur les appareils. Une réinitialisation de mot de passe qui permet de prendre des comptes arbitraires est un défaut du produit qui touche chaque utilisateur. L'agence n'a confirmé ni le volume ni la méthode et renvoie à l'enquête en cours.

Ce type de système existe dans beaucoup de produits B2B : un back-office à forts privilèges où des comptes institutionnels (clients, partenaires, autorités, support) consultent des dossiers individuels.

Pourquoi les comptes institutionnels sont visés

Les comptes des partenaires (policiers, agents d'autres administrations, prestataires) sont souvent moins surveillés que ceux des employés : ils dépendent d'une autre organisation, avec ses propres règles d'appareils et de mots de passe. Ils donnent pourtant accès aux mêmes dossiers.

Faille 1 : des identifiants hors du périmètre maîtrisé

Identifiants enregistrés dans un fichier, un navigateur ou une application de notes sur un appareil personnel, sans MFA effective : un vol de l'appareil, un logiciel espion ou une sauvegarde cloud suffit à les récupérer.

Test : pour chaque compte capable de consulter des dossiers, la connexion depuis un appareil non géré est-elle possible ? La MFA est-elle exigée à chaque connexion ou seulement à la première ? Les sessions longues survivent-elles à un changement de mot de passe ?

Faille 2 : une réinitialisation de mot de passe insuffisamment vérifiée

Le mécanisme censé secourir l'authentification devient le chemin d'attaque principal. Les erreurs classiques : jeton de réinitialisation prévisible ou réutilisable, lien envoyé à une adresse modifiable dans la même requête, question secrète, en-tête Host utilisé pour construire le lien, réinitialisation qui désactive la MFA. Elles sont détaillées dans notre article sur les 7 erreurs de réinitialisation.

Test :

1. Demandez deux réinitialisations pour un compte de test : le premier lien est-il invalidé ? Le jeton expire-t-il en moins d'une heure ?
2. Interceptez la requête et ajoutez un second e-mail, ou modifiez l'en-tête Host : le lien part-il ailleurs ou pointe-t-il vers un autre domaine ?
3. Après réinitialisation, la MFA est-elle toujours exigée ? Les sessions existantes sont-elles coupées ? Une notification part-elle vers l'adresse connue ?

Faille 3 : des dossiers énumérables

Moissonner des fiches en itérant sur des identifiants suppose que des milliers de requêtes séquentielles n'ont déclenché aucune limite ni alerte.

Test : avec un compte de test, enchaînez quelques centaines de consultations sur des identifiants consécutifs. L'API ralentit-elle, bloque-t-elle, quelqu'un est-il prévenu ? Les identifiants sont-ils séquentiels ? Voir notre article sur l'énumération et le rate limiting.

Comment corriger

1. MFA résistante à l'hameçonnage sur tout accès à des données personnelles, sans exception pour les comptes « de confiance », qui sont précisément ceux qu'on cible.
2. Accès réservé aux appareils gérés pour les comptes à forts privilèges.
3. Réinitialisation traitée comme une surface d'attaque : jetons aléatoires à usage unique et courte durée, aucune désactivation de la MFA, notification systématique.
4. Plafonds de consultation par compte et alerte sur les consultations séquentielles.
5. Journaux conservés et protégés : quand un groupe revendique et que l'organisation minimise, seuls des journaux d'accès complets établissent le périmètre réel.

Un mode opératoire industrialisé

ShinyHunters apparaît dans plusieurs dossiers de 2026, comme l'envoi d'hameçonnages Trezor via Brevo. Le schéma est constant : un accès, une base, une demande de rançon, une publication en cas de refus. La question utile devient : combien de fiches un seul compte compromis peut-il extraire en une nuit, et qu'est-ce qui l'arrête ?

Un agent IA et la fuite DAVID : quels changements ?

Un agent IA branché sur un back-office de ce type (pour répondre aux agents, vérifier un dossier, préparer un rapport) cumule les trois failles : il détient un compte à privilèges, ses identifiants vivent dans une configuration, et il peut enchaîner les consultations sans fatigue. Une injection de prompt dans un document ou un message qu'il traite peut lui faire parcourir des dossiers par identifiant et en recopier le contenu. Ses consultations doivent être plafonnées, limitées au dossier de la demande et journalisées au nom de la personne qui l'utilise.

Pour vérifier combien de dossiers un agent manipulé peut extraire de votre back-office, le Red Team Agent Express teste ce scénario en cinq jours.