Repérer le password spraying et le credential stuffing dans vos logs

Le password spraying et le credential stuffing se traduisent tous deux par un tas de connexions échouées, mais la forme de ce tas diffère, et la parade aussi. Si votre seule alerte est « cinq échecs sur un même compte », vous passerez à côté des deux.

Trois attaques, trois profils

Le Credential Stuffing Prevention Cheat Sheet de l'OWASP les distingue ainsi :

L'OWASP indique que, dans bien des cas, les défenses sont les mêmes et qu'elles fonctionnent aussi contre le brute force.

Que chercher dans les logs

La stratégie de détection de MITRE pour le password spraying repose sur un volume élevé d'échecs d'authentification avec un seul mot de passe, ou un petit ensemble, sur de nombreux comptes utilisateurs dans une fenêtre de temps donnée. Pour le credential stuffing, il s'agit de multiples échecs avec des paires identifiant/mot de passe distinctes depuis une même adresse IP ou une même session sur une courte période.

Les attaquants s'adaptent aux contre-mesures les plus évidentes :

• Spraying ralenti. MITRE décrit un outillage d'APT28 qui effectuait environ quatre tentatives par heure et par compte ciblé, pendant des jours ou des semaines. L'activité de Quad7 se limitait à une seule tentative de connexion sur 24 heures, ce qui échappait aux seuils de détection du brute force. Des compteurs par compte ne détecteront pas cela.
• Spraying distribué. MITRE note aussi qu'APT28 a utilisé un cluster Kubernetes pour mener des sprays distribués à grande échelle. Un simple décompte par IP source passera à côté, puisqu'aucune adresse ne cumule beaucoup d'échecs. Comptez aussi les comptes distincts en échec par fenêtre de temps, toutes sources confondues, et ventilez ces mêmes données par ASN et par user agent.
• Protocoles plus discrets. Les attaquants peuvent recourir à des tentatives LDAP et Kerberos, moins susceptibles de déclencher des événements très visibles comme l'événement Windows « échec d'ouverture de session » d'ID 4625, couramment généré par des connexions SMB échouées. Collectez les échecs LDAP et Kerberos en plus du 4625.

Les attaquants visent en général les services d'administration sur des ports courants : SSH (22/TCP), RDP (3389/TCP), SMB (445/TCP), LDAP (389/TCP), Kerberos (88/TCP) et les interfaces d'administration web sur les ports 80 et 443. Ils ciblent aussi le SSO, les applications cloud en authentification fédérée et les messageries exposées sur Internet comme Office 365 et OWA.

Microsoft 365 : bien utiliser le smart lockout

Le smart lockout de Microsoft Entra est toujours actif. Par défaut, il verrouille un compte après 10 tentatives échouées dans les tenants Azure Public, ou trois dans les tenants Azure US Government. Le premier verrouillage dure une minute, puis s'allonge lors des échecs suivants. Microsoft ne communique pas le rythme de cette augmentation.

• Il mémorise les hashes des trois derniers mots de passe erronés : répéter le même mauvais mot de passe n'incrémente donc pas le compteur. Cela évite qu'une faute de frappe répétée verrouille l'utilisateur. En revanche, cela n'apporte presque rien face à un spray, où chaque compte ne voit le mot de passe qu'une seule fois.
• Les emplacements familiers et inconnus ont des compteurs de verrouillage distincts : un attaquant venant d'un nouvel emplacement peut être verrouillé pendant que l'utilisateur légitime continue à travailler.
• Les valeurs personnalisées nécessitent Microsoft Entra ID P1 ou supérieur. Connectez-vous au centre d'administration Microsoft Entra avec au moins le rôle Authentication Policy Administrator, puis allez dans Entra ID > Authentication methods > Password protection. Vous y définissez le Lockout threshold et le Lockout duration en secondes (60 par défaut).
• Entra bloque aussi par défaut certaines connexions sur la base de signaux de trafic IP et de comportement, et renvoie AADSTS50053 - IdsLocked, que le mot de passe ait été valide ou non. Considérez les comptes qui affichent ce code comme ciblés, mais n'y voyez pas la preuve que le mot de passe était faux ou correct.

Le smart lockout ne garantit pas qu'un utilisateur légitime ne sera jamais verrouillé. MITRE rappelle l'autre face du problème : une politique trop stricte peut provoquer un déni de service, avec tous les comptes visés par l'attaque verrouillés.

Environnements hybrides

Avec la pass-through authentication, le seuil Entra doit être inférieur à celui d'AD DS en local, et ce dernier doit être au moins deux à trois fois plus élevé. La durée de verrouillage Entra doit être supérieure à celle d'AD DS. L'exemple de Microsoft : un seuil de 10 contre 20, et 120 secondes contre 60. La durée Entra se règle en secondes et celle d'AD DS en minutes, vérifiez donc les unités.

Le suivi des hashes n'est pas disponible avec la pass-through authentication. Pour lire vos valeurs AD DS, ouvrez la Gestion des stratégies de groupe, modifiez la stratégie qui contient vos paramètres de verrouillage, puis parcourez Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.

Votre propre page de connexion et vos services exposés

Le verrouillage est un contrôle par compte. Selon notre lecture, une campagne de stuffing qui essaie chaque compte une ou deux fois n'atteindra souvent jamais le seuil : ne la considérez donc pas comme votre défense principale. MITRE avertit que le stuffing peut provoquer de nombreux échecs et verrouillages, mais cela dépend de votre politique. Ses mesures d'atténuation, communes aux deux techniques, ajoutent :

• L'authentification multifacteur (MFA), activée sur les services exposés sur Internet partout où c'est possible.
• Des politiques d'accès conditionnel qui bloquent les connexions depuis des appareils non conformes ou depuis l'extérieur des plages d'IP définies de l'organisation.
• Le blocage des requêtes à risque, comme celles issues de services d'anonymisation ou de proxys.
• Des politiques de mots de passe fondées sur les recommandations du NIST.
• Pour le stuffing, la réinitialisation proactive des comptes dont on sait qu'ils figurent dans des identifiants compromis, soit immédiatement, soit après détection de tentatives de brute force.

Pour une application développée en interne, l'Authentication Cheat Sheet de l'OWASP contient des sections sur la protection contre les attaques automatisées, les CAPTCHA, ainsi que la journalisation et la supervision.

Par où commencer

1. Listez toutes les connexions accessibles depuis Internet : Microsoft 365 ou OWA, VPN, RDP, SSH, SSO et vos propres formulaires web. Fermez tout port d'administration qui n'a pas besoin d'être ouvert.
2. Vérifiez le seuil et la durée du smart lockout sous Entra ID > Authentication methods > Password protection. Avec la pass-through authentication, comparez-les à votre politique de verrouillage AD DS en appliquant les règles ci-dessus.
3. Construisez deux requêtes sur vos logs de connexion. La première compte les comptes distincts en échec de connexion par IP source et par heure. La seconde ignore la source : elle compte les comptes distincts en échec par fenêtre de temps, tous azimuts, puis ventile par ASN et par user agent. Alertez sur les deux, et gardez AADSTS50053 comme vue séparée.
4. Activez la MFA sur tous les services exposés sur Internet, puis ajoutez des règles d'accès conditionnel pour les appareils non gérés et les services d'anonymisation.
5. Comparez les comptes de vos collaborateurs avec les fuites connues, par exemple avec notre vérification de mots de passe compromis, et réinitialisez ceux qui correspondent. Si vous manquez de personnel pour surveiller les logs au quotidien, la supervision managée comble ce manque.