Lundi 9h, quatre alertes sont ouvertes. Laquelle traitez-vous EN PREMIER ?
Réponse courte
Triez par impact et accessibilité : un dumping d'identifiants (signature mimikatz) sur un contrôleur de domaine est un événement touchant les joyaux de la couronne, pouvant mener à la compromission complète du domaine ; traitez-le en premier. Le scan de ports externe a déjà été bloqué par l'IDS, l'extension de navigateur non approuvée est de faible gravité, et un certificat TLS expiré sur une machine de test interne est informatif. La compétence SOC clé est de prioriser par rayon d'impact et probabilité d'escalade, pas par l'ancienneté ni le « bruit » de l'alerte.
Le tri est le cœur quotidien du travail en SOC, et cette question sépare les analystes qui réagissent au volume ou à la fraîcheur des alertes de ceux qui raisonnent en termes d'impact et de probabilité. Quatre alertes sont ouvertes ; une seule est un chemin potentiel vers la compromission totale.
Pourquoi l'alerte sur le contrôleur de domaine l'emporte
Un outil de dumping d'identifiants (signature mimikatz) s'exécutant sur un contrôleur de domaine frôle le pire des cas. Le DC détient les clés du royaume — vider LSASS ou la base NTDS.dit peut livrer tous les identifiants du domaine, y compris l'Admin de domaine et le hash krbtgt (permettant les Golden Tickets). C'est une activité de post-exploitation active sur un actif joyau de la couronne, avec un chemin direct vers un contrôle à l'échelle du domaine. Fort impact, forte probabilité d'escalade, en cours maintenant : elle passe en premier.
Pourquoi les autres attendent
- Scan de ports bloqué — l'IDS l'a déjà rejeté. Une reconnaissance empêchée est de faible urgence ; il n'y a pas de point d'ancrage actif à poursuivre.
- Extension de navigateur non approuvée — un problème de politique/hygiène, de faible gravité. À traiter, mais ce n'est pas une intrusion active sur une infrastructure critique.
- Certificat TLS expiré sur une machine de test interne — informatif. Aucune atteinte à la confidentialité ou à l'intégrité, aucun attaquant, et c'est un système hors production. C'est la priorité la plus basse des quatre.
Le principe de priorisation
Classez par rayon d'impact (combien de dégâts si c'est réel) et probabilité/stade (exploitation active ou bruit déjà atténué ?). L'alerte DC est haute sur les deux axes ; les autres sont basses sur l'un ou les deux. Notamment, vous ne priorisez pas selon l'alerte la plus ancienne, la plus bruyante ou la plus facile à clore — c'est ainsi que de vrais incidents se retrouvent enterrés sous des tâches subalternes.
Ce que le recruteur évalue
Il veut voir un tri structuré : identifier l'actif joyau de la couronne, reconnaître la post-exploitation active, et expliquer pourquoi les trois autres peuvent attendre. Un signal bonus est de nommer les prochaines actions sur le DC — isoler, capturer la mémoire, forcer la réinitialisation des identifiants à l'échelle de l'entreprise, et vérifier une compromission de krbtgt — ce qui montre que vous comprenez les enjeux, pas seulement le classement.
Questions de suivi probables
- Pourquoi un contrôleur de domaine change-t-il le calcul de gravité par rapport à la même alerte sur un poste de travail ?
- Quelles actions immédiates suivent une fois le dumping d'identifiants confirmé sur le DC ?
- Comment justifieriez-vous la dépriorisation des trois autres à un manager demandant pourquoi elles sont encore ouvertes ?