Utilisez ce playbook pour examiner les alertes par pulvérisation de mot de passe déclenchées par plusieurs échecs de connexion (trop d’échecs d’authentification à partir de plusieurs adresses IP pour le même utilisateur). Les étapes suivantes vous donnent une procédure pas à pas des actions, des tâches et des flux secondaires disponibles dans le playbook Brouillage possible de mot de passe.
Avant de commencer
Rôle requis :
sn_si.admin
flow_designer
Assurez-vous d’avoir installé le spoke Security Operations (sn_sec_spoke).
Procédure
Lorsque le playbook est déclenché et commence à s’exécuter, dans l’action 1, vous devez vérifier si les activités proviennent de l’adresse IP du client.
Identifiez les adresses IP effectuant l’attaque par pulvérisation de mot de passe. Par exemple, utilisez les TXID (ID de transaction) de l’alerte et comparez-les aux journaux F5.
Dans l’action 2, si les activités proviennent de l’adresse IP du client, effectuez les actions suivantes :
Dans l’action 3, vous devez lancer un examen post-incident de l’attaque possible par pulvérisation de mot de passe.
Dans l’action 4, le flux se termine.
Dans l’action 5, si les activités ne proviennent pas de l’adresse IP du client, déterminez l’adresse IP source de l’attaquant à partir des détails de l’alerte.
Dans l’action 6, vous devez valider la réputation IP à l’aide d’outils OSINT (Open-Source Intelligence) et le modèle de trafic de ces adresses IP au cours des sept derniers jours.
Figure 1. Playbook de pulvérisation de mot de passe possible
Dans l’action 7, vous devez identifier les noms d’utilisateur qui se sont connectés avec succès à l’aide de l’attaque Password Spray.
Dans l’action 8, vous devez identifier le nombre d’échecs de connexion et de modèles.
Dans l’action 9, vous devez identifier les indicateurs d’un vrai positif.
Vérifiez le trafic provenant des adresses IP sources au cours des 60 derniers jours. Aucun trafic historique ne peut être une indication d’un vrai positif.
Vérifiez les modèles de nom d’utilisateur présentant des échecs d’authentification et leur nombre. Plus le nombre est élevé, plus la probabilité qu’il s’agisse d’un vrai positif est élevée.
Le nom d’utilisateur ressemble à une base de dictionnaire (de A à Z) et peut avoir des noms d’administrateur communs tels que admin, sysadmin, root, entre autres
Le même nom d’utilisateur peut avoir des modèles différents dans l’attaque par pulvérisation, comme la même alerte peut avoir des échecs pour john.doe, johnd, jdoe, john_doe, jdoe7, etc., indiquant que les attaquants devinent le modèle de nom d’utilisateur en fonction des cas d’utilisation courants.
Notez l’agent utilisateur et les URI des journaux F5 à l’étape ci-dessus, et voyez si les IOC sont liés aux alertes Red Condor. S’ils correspondent, alors c’est un véritable événement positif.
Dans l’action 10, sur la base de l’enquête effectuée jusqu’à présent, vous devez vérifier s’il s’agit d’un cas d’attaque possible par pulvérisation de mot de passe ou non.
Dans l’action 11, s’il s’agit d’une attaque par pulvérisation de mot de passe, effectuez les actions suivantes :
Dans l’action 12, vous devez vous coordonner avec les équipes appropriées pour verrouiller tous les comptes nécessaires et enquêter sur les activités malveillantes.
Figure 2. Playbook de pulvérisation de mot de passe possible
Dans l’action 13, vous devez lancer un examen post-incident de l’attaque possible par pulvérisation de mot de passe.
Dans l’action 14, le flux se termine.
Dans l’action 15, vous devez vérifier s’il ne s’agit pas d’un cas d’attaque possible par pulvérisation de mot de passe.
Dans l’action 16, s’il ne s’agit pas d’une attaque par pulvérisation de mot de passe, effectuez les actions suivantes :
Dans l’action 17, vous devez documenter les résultats obtenus jusqu’à présent.
Dans l’action 18, vous devez initier un examen post-incident de l’attaque possible par pulvérisation de mot de passe.
Dans l’action 19, le flux se termine.
Dans l’action 20, vous devez consulter les pairs et le gestionnaire GIR pour obtenir des conseils.
Dans l’action 21, une tâche de réponse est créée pour terminer la revue post-incident avant de fermer la tâche.