Introduction

Dans ce nouveau post, comme promis dans le dernier post, je vais vous montrer la vraie puissance de Wazuh et comment est-ce que Wazuh peut nous aider à améliorer la sécurité de notre infrastructure, mais bien entendu, avant de faire ça, je vais installer Sysmon sur Windows (j’expliquerai plus tard ce que c’est), ajouter quelques rules Wazuh pour améliorer la capacité de détection de Wazuh. Tout cela est plus dans ce post !

Nouvelles Rules

Dans cette grande partie, on va faire deux choses principalement : on va d’abord installer Sysmon sur nos systèmes Windows, et également revisiter nos configurations de groupes pour les améliorer et les optimiser. Une fois que nous aurons fait ça, j’importerai de nouvelles règles sur notre Wazuh-Server pour avoir une meilleure détection des possibles menaces qui peuvent exister sur nos systèmes.

Mais avant de commencer à faire toute la pratique que nous aimons tant, je suis obligé de vous faire passer par un peu de théorie.

C’est quoi les regles et les decoders ?

C’est quoi les règles et les décodeurs ? Tout d’abord, il faut savoir que chaque ligne de log importée depuis un Wazuh-Agent passe forcément par un décodeur, et au besoin elle passe également par une règle. Mais c’est quoi un décodeur ?

Un décodeur, c’est tout simplement une regex que le Wazuh-Server va essayer de faire passer à chaque ligne de log. Ces décodeurs permettent d’extraire tout type d’information à propos d’un log donné.

Par exemple, une ligne de log SSH peut ressembler à cela :

May 21 20:22:28 slacker2 sshd[8813]: Accepted password for root from 192.168.20.185 port 1066 ssh2
May 21 20:22:28 sol2 sshd[23857]: [ID 702911 auth.notice] User test1, coming from 192.168.2.185,  -  authenticated.
Oct 11 08:05:46 hostname auth|security:info sshd[323808]: Accepted publickey for usr1 from 2.3.4.5 port 37909 ssh2

Lorsque ce groupe de lignes de log va arriver vers notre Wazuh-Server, il va les faire passer une par une par des décodeurs (des regex) et récupérer des infos telles que :

• Le Timestamp
• Le service ssh
• Le user qui s’authentifie
• IP SRC
• Erreurs

Et d’autres choses que ssh peut nous générer. Si on veut, on peut voir ces décodeurs, il faudra juste aller vers : Server Management/Decoders

Une fois dans ce menu, vous allez voir quelque chose qui ressemble à ça :

Ici, vous pouvez voir la liste entière de tous les décodeurs que Wazuh-Server utilise. Par exemple, prenons le fichier décodeurs 0310-ssh_decoders.xml :

Vous pouvez voir d’un coup d’œil qu’il s’agit simplement de string regex, où les logs seront passés un par un pour extraire tout type d’information.

Parlons maintenant des Rules. Une fois que le Wazuh-Server aura fait passer les logs par les décodeurs, il va faire passer ces chaînes de caractères par les règles, c’est-à-dire qu’il va essayer de faire une corrélation entre ce que les logs disent et un niveau d’alerte, une Mitre ATTACK ou des niveaux de compliance, ou tout à la fois.

Si vous voulez voir à quoi ça ressemble les Rules Wazuh il faudra se diriger vers : Server Management/Rules:

Ici vous pouvez voir que les règles sont regroupées par famille de rules. Si on entre dans le fichier 0310-ssh_decoders.xml

On peut voir que le Wazuh-Server va essayer de refaire passer des regex sur les champs extraits pour séparer vraiment chaque type d’évènement. Je vous invite à bien regarder comment ce fichier est écrit, car c’est passionnant de voir combien de types d’erreurs est-ce que le service ssh, par exemple, peut générer.

Si vous voulez voir Wazuh-Server en action, il faut se diriger vers le menu : Server Management/Ruleset Test

Ici, on va pouvoir copier/coller des lignes de log de ce qu’on veut, et voir quel est le processus logique de Wazuh pour générer une alerte s’il en trouve le besoin.

Je vous invite à copier/coller les lignes de log que j’ai mises un peu plus haut, qui mettent en lumière une tentative réussie de connexion par ssh par un utilisateur. Normalement, vous devriez avoir la sortie suivante :

Ici, vous pouvez voir que Wazuh a bien d’abord extrait les champs qui sont importants dans le message, et puis il a fait passer la ligne de log dans les règles jusqu’à ce qu’une règle matche, et après, si jamais la règle matche, il lance l’alerte qui convient. Dans ce cas, il génère une alerte de Niveau 3.

Installation SYSMON

Sysmon, si vous ne le connaissez pas, est un outil développé par l’équipe sysinternals qui a créé beaucoup d’utilitaires très utiles pour les sysadmins. C’est également un outil très puissant qui permet une meilleure journalisation des événements de sécurité système sous Windows. Il s’agit d’un élément indispensable pour une surveillance efficace.

Sysmon permet, entre autres, de logger tous ces types d’événements :

• Création de processus
• Connexion réseau
• Fin d’un processus
• Chargement de pilote
• Chargement d’image
• Evènement CreateRemoteThread (création d’un thread par un processus)
• Evènement RawAccessRead
• Requête DNS

Donc ce n’est pas un outil qu’il faut sous-estimer. Pour l’installer, rien de plus simple : on se dirige vers leur site officiel :

• Lien vers site web sysinternals

Également, il faudra télécharger cette configuration de sysmon :

• Lien vers sysmon.xml

Cette configuration fait partie d’un repository Github très connu, qui va pré-paramétrer notre sysmon avec toutes les alertes de base nécessaires pour pouvoir détecter tout ce qui se passe dans une machine, tout cela en les mettant en relation avec des Mitre ATTACK, ce qui est très utile.

Vous pouvez bien entendu créer votre propre fichier de configuration Sysmon, mais je ne vais pas m’attarder sur cela, pour faire en sorte que le post soit le plus concis possible.

Une fois que vous aurez téléchargé votre exécutable sysmon, il faudra l’extraire et lancer la commande suivante dans un Powershell avec les droits Admin :

sysmon.exe -accepteula -i sysmonconfig.xml

Avec cette commande, on va juste dire à Sysmon quelles sont les choses qu’il doit surveiller (il y en a vraiment beaucoup) et une fois qu’il connaît ça, il va se mettre en mode daemon et normalement démarrer automatiquement à tous les prochains redémarrages.

Ensuite, je vous invite à aller au canal de journalisation suivant dans l’observateur d’événements :

• Journaux D'applications\Microsoft\Windows\Sysmon\Operational

Et vous verrez tous les logs que le sysmon aura deja receulli :

Seulement avec l’observateur d’événements, on peut faire plein de choses, on peut aller jusqu’à détecter les événements qui ne vont pas, mais bon ce n’est pas le sujet du post.

Modification Groupes Windows

Maintenant, il faut bien entendu récupérer ces événements, car à l’instant, notre Wazuh-Agent ignore que ce canal de journalisation existe. Il faut donc lui dire d’aller les récupérer. Pour cela, on va se diriger vers la page des groupes,

Puis on appuie sur le bouton du stylo de notre groupe Windows :

Une fois dedans, je vous invite a copier coller ceci :

Group Windows Agent

Avec ce fichier de config qui sera déployé sur tous nos serveurs Windows, on va pouvoir récupérer les configs Sysmon et autres, en plus des informations qu’on a déjà. Par exemple, on a activé le module FIM, c’est-à-dire qu’on va pouvoir vérifier l’intégrité des fichiers et voir s’ils ont été modifiés.

On va également surveiller de près le comportement de certains .exe, surveiller certaines entrées Regedit qui sont sensibles, entre autres choses. C’est un fichier de config vraiment très très complet.

Une fois qu’on a déployé ce fichier de config, on va maintenant importer les nouvelles règles sur notre Wazuh-Manager qui vont nous servir pour traiter ces nouvelles informations. Je vous donne ci-dessous un script bash qu’il faut lancer sur le serveur où se trouve le Wazuh-Manager. C’est un script qui va récupérer pas mal de règles faites par l’équipe SOC-Fortress, qui sont bien faites et très optimisées.

Pour les importer on lance ce script dans le serveur :

curl -so ~/wazuh_socfortress_rules.sh https://raw.githubusercontent.com/socfortress/Wazuh-Rules/main/wazuh_socfortress_rules.sh && bash ~/wazuh_socfortress_rules.sh

Une fois lance, vous devriez voir quelque chose qui ressemble a ceci :

Et voilà ! Maintenant, on a nos règles custom qui sont installées dans notre Wazuh-Server. Si vous voulez aller voir ces règles, vous savez déjà comment faire ;)

On va maintenant regarder ces fameux logs sysmon sur notre interface Wazuh. Pour cela, nous allons sélectionner notre machine Windows 10. Une fois que nous l’avons sélectionnée dans l’interface, il faudra aller dans l’onglet Threat Hunting, comme présenté dans le dernier post. Ici, vous pourrez regarder et faire des recherches sur tous les logs envoyés depuis le Wazuh-Agent installé sur cette machine.

Avant d’aller plus dans les détails, je vais vous présenter un peu plus en profondeur cette interface.

• Carré 1 : Dans cette partie, vous pourrez regarder les champs, c’est-à-dire les clés de valeur que notre Wazuh-Agent nous a envoyées. Par exemple, on a le agent.id et d’autres. Lorsque l’on survole cette clé, on peut la sélectionner en appuyant sur le petit +. Une fois fait, on verra dans le carré 2 ce champ en plus du timestamp. Cela peut être utile pour pouvoir d’un coup d’œil discerner la vraie alerte de la fausse alerte.

• Carré 2 : Ici, vous avez les logs. En soi, vous pouvez agrandir cette partie en appuyant sur la flèche, vous aurez tous les détails. On ira plus en détail sur cette partie juste après.

• Les carrés 3 et 4 : vous avez quelques champs mis en valeur comme le champ rule.level ou le champ rule.id.

• Dans le carré 5 : on peut filtrer la date et pouvoir sélectionner le timerange qu’on veut.

Visualisons maintenant un log. Je vais vous montrer un log d’un processus Windows qui a lancé une connexion vers un serveur sur Internet.

Pour information, lorsque j’ai pris cette capture d’écran, j’avais fait un téléchargement d’un exécutable sur Internet en utilisant le navigateur Firefox.

J’ai mis des carrés rouges dans toutes les informations importantes que nous pouvons tirer de ce log. Tout d’abord, nous avons le Event ID Sysmon. On voit que c’est l’event ID 3, l’event ID 3 correspond, selon la documentation de Sysmon, à une connexion réseau (vous pouvez voir tous les types d’event ID sur ce site : Events ID).

Déjà, lorsque nous voyons une connexion réseau, notre premier réflexe est de se dire, qui a lancé cette connexion, avec qui il essaye de communiquer, et est-ce que c’est une menace ?

Toutes ces questions, on peut y répondre avec ce simple log Sysmon. Tout d’abord, nous avons l’adresse IP de destination, ainsi que le port de destination. Dans ce cas, nous pouvons voir qu’un service de Windows Defender essaye de parler avec un serveur de chez Microsoft. Nous pouvons savoir qu’il appartient bien à Microsoft en utilisant une base de données d’échange d’informations entre analystes de cybersécurité : OTX

Nous avons même le ProcessID, qui peut nous aider, si on le veut, à corréler et à mettre en relation tout ce que ce service de Windows Defender a pu faire.

Quant à savoir si c’est une menace, c’est à nous de décider. On sait que l’adresse IP de destination appartient à des services internes de Microsoft, on sait que le binaire qui a lancé cette connexion est un binaire signé de chez Microsoft, et que c’est une attitude normale lorsqu’on télécharge un fichier sur Internet que Windows Defender aille chercher des signatures.

Donc, le travail d’un analyste SOC, c’est ça : c’est de décider si oui ou non ça vaut le coup d’approfondir la recherche sur une alerte en question. C’est un travail qui demande rigueur et discipline.

Conclusion

Et voilà, merci beaucoup d’avoir suivi ce post, je vous dis à la prochaine !