Guide Sysmon Threat Intelligence, partie 3. Analyse graphique avancée des menaces Sysmon

Cet article est le troisième et dernier volet de la série Sysmon Threat Analysis. Toutes les autres parties de la série:



Partie 1. Présentation de Sysmon Log Analysis

Partie 2. Utilisation des données d'événement Sysmon pour détecter les menaces

Partie 3. Analyse avancée des menaces Sysmon à l'aide de graphiques (nous sommes ici)

Recherche de sous-graphes non standard avec les données d'événement Sysmon (exemple simple)

Avant de regarder un exemple d'identification des anomalies dans les sous-graphiques qui indiquent une menace potentielle (et si ces mots ne réveillent pas le nerd en vous, alors rien ne vous réveillera!), Faisons une petite digression.



À ce stade, je dois émettre un avertissement: cet article, ainsi que le code sur GitHub, ne peut pas remplacer une solution de niveau entreprise. Cela peut aider à identifier les menaces à plus petite échelle, mais ma noble mission est d'aider les professionnels de la sécurité informatique à comprendre et à apprécier les solutions de protection contre les menaces du monde réel. Et une façon d'y parvenir est de créer vous-même votre propre solution (avec mon aide).



Des expériences à domicile vous aideront à comprendre à quel point il est difficile de faire évoluer un logiciel de détection des menaces de bricolage. Vous devrez travailler avec de grands ensembles de données et tout ce qui y est lié: nettoyage (qui est une tâche extrêmement difficile), traitement efficace (trouver les structures de données nécessaires, algorithmes, etc.) et fournir des résultats avec un faible nombre de faux positifs afin que votre les mêmes collègues ne vous ont alors pas grimpé avec leurs poings. Dans cet esprit, vous voudrez peut-être envisager une solution de détection des menaces toute faite ... mais seulement après avoir terminé notre série d'articles et mené vos propres expériences.

Définition des poids des graphiques

Un moyen simple de créer une solution de protection contre les menaces qui ne repose pas sur les signatures de logiciels malveillants consiste à utiliser le graphique des menaces de la partie précédente .



Un tel graphique connecte les nœuds de processus en fonction des entrées du journal des événements Sysmon.

Remarque: je n'ai pas séparé chaque événement de démarrage de processus (ID d'événement 1 dans les événements Sysmon) en un sommet distinct. Au lieu de cela, j'ai créé un graphique plus abstrait qui montre, par exemple, que le sommet PowerShell a un lien vers n'importe quelle application à partir de laquelle il s'exécute sous n'importe quel utilisateur - un lien pour Excel, un pour le navigateur, etc.

L'arborescence PSQuickGraph de mon graphique de menaces Sysmon. Faites attention à la branche anormale sous cmd.exe





Cependant, nous voulons toujours garder une trace de la fréquence des processus en cours d' exécution. Par exemple, si PowerShell a lancé "whoami" 1 fois et l'éditeur Windows obsolète "Notepad.exe" 10 fois, les données des arêtes du graphique s'étendant à partir du sommet PowerShell doivent être marquées avec les "pondérations" correspondantes de 1 et 10, respectivement. Est-ce logique?



Dans la plupart des algorithmes de détection des menaces les plus simples, ce poids devient une métrique pour comparer les régions du graphique. Le point principal est qu'un sous-graphe avec un poids moyen inférieur par rapport au poids moyen global est suspect.

N'est-ce pas? Le sommet rarement visité est une zone anormale. Par conséquent, si les actions de l'utilisateur dans l'analyse des menaces potentielles vont vers un sous-graphique rarement utilisé, vous devez augmenter le niveau d'alarme au jaune.



L'approche que je décris et les scripts PowerShell ci-dessous ne sont pas destinés à être utilisés à des fins pratiques pour de grandes infrastructures. Mais pour un serveur distinct, la solution peut s'avérer efficace, ou au moins fournir une vérification indépendante des solutions d'entreprise que vous utilisez.



Ai-je mentionné que les algorithmes PowerShell de Doug Finke pour les structures de données sont des outils formidables et puissants? Sans son travail, je n'aurais rien réalisé dans mon projet de graphes d'anomalies. Merci encore, Doug!



Avec l'aide de sa bibliothèque PowerShell de belles fonctions graphiques, je peux facilement calculer le poids de mon graphique de menace Sysmon avec seulement quelques lignes PS, et également connaître le poids moyen des sommets pour l'ensemble du graphique. En parcourant le graphe, le code attribue également à chaque sommet le poids de toutes ses arêtes sortantes:

$AW=0 #average weight
$GW=0 #total weight

$mset = [System.Collections.ArrayList]@() #master set of subraphs
#calculate total weight by summing up the frequencies or weights of the edges
foreach ($e in $g.getAllEdges() ) {
    $GW = $GW + $e.weight
}
write-host "Weight of Graph: " $GW
$AW = $GW / $g.vertices.count
write-host "Average weight per vertex: " $AW

#assign weight of edges to vertice
for ($i=0; $i -lt $g.vertices.count; $i++) { 
   $w=0
   $v=$g.vertices[$i]
   foreach($e in $v.getEdges()) {
      if($e -eq $null) {continue}
      $w=$w + $e.weight
   }
   $v.value.Weight = $w
}

Le code ci-dessus fait les calculs dont nous avons besoin. Dans ce cas, chaque sommet peut être considéré comme la fréquence des visites, en fonction des arêtes sortantes.



La partie la plus difficile de mon script de graphique d'anomalies PowerShell - que je vais vous montrer sous peu - est de trouver les régions du graphique les moins susceptibles de se produire, puis de trouver le plus grand sous-graphique qui les contient . Vous devrez peut-être feuilleter un vieux livre d'informatique pour terminer cette tâche. Mais ce n'est en fait pas si difficile à écrire!



J'ai utilisé la recherche classique en largeur d'abord pour mon graphe en visitant chaque sommet, puis en l'élargissant aux dépens des sommets voisins jusqu'à ce que mon sous-graphe atteigne un certain seuil en fonction du poids moyen du sommet. Comme ça:

function extend-subgraph($v, $t) {
    $vertexQueue = New-Object Queue
    
    #initialize
    $vertexQueue.enqueue($v)
    $h=$v.value.Weight
    $s=@() #subgraph
    $s+=$v
    $extend=$false
    while (!$vertexQueue.isEmpty()) { #bfs
        $currentVertex = $vertexQueue.dequeue()
        $es= $currentVertex.getEdges()
        foreach($e in $es) {
            $ev= $e.endVertex                
            if ((($h + $ev.value.Weight)/($s.count+1) -lt $th)  {        
                #extend the sub-graph
                $s+=$ev
                $h =$h + $ev.value.weight
                #queue it up
                $vertexQueue.enqueue($ev)
            }
        }

Un petit mot pour les bricoleurs: pour créer un tableau de tableaux, utilisez le type arraylist et vous vous épargnerez beaucoup de maux de tête.

Menaces et sous-graphiques de faible poids

Il existe de nombreux algorithmes différents pour les graphes anormaux. Celui que j'ai utilisé est basé sur un certain graphBAD que j'ai trouvé sur Internet - et je vous donnerai un lien dès que je le retrouverai.



En général, le principal problème dans la détection pratique des menaces est de trouver un bon ensemble de données pour former une base de référence. En tant que blogueur à plein temps et spécialiste de la détection des menaces pendant les fêtes, je n'ai jamais réussi à créer un journal Sysmon suffisamment intéressant contenant de nombreuses applications différentes. Il était assez difficile de générer des sous-graphiques anormaux car je n'avais pas un écart de poids assez important. D'une manière ou d'une autre, lorsque vous utilisez un vrai serveur, vous pouvez vous retrouver avec un bien meilleur ensemble de données que l'utilisation occasionnelle d'une instance AWS Windows, comme dans mon cas.



Le script PS de graphes anormaux que j'ai écrit était tout à fait capable de produire des sous-graphes suspects avec des poids moyens faibles. Et j'ai même réussi à attraper des environnements intéressants (voir ci-dessous).

Algorithme de pondérations de sous-graphes en action: un environnement intéressant avec des pondérations de sous-graphe 7 faibles





Comme je l'ai mentionné plus tôt, il existe d'autres algorithmes pour détecter les anomalies dans les graphiques avec des métriques autres que les poids simples qui valent la peine d'être appris. L'un d'eux recherche des clusters de sommets «similaires» et remarque les connexions ou connexions entre différents environnements. Dans ce cas, l'anomalie réside dans l'utilisateur ou le processus qui connecte les environnements via une autre caractéristique. Cela a du sens, n'est-ce pas?



Si votre nerd intérieur est fort en vous, vous pouvez consulter SCAN(Algorithme de clustering structurel pour les réseaux), qui fait ce qui précède. Avec les algorithmes PowerShell de Doug Finke, vous pouvez même l'utiliser. Je veux moi-même prendre en charge ce projet et le publier bientôt sur mon GitHub .

Trouvez des anomalies grâce à des marches aléatoires

Terminons cette section avec une autre façon de trouver des anomalies dans le graphique des menaces. J'ai évoqué cette approche à la fin de la partie précédente . Pour moi, en tant que personne avec les mathématiques sur le «vous», il est plus intuitif. Et les fans de la vieille émission de télévision numb3rs reconnaîtront immédiatement le concept des chaînes de Markov [s'éclaircir la gorge].



Pour tout le monde, vous pouvez considérer cela comme une "promenade aléatoire" dans le graphique. A chacun des sommets, nous lançons un dé et sélectionnons une arête du graphe en fonction de son poids: plus le poids de l'arête est élevé, plus les chances que nous le suivions soient élevées. Vous devez diviser le graphe en deux parties - appelées graphe biparti en théorie des graphes - avec les utilisateurs d'une part et les applications de l'autre.



Ensuite, vous classeztoutes les applications de sommet pouvant être atteintes par l'utilisateur en fonction de la probabilité d'atteindre un sommet particulier. Pour analyser la menace, vous rechercherez ensuite les applications en cours d'exécution, et si l'une d'entre elles a une très faible probabilité de l'atteindre, alors vous avez peut-être trouvé une menace réelle!



Plus un karma pour celui qui l'a lié à l'algorithme PageRank de Google . Je vais décrire cela plus en détail dans la section suivante, mais les personnes intéressées peuvent rechercher sur Google l'expression marche aléatoire avec redémarrage .

Théorie de la traversée aléatoire et pratique EQL

Prenons une autre digression et analysons ce que nous essayons de réaliser avec le journal Sysmon, qui est un excellent outil pour détecter les menaces et mener des enquêtes post-incident.

• , Sysmon. Sysmon , .
• 2 Sysmon , , .
• Dans la troisième partie, nous avons plongé dans un aperçu d'un algorithme simple qui considère les connexions de bord comme des poids. Les sections d'un graphique pesant moins (en termes d'arêtes) que le poids moyen total sur l'ensemble du graphique peuvent constituer une menace potentielle. Je vais télécharger les scripts PowerShell des algorithmes de cette section sur mon GitHub (après les avoir survolés).

L'avantage de ces méthodes est qu'elles ne dépendent pas de commandes spécifiques ou de noms de processus que les attaquants modifient ou masquent constamment.

En outre, il existe une autre méthode basée sur les probabilités pour trouver des vulnérabilités. Regardons cela de plus près.

Traversée accidentelle du graphique de vulnérabilité à partir de données basées sur des événements Sysmon

Au lieu d'analyser la structure du graphe lui-même, nous pouvons considérer les liens comme un chemin ou une feuille de route, dans laquelle chaque application est un arrêt distinct en cours de route. À partir des données du journal Sysmon, nous pouvons obtenir la fréquence à laquelle chaque application démarre à partir de son parent.



Si vous regardez mon script de graphique de menace sur GitHub, vous constaterez que cette fréquence est stockée dans chaque objet de bord en utilisant les merveilleux algorithmes PowerShell de Doug Finke.

On peut considérer la fréquence de franchissement de chacune des arêtes du graphe de vulnérabilité comme une probabilité!





L'étape suivante consiste à utiliser ces informations pour déterminer la probabilité, par exemple, de lancer une application PowerShell taskmgr.exe, un analyseur de processus Windows, un bloc-notes ou hostname.exe.



Qu'est-ce que je veux en venir?



En bref: je peux créer une matrice de transition de probabilité, si appréciée des adeptes de Markovet couramment utilisé dans les systèmes de modélisation. En fait, lancer les dés, passer à l'application suivante dans le graphique et répéter ces actions est un parcours aléatoire du graphique. Finalement, cette méthode mathématique classe chaque sommet du graphe en fonction de la probabilité d'y arriver à partir du point de départ. Et vous découvrirez que, par exemple, le lancement de feuilles de calcul à partir de l'Explorateur Windows est un processus extrêmement courant et que le moteur Windows Script Host Engine est théoriquement extrêmement non standard et, par conséquent, potentiellement un indicateur de menace.

Cette méthode est connue sous le nom de Random Walk With Restart (ci-après - RWWR, marche aléatoire avec redémarrage) et est une variante du désormais légendaire algorithme de classement Google PageRank .

Jetons un coup d'œil à un morceau de script que j'ai écrit pour calculer ces classements:

#lets build a row
$row= @(0)*$g.vertices.count
$w=0

foreach($e in $start.getEdges()) {    #calculate total frequency
    $w+=$e.weight
}
if ($w -eq 0)  {   #make it connected
$row[$ix] =1
}
else {  #we assign probabilitys
    #now create transition probability
    foreach($e in $start.getEdges()) {
        $ev = $e.endVertex
        $p = $e.weight
        $jx = v-index $ev.value.Key
        $row[$jx]= $p/$w #normalize by dividing by total
    }
}
$P[$ix] = $row  #yay! One row added to transition matrix

Pour chaque sommet, je calcule la fréquence résultante de tous les voisins, puis j'assigne la probabilité de chaque transition à travers la normalisation par le total. Ainsi, si PowerShell.exe a 20 visites à tous ses voisins, mais que nc.exe n'a été visité qu'une seule fois à partir du haut de PowerShell.exe, la probabilité d'y aller sera de 1/20 ou 0,05. Est-ce logique?



La difficulté réside dans le calcul de la matrice utilisée dans RWWR, mais pour ceux qui ont suivi des cours de modélisation probabiliste, cette procédure ne sera pas difficile. Il y a un bon article de synthèse à ce sujet sur le site Web de Medium .



Mon script, que j'appelle random-rater , classe et produit les 10 plus petitsvaleurs de la liste. De cette manière, vous pouvez obtenir des applications qui ont la plus faible probabilité d'être lancées, à partir d'un sommet donné du graphique des menaces. Voici le résultat lorsque vous utilisez PowerShell.exe comme point de départ:

L'algorithme Random Walk With Restart peut produire un classement des menaces de type Google. Hmmm, whoami est le moins susceptible de fonctionner.





En guise de note pratique et d'avertissement, il convient de noter que PWWR sera un problème de big data dans un système réel. Même dans le cas de mon petit journal Sysmon, le retard de calcul était assez perceptible en raison du grand nombre d'opérations en virgule flottante.

Event Query Language (EQL) pour l'analyse des menaces

Pour l'instant, il convient de noter que les fournisseurs qui utilisent des approches plus sophistiquées pour détecter les menaces dans leurs produits vont bien au-delà de ce que vous ou moi pouvons faire par vous-même. Et, certainement, avec une précision beaucoup plus élevée.



Pour ceux qui veulent se plonger dans le sujet de la détection des menaces, mais qui ne veulent pas travailler avec mes scripts - je comprends! - il existe un langage de requête d'événement ou EQL . C'est un projet open source pour appliquer le journal Sysmon Query Language, que vous pouvez en savoir plus sur la très complète après... EQL n'est pas seulement idéal pour enquêter sur les incidents, mais il peut également être utilisé comme un outil tant que vous disposez d'une copie récente du journal Sysmon.



La suite EQL fournit un gestionnaire d'événements qui convertit le journal en JSON lisible par l'homme. Vous pouvez consulter une copie de ma branche sur GitHub. Contrairement à mon script PS statique show-menace-path , EQL vous permet d'effectuer des requêtes à la volée.



Disons que je suis intéressé par tous les shells cmd.exe qui ont été lancés au nom de scvhost.exe - cela peut être un signe de l'utilisation par l'attaquant de psexec.exe ou smb.exe. La demande ressemblera à ceci:

Utilisation d'EQL pour rechercher les shells cmd.exe lancés à partir de svchost.exe. Au fait, jq est un utilitaire Linux pour afficher des données JSON.



Il existe un moyen encore plus cool et plus puissant d'obtenir ce résultat en utilisant le modificateur enfant. Cette requête EQL vous permet de rechercher dans tous les processus avec un ancêtre spécifié, n'importe où dans la hiérarchie. Par exemple, vous pouvez rechercher des applications qui, par exemple, avaient le processus regsvr32.exe comme ancêtre et pourraient avoir exploité une vulnérabilité bien connue que j'ai décrite ici .



Il y a trop de choses à dire sur EQL dans cet article déjà long, je préfère donc publier un article séparé sur les détails de la maîtrise d'EQL pour la détection de vulnérabilités.

Réflexions finales sur les solutions de détection des menaces de bricolage

J'ai promis de télécharger le référentiel Sysmon avec tous les scripts de détection des menaces décrits dans cet article. Revenez régulièrement sur mon GitHub car j'ajouterai de nouveaux outils de détection des menaces basés sur des graphiques au fil du temps, ainsi que de la documentation supplémentaire - trop de choses à couvrir dans un article.

Vous êtes arrivé à cet endroit, félicitations!



Essayez mes scripts ou utilisez-les comme base pour développer vos propres idées de détection des menaces. PowerShell est bien adapté aux algorithmes complexes. Pour moi, qui a grandi dans le langage shell Linux, ce fut une agréable surprise de travailler avec un langage de script mature. Et je vous conseille de consulter la galerie PowerShell, une autre excellente ressource pour les scripts de combat prêts à l'emploi: vous n'avez pas à réinventer la roue dans le monde PowerShell.



Un autre point plus important à retenir de l'article entier sera la réalisation que les fournisseurs de solutions de niveau entreprise utilisent non seulement des technologies de détection des menaces beaucoup plus sophistiquées que celles qu'un développeur informatique peut écrire pendant son temps libre, mais également l'adaptabilité de ces solutions pour travailler avec le niveau de trafic. grande organisation. Bien entendu, utiliser des solutions de bricolage pour analyser un serveur sous-utilisé ou une validation supplémentaire de produits d'entreprise est une bonne idée. Mais l' intelligence et l'identification des menaces sont en effet un problème de Big Data , et évidemment pas un défi que PowerShell peut résoudre.



Si vous souhaitez en savoir plus sur la façon dont Varonis gère l'analyse et la détection des menaces, vous pouvez toujours demander une démonstration personnelle .