Compter les comptes compromis distincts dans les logs d'authentification
Le défi
Cette nuit, une adresse externe a mené une attaque par bourrage d'identifiants contre le point de connexion et, contrairement au scanner bruyant du début de nuit, celle-ci est entrée. Votre rapport d'incident n'a pas besoin de l'adresse de l'attaquant, il a besoin de l'étendue de la compromission. Déterminez quelle adresse externe a réellement réussi, puis comptez combien de comptes DISTINCTS elle a réussi à ouvrir. Lisez attentivement : un compte a été ouvert deux fois depuis cette adresse, donc le nombre de connexions réussies n'est pas le nombre de comptes, et un autre compte s'est arrêté à la demande de second facteur et n'a jamais été ouvert. Soumettez le nombre de comptes distincts.
Ce que tu vas apprendre
- Distinguer une tentative de spray infructueuse d'une campagne de credential stuffing réussie
- Filtrer une table SIEM en combinant des termes field:value
- Compter des entités distinctes plutôt que des lignes d'événements brutes
- Reconnaître qu'une connexion bloquée par le MFA n'est pas une compromission
- Communiquer l'étendue de la compromission comme le chiffre qui pilote la réponse à incident
Compétences testées
Prérequis
- Lecture de lignes de logs structurées
- Compréhension du MFA et du credential stuffing
Comment ça marche
Trouver l'attaquant est la partie facile d'une intrusion. Ce qui pilote la réponse, c'est le périmètre : combien de comptes sont réellement tombés. Chaque décision en aval, de la réinitialisation forcée des mots de passe à la notification de la violation, est dimensionnée par ce chiffre, et c'est un nombre de comptes, pas un nombre d'événements.
Deux adresses externes apparaissent pendant la nuit. 203.0.113.91 teste des noms d'utilisateur génériques comme admin, root et jenkins, et échoue à chaque fois. Elle est bruyante et inoffensive. 198.51.100.24 parcourt de vrais noms d'employés, échoue dix-neuf fois et réussit cinq fois, les succès étant mêlés aux échecs. Bruyant n'est pas synonyme de dangereux, et l'adresse la plus bruyante est celle qui n'a rien obtenu.
Filtrer sur src_ip:198.51.100.24 action:login result:success donne cinq lignes, mais seulement quatre noms distincts, car j.arnold s'est connecté deux fois. Un autre compte, p.novak, apparaît deux fois avec result:mfa_required : le mot de passe était correct, il figurait donc dans la même liste de fuite, mais le second facteur a bloqué la connexion. Ce compte a été attaqué, pas compromis. L'étendue réelle est de quatre, et les événements d'export qui suivent le confirment, puisqu'ils ne proviennent que de comptes réellement connectés.
Erreurs fréquentes
- Répondre 5. C'est le nombre d'événements de connexion réussis.
j.arnoldapparaît deux fois, donc le nombre de comptes distincts est inférieur de un. - Répondre 6. Cela compte
p.novak, dont le résultat estmfa_required. Le second facteur a bloqué la connexion, donc le compte n'a jamais été ouvert. - Enquêter sur 203.0.113.91. Elle génère le plus d'événements mais ne réussit jamais une seule fois. Le volume n'est pas l'impact.
- Compter les succès internes. Les lignes
10.12.4.xsont des connexions normales du personnel via le VPN du bureau, avant et après la fenêtre de l'incident. - Filtrer uniquement sur result:success. Cela mélange les connexions légitimes du bureau avec celles de l'attaquant : l'adresse source doit faire partie du filtre.
Comment s'en protéger
Le credential stuffing fonctionne parce que les mots de passe sont réutilisés, donc les contrôles qui comptent sont ceux qui rendent un mot de passe correct insuffisant.
- Exigez un second facteur pour chaque compte, et privilégiez des facteurs résistants au phishing. Dans cet incident, le MFA est la seule raison pour laquelle le chiffre est quatre et non cinq.
- Vérifiez les nouveaux mots de passe et les mots de passe existants par rapport aux corpus de fuites connues, et forcez une réinitialisation en cas de correspondance.
- Limitez le débit et retardez progressivement l'authentification par adresse source et par compte, afin que dix-neuf échecs depuis une adresse n'atteignent jamais une vingtième tentative.
- Alertez sur la forme de l'attaque : de nombreux noms d'utilisateur distincts depuis une seule adresse sur une courte fenêtre, en particulier en dehors des heures de bureau.
- Instrumentez ce qui se passe après une connexion, car l'export de
payroll_q3.xlsxquelques minutes après une connexion à 02:31 est un signal plus fort que la connexion elle-même. - Préparez à l'avance des requêtes de délimitation qui comptent des entités distinctes, afin que les équipes d'intervention n'aient pas à calculer l'étendue de la compromission à la main sous pression.