Détecter les incidents types : force brute, compte administrateur, PowerShell

Détecter un incident avec Wazuh, c'est reconnaître dans les alertes les symptômes d'une attaque connue (une rafale d'échecs de connexion, un compte ajouté à un groupe d'administration, un script PowerShell masqué), puis les qualifier : vraie attaque, fausse alerte ou action légitime mais inhabituelle. Ce chapitre décrit, pour les incidents les plus courants dans une PME, les traces qu'ils laissent dans les journaux, les règles de Wazuh qui se déclenchent, les règles personnalisées qui complètent la détection, et ce qu'il faut vérifier avant de décider. Les attaques sont décrites par leurs traces, jamais par les moyens de les mener.

De l'alerte à la décision

Face à une alerte, la même démarche à chaque fois :

1. Lire : quelle règle, quel niveau, quelle machine (agent.name), quel compte, quelle adresse source, à quelle heure ?
2. Remettre en contexte : que s'est-il passé juste avant et juste après, sur la même machine, avec le même compte, depuis la même adresse ? Une recherche sur une heure autour de l'alerte (chapitre 10).
3. Qualifier l'alerte :

4. Décider : clore l'alerte avec une justification ; ou ouvrir un incident et déclencher la réponse à incident (confinement, éradication, retour à la normale) ; ou escalader à quelqu'un de plus expérimenté.
5. Tracer : la décision, ses raisons et les vérifications faites vont dans le ticket. Un faux positif récurrent devient une exception documentée ou une correction de la cause.

Force brute sur SSH

Le principe. L'attaquant essaie des mots de passe en série sur un compte, ou des comptes courants (root, admin, deploy) avec des mots de passe courants, jusqu'à en trouver un qui marche.

Les traces. Sur srv-web, dans journald, des dizaines de lignes en quelques minutes, depuis la même adresse :

Nov  3 02:58:41 srv-web sshd-session[3101]: Invalid user admin from 192.168.10.71 port 40112
Nov  3 02:58:42 srv-web sshd-session[3101]: Failed password for invalid user admin from 192.168.10.71 port 40112 ssh2
Nov  3 02:58:46 srv-web sshd-session[3102]: Failed password for root from 192.168.10.71 port 40114 ssh2
...
Nov  3 03:00:50 srv-web sshd-session[3139]: Accepted password for deploy from 192.168.10.71 port 40256 ssh2

Les alertes de Wazuh.

La règle 40112 est celle qui compte : des échecs en rafale, c'est une tentative ; un succès juste après, depuis la même adresse, c'est probablement une réussite. La tentative relève de la surveillance, la réussite d'un incident.

Vérifier. L'adresse source est-elle connue (le poste .71 est celui d'un salarié du VLAN 10, il n'a aucune raison de faire du SSH vers un serveur de la DMZ) ? Le compte qui a réussi est-il légitime, et cette connexion était-elle prévue ? Qu'a fait la session ensuite (commandes sudo, fichiers modifiés, alertes FIM) ?

Réagir. Si la réussite est confirmée : couper la session et désactiver le compte, isoler srv-web, examiner le poste source, qui est lui-même probablement compromis. Pour prévenir : SSH par clé uniquement, connexion limitée au VLAN d'administration, et la règle de niveau 10 sur root du chapitre 7.

Force brute sur l'annuaire

Les traces. Sur le contrôleur de domaine, des 4625 en série sur un même compte, depuis la même adresse, avec le code d'erreur 0xC000006A (mauvais mot de passe) ; puis, si la stratégie de verrouillage est en place, un 4740 (compte verrouillé) ; parfois un 4624 final.

Pour repérer un succès après une rafale, l'équivalent Windows de la règle 40112, une règle personnalisée rapproche une ouverture de session réussie (60106) d'une alerte d'échecs multiples venue de la même adresse :

<group name="sorbier,windows,">
  <rule id="100300" level="12" timeframe="300">
    <if_sid>60106, 92651, 92652, 92653, 92657</if_sid>
    <if_matched_sid>60204</if_matched_sid>
    <same_field>win.eventdata.ipAddress</same_field>
    <description>Sorbier : ouverture de session réussie après une rafale d'échecs depuis la même adresse</description>
    <mitre>
      <id>T1110</id>
      <id>T1078</id>
    </mitre>
  </rule>
</group>

<if_sid> désigne l'événement qui déclenche (une connexion réussie), <if_matched_sid> celui qui doit s'être produit dans les 300 secondes précédentes (l'alerte d'échecs multiples), et <same_field> exige la même adresse source dans les deux.

Pourquoi cinq parents et pas seulement 60106 ? Parce qu'une règle n'est évaluée que si aucune de ses « sœurs » plus prioritaires n'a déjà pris l'événement. Wazuh fournit sous 60106 une règle de niveau 0, 92651 « Successful Remote Logon », qui intercepte toute connexion réussie venue d'une adresse IPv4 distante ; les règles de niveau 0 sont évaluées en premier. Sous elle, 92652 (authentification NTLM, niveau 6) et 92653 (bureau à distance, niveau 3) prennent le relais, et 92657 est l'enfant de 92652 quand le nom du poste client est renseigné. Une règle accrochée au seul 60106 ne serait donc jamais évaluée pour une connexion réseau ou RDP réussie, c'est-à-dire exactement le cas visé. D'où la liste de parents.

Pulvérisation de mots de passe

Le principe. La pulvérisation (password spraying) inverse la force brute : un mot de passe courant (Sorbier2026!, Bienvenue1) essayé sur beaucoup de comptes, un ou deux essais chacun. Aucun compte n'atteint le seuil de verrouillage, et les règles qui comptent les échecs par compte ne voient rien.

Les traces. Des 4625 depuis une même adresse, chacun sur un compte différent, étalés sur quelques minutes. Une règle personnalisée compte exactement ce motif :

<group name="sorbier,windows,">
  <rule id="100310" level="12" frequency="10" timeframe="300">
    <if_sid>60122, 60204</if_sid>
    <if_matched_sid>60122</if_matched_sid>
    <same_field>win.eventdata.ipAddress</same_field>
    <different_field>win.eventdata.targetUserName</different_field>
    <description>Sorbier : échecs de connexion sur de nombreux comptes depuis la même adresse (pulvérisation)</description>
    <mitre>
      <id>T1110.003</id>
    </mitre>
    <group>authentication_failures,</group>
  </rule>
</group>

Dix échecs en cinq minutes, depuis la même adresse, sur des comptes différents : niveau 12. La règle compte les événements 60122, mais elle est aussi accrochée à 60204 : dès que huit échecs venus de la même adresse sont réunis en quatre minutes, la règle fournie 60204, évaluée avant la tienne, peut classer l'événement à la place de 60122 ; une règle accrochée au seul 60122 risquerait alors de ne plus être évaluée au moment précis où la pulvérisation devient visible. Une pulvérisation qui passe par Kerberos produit, sur le contrôleur, des 4771 (échec de pré-authentification) plutôt que des 4625 ; une seconde règle sur le même modèle couvre ce cas.

Réagir. Identifier les comptes visés, vérifier si l'un d'eux a ensuite réussi à se connecter (un 4624 depuis la même adresse), forcer le changement de mot de passe des comptes concernés, et revoir la politique de mots de passe : un mot de passe comme Sorbier2026! ne devrait pas pouvoir exister.

Un nouveau compte d'administration

Le principe. Une fois entré, l'attaquant veut rester et monter en droits : il crée un compte à lui, ou en réutilise un, et l'ajoute à un groupe d'administration.

Les traces et les alertes.

Wazuh reconnaît les groupes sensibles par leur SID, qui ne change pas avec la langue du système : S-1-5-32-544 pour Administrateurs, un SID qui se termine par -512 pour Admins du domaine. Un domaine en français est donc couvert comme un domaine en anglais.

L'enchaînement « compte créé, puis ajouté à un groupe d'administration dans l'heure » est caractéristique. Une règle le signale :

<group name="sorbier,windows,">
  <rule id="100320" level="14" timeframe="3600">
    <if_sid>60154,60159</if_sid>
    <if_matched_sid>60109</if_matched_sid>
    <description>Sorbier : compte créé puis groupe d'administration modifié dans l'heure</description>
    <mitre>
      <id>T1136.002</id>
      <id>T1098.007</id>
    </mitre>
  </rule>
</group>

Elle ne vérifie pas qu'il s'agit du même compte (le 4720 et le 4728 ne rangent pas le compte dans le même champ) : c'est à l'analyste de le constater en ouvrant les deux alertes. Avec la règle 100110 du chapitre 7, qui monte au niveau 14 toute modification de ces groupes la nuit, les cas graves sont couverts.

Vérifier. Qui a fait la modification (le champ subjectUserName de l'événement) ? Un ticket de changement existe-t-il ? Le compte ajouté est-il nominatif, connu, et doit-il être administrateur ? Un compte de service qui ajoute quelqu'un à Admins du domaine n'a aucune raison légitime de le faire : son mot de passe est probablement volé.

Réagir. Retirer le compte du groupe, le désactiver, réinitialiser le mot de passe du compte qui a fait la modification, et chercher ce que le nouveau compte a fait depuis sa création (connexions 4624 avec son nom). La protection de l'annuaire (comptes à privilèges, modèle en tiers) est traitée dans le cours Sécurité de l'Active Directory, qui liste aussi les événements à surveiller.

Un PowerShell suspect

Le principe. PowerShell est l'outil d'administration de Windows, donc aussi l'outil préféré des attaquants : il est présent partout, signé par Microsoft, et peut télécharger et exécuter du code en mémoire. Les attaquants masquent leurs commandes, en particulier en les encodant en Base64 (paramètre -EncodedCommand et ses abréviations), pour qu'un antivirus ou un administrateur ne les reconnaisse pas.

Les traces. Elles n'existent que si les sources du chapitre 5 sont actives :

• Sysmon, événement 1 : powershell.exe lancé avec une longue chaîne encodée sur sa ligne de commande, et surtout son processus parent : PowerShell lancé par WINWORD.EXE ou OUTLOOK.EXE, c'est presque toujours une pièce jointe piégée ;
• PowerShell/Operational, événement 4104 : le code réellement exécuté, décodé, qui contient par exemple FromBase64String ou le téléchargement d'un contenu distant.

Les règles fournies ne couvrent pas tous les parents suspects. Celle-ci, accrochée à la création de processus de Sysmon (règle 61603, niveau 0), alerte quand une application Office lance un interpréteur de commandes :

<group name="sorbier,sysmon,">
  <rule id="100330" level="12">
    <if_sid>61603, 92021, 92028</if_sid>
    <field name="win.eventdata.parentImage" type="pcre2">(?i)\\(winword|excel|powerpnt|outlook)\.exe$</field>
    <field name="win.eventdata.image" type="pcre2">(?i)\\(powershell|pwsh|cmd|wscript|cscript|mshta)\.exe$</field>
    <description>Sorbier : une application Office a lancé un interpréteur de commandes</description>
    <mitre>
      <id>T1059</id>
      <id>T1566.001</id>
    </mitre>
  </rule>
</group>

T1566.001 est la sous-technique Spearphishing Attachment : la pièce jointe piégée, très probable origine de ce lancement. Les deux parents supplémentaires viennent des règles fournies : une règle fournie peut correspondre avant la tienne. 92028 « Powershell executed script », de niveau 0, prend tout PowerShell lancé avec un fichier de script (.ps1, .bat, .vbs…) sur sa ligne de commande, et 92021 tout PowerShell qui supprime des fichiers : sans elles dans <if_sid>, une macro qui lance powershell.exe -File … ne serait jamais vue par la règle. Teste la règle sur une machine de laboratoire en provoquant l'événement légitimement (une macro de test que tu as écrite toi-même, qui lance cmd.exe et ne fait rien d'autre), et vérifie dans l'alerte quel rule.id a été retenu. Une application Office qui lance mshta.exe est déjà couverte par la règle fournie 92047 (niveau 12).

Vérifier. Quel utilisateur, quel document ouvert juste avant (Sysmon 11, fichiers créés), quelles connexions réseau a faites le processus (Sysmon 3, 22) ? Le contenu du 4104 montre ce que le script a voulu faire.

Réagir. Isoler le poste du réseau (sans l'éteindre), bloquer au pare-feu les adresses contactées, chercher le même document ou les mêmes adresses sur les autres machines (indicateurs de compromission), et réinitialiser le mot de passe de l'utilisateur.

Journal effacé, service installé, agent arrêté

Trois traces de l'attaquant qui s'installe ou se cache :

Les postes s'éteignent tous les soirs : les règles 504 et 506 restent au niveau 3 pour eux. Pour les serveurs, une règle les relève, en reconnaissant le nom de l'agent dans le message :

<group name="sorbier,wazuh,">
  <rule id="100340" level="12">
    <if_sid>504,506</if_sid>
    <match>srv-ad|srv-fichiers|srv-gestion|srv-collecte|srv-web</match>
    <description>Sorbier : l'agent Wazuh d'un serveur s'est arrêté ou ne répond plus</description>
    <mitre>
      <id>T1685</id>
    </mitre>
  </rule>
</group>

Le nom de l'agent figure bien dans le message, que le serveur Wazuh fabrique lui-même : ossec: Agent disconnected: 'srv-ad-any'. pour la règle 504 (le nom, un tiret, puis l'adresse enregistrée, any par défaut), ossec: Agent stopped: 'srv-ad->any'. pour la règle 506. srv-ad couvre aussi srv-ad2, puisque <match> cherche le texte n'importe où dans le message. Lors d'une maintenance planifiée d'un serveur, l'alerte est attendue : on la rattache au ticket de changement.

Un balayage vu par le pare-feu

Les traces. Dans le journal de pfSense, des dizaines de paquets bloqués en quelques secondes depuis la même adresse, vers des ports ou des adresses qui se suivent. Wazuh lève la règle 87702 (18 blocages en 45 secondes depuis la même source, niveau 10). Depuis Internet, c'est le bruit de fond permanent des robots : on le constate, on ne s'en alarme pas. Depuis l'intérieur (un poste du VLAN 10 qui balaie le VLAN 20), c'est tout autre chose : une machine compromise qui explore le réseau (Discovery). Même règle, même niveau, gravité réelle très différente : c'est la remise en contexte qui fait la différence.

Exercices