Contexte
Une attaque par force brute consiste à deviner un mot de passe en testant automatiquement de nombreuses combinaisons, ou en parcourant une liste de mots de passe courants jusqu'à trouver le bon. Le protocole RDP (Remote Desktop Protocol), très utilisé pour l'administration à distance des postes Windows, est une cible classique de ce type d'attaque lorsqu'il est exposé sans protection suffisante.
Dans le cadre du volet SOC (Security Operations Center) du projet Solaris, j'ai voulu vérifier concrètement notre capacité de détection : configurer le RDP sur une machine Windows cible, simuler une attaque par force brute depuis une machine Ubuntu, puis retrouver la trace de cette attaque dans Splunk — jusqu'à identifier l'adresse IP et le nom de la machine attaquante.
1. Préparer la cible : activer RDP sur Windows
Sur la machine Windows visée par le test :
- Ouvrir Paramètres → Système → Bureau à distance.
- Activer l'option Autoriser les connexions à distance à cet ordinateur.
2. Installer et configurer le Splunk Forwarder
Pour que Splunk puisse voir les tentatives de connexion, les journaux d'événements Windows (Event Viewer) doivent être collectés et envoyés vers le serveur Splunk via un forwarder.
Vérifier le statut du forwarder
sudo /opt/splunkforwarder/bin/splunk status
Pointer le forwarder vers le serveur Splunk
sudo /opt/splunkforwarder/bin/splunk add forward-server ip_serveur:9997 -auth user:mdp sudo /opt/splunkforwarder/bin/splunk set deploy-poll ip_serveur:8089 -auth user:mdp
Vérifier la connexion au serveur
sudo /opt/splunkforwarder/bin/splunk list forward-server
Puis redémarrer la machine cliente :
reboot
localhost:8000), il faut aussi créer l'index de collecte (Settings → Indexes → New Index) et ajouter la source dans Settings → Add Data → Forward.3. Simuler l'attaque depuis Ubuntu
Pour reproduire une attaque par force brute sur RDP, j'ai utilisé Hydra, un outil qui teste automatiquement une liste de mots de passe sur un service donné — ici depuis une machine attaquante Ubuntu (IP 192.168.1.152) vers la cible Windows (IP 192.168.1.153).
sudo apt install hydra
# hydra -l [utilisateur] -P [liste de mots de passe] rdp://[IP cible]
hydra -l admin -P /home/kevin/password-list.txt rdp://192.168.1.153
4. Retrouver l'attaque dans Splunk
Une fois l'attaque simulée, direction Splunk pour rechercher les événements d'échec d'authentification correspondants — EventCode 4625, le code Windows pour un échec de connexion :
index=* host="DESKTOP-E8EIAMF" source="WinEventLog:Security" EventCode=4625
En dépliant les résultats (Show all lines), Splunk remonte le détail de chaque tentative échouée — et notamment la provenance de la connexion : une station de travail Ubuntu à l'adresse 192.168.1.152, exactement la machine utilisée pour l'attaque.
5. Aller plus loin : détecter une persistance
Un deuxième cas pratique a consisté à simuler ce qu'un attaquant ferait après avoir obtenu un accès : créer un compte local avec des droits administrateur pour maintenir sa présence sur la machine.
net user pirate123 MaSuperPass123! /add net localgroup Administrateurs pirate123 /add
Côté Splunk, cette action se traduit par des événements de gestion de comptes qu'on peut rechercher ainsi :
index=* EventCode=4720 OR EventCode=4728 OR EventCode=4732
Les codes 4720 (création de compte), 4728 et 4732 (ajout à un groupe) permettent de repérer immédiatement la création d'un compte suspect et son ajout au groupe des administrateurs — un signal fort à intégrer dans les règles d'alerte du SOC.
Ce qu'il faut retenir
- Les journaux d'événements Windows Security sont une source de détection incontournable pour les tentatives de connexion RDP.
- Les EventCode 4625 (échec de connexion) et 4720/4728/4732 (gestion de comptes) sont des signaux clés à surveiller.
- Un simple exercice de simulation permet de valider concrètement la chaîne de détection : collecte → indexation → recherche → alerte.
- Cette validation a nourri les règles de corrélation mises en place pour le SOC du projet Solaris.