Guide d'analyse des menaces Sysmon, partie 2. Utilisation des données d'événements Sysmon pour identifier les menaces





Cet article est le premier d'une série sur l'analyse des menaces Sysmon. Toutes les autres parties de la série:

Partie 1. Présentation de l'analyse des journaux Sysmon

Partie 2. Utilisation des données d'événements Sysmon pour détecter les menaces (nous sommes ici)

Partie 3. Analyse approfondie des menaces Sysmon à l'aide de graphiques



Dans cette section, nous allons aller plus loin et commencer à utiliser des informations détaillées fourni par Sysmon. Voici trois points principaux sur lesquels nous allons travailler:



  1. Utiliser PowerShell pour accéder directement aux informations granulaires sur les processus;
  2. Construire et visualiser une hiérarchie de processus est la première étape importante dans la recherche de menaces;
  3. Utilisez les métadonnées Sysmon pour générer des métriques importantes utiles dans les enquêtes avancées sur les menaces, telles que le calcul de la fréquence à laquelle des processus spécifiques sont lancés.


Utilisation de Get-Sysmonlogs



Examinons maintenant de plus près ma merveilleuse commande qui convertit les événements Sysmon en objets PowerShell. Je suis assez fier de ne pas avoir à écrire manuellement des lignes de code distinctes pour chacun des champs. Et voici, en fait, la grande divulgation du code:



$events = Get-WinEvent  -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 }
 
foreach ($event in $events)  {
    $ev = $event.Message -split "`r`n"
    $jsons="{ "
    foreach ($line in $ev) {
        $line=$line -replace "\\","\\" `
               -replace "\{"," " `
               -replace "\}"," " `
               -replace '"','\"' `
               -replace "`n"," " 
        $line=$line -replace '(\s*[\w\s]+):\s*(.*)', '"$1":"$2",'
        $jsons = $jsons + $line } 

        $jsons =$jsons + '"blah" : "blah" }' 
        ConvertFrom-Json -InputObject $jsons 
    }
}


Tout le code est maintenant disponible sur GitHub et vous pouvez le télécharger et l'importer en tant que module Sysmon pour votre propre projet. La seule instabilité est liée à la suppression de quelques caractères désagréables - crochets, barres obliques inverses, caractères de fin de ligne, guillemets - pour rendre la sortie plus proche de JSON.

Ainsi, le signal classique d'un intrus grouillant autour du système est l'utilisation de la commande "whoami", et suit souvent après "hostname". Un hacker (ou peut-être un initié) qui s'empare du compte de quelqu'un veut s'assurer que l'impersonnalisation fonctionne, donc il tape souvent les commandes ci-dessus dès qu'il est sur le serveur de la victime. Pour le reste, "whoami" et "hostname" ne sont pas les mots qu'ils taperaient dans la console de leur propre système, même s'ils utilisent un jour la ligne de commande.



Avec ma commande soignée qui donne accès à toutes les entrées du journal Sysmon, nous pouvons facilement concocter une chaîne de filtrage de nom de processus (comme nous l'avons fait dans la première partie ). Dans le même temps, avec Sysmon, nous pouvons aborder le problème de manière encore plus granulaire en examinantla ligne de commande du processus parent .



Habituellement, lorsqu'un hacker pénètre dans le réseau et accède à la ligne de commande, il s'agit d'un cmd obsolète - au fait, c'est exactement ce qui se passe dans le cas d'un hack avec psexec ou smbexec . En utilisant la sortie de get-symonlogs, il est possible d'attraper les processus whoami qui ont été engendrés par ces shells hérités, et ce serait une bonne preuve d'une menace.



Attention: Whoami a été lancé via le shell cmd obsolète



Attention: Whoami a été lancé via le shell cmd obsolète.





D'un point de vue pratique, la recherche dans les journaux "bruts" du journal des événements Windows et les processus de correspondance est tout simplement impossible. Comme nous venons de le voir, les enregistrements Sysmon ouvrent de nombreuses possibilités d'analyse des menaces. Continuons donc notre exploration en cartographiant les données Sysmom dans des structures plus complexes.



Les bases des structures de données: listes et graphiques



Les journaux Sysmon nous fournissent non seulement la ligne de commande du processus parent, mais également l'ID du processus!



Je pense que vous avez déjà deviné ce que cela signifie. Mais quand même: nous pouvons désormais relier les processus dans une hiérarchie et, je n'ai pas peur de le dire, des réseaux. En vous rappelant les concepts de base de l'informatique, vous pouvez trouver des structures de données naturelles pour obtenir ces informations - les listes et les graphiques liés sont les premiers à venir à l'esprit.



Au début, je pensais que je devrais dépoussiérer ma copie de The Data Structures for Poets and Sous-Chefs, mais Internet m'a ensuite aidé. Je suis tombé sur la magnifique collection d'algorithmes de base de Doug Finke sur Gihub écrits en PowerShell. Merci Doug!

Après avoir traversé une courbe d'apprentissage, j'ai pu utiliser ses algorithmes pour structurer mes événements Sysmon. J'ai construit les structures de données sous forme de liste et de graphique, puis, à l'aide de l'API, j'ai écrit une fonction PowerShell pour rechercher une commande et afficher la hiérarchie des processus. Cool.



Je l'ai nommé show-menace-path . Il recherche en profondeur d'abord dans la hiérarchie des processus et affiche les noms d'application et les commandes associées pour l'application racine spécifiée comme paramètre d'entrée. Pour mon premier test, j'ai recherché "whoami.exe". Et voici ce que j'ai vu:



Hiérarchie des processus: le processus 2452 semble suspect!



Hiérarchie des processus: le processus 2452 semble suspect!





Un bonus supplémentaire pour ceux qui ont remarqué dans la sortie ci-dessus que whoami associé au processus 2452 était appelé via le shell cmd obsolète, qui à son tour était lancé par un fichier exe avec un nom étrange dans le dossier Windows.



Hmmm. Si vous êtes familier avec les mécanismes des appels à distance psexec décrits ici , alors dans votre esprit, vous devriez déjà sonner les cloches. Mais je vais vous dire un petit secret: jouant le rôle d'un hacker, j'avais précédemment lancé ce whoami depuis un serveur Linux distant en utilisant les scripts python Impacket.



L'objectif est de démontrer qu'avec l'aide de journaux enrichis Sysmon et d'une petite partie de PowerShell, vous pouvez préparer un utilitaire complètement pratique pour identifier les vulnérabilités, comme je viens de le faire avecshow-menace-chemin .



Traquer les menaces avec des graphiques dirigés



Il est temps de faire des choses étranges. Avec toutes ces informations de processus provenant de Sysmon, vous pouvez regarder les relations plus généralement. En d'autres termes, je souhaite afficher les applications en cours d'exécution - PowerShell.exe, Explorer.exe, etc. - comme les sommets du graphe et associez-les à l'application qui à son tour les a lancés. Le résultat est un diagramme montrant comment les applications interagissent les unes avec les autres (au lieu de créer un sommet séparé pour chaque instance de processus).



D'un point de vue technique, nous parlons d'un graphe orienté dans lequel un chemin, pour ainsi dire, est un chemin à sens unique de l'application à son processus parent.



À ce stade, ce serait bien de jeter un œil à la visualisation de ce dont je parle. Heureusement, il existe un excellent utilitaire de visualisation de graphiques PowerShell appelé GraphViz , qui propose des wrappers extrêmement simples via PSQuickGraph . Puis avec un petit bout de code ...



#Let's graph it!!!
$gv = New-Graph -Type BiDirectionalGraph # PSQuickGraph
foreach ($e in $g.getAllEdges() )  { $g from Doug Fink's functions
    $vs= $e.startvertex
   $ve= $e.endvertex
    PSQuickGraph\Add-Edge -From $vs.value.Key -To $ve.value.Key -Graph $gv |Out-Null
}
Show-GraphLayout -Graph $gv


... vous pouvez visualiser les interactions complexes entre les applications via l'interface GraphViz:



GraphViz: bibliothèque PowerShell pour la visualisation des hiérarchies de processus



GraphViz: une bibliothèque PowerShell pour la visualisation des hiérarchies de processus





Que fait-il? Il s'agit essentiellement d'un moyen graphique d'identifier les menaces. Au lieu de rechercher une signature spécifique du texte, comme nous l'avons fait précédemment avec la commande show-menace-path, nous pouvons maintenant essayer de trouver des anomalies sur le graphique.



L'idée est de comprendre ce qu'est une image normale du voisinage des graphes et des sous-graphes - ils ressemblent généralement à des structures connectées dans la visualisation - et ensuite essayer de trouver des sommets qui semblent plus détachés. Et en fait, nos yeux sont bien adaptés à cette tâche. Heureusement, il existe également des algorithmes simples de détection de voisinage et de détection des menaces. Et il était une fois votre humble serviteur a même écrit un post sur l'utilisation de la technique de détection des quartiers dans un réseau social associé à ... le célèbre héros de la révolution aux États-Unis .



L'avantage de cette approche pour trouver des attaquants est que les pirates peuvent changer leurs techniques et masquer leurs attaques, mais il leur est difficile de cacher leurs schémas graphiques.



Dans la troisième partie de notre revue, nous approfondirons l'analyse et l'application d'algorithmes et de méthodes de recherche de vulnérabilités. Rester avec nous!



All Articles