Cet article est la première partie d'une série sur l'analyse des menaces Sysmon. Les autres parties de la série :
Partie 1. Introduction à l'analyse des journaux Sysmon (nous sommes ici)
Partie 2. Utilisation des données d'événements Sysmon pour identifier les menaces
Partie 3. Analyse approfondie des menaces Sysmon à l'aide de graphes
Si vous êtes impliqué dans la sécurité de l'information, vous devez souvent gérer des attaques en cours. Si vous avez un œil entraîné, vous pouvez rechercher des activités anormales dans les journaux bruts — par exemple, un script PowerShell avec la commande ou un script VBS se faisant passer pour un fichier Word, en parcourant simplement la dernière activité du journal des événements Windows. Mais c'est vraiment un vrai casse-tête. Heureusement, Microsoft a créé Sysmon, qui rend l'analyse des attaques beaucoup plus facile.
Vous voulez comprendre les idées de base derrière les menaces affichées dans le journal Sysmon ? Téléchargez notre guide et vous réaliserez comment des initiés peuvent surveiller discrètement d'autres employés. Le principal problème avec le journal des événements Windows est le manque d'informations sur les processus parents, c'est-à-dire qu'il est impossible de comprendre la hiérarchie des processus. Dans les enregistrements du journal Sysmon, en revanche, on trouve l'identifiant du processus parent, son nom et la ligne de commande exécutée. Merci, Microsoft.
Dans la première partie de notre série, nous examinerons ce que nous pouvons faire avec les informations de base provenant de Sysmon. Dans la deuxième partie, nous tirerons pleinement parti des informations sur les processus parents pour créer des structures de correspondance plus complexes, connues sous le nom de graphes de menaces. Dans la troisième partie, nous examinerons un algorithme simple qui scanne le graphe des menaces pour rechercher une activité non standard via l'analyse du « poids » du graphe. Et enfin, en guise de récompense, vous découvrirez une méthode de détection des menaces probabiliste (et claire).
Partie 1 : Introduction à l'analyse des journaux Sysmon
Qu'est-ce qui peut aider à comprendre les complexités du journal des événements ? En fin de compte, c'est le SIEM. Il normalise les événements et simplifie leur analyse ultérieure. Mais nous n'avons pas besoin d'aller aussi loin, du moins au début. Pour comprendre les principes du SIEM, il suffit d'essayer la merveilleuse utilité gratuite Sysmon. Et c'est étonnamment facile à utiliser. Bravo, Microsoft !
Quelles sont les fonctionnalités de Sysmon ?
En bref, des informations utiles et lisibles sur les processus (voir les images ci-dessous). Vous découvrirez plein de détails utiles qui ne figurent pas dans le journal des événements Windows, mais surtout les champs suivants :
- ID du processus (en décimal, pas en hexadécimal !)
- ID du processus parent
- La ligne de commande du processus
- La ligne de commande du processus parent
- Le hachage de l'image du fichier
- Les noms des images de fichiers
Sysmon s'installe à la fois en tant que pilote de périphérique et en tant que service – en savoir plus Son principal avantage est la possibilité d'analyser les journaux de plusieurs sources, de corréler les informations et de consolider les valeurs résultantes dans un seul dossier de journal des événements, situé à l'emplacement Microsoft -> Windows -> Sysmon -> Opérationnel. Dans mes propres enquêtes sur les journaux Windows, qui donnent des frissons dans le dos, j'ai constamment dû passer d'un dossier de journaux PowerShell à un dossier « Sécurité », feuilletant les journaux des événements dans une tentative héroïque de faire correspondre des valeurs entre eux. Ce n'est certainement pas une tâche simple, et comme je l'ai compris plus tard, il valait mieux avoir de l'aspirine à portée de main.
Sysmon fait un saut qualitatif en avant, fournissant des informations utiles (ou comme aiment à dire les vendeurs, efficaces) pour comprendre les processus fondamentaux. Par exemple, j'ai lancé une session cachée , simulant le déplacement d'un insider malveillant dans le réseau. Voici ce que vous verrez dans le journal des événements Windows :
Dans le journal Windows, certaines informations sur le processus sont visibles, mais elles sont peu utiles. De plus, les identifiants de processus en hexadécimal ???
Chez un professionnel de l'IT ayant une compréhension des bases du hacking, la ligne de commande doit susciter des soupçons. Utiliser cmd.exe pour lancer une autre commande avec redirection de la sortie dans un fichier au nom étrange ressemble clairement à des actions de logiciel de contrôle et de gestion : de cette manière, un pseudo-shell est créé à l'aide des services WMI.
Voyons maintenant l'équivalent de l'enregistrement dans Sysmon, en faisant attention à la quantité d'informations supplémentaires qu'il nous fournit :
Les capacités de Sysmon en un seul coup d'œil : informations détaillées sur le processus de manière lisible
Vous voyez non seulement la ligne de commande, mais aussi le nom du fichier, le chemin de l'application exécutable, ce que Windows sait à ce sujet (« Windows Command Processor »), l'identifiant du processus parent, la ligne de commande du parent, ayant lancé le shell cmd, ainsi que le vrai nom du fichier du processus parent. Tout en un seul endroit, enfin !
À partir du journal Sysmon, nous pouvons conclure qu'il est très probable que cette ligne de commande suspecte, que nous avons vue dans les journaux « bruts », ne soit pas le résultat d'une activité normale d'un employé. Au contraire, elle a probablement été générée par un processus de type C2 - wmiexec, comme je l'ai mentionné précédemment - et a été directement engendrée par le processus de service WMI (WmiPrvSe). Nous avons maintenant un indicateur que l'attaquant distant ou un insider teste l'infrastructure d'entreprise.
Présentation de Get-Sysmonlogs
Il est bien sûr fantastique que Sysmon rassemble les journaux au même endroit. Mais il serait encore mieux que nous puissions accéder aux champs individuels du journal de manière programmatique – par exemple, via des commandes PowerShell. Dans ce cas, nous pourrions écrire un petit script PowerShell qui automatiserait la recherche de menaces potentielles !
Je ne suis pas le premier à avoir eu cette idée. Et c'est une bonne chose que certaines publications sur des forums et GitHub expliquent déjà comment utiliser PowerShell pour analyser les journaux Sysmon. Dans mon cas, je voulais éviter d'avoir à écrire des lignes distinctes de script d'analyse pour chaque champ Sysmon. J'ai donc utilisé le principe du paresseux et, je pense, j'ai finalement trouvé quelque chose d'intéressant.
Le premier point important est la capacité de la commande à lire les journaux Sysmon, à filtrer les événements nécessaires et à afficher le résultat dans une variable PS, comme ici :
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Si vous souhaitez vérifier le fonctionnement de l'équipe par vous-même, vous pouvez obtenir une série de chaînes de texte au format simple à partir de l'affichage du contenu du premier élément du tableau $events, $events[0].Message.
Youpi ! Sortie du log Sysmon au format JSON prêt à l'emploi
Vous pensez à la même chose que moi ? En y ajoutant un peu plus d'efforts, il est possible de convertir la sortie en une chaîne formatée au format JSON, puis de la charger directement dans un objet PS à l'aide de la puissante commande .
Je vais vous montrer le code PowerShell pour la conversion - il est très simple - dans la prochaine partie. Mais pour l'instant, examinons ce que ma nouvelle commande appelée get-sysmonlogs, que j'ai installée en tant que module PS, peut faire.
Au lieu de plonger dans l'analyse des logs Sysmon via l'interface peu pratique du journal des événements, nous pouvons rechercher sans effort l'activité incrémentale directement depuis la session PowerShell, et utiliser également la commande PS (alias - « ? ») pour réduire les résultats de sortie :
Liste des cmd shells lancés via WMI. Analyse des menaces à bas prix avec notre propre commande Get-Sysmonlogs
Incroyable ! J'ai créé un outil d'interrogation du log Sysmon comme s'il s'agissait d'une base de données. Dans notre article sur , il était mentionné que cette fonction sera accomplie par le super outil décrit, bien que ce soit formellement via une interface SQL-like réelle. Oui, EQL est élégant, mais nous y reviendrons dans la troisième partie.
Sysmon et analyse des graphes
Abstraisons-nous et pensons à ce que nous avons créé. En gros, nous avons maintenant une base de données d'événements Windows accessible via PowerShell. Comme je l'ai noté précédemment, il existe des connexions ou des relations entre les enregistrements - via ParentProcessId - ce qui permet d'obtenir la hiérarchie complète des processus.
Si vous avez lu la série vous savez que les hackers aiment créer des attaques complexes en plusieurs étapes, où chaque processus joue son petit rôle et prépare le terrain pour la prochaine étape. De telles choses sont extrêmement difficiles à intercepter simplement à partir du log « brut ».
Mais avec ma commande Get-Sysmonlogs et la structure de données supplémentaire que nous examinerons plus loin (bien sûr, c'est un graphe), nous aurons un moyen pratique de détecter des menaces - pour cela, il suffira d'effectuer la bonne recherche sur les sommets.
Comme toujours dans nos projets de blog DYI, plus vous travaillez sur l'analyse des détails des menaces à petite échelle, mieux vous réalisez à quel point la détection des menaces au niveau organisationnel est complexe. Et cette prise de conscience est extrêmement importante.
Nous rencontrerons les premières difficultés intéressantes dans la deuxième partie de l'article, où nous commencerons à lier les événements Sysmon en structures beaucoup plus complexes.
Source : habr.com
