I. Présentation

Dans cet article, nous allons apprendre à utiliser l'outil ADTimeline proposé par l'ANSSI. Nous pouvons utiliser pour identifier les actions malveillantes effectuées au sein de l'Active Directory et effectuer un suivi des menaces.

Dans la première partie de cet article, nous allons évoquer les deux grandes méthodes pour accéder à la traçabilité des changements effectués dans l'Active Directory, puis nous verrons comment utiliser l'outil ADTimeline. Ceci nous amènera à utiliser Splunk pour effectuer l'analyse des données collectées par cet outil.

• Cliquez ici pour regarder la vidéo sur YouTube

En complément, je vous recommande la lecture de cet article :

• Zircolite - Investigation numérique sur les journaux Windows

II. Traçabilité des changements effectués dans l'Active Directory

A. Les journaux d'audit

Il y a plusieurs façons d'effectuer la traçabilité des changements opérés dans l'Active Directory. La bonne pratique consiste à configurer la stratégie d'audit des contrôleurs de domaine Active Directory afin de générer des événements de sécurité pertinent et de les collecter dans un SIEM ou un puits de logs, afin de les centraliser, de les sauvegarder et de les analyser plus facilement (corrélation entre les événements). Ces journaux peuvent aussi être analysés par des applications tierces spécialisées dans la surveillance de l'Active Directory.

• Centralisation des logs, un outil pour la sécurité

Les journaux d'audit sont visibles via le journal "Sécurité" que nous pouvons consulter par l'intermédiaire de l'Observateur d'événements de Windows.

Malheureusement, cette configuration recommandée est encore trop peu souvent mis en place dans les organisations. Dans ce cas, comment faire ?

B. Les métadonnées de réplication

Il y a une autre source sur laquelle nous pouvons nous appuyer pour tenter de retracer l'historique des changements apportés à l'Active Directory : les métadonnées de réplication.

Bien que ce ne soit pas aussi complet que le journal "Sécurité" de Windows, c'est une source d'informations précieuses comme nous le verrons dans la suite de cet article. Surtout, elles le sauront d'autant plus si les journaux d'audit ne sont pas actifs ou qu'ils ont été supprimés par un attaquant.

Remarque : les métadonnées de réplication seront générées sur un contrôleur de domaine Active Directory, même s'il s'agit d'un environnement avec un seul contrôleur de domaine.

À chaque fois qu'un objet de l'Active Directory est modifié, ceci modifie un ou plusieurs attributs, et engendre la création d'informations de réplication pour résumer l'opération effectuée.

• msDS-ReplAttributeMetaData pour les attributs non liés, ce qui permet d'avoir des informations sur la dernière modification de chacun des attributs. À chaque fois, plusieurs propriétés seront précisées, notamment "pszAttributeName" pour le nom de l'attribut modifié et "ftimeLastOriginatingChange" pour la date de la dernière modification de l'attribut.

À partir des cmdlets PowerShell permettant d'interroger l'Active Directory, notamment "Get-ADUser" et "Get-ADGroup", cet attribut peut être consulté. Voici un exemple pour obtenir les métadonnées de réplication associées à l'utilisateur "tech.t2" :

Get-ADUser -Identity "Tech.T2" -Properties msDS-ReplAttributeMetaData | Select -ExpandProperty msDS-ReplAttributeMetaData

Ce qui donne :

• msDS-ReplValueMetaData pour les attributs liés, dont la valeur dépend d'un calcul effectué à partir d'un autre attribut.

Par ailleurs, ces informations peuvent être consultées à l'aide de l'outil "repadmin" ou du cmdlet PowerShell nommé "Get-ADReplicationAttributeMetadata". L'exemple ci-dessous permet d'obtenir les métadonnées de réplication pour l'objet "CN=Technicien T2,OU=Utilisateurs,OU=T2,OU=Tiering,OU=IT,DC=it-connect,DC=local" (utilisateur nommé "Technicien T2"), à partir du DC nommé "SRV-ADDS-01.it-connect.local", en sélectionnant uniquement l'événement le plus récent.

Get-ADReplicationAttributeMetadata -Object "CN=Technicien T2,OU=Utilisateurs,OU=T2,OU=Tiering,OU=IT,DC=it-connect,DC=local" -Server "SRV-ADDS-01.it-connect.local" | Select -First 1

Voici le résultat retourné par cette commande :

Remarque : un attribut non lié correspond à un attribut dont la valeur est spécifique à l'objet (l'e-mail, le nom, etc...) alors qu'un attribut lié stocke une information qui met en relation deux objets (la liste des groupes dont est membre un utilisateur, par exemple).

III. Qu'est-ce que l'outil ADTimeline ?

ADTimeline est un outil de suivi des modifications apportées à l'Active Directory. Il peut être utilisé par les administrateurs systèmes, mais également les professionnels de la cybersécurité dans le cadre d'une investigation numérique ou d'une réponse à incident. Il permet de faciliter les opérations de threat hunting (recherche de menaces).

En effet, l'outil ADTimeline a été développé par l'ANSSI (Agence nationale de la sécurité des systèmes d'information) dans le but de générer la chronologie des modifications apportées à Active Directory à partir des métadonnées de réplication. Autrement dit, il ne dépend pas directement du journal "Sécurité" de Windows puisque sa source de données est différente.

Cet outil gratuit est développé en PowerShell et il est disponible sur GitHub. Je vous invite à récupérer l'archive ZIP de ce projet si vous souhaitez l'utiliser.

• GitHub - ADTimeline

ADTimeline a été présenté pour la première fois à l'occasion de l'événement CoRI&IN 2019 (Conférence sur la réponse aux incidents et l’investigation numérique). Vous pouvez retrouver les slides de cette présentation sur cette page.

IV. Exécuter un audit avec ADTimeline

Désormais, nous allons commencer à manipuler ADTimeline : la première étape consiste à effectuer une analyse de l'Active Directory pour générer des fichiers d'audit.

ADTimeline peut analyser un Active Directory en ligne, ainsi qu'une base Active Directory hors ligne à partir du fichier "ntds.dit". Ici, nous allons analyser le domaine Active Directory "it-connect.local" qui contient 2 contrôleurs de domaine : "SRV-ADDS-01" et "SRV-ADDS-02".

Pour cela, téléchargez le ZIP du projet à partir du GitHub et décompressez-le sur votre serveur. Il convient d'être "Administrateur du domaine" pour effectuer l'analyse. À partir d'une console PowerShell, exécutez simplement la commande suivante (des paramètres sont disponibles pour cibler un DC spécifique, par exemple) :

.\ADTimeline.ps1

Patientez pendant l'analyse. ADTimeline va analyser les métadonnées de réplications de vos objets et générer un rapport.

Suite à l'analyse, ADTimeline va générer un ensemble de fichiers. Voici ce qui est précisé sur le GitHub officiel à ce sujet :

• timeline_%DOMAINFQDN%.csv : la chronologie générée avec les métadonnées de réplication AD des objets récupérés.
• logfile_%DOMAINFQDN%.log : fichier journal du script. Vous y trouverez également diverses informations sur le domaine.
• ADobjects_%DOMAINFQDN%.xml : objets d'intérêt récupérés via LDAP.
• gcADobjects_%DOMAINFQDN%.xml : objets d'intérêt récupérés via le catalogue global.

Pour ma part, j'ai obtenu les fichiers suivants :

Que fait-on de ces fichiers ? Ne vous attendez pas à trouver un rapport HTML ou un document prêt à l'emploi. Pour analyser ces données, nous allons devoir utiliser Splunk.

V. Analyser les données d'ADTimeline avec Splunk

La seconde étape consiste à exploiter les fichiers générés par ADTimeline avec la solution Splunk. Nous pouvons utiliser la version gratuite. Bien qu'elle soit limitée, elle conviendra pour l'utilisation d'ADTimeline.

A. Installer Splunk sur Windows Server

Splunk peut être installé sur Windows Server, sur Linux, mais aussi par l'intermédiaire d'un conteneur Docker. Pour cette démonstration, il sera installé sur un serveur Windows Server 2022 : l'exécutable permet de l'installer en quelques clics.

Vous pouvez télécharger Splunk en utilisant le lien ci-dessous. Ceci implique de créer un compte sur le site de Splunk. "Après l'installation, vous disposerez d'une licence d'essai pour l'entreprise pendant 60 jours. Vous pouvez passer à la licence gratuite à tout moment avant la fin de la période d'essai.", précise le site officiel de Splunk.

• Télécharger Splunk Enterprise

Pour effectuer l'installation, suivez l'assistant... La seule chose à effectuer, c'est de définir un nom d'utilisateur et un mot de passe pour le compte "Administrateur" de la plateforme.

Ensuite, vous pouvez vous connecter à l'interface Web de Splunk avec un navigateur et vous authentifier avec votre compte.

http://127.0.0.1:8000/
http://<Adresse IP du serveur>:8000/

Pour plus d'informations sur la version gratuite, consultez ce lien :

• Au sujet de Splunk Free

B. Ajouter l'application ADTimeline à Splunk

L'ANSSI a créé une application "ADTimeline" pour Splunk afin de permettre l'analyse des données à partir de cette plateforme. A partir de votre compte Splunk, vous pouvez télécharger cette archive sur la Splunkbase :

• Splunk - App ADTimeline

Pour installer l'application, suivez cette procédure :

1 - Cliquez sur "Apps" dans le menu puis sur "Manage Apps".

2 - Cliquez sur "Install App From File" en haut à droite.

3 - Cliquez sur le bouton "Choose File" pour sélectionner le fichier "adtimeline_12.tgz" et validez.

Patientez un instant pendant l'installation de l'application. Ceci va créer une nouvelle entrée dans le menu "Apps" :

Inutile de cliquer dessus pour le moment, car nous devons commencer par importer des données.

C. Importer les données dans Splunk

Nous allons devoir importer les données dans Splunk, c'est-à-dire les fichiers générés par ADTimeline (sauf le fichier "logfile"). Pour ma part, je dois importer les deux fichiers suivants :

timeline_it-connect.local.csv
ADobjects_it-connect.local.xml

A partir de la page d'accueil de Splunk, cliquez sur le bouton "Add data".

Puis, chargez un premier fichier, par exemple, le fichier "timeline_<domaine>.csv". Il faut charger un fichier à la fois.

À l'étape "Set Source Type", choisissez le type de source "adtimeline" pour ce fichier. Attention, le type de source à sélectionner dépend du fichier choisi à l'étape précédente.

• timeline_%DOMAINFQDN%.csv = adtimeline
• ADobjects_%DOMAINFQDN%.xml = adobjects
• gcADobjects_%DOMAINFQDN%.xml = gcobjects

À l'étape "Input Settings", sélectionnez "Constant value" et indiquez le nom de votre domaine.

Poursuivez jusqu'à la fin...

Répétez l'opération pour importer chaque fichier généré par ADTimeline.

D. Le tableau de bord ADTimeline

Il est temps de cliquer sur "ADTimeline" dans le menu "Apps" de Splunk pour explorer les données ! Plusieurs onglets sont accessibles :

• Search : exécuter des requêtes sur le jeu de données importé en s'appuyant sur le langage SPL (Search Processing Language) développé par Splunk.
• Getting started : documentation de l'outil ADTimeline, similaire à celle du GitHub.
• AD General Information : des informations sur votre infrastructure Active Directory et les comptes sensibles.
• AD Threat Hunting : des événements relatifs à vos objets Active Directory, de façon chronologique, ainsi que des métriques clés pour permettre d'identifier et de suivre les menaces (threat hunting).

Désormais, nous allons regarder d'un peu plus près les différents onglets, notamment ceux nommés "AD General Information" et "AD Threat hunting".

E. ADTimeline : AD General Information

Cet onglet donne accès à deux sous-sections : "Active Directory Infrastructure" et "Sensitive Accounts".

• Active Directory Infrastructure

Cette section va permettre d'obtenir des informations sur le niveau fonctionnel du domaine et de la forêt, la liste des contrôleurs de domaine Active Directory, la répartition des rôles FSMO, l'état de certaines fonctionnalités d'ADDS (corbeille, LAPS, silo d'authentification, groupe Protected Users, Service Connection Points, etc.), et il va aussi indiquer s'il y a un serveur de messagerie Exchange, un ADCS ou un ADFS.

• Sensitive Accounts

Cette section, comme son nom l'indique, va permettre d'obtenir la liste des comptes sensibles, à commencer par les comptes "Administrateurs". Il s'intéresse aussi à tous les comptes où l'attribut "adminCount" est égal à "1", tout en retraçant l'historique de modifications de ces comptes.

Active Directory et l'attribut adminCount

Mais ce n'est pas tout, l'outil va permettre de remonter les comptes sensibles vulnérables à l'attaque ASREPRoast. Il met aussi en évidence le ratio entre les comptes sensibles et les comptes non sensibles vulnérables à ASREPRoast. Ici, j'ai volontairement configuré un compte de mon annuaire Active Directory pour qu'il soit détecté par ADTimeline :

Pour en savoir plus sur l'attaque ASREPRoast, vous pouvez lire notre article complet sur le sujet :

Active Directory et l'attaque ASREPRoast

F. ADTimeline : AD Threat Hunting

Désormais, nous allons basculer sur les différentes sections sous "AD Threat Hunting", toujours à partir de Splunk.

• Investigate timeframe

La section "Investigate timeframe" liste toutes les modifications effectuées dans l'annuaire Active Directory, de façon chronologique, en s'appuyant sur les métadonnées de réplications. Il est possible d'appliquer des filtres pour cibler une période précise.

Par exemple, sur l'image ci-dessous, nous constatons qu'il y a eu un verrouillage sur le compte "Admin T0" et une modification de l'attribut "msD-SupportedEncryptionTypes" sur le compte "Technicien T2", ce qui a aussi eu un impact sur l'attribut "UserAccountControl". Nous savons également quel DC a été sollicité pour effectuer l'opération.

Active Directory et l'attribut UserAccountControl

Ce qui est puissant et pratique, c'est le fait de pouvoir cliquer sur les éléments des graphes. Par exemple, si nous cliquons sur "UserAccountControl", nous pouvons obtenir des informations sur tous les comptes où cet attribut a été altéré, avec une vue chronologique. Autrement dit, ceci permet de visualiser toutes les occurences d'un événement.

Cette section remonte également d'autres informations, dont des statistiques telles que la répartition par ObjectClass pour les modifications des objets, ainsi qu'une timeline avec le nombre de modifications par jour.

• Track suspicious activity

Pour effectuer un suivi des actions suspectes, rendez-vous dans l'entrée "Track suspicious activity" où ADTimeline va regrouper tous les événements importants pouvant être le signe d'une activité suspecte. Voici quelques indicateurs visibles sur cette page :

- Historique de verrouillage des comptes, par jour : s'il y a un pic avec de nombreux comptes verrouillés sur une même journée, c'est suspect !

- Modifications sur les ACL (permissions)

- Comptes ajoutés et retirés des groupes

- Modifications suspectes de l'attribut SIDHistory

- Modifications sur les GPO pour altérer la stratégie d'audit (ce qui va impacter le journal "Sécurité")

- Détection d'une attaque de type DCShadow

- Etc...

Je vous encourage à consulter la documentation d'ADTimeline pour avoir la liste complète. À chaque fois, vous remarquerez la présence de liens pour renvoyer vers les TTP correspondantes dans le framework MITRE ATT&CK.

En complément, l'entrée "Track suspicious activity" du menu sert à obtenir des informations sur les événements suspects relatifs à un serveur Exchange.

VI. Conclusion

ADTimeline est un outil très utile et facile à utiliser puisque la collecte des informations est simple, tout comme l'installation de Splunk et l'intégration des données. Néanmoins, l'analyse des résultats n'est pas à la portée de tout le monde. En effet, il faut avoir une bonne connaissance de l'Active Directory, notamment des attributs, ainsi que des attaques fréquentes, pour être capable d'identifier et de retracer une activité malveillante.

Qu'en pensez-vous ?

The post Suivi des menaces et investigation numérique dans l’Active Directory avec l’outil ADTimeline first appeared on IT-Connect.

I. Présentation

Dans cet article, nous allons découvrir Zircolite, un outil d'investigation numérique simple d'utilisation capable de détecter des évènements de sécurité suspects dans différents formats de journaux d'évènements (logs), dont le format .evtx (Windows), les logs Auditd Linux, le format JSON, etc.

Cet outil peut être utilisé lors d'une suspicion d'intrusion sur un composant du système d'information, lors d'un contrôle de routine (threat hunting) sur les journaux ou lors d'une investigation numérique en bonne et due forme. L'intérêt de Zircolite est qu'il est standalone, il ne nécessite pas de serveur web ou base de donnée. Il peut être exécuté sur n'importe quel système Linux munit de Python3, ou sous Windows en tant que simple exécutable. Également, il est très simple d'utilisation et repose sur un standard pour la détection des évènements suspects : les règles Sigma.

II. Détection, investigation numérique et règles Sigma

A. Sigma : règles de détection pour les journaux d'évènements

À l'instar des règles Yara (pour les fichiers) et des règles Snort (pour les trames réseaux), les règles Sigma sont un format unifié de règles de détection orienté sur les journaux d'évènements. Ce format propose une manière uniforme de définition d'un évènement de sécurité à rechercher dans les journaux à l'aide de conditions qui seront utilisées comme critères de recherche et de catégorisation d'un évènement.

Les règles Sigma sont donc prises en compte par un grand nombre d'outils et disposent d'un autre avantage très important : la conversion.

L'écosystème des règles Sigma est, en effet, très intéressant, car il intègre des outils capables de convertir les règles Sigma en requêtes ou commandes spécifiques à certains produits. Par exemple, une requête KQL (pour ELK), Splunk, ou même une requête PowerShell en utilisant le cmdlet "Get-WinEvent". Bref, un sujet très intéressant là aussi. Voici un exemple :

$ sigma-cli convert --target splunk --pipeline splunk_windows /opt/sigma/rules/windows/sysmon/sysmon_file_block_executable.yml
Parsing Sigma rules [####################################] 100%
source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=27

Je viens de convertir la règle de détection Sigma "sysmon_file_block_executable.yml" en requête Splunk. Dans les faits, Zircolite utilise activement cette possibilité afin de convertir les évènements et les règles de recherche au format SQL/SQLite :

L'occasion ici de rappeler l'importance des journaux d'évènements, tant dans leur configuration, journaliser les bons évènements, notamment ceux de sécurité, que dans leur centralisation/externalisation : ne pas laisser les journaux sur le système qui les a générés, en faire une copie, une sauvegarde, dans un endroit sûr. En cas d'attaque, une équipe d'investigation numérique ou de remédiation aura du mal à vous aider si les journaux permettant de retracer le dérouler d'une cyberattaque ne sont pas complets et à disposition, voire n'ont jamais été produits.

Pour en apprendre plus, je vous recommande notre article sur le sujet de la centralisation des logs :

• Centralisation des logs, un outil pour la sécurité

B. Exemple de règle SIGMA

Pour l'exemple, voici une règle Sigma issue du Github SigmaHQ/Sigma, l'une des places centrales de la collaboration autour des règles de détection Sigma :

title: Suspicious PowerShell Download
id: 3236fcd0-b7e3-4433-b4f8-86ad61a9af2d
related:
  - id: 65531a81-a694-4e31-ae04-f8ba5bc33759
type: derived
status: test
description: Detects suspicious PowerShell download command
references:
  - https://www.trendmicro.com/en_us/research/22/j/lv-ransomware-exploits-proxyshell-in-attack.html
author: Florian Roth (Nextron Systems)
date: 2017/03/05
modified: 2023/10/27
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  product: windows
  category: ps_classic_start
detection:
  selection_webclient:
    Data|contains: 'Net.WebClient'
  selection_download:
    Data|contains:
      - '.DownloadFile('
      - '.DownloadString('
  condition: all of selection_*
falsepositives:
  - PowerShell scripts that download content from the Internet
level: medium

Une explication détaillée des règles Sigma, de leur fonctionnement et de leur utilisation pourrait faire l'objet d'un cours entier, mais nous pouvons au moins nous intéresser aux points suivants :

logsource:
  product: windows
  category: ps_classic_start

Ces instructions permettent de spécifier dans quel type de logs, nous allons chercher notre information, ici pour les produits Windows et la catégorie "ps_classic_start", c'est-à-dire les journaux PowerShell. Une liste complète des logsource et catégories utilisables peut être trouvées sur la documentation officielle Sigma.

Viennent ensuite les conditions de notre recherche :

detection:
  selection_webclient:
    Data|contains: 'Net.WebClient'
  selection_download:
    Data|contains:
      - '.DownloadFile('
      - '.DownloadString('
  condition: all of selection_*

Nous pouvons noter deux conditions ("selection_webclient" et "selection_download") qui doivent toutes deux être remplies ("condition: all of selection_*"). La première indique que le champ "Data" (le contenu de la commande PowerShell analysée) doit contenir "Net.WebClient" et la seconde qu'il doit contenir ".DownloadFile(" ou ".DownloadString('".

Les nombreuses autres instructions de cette règle permettent de spécifier son auteur, son niveau de criticité, d'obtenir des références externes, etc.

Zircolite propose ses propres règles Sigma, mais n'importe quel jeu de règle utilisant ce format peut être utilisé, c'est ce qui fait la grande puissance de l'outil. Vous pouvez retrouver les règles inclus dans Zircolite ici : Github - Zircolite-Rules et localement dans le sous-répertoire d'installation de Zircolite "rules" :

┌──(mdo㉿purple-it-connect)-[/opt/Zircolite]
└─$ ls rules/ -l
total 31172
-rw-r--r-- 1 mdo mdo    2880 Apr  7 10:53 README.md
-rw-r--r-- 1 mdo mdo  155135 Apr  7 10:53 rules_linux.json
-rw-r--r-- 1 mdo mdo 2323097 Apr  7 10:53 rules_windows_generic.json
-rw-r--r-- 1 mdo mdo 3826967 Apr  7 10:53 rules_windows_generic_full.json
-rw-r--r-- 1 mdo mdo 2323097 Apr  7 10:53 rules_windows_generic_high.json
-rw-r--r-- 1 mdo mdo 3617269 Apr  7 10:53 rules_windows_generic_medium.json
-rw-r--r-- 1 mdo mdo 3748878 Apr  7 10:53 rules_windows_generic_pysigma.json
-rw-r--r-- 1 mdo mdo 2329413 Apr  7 10:53 rules_windows_sysmon.json
-rw-r--r-- 1 mdo mdo 3837588 Apr  7 10:53 rules_windows_sysmon_full.json
-rw-r--r-- 1 mdo mdo 2329413 Apr  7 10:53 rules_windows_sysmon_high.json
-rw-r--r-- 1 mdo mdo 3627164 Apr  7 10:53 rules_windows_sysmon_medium.json
-rw-r--r-- 1 mdo mdo 3773777 Apr  7 10:53 rules_windows_sysmon_pysigma.json 

Je vous propose également d'autres sources intéressantes de règles Sigma :

• Les règles Sigma "officielles" de SigmaHQ : Github - SigmaHQ/sigma
• La base de règle de mdecrevoisier : Github - mdecrevoisier/SIGMA-detection-rules

Ces deux sources vous donneront largement de quoi faire, utilisez les notamment pour comprendre le format des règles Sigma et commencer à jouer avec. Gardez en tête cependant que même en utilisant comme base un jeu de règles à jour et éprouvé, les règles les plus efficaces sont celles qui ont été adaptées à votre contexte métier et technique.

Maintenant que nous avons une idée légèrement meilleure de ce que sont les règles Sigma, largement utilisées par les blue teams (équipe de défense et détection) et par Zircolite, passons à l'action.

III. Zircolite : détection d'évènements suspects

A. Installation de Zircolite

Si vous souhaitez utiliser Zircolite depuis un système Windows, il suffit de télécharger l'archive Release du projet et de la décompresser sur votre système :

• Github - Zircolite Release

L'utilisation depuis Windows peut sembler la plus simple si vous souhaitez analyser des journaux Windows. Cependant, Zircolite peut aussi être utilisé en tant que script Python de la même façon. Dès lors, il faut télécharger le code source depuis Github et installer les dépendances Python :

cd /opt
git clone https://github.com/wagga40/Zircolite.git
cd Zircolite
pip install -r requirements.full.txt

Dans le cadre de l'article, je l'installe sur un système Kali Linux Purple, basé sur Debian.

B. Exporter ses logs Windows

Nous sommes prêts à analyser nos journaux d'évènements, mais commençons par les récupérer depuis un système qui nous intéresse. Sur un système Windows, les journaux d'évènements sont nativement stockés dans des fichiers ".evtx". Ceux-ci sont situés dans le répertoire "C:\Windows\System32\winevt\Logs" :

Si l'on souhaite analyser seulement une partie nos journaux, par exemple, d'une date à une autre ou certains évènements ID, nous pouvons effectuer les filtres qui nous intéressent dans l'Observateur d'évènements, puis exporter le résultat. Il faut pour cela se positionner dans le journal à exporter, puis cliquer sur "Enregistrer tous les évènements sous…" dans le panneau droit :

Il est également possible d'exporter les journaux d'évènements dans un fichier ".evtx" via la ligne de commande grâce à l'utilitaire "wevtutil.exe", présent nativement sous Windows. Voici un exemple pour exporter le journal "Sécurité" :

wevtutil export-log Security Z:\Security.evtx

Dans ces deux derniers cas, nous aurons en résultat un fichier ".evtx" à analyser.

Si vous ne souhaitez pas analyser vos propres journaux Windows ou que vous n'en avez pas sous la main, pas de panique. Voici une source qui propose des journaux Windows contenant des évènements de sécurité, des traces d'attaques, etc. :

• Github - EVTX-ATTACK-SAMPLES

Enfin, certains challenges Sherlocks de Hack The Box proposent également des fichiers ".evtx" contenant des traces de cyberattaque. Il s'agit là aussi d'un très bon moyen de s’entraîner.

C. Analyse les logs Windows avec Zircolite

Maintenant que nous avons tout à notre disposition, nous pouvons utiliser Zircolite pour mener une analyse sur ces journaux à l'aide de règles de détection Sigma :

python3 zircolite.py --evtx XXXX.evtx

Sous Windows, le format de la commande est le même :

Z:\zircolite_win> .\zircolite_win_x64_2.20.0.exe --evtx Z:\Windows_SecurityLog.evtx

Il est possible de fournir en entrée à Zircolite un fichier ".evtx," ou un dossier complet contenant un ensemble de fichiers ".evtx". Par exemple, si vous ne savez pas très bien où et quoi chercher et que vous avez copié tout le contenu du répertoire "C:\Windows\System32\winevt\Logs" :

python3 zircolite.py --evtx monRepertoire\

Voici le résultat obtenu lors de l'exécution de Zircolite sous Linux :

Zircolite nous indique ici dans un premier temps le jeu de règles Sigma qu'il va utiliser ("rules/rules_windows_generic_py_sigma.json"). Puis, il va analyser les journaux d'évènements fournit en entrées avec ces règles Sigma et nous afficher les évènements découverts, leur sévérité (High, Medium, Low), et leur nombre d’occurrences.

Parmi les éléments notables de l'exemple ci-dessus, on peut noter l'utilisation de "mimikatz", la réalisation d'une attaque DCSync, une opération de suppression des journaux d'évènements... Pas de doute ici, un attaquant est passé par là !

Si l'on souhaite utiliser un autre jeu de règles (des règles personnalisées par exemple), il est possible de le spécifier avec l'option "-r" :

python3 zircolite.py --evtx /tmp/EVTX-ATTACK-SAMPLES/Persistence/ -r /opt/Zircolite/rules/rules_windows_sysmon_full.json

Ce second jeu de règle utilisé me remonte par exemple 155 évènement suspects contre 47 avec le jeu de règle "par défaut". Une différence assez nette qui montre l'importance de disposer d'un jeu de règles complet et adapté à son contexte et aux évènements recherchés.

Vous remarquerez ici que j'ai utilisé les règles Sigma spécifiques aux évènements Sysmon, je vous invite à consulter notre article dédié pour en savoir plus sur ce qu'est Sysmon et son apport en termes de sécurité :

• Windows - Utilisation de Sysmon pour tracer les activités malveillantes

L'avant-dernière ligne nous indique qu'un fichier de sortie au format JSON a été créé : "detected_events.json". Ce fichier au format JSON est intéressant si l'on souhaite aller plus loin dans l'investigation des évènements découverts :

Le contenu de cette sortie contient de nombreux détails techniques qui permettent d'en savoir plus sur les évènements suspects. Tous ne peuvent être affichés dans la sortie terminale de Zircolite pour des raisons de lisibilité. Dans ce fichier, vous n'aurez donc que des évènements suspects qui méritent une investigation. Zircolite a fait le tri parmi vos milliers de journaux pour n'en sortir que les évènements suspects d'après un ensemble de règle de détection Sigma.

Si vous n'êtes pas familier de la cybersécurité, l'élément principal sur lequel vous pourrez vous baser pour mieux comprendre les évènements suspectés relevés et les règles de détection sont le contenu des champs "references" (souvent des liens vers des blogposts) et les "tags". Ce dernier champ utilise les identifiants TTP du framework MITRE ATT&CK qui contient beaucoup d'informations sur les différents types d'attaques et modes opératoires des attaquants.

N'hésitez pas à utiliser un moteur de recherche ou le site du framework MITRE ATT&CK pour en apprendre plus sur une attaque identifiée par son TTP. Par exemple T1548 - Abuse Elevation Control Mechanism.

Il est aussi possible de ne s'intéresser qu'aux journaux d'évènements au-delà ("--after" ou "-A") ou avant ("--before" ou "-B") une certaine date, ce qui permet de filtrer ces derniers et d'améliorer les performances de recherche :

python3 zircolite.py --evtx /tmp/EVTX-ATTACK-SAMPLES/ -r /opt/Zircolite/rules/rules_windows_sysmon_full.json -A 2019-05-11T17:58:00 -B 2021-06-02T23:00:00

Le format à respecter pour spécifier une date est le suivant "<AAA-MM-DD>T<HH:MM:SS>", le "T" étant une valeur fixe. C'est notamment utile lorsque nous disposons de premières informations temporelles nous permettant d'orienter nos recherches.

D. Traiter la sortie JSON de Zircolite

Le format JSON étant un standard pris en charge par de nombreux outils, cela permet de faciliter la lecture et le traitement de ces données. Pour une utilisation et investigation immédiate sur ces évènements, nous pouvons, par exemple, utiliser la commande "jq", qui permet de parser, trier et filtrer les données JSON :

• Lister tous les évènements suspects, les tags associés (TTP), ainsi que l'heure et l'hôte pour chaque occurrence :

jq '.[] | {title: .title, tags: .tags, matches: [.matches[] | {Time:.UtcTime, Computer:.Computer}]}' /tmp/zircolite_persistence.json

Voici un résultat possible de ce filtre "jq" :

• Obtenir tous les évènements qui concernent un système précis :

jq '.[] | {title: .title, tags: .tags, matches: [.matches[] | select( .Computer == "PC01.example.corp")]}' /tmp/zircolite_persistence.json

• Afficher les évènements avec un tri par date, pour tenter d'établir un séquençage des évènements :

jq '[.[].matches[]] | sort_by(.SystemTime) ' /tmp/zircolite_persistence.json

• Même chose avec un filtre sur le nom d'un système précis :

jq '[.[].matches[]| select( .Computer == "PC01.example.corp")] | sort_by(.SystemTime)' /tmp/zircolite_persistence.json

Cette dernière commande est la plus parlante, puisque l'on commence à avoir un ordonnancement dans le temps des évènements suspects sur un système précis. Comme vous le voyez, connaître les subtilités du format JSON et manier "jq" est nécessaire ici. Sachez également que Zircolite peut directement envoyer les journaux obtenus par son analyse à différents composants comme un serveur Splunk ou ELK.

III. Utiliser le rapport web de Zircolite

Un dernier point important qu'il faut mentionner lorsque l'on parle de Zircolite est son interface web (autonome, elle aussi). Celle-ci peut être générée pour chaque analyse et contient une présentation graphique des évènements de sécurité relevés. Pour générer ce rapport au format web, il faut utiliser l'option "--package" :

python3 zircolite.py --evtx /tmp/EVTX-ATTACK-SAMPLES/ -r /opt/Zircolite/rules/rules_windows_sysmon_full.json --package
[...]
[+] Results written in : detected_events.json
[+] Generating ZircoGui package to : zircogui-output-6QYQ.zip
[+] Cleaning 

Zircolite crée alors une archive contenant des fichiers .css, .js, et .html, qu'il faut décompresser :

unzip zircogui-output-6QYQ.zip -d /tmp/Z1
firefox /tmp/Z1/index.html

Dès lors, la page web peut-être ouverte avec n'importe quel navigateur. La première vue que nous obtenons est une synthèse des évènements suspects identifiés par Zircolite dans les journaux analysés. On y trouve notamment une catégorisation de ces évènements basée sur le framework MITRE ATT&CK et par niveau de criticité :

Plus bas dans cette même page, nous pouvons obtenir une timeline des évènements relevés. Cette vue est très intéressante pour obtenir rapidement une vue d'ensemble de l'attaque (si l'on dispose de tous les journaux et des bonnes règles Sigma bien sûr) :

Chaque évènement est positionné dans le temps par rapport aux autres (grâce à l'horodatage de chacun) et catégorisé en fonction de sa typologie avec les catégories du framework MITRE ATT&CK.

Dans le cadre d'une investigation numérique, l'établissement d'une timeline de l'attaque est l'un des objectifs principaux de l'équipe forensic. L'idée de pouvoir identifier très rapidement le séquençage des évènements pour mieux comprendre l'objectif de l'attaquant et son mode opératoire, ce qui permet de prendre les bonnes décisions concernant la suite des évènements.

Nous pouvons alors sélectionner n'importe lequel de ces évènements pour avoir des informations plus précises sur celui-ci (cliquez sur l'image pour zoomer) :

Ce tableau contient de nombreuses colonnes et vous avez la possibilité de les étudier en utilisant la barre de défilement horizontale. Ces colonnes contiennent l'ensemble des informations de l'évènement sélectionné et initialement stocké dans le fichier ".evtx". Il s'agit des mêmes informations que celles présentes dans le fichier JSON étudié précédemment, mais affichées de manière plus lisible dans une page web (cliquez sur l'image pour zoomer) :

Cette simple vue nous permet, par exemple, de savoir que le processus "MSSQL" a exécuté un script via "cmd.exe" avec les droits de l'utilisateur "sqlsvc" sur le poste "MSEDGEWIN10". Cette vue par tableau permet également d'effectuer de nombreux filtres, à l'instar de ce que nous avons fait via "jq" sur le fichier JSON généré par Zircolite.

Le dernier élément notable de ce rapport web est la matrice du framework MITRE ATT&CK, qui montre tous les TTP détectés dans l'ensemble de journaux fournis en entrées (cliquez sur l'image pour zoomer) :

Là aussi, cette vue d'ensemble aide à se faire très rapidement une idée de la portée de l'attaque et des différentes opérations de l'attaquant sur les systèmes concernés.

IV. Conclusion

Dans cet article, nous avons fait le tour de Zircolite au travers des cas concrets sur des journaux d'évènements Windows. Nous avons notamment vu que Zircolite peut être utilisé de façon très simple en ligne de commande afin d'identifier des évènements suspects, d'étudier les détails de ces évènements et d'offrir une vue d'ensemble avec timeline d'une cyberattaque.

Il reste naturellement beaucoup de choses à découvrir au sujet de l'investigation numérique (forensic), des règles Sigma et de Zircolite. Néanmoins, le contenu de l'article devrait vous donner les bases de son utilisation, utiles pour l'étudier plus en profondeur et l'utiliser quotidiennement ou occasionnellement. Également, n'oubliez pas que Zircolite permet de traiter d'autres formats de journaux comme les journaux Sysmon for Linux, auditd, JSON, JSONL, etc... Même si cela n'a pas été traité dans l'article.

Au-delà de l'outil, cet article a permis de rappeler un grand nombre d'éléments concernant la sécurité d'un système unique ou de tout un système d'information : le durcissement des configurations pour permettre la journalisation des évènements importants de sécurité, la sauvegarde et centralisation de ces évènements, la capacité à pouvoir intervenir rapidement suite à une cyberattaque et commencer les premières investigations, etc.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

The post Comment effectuer une investigation numérique sur les journaux d’évènements Windows avec Zircolite ? first appeared on IT-Connect.