La magie du XPath

1. Introduction

Dans cet article, nous allons voir comment il est possible de d’envoyer vers QRadar (quasiment) tous les logs qu’une machine Windows récupère. Vous avez vu précédemment comment mettre en place la collecte d’une machine Windows via un agent Wincollect, mais nous n’avions pas creusé ce qui est récupéré par cet agent.

Pour mieux comprendre la suite, il faut d’abord savoir que :

Microsoft divise les logs en 6 catégories + un dossier contenant les logs des applications et services de la machine
Les 6 catégories sont requêtables par l’agent Wincollect

Cela veut donc dire qu’il n’est pas possible de passer par les cases à cocher suivantes pour récupérer tous les logs d’une machine Windows :

Avant de vous expliquer comment faire pour récupérer tout ce que vous souhaitez, faisons un tour d’horizon de ce que va apporter ce nouveau système de collecte.

2. Pourquoi l’utiliser

Le XPath ou XML Path est une fonctionnalité qui va nous permettre d’être en mesure de collecter tous les événements visibles dans l’observateur d’événements sous Windows. Donc, de surcroit, il va permettre de combler le manque apporté par les cases à cocher pour sélectionner la catégorie de logs.

On va donc pouvoir augmenter la couverture sécurité.

L’un des autres points très intéressants de l’utilisation du XPath est qu’il va permettre d’affiner le choix dans la collecte. Par exemple, au lieu de collecter tous les événements de la catégorie “Sécurité”, je peux choisir de ne récupérer que les événements 4624 puisque ce sont ceux qui m’intéressent.

Ainsi, non seulement la couverture est meilleure en utilisant le XPath, mais également la granularité dans ce que l’on souhaite collecter.

En effet, en parlant de granularité, il est non seulement possible de filtrer sur l’ID d’un événement comme mentionné juste avant, mais il est également possible de filtrer sur à peu près tout ce que vous avez dans un événement Windows. Par exemple, si je souhaite n’avoir que les événements qui concernent un utilisateur en particulier, je vais être en mesure de le faire.

3. Comment utiliser le XPath

L’utilisation de cette fonctionnalité est assez simple, surtout si vous avez une machine Windows sous la main pour effectuer vos tests. En effet, pour mettre en place “XPath”, vous allez devoir trouver la requête, qui peut être assimilée à votre “filtre”, correspondant à vos envies. Cette construction va se faire côté Windows et vous n’aurez ensuite qu’à l’implémenter dans la log source que vous souhaitez sur QRadar.

a. Côté client

Rendez vous donc sur une machine Windows, idéalement la machine que vous allez collecter et sur laquelle vous allez appliquer le XPath. Lancez l’observateur d’événements et ouvrez la création de vue personnalisée comme ci-dessous :

Vous visualisez tout de suite que dans la nouvelle page on retrouve l’onglet “XML” qui va nous servir pour plus tard. Maintenant appliquons les filtres que nous souhaitons, par exemple si je souhaite :

n’avoir que les événements “Critique” et “Avertissement”
n’avoir que des événements du journal “Sécurité”
n’avoir que des événements concernant l’utilisateur “Administrateur”

je vais appliquer les changements suivants :

Les filtres étant bons, nous allons récupérer le XPath pour la suite de la configuration. Pour cela, allez dans l’onglet “XML” comme mentionné plus haut, vous y retrouverez la recherche sous forme de “code” directement construite. Il ne reste plus qu’à cliquer sur le bouton “Modifier la requête” pour pouvoir la copier-coller.

b. Côté serveur QRadar

Nous avons désormais notre XPath, il ne reste plus qu’à le mettre où il faut, à savoir dans les paramètres de la log source. Pour ce faire, allez dans le “Log Source Management” puis recherchez votre log source via la barre de recherche. Ensuite :

Cliquez sur la log source pour ouvrir le panel des configurations de cette dernière
Cliquez sur l’onglet “Protocol” dans le panel qui vient de s’ouvrir
Cliquez sur “Edit”
Copiez-collez dans la section “XPath Query” le XPath que vous avez défini dans la partie précédente
Cliquez sur “Save” qui va apparaître en lieu et place du bouton “Edit”

Les changements de collecte vont s’appliquer automatiquement dès que l’agent Wincollect va se synchroniser avec la console. Si toutefois la configuration n’a pas l’air de se mettre en place, vous pouvez forcer un redémarrage du service Wincollect sur la machine Windows.

4. Cas d’utilisation

Nous avons vu comment mettre en place une configuration basique, regardons maintenant quelques cas d’usage qui vont vous permettre de comprendre ce qu’il est possible de faire via cette fonctionnalité.

a. Collecte de logs Powershell

Prérequis : Avoir les événements d’actions Powershell inscrits dans l’observateur d’événements, pour cela suivre la procédure suivante : about_Logging_Windows

Dans cet exemple, nous souhaitons récupérer les logs des actions effectuées via Powershell, cela permettra notamment de pouvoir identifier des actions perpétrées par un attaquant. En effet, une règle vérifiant que certains mots clés n’apparaissent pas dans une ligne de commande est un bon début pour identifier les binaires d’attaques et de scan de système les plus connus.

Après avoir effectué quelques recherches, on trouve que l’événement 4104, “Exécuter une commande distante”, permet de récupérer la ligne de commande passée. De plus en prenant un événement et en regardant les informations complémentaires on trouve que ce dernier fait partie du journal “Microsoft-Windows-PowerShell/Operational”.

Avec toutes ces informations nous sommes donc en mesure de pouvoir établir du XPath suivant :

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-PowerShell/Operational">
    <Select Path="Microsoft-Windows-PowerShell/Operational">*[System[(EventID=4104)]]</Select>
  </Query>
</QueryList>

b. Collecte de logs SSH

Prérequis : Avoir un serveur SSH sur la machine que vous souhaitez superviser, pour cela suivre la procédure suivante : Get started with OpenSSH for Windows

Dans ce deuxième exemple, nous avons pour objectif de récupérer les événements de ce serveur OpenSSH et donc de pouvoir détecter d’éventuel bruteforce ou accès suspects.

Si l’on revient sur l’observateur d’événements, on note que dans l’arborescence des différents journaux apparaît le dossier “OpenSSH”.

Pour valider que c’est bien cela, on lance une session SSH sur un terminal vers notre serveur supervisé et on regarde les événements.

On constate que :

le journal est le suivant : “OpenSSH/Operational”

Avec cette information nous sommes donc en mesure de pouvoir établir du XPath suivant :

<QueryList>
  <Query Id="0" Path="OpenSSH/Operational">
    <Select Path="OpenSSH/Operational">*</Select>
  </Query>
</QueryList>

5. Conclusion

Nous avons vu comment fonctionnait le filtrage XML (XPath) sur l’observateur d’événements Windows et quels étaient les avantages de l’utiliser dans la collecte QRadar. Vous pouvez maintenant explorer les logs Windows à la recherche de nouveaux périmètres à contrôler et donc de nouvelles règles de détection.

À noter tout de même que XML 1.0 possède quelques limitations, comme la non possibilité de pouvoir effectuer des recherches textuelles via des expressions régulières sur les différentes valeurs de votre log. Pour plus de détails je vous renvoie vers la documentation que je mets dans la bibliographie.

N’hésitez pas à partager vos trouvailles dans les événements Windows, ainsi que les scenarii qu’il est possible d’en tirer.

6. Bibliographie

Documentation sur le fonctionnement du filtrage XML sous Windows : Advanced XML filtering in the Windows Event Viewer
Utilisation du XPath d’après la documentation IBM : QRadar WinCollect: How to use Microsoft Event Viewer to create an XPath Query
Mise en place d’un serveur OpenSSH sous Windows : Get started with OpenSSH for Windows
Mise en place de la transcription Powershell sous Windows : about_Logging_Windows

Merci d’avoir suivi ce petit tuto, en espérant que cela vous ait été utile. N’hésitez pas à me communiquer vos ressentis, tips…etc via le formulaire ci-dessous.

MENU PRINCIPAL