Détecter le password spraying dans le System Log Okta
Détecter password spraying, force brute et credential stuffing sur Okta : échecs par IP et par utilisateur, événements ThreatInsight et le succès à rechercher.
TL;DR. Le password spraying, c'est beaucoup d'utilisateurs, peu de tentatives chacun, depuis la même source : des user.session.start ou user.authentication.verify en échec regroupés par client.ipAddress, touchant huit comptes ou plus en une heure avec environ trois tentatives au maximum par compte. La force brute, c'est l'inverse : beaucoup d'échecs sur un seul compte. Les deux ne comptent vraiment que s'ils sont suivis d'un succès depuis la même source : cherchez donc ce succès en premier. Les attaques distribuées via des proxys résidentiels échappent au regroupement par IP ; pivotez aussi sur l'ASN, le user agent et les événements ThreatInsight.
Trois attaques, trois formes
| Attaque | Forme dans le journal | ATT&CK |
|---|---|---|
| Password spraying | une source, beaucoup d'utilisateurs, 1 à 3 tentatives chacun | T1110.003 |
| Devinette de mot de passe (force brute) | beaucoup de tentatives sur un utilisateur | T1110.001 |
| Credential stuffing | couples identifiant/mot de passe connus, répartis sur de nombreuses sources, taux de réussite élevé sur les mots de passe réutilisés | T1110.004 |
Le spraying reste volontairement sous les seuils de verrouillage : une poignée de mots de passe courants par compte, sur des centaines de comptes. C'est pourquoi le verrouillage par utilisateur n'est pas une détection.
L'équipe Identity Threat Research d'Okta a signalé au printemps 2024 de vastes campagnes de credential stuffing acheminées via Tor et des proxys résidentiels, si bien que le trafic semblait provenir d'appareils d'utilisateurs ordinaires plutôt que de fournisseurs de VPS (Okta Security : bloquer les services d'anonymisation). Gardez-le en tête quand un spraying « vient » de centaines d'IP grand public.
Les événements
| eventType | À lire |
|---|---|
user.session.start avec outcome.result = FAILURE | outcome.reason (par exemple INVALID_CREDENTIALS), IP, ASN, user agent |
user.authentication.verify en FAILURE | idem |
user.session.start en SUCCESS depuis la même source | la compromission |
user.account.lock | verrouillages provoqués par les tentatives |
security.threat.detected | requête depuis une IP classée malveillante par ThreatInsight |
security.attack.start | ThreatInsight a détecté que l'organisation est attaquée |
security.breached_credential.detected | un identifiant associé à une fuite connue a été utilisé |
security.threat.detected et security.attack.start sont les deux requêtes que suggère Okta Security pour surveiller ces campagnes (source). Quand ThreatInsight est en mode « log and enforce », les requêtes d'IP jugées très menaçantes peuvent être bloquées avant l'authentification et ne jamais devenir des échecs user.session.start, ce qui change le sens de vos comptages.
Comment l'analyseur les détecte
| Règle | Regroupement | Seuil | Aggravation |
|---|---|---|---|
access.password_spray | IP cliente | ≥ 8 utilisateurs distincts en échec en 1 h, moyenne ≤ 3 échecs par utilisateur → élevée | un user.session.start réussi depuis cette IP dans l'heure → critique |
access.brute_force | utilisateur | ≥ 10 échecs en 15 min → moyenne | une connexion réussie dans les 30 min → élevée |
threat.threatinsight | IP cliente | tout événement ThreatInsight, ou debugData.threatSuspected = true → moyenne | — |
threat.breached_credential | — | tout security.breached_credential.detected → moyenne | — |
La condition sur la « moyenne de tentatives par utilisateur » est ce qui distingue un spraying d'un NAT bruyant. Une IP de sortie de bureau où beaucoup de gens se trompent de mot de passe le lundi matin produit de nombreux utilisateurs avec un échec chacun, mais aussi un flux régulier de succès pour ces mêmes utilisateurs. Regardez le taux de réussite avant de paniquer.
Traquer un spraying que les règles pourraient manquer
La règle par IP est précise mais facile à contourner avec un réseau de proxys. Complétez-la à la main :
- Regroupez les échecs par ASN plutôt que par IP (
securityContext.asNumber). Un ASN d'hébergeur avec des échecs sur 50 de vos utilisateurs, c'est un spraying même si chaque requête utilise une IP différente. - Regroupez par user agent. Les outils de spraying utilisent souvent une chaîne de user agent fixe, parfois datée, sur toutes leurs IP.
- Regardez les noms d'utilisateur ciblés. Les sprays parcourent des listes alphabétiques, incluent d'anciens salariés, ou suivent un modèle de nommage (
prenom.nom) deviné à partir de sources publiques. - Trouvez les succès. Pour chaque IP, ASN ou user agent présent dans les échecs, listez ses connexions réussies. Cette courte liste, c'est votre incident.
- Vérifiez ce qu'ont fait ensuite les comptes concernés : demandes push (tentative de fatigue ?), enrôlement de facteur, SSO.
Dans l'analyseur, l'onglet Entités liste les IP avec ASN, pays, nombre d'événements et nombre d'échecs : triez par échecs, puis cliquez sur Événements pour les principales sources.
Lire outcome.reason
Tous les échecs ne se valent pas, et c'est le champ de raison qui sépare un spraying d'un problème utilisateur. INVALID_CREDENTIALS sur de nombreux comptes depuis une même source, c'est le spraying lui-même. Des échecs qui aboutissent à un user.account.lock montrent que l'attaquant a dépassé votre politique de verrouillage : utile pour le périmètre (quels comptes débloquer), et signe qu'il n'a pas été prudent. Une série d'échecs pour un utilisateur depuis son réseau habituel, suivie d'un succès depuis ce même réseau, c'est quelqu'un qui a oublié un changement de mot de passe, pas une attaque. Lisez toujours la raison avec la source.
Si une connexion a réussi
Un mot de passe correct sur un compte qui exige la MFA signifie que l'attaquant a maintenant besoin du second facteur : c'est exactement le point de départ d'une fatigue MFA ou d'une réinitialisation par le helpdesk. Agissez avant qu'il ne l'obtienne :
- Réinitialisez le mot de passe et supprimez les sessions de chaque compte ayant un succès depuis la source attaquante.
- Vérifiez pour chacun les push, les enrôlements de facteurs et le SSO après le succès.
- Bloquez la source avec une zone réseau de blocage ; bloquez les anonymiseurs avec une zone dynamique enrichie.
- Prévenez les utilisateurs concernés : leur mot de passe est connu, et il est peut-être réutilisé ailleurs.
Prévention
- ThreatInsight en mode « Log and enforce security based on threat level » plutôt qu'en journalisation seule (Okta Help Center).
- Des zones dynamiques enrichies pour bloquer anonymiseurs, Tor et proxys à la connexion, un contrôle recommandé par Okta Security pour ces campagnes (source).
- Des authentificateurs sans mot de passe et résistants au phishing : il n'y a plus de mot de passe à « sprayer ».
- La protection contre les mots de passe divulgués là où elle est disponible, et la sensibilisation des utilisateurs à la réutilisation.