Cet article est la première partie d'une série sur l'analyse des menaces Sysmon. Toutes 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 graphiques
Si vous travaillez dans le domaine de la sécurité de l’information, vous devez probablement souvent comprendre les attaques en cours. Si vous avez déjà un œil exercé, vous pouvez rechercher une activité non standard dans les journaux « bruts » non traités - par exemple, un script PowerShell en cours d'exécution. ou un script VBS prétendant être un fichier Word - en faisant simplement défiler la dernière activité dans le journal des événements Windows. Mais c’est un très gros casse-tête. Heureusement, Microsoft a créé Sysmon, qui facilite grandement l'analyse des attaques.
Vous souhaitez comprendre les idées de base derrière les menaces affichées dans le journal Sysmon ? Téléchargez notre guide et vous réalisez à quel point les initiés peuvent observer subrepticement les autres employés. Le principal problème lié à l'utilisation du journal des événements Windows est le manque d'informations sur les processus parents, c'est-à-dire il est impossible d'en comprendre la hiérarchie des processus. Les entrées du journal Sysmon, en revanche, contiennent l'ID du processus parent, son nom et la ligne de commande à lancer. Merci, Microsoft.
Dans la première partie de notre série, nous verrons ce que vous pouvez faire avec les informations de base de Sysmon. Dans la deuxième partie, nous tirerons pleinement parti des informations sur les processus parents pour créer des structures de conformité plus complexes appelées graphiques de menaces. Dans la troisième partie, nous examinerons un algorithme simple qui scanne un graphique de menace pour rechercher une activité inhabituelle en analysant le « poids » du graphique. Et à la fin, vous serez récompensé par une méthode de détection probabiliste des menaces soignée (et compréhensible).
Partie 1 : Introduction à l'analyse des journaux Sysmon
Qu'est-ce qui peut vous aider à comprendre les complexités du journal des événements ? En fin de compte - SIEM. Il normalise les événements et simplifie leur analyse ultérieure. Mais nous n’avons pas besoin d’aller aussi loin, du moins pas au début. Au début, pour comprendre les principes du SIEM, il suffira d’essayer le merveilleux utilitaire gratuit Sysmon. Et elle est étonnamment facile à travailler. Continuez comme ça, Microsoft !
Quelles sont les fonctionnalités de Sysmon ?
En bref, des informations utiles et lisibles sur les processus (voir images ci-dessous). Vous trouverez de nombreux détails utiles qui ne figurent pas dans le journal des événements Windows, mais les plus importants sont les champs suivants :
- ID de processus (en décimal, pas en hexadécimal !)
- ID du processus parent
- Ligne de commande de processus
- Ligne de commande du processus parent
- Hachage de l'image du fichier
- Noms des images de fichiers
Sysmon est installé à la fois en tant que pilote de périphérique et en tant que service - plus de détails Son principal avantage est la possibilité d'analyser les journaux de plusieurs sources, corrélation des informations et sortie des valeurs résultantes dans un dossier de journal des événements situé le long du chemin Microsoft -> Windows -> Sysmon -> Opérationnel. Au cours de mes propres enquêtes époustouflantes sur les journaux Windows, je me suis retrouvé constamment obligé de basculer entre, par exemple, le dossier des journaux PowerShell et le dossier Sécurité, parcourant les journaux d'événements dans une vaillante tentative de corréler d'une manière ou d'une autre les valeurs entre les deux. . Ce n’est jamais une tâche facile et, comme je l’ai réalisé plus tard, il valait mieux s’approvisionner immédiatement en aspirine.
Sysmon fait un pas de géant en fournissant des informations utiles (ou, comme les fournisseurs aiment le dire, exploitables) pour aider à comprendre les processus sous-jacents. Par exemple, j'ai commencé une session secrète , simulant le mouvement d'un initié intelligent au sein du réseau. Voici ce que vous verrez dans le journal des événements Windows :
Le journal Windows affiche des informations sur le processus, mais elles sont peu utiles. Plus les identifiants de processus en hexadécimal ???
Pour un informaticien professionnel comprenant les bases du piratage informatique, la ligne de commande devrait être suspecte. Utiliser cmd.exe pour ensuite exécuter une autre commande et rediriger la sortie vers un fichier au nom étrange est clairement similaire aux actions d'un logiciel de surveillance et de contrôle. : De cette manière, un pseudo-shell est créé à l'aide des services WMI.
Jetons maintenant un coup d'œil à l'équivalent de l'entrée Sysmon, en notant la quantité d'informations supplémentaires qu'il nous donne :
Fonctionnalités Sysmon dans une capture d'écran : informations détaillées sur le processus sous une forme lisible
Vous voyez non seulement la ligne de commande, mais aussi le nom du fichier, le chemin d'accès à l'application exécutable, ce que Windows en sait (« Processeur de commandes Windows »), l'identifiant parental processus, ligne de commande le parent, qui a lancé le shell cmd, ainsi que le vrai nom de fichier du processus parent. Tout au même endroit, enfin !
À partir du journal Sysmon, nous pouvons conclure qu’avec un degré de probabilité élevé, cette ligne de commande suspecte que nous avons vue dans les journaux « bruts » n’est pas le résultat du travail normal de l’employé. Bien au contraire, il a été généré par un processus de type C2 - wmiexec, comme je l'ai mentionné plus tôt - et a été directement généré par le processus de service WMI (WmiPrvSe). Nous disposons désormais d’un indicateur indiquant qu’un attaquant distant ou interne teste l’infrastructure de l’entreprise.
Présentation de Get-Sysmonlogs
Bien sûr, c'est génial lorsque Sysmon place les journaux au même endroit. Mais ce serait probablement encore mieux si nous pouvions accéder aux champs de journaux individuels par programmation, par exemple via des commandes PowerShell. Dans ce cas, vous pourriez écrire un petit script PowerShell qui automatiserait la recherche de menaces potentielles !
Je n'étais pas le premier à avoir une telle idée. Et c'est bien que dans certains posts du forum et GitHub Il a déjà été expliqué comment utiliser PowerShell pour analyser le journal 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 de l’homme paresseux et je pense avoir trouvé quelque chose d’intéressant.
Le premier point important est la capacité de l'équipe lisez les journaux Sysmon, filtrez les événements nécessaires et affichez le résultat dans la variable PS, comme ici :
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Si vous souhaitez tester la commande vous-même, en affichant le contenu dans le premier élément du tableau $events, $events[0].Message, le résultat peut être une série de chaînes de texte avec un format très simple : le nom du Champ Sysmon, deux points, puis la valeur elle-même.
Hourra! Sortie du journal Sysmon au format prêt pour JSON
Pensez-vous la même chose que moi ? Avec un peu plus d'effort, vous pouvez convertir la sortie en une chaîne au format JSON, puis la charger directement dans un objet PS à l'aide d'une commande puissante. .
Je montrerai le code PowerShell pour la conversion - c'est très simple - dans la partie suivante. Pour l'instant, voyons ce que peut faire ma nouvelle commande appelée get-sysmonlogs, que j'ai installée en tant que module PS.
Au lieu de plonger profondément dans l'analyse des journaux Sysmon via une interface de journal d'événements peu pratique, nous pouvons facilement rechercher une activité incrémentielle directement à partir d'une session PowerShell, ainsi qu'utiliser la commande PS. (alias – « ? ») pour raccourcir les résultats de la recherche :
Liste des shells cmd lancés via WMI. Analyse des menaces à bas prix avec notre propre équipe Get-Sysmonlogs
Merveilleux! J'ai créé un outil pour interroger le journal Sysmon comme s'il s'agissait d'une base de données. Dans notre article sur il a été noté que cette fonction sera exécutée par l'utilitaire cool qui y est décrit, bien que formellement toujours via une véritable interface de type SQL. Oui, EQL élégant, mais nous y reviendrons dans la troisième partie.
Analyse Sysmon et graphique
Prenons du recul et réfléchissons à ce que nous venons de créer. Essentiellement, nous disposons désormais d'une base de données d'événements Windows accessible via PowerShell. Comme je l'ai noté plus tôt, il existe des connexions ou des relations entre les enregistrements - via ParentProcessId - de sorte qu'une hiérarchie complète de processus peut être obtenue.
Si vous avez lu la série vous savez que les pirates adorent créer des attaques complexes en plusieurs étapes, dans lesquelles chaque processus joue son propre petit rôle et prépare un tremplin pour l'étape suivante. Il est extrêmement difficile de détecter de telles choses simplement à partir du journal « brut ».
Mais avec ma commande Get-Sysmonlogs et une structure de données supplémentaire que nous examinerons plus loin dans le texte (un graphique, bien sûr), nous disposons d'un moyen pratique de détecter les menaces - ce qui nécessite simplement d'effectuer la bonne recherche de sommet.
Comme toujours avec nos projets de blog DYI, plus vous travaillez sur l’analyse des détails des menaces à petite échelle, plus vous réaliserez à quel point la détection des menaces est complexe au niveau de l’entreprise. Et cette prise de conscience est extrêmement point important.
Nous rencontrerons les premières complications intéressantes dans la deuxième partie de l'article, où nous commencerons à relier les événements Sysmon entre eux dans des structures beaucoup plus complexes.
Source: habr.com