Les équipes Intelligence Artificielle (AI) et Cyber Threat Intelligence (CTI) d’HarfangLab unissent leurs forces pour prévenir et détecter les menaces. L’an passé, nous avons travaillé sur tous les aspects de l’IA pour améliorer notre détection de malwares, et avons pris en compte de nouveaux types de données pour étendre nos capacités. Notre travail sur les scripts PowerShell est un bon exemple de collaboration réussie. Voyons comment cela s’est passé.
Sécuriser des postes de travail devient de plus en plus difficile, en particulier du fait de l’essor des attaques par malwares fileless. La chaîne d’infection de ces attaques n’implique que peu de fichiers, voire aucun. La plus grande partie de l’étape d’infection se déroule dans l’espace mémoire (au lieu du système de fichiers) ; il est donc plus simple pour ces attaques d’échapper à la détection.
Bien que les outils tels que PowerShell de Microsoft soient légitimes, ils peuvent être utilisés à des fins malveillantes. Les attaquants peuvent y avoir recours pour télécharger et installer des malwares, dérober des données sensibles, supprimer des fichiers, voire même obtenir un accès non autorisé au système. En complément des règles écrites par l’équipe CTI, ces attaques nous ont donc amenées à explorer comment l’IA peut contribuer à leurs détections.
Les scripts PowerShell : une source intéressante de données
Pour commencer le projet, il nous faut comprendre le langage PowerShell et comment les scripts peuvent être récupérés efficacement. L’équipe CTI a fourni l’expertise nécessaire à ces deux étapes.
Comprendre PowerShell
Microsoft PowerShell est un framework open source en .NET. Il s’agit non seulement d’une interface en ligne de commande (un shell), mais aussi d’un langage interprété capable de lancer des scripts (ensemble de commandes). Il peut s’avérer très puissant pour automatiser des tâches d’administration et gérer les OS Windows. Au-delà de Windows, PowerShell supporte aussi d’autres plates-formes, dont Linux et macOS.
Collecter des scripts PowerShell pour constituer un ensemble robuste de données
Les scripts PowerShell sont enregistrés dans le journal d’évènements de Windows si ScriptBlockLogging est activé sur la machine. Ce journal enregistre dans le détail les évènements liés au système, à sa sécurité, et aux applications sur un OS Windows. Il est utilisé pour surveiller le système. Les journaux d’évènements sont accessibles depuis l’Observateur d’évènements (event viewer). Dans notre cas, nous cherchons les évènements sous l’identifiant 4104
avec pour nom de source Microsoft-Windows-PowerShell
.
Pour construire notre ensemble de données, nous avons passé en revue de nombreuses bases de données publiques. La plupart de ces bases se trouvent sur GitHub, l’utilisateur danielbohannon dispose d’une grande collection de commandes visant à générer du PowerShell malveillant, et nous avons trouvé un autre ensemble dans un article par Fang Yong, Zhou Xiangyu et Huang Cheng : Effective method for detecting malicious PowerShell scripts based on hybrid features. Afin d’étendre cet ensemble de données, nous avons demandé à l’équipe CTI quelles familles connues de malwares utilisent des scripts PowerShell. Une fois les données collectées, le modèle peut être créé.
Détecter les scripts PowerShell malveillants : un développement itératif mettant à contribution les équipes CTI et IA
L’équipe IA travaille sur un module basé sur du Machine Learning pour la détection de scripts PowerShell malveillants. Appliqué à chaque fichier PowerShell, il définit un « score de malveillance potentielle ». Au cours de la réflexion sur ce projet, l’équipe IA a œuvré conjointement avec l’équipe CTI pour comprendre si les scripts PowerShell sont fréquemment utilisés dans des attaques, et comment reconnaitre des portions malveillantes dans les scripts.
Convertir les scripts PowerShell en un Abstract Syntax Tree (AST)
Il nous faut trouver un moyen de représenter les scripts PowerShell pour pouvoir facilement en extraire des caractéristiques. Cette conversion AST est une fonctionnalité de PowerShell pour l’analyse du code. Elle décompose le code en un arbre hiérarchique dont chaque élément représente une partie de l’arbre.
Ci-dessous, l’exemple présente un script simple contenant une seule commande : Get-Date.ps1
. Nous pouvons utiliser deux méthodes (listées plus bas) pour convertir le script PowerShell en AST
: depuis le fichier ou depuis le code source.
# get AST object from script file
$script = Get-Date.ps1
$AST = [System.Management.Automation.Language.Parser]::ParseFile($script, [ref]$null, [ref]$null)
# get AST object from PowerShell code
$code = 'Get-Date -Format "dddd dd/MM/yyyy HH:mm K"'
$AST = [System.Management.Automation.Language.Parser]::ParseInput($code, [ref]$null, [ref]$null)
Pour illustrer la représentation graphique d’un objet AST
, nous avons recours au module ShowPSAst
de PowerShell.
# install ShowPSAst module
Install-Module -Name ShowPSAst -Scope CurrentUser -Force
# import commands from ShowPSAst module
Import-Module ShowPSAst
# show the AST of a script or script module
Show-Ast Get-Date.ps1
Construire notre modèle de détection de scripts PowerShell malveillants
Notre algorithme implique trois étapes :
- Le script PowerShell est converti vers un AST.
- Les caractéristiques pertinentes sont calculées et extraites de l’AST en question. Nous obtenons une représentation numérique du fichier.
- Cette représentation est soumise à notre modèle de classification, constitué d’un ensemble d’arbres de décision, et entraîné au moyen de la technique de gradient boosting.
Nous assemblons une liste de commandes PowerShell et sélectionnons les 2 000 mots les plus fréquents comme vocabulaire. Pour extraire les caractéristiques, nous utilisons TF-IDF (term frequency-inverse document frequency) – mesure statistique évaluant la pertinence d’un mot pour un fichier donné, relativement à une collection de fichiers (corpus).
Travailler avec l’équipe CTI pour optimiser les résultats
Lorsqu’on analyse des scripts PowerShell non vus au préalable (et donc non étiquetés/labélisés), il est difficile de déterminer s’ils sont malveillants ou inoffensifs. C’est alors que les experts interviennent : l’équipe CTI peut efficacement qualifier nos données et fournir des retours sur la performance de cet algorithme. Sur un sous-ensemble de données, quand notre modèle trouve des scripts PowerShell potentiellement malveillants, nous les envoyons à l’équipe CTI pour qu’elle les analyse. Grâce à ces retours, il nous est possible d’améliorer notre jeu de données et définir le nombre de faux positifs.
Après validation de la conception et des performances de notre modèle, nous décidons de le tester sur des données de production réelles. Nous rassemblons des scripts PowerShell depuis les données de la télémétrie (issues des journaux d’événements Windows) et nous les inspectons avec notre modèle. Notre modèle a identifié certains scripts non détectés par notre moteur basé sur des règles et signatures.
L’intérêt de cette approche tient dans le fait que pour créer de nouvelles règles, l’équipe CTI doit constamment étudier des scripts (parfois même des milliers de scripts). Avec notre modèle, nous pouvons limiter cette analyse à une douzaine de fichiers, en trouvant dans le lot ceux qui sont réellement malveillants. Le processus d’écriture de nouvelles règles peut donc être allégé.
Conclusion : identifier des menaces et augmenter la valeur ajoutée grâce à l’IA
La collaboration entre les équipes IA et CTI est essentielle dans la création de nouveaux modèles. Dans notre scénario, l’équipe CTI a identifié une ressource pour laquelle l’IA pourrait représenter une valeur ajoutée : les scripts PowerShell. Avec leur aide, notre équipe a pu qualifier les données et améliorer le modèle, ce qui a permis de détecter efficacement des scripts PowerShell malveillants. La prochaine étape de cette collaboration consiste à déterminer dans quelle mesure notre modèle peut aider l’équipe CTI à écrire de nouvelles règles. Nous devons aussi qualifier les faux positifs dans notre modèle afin de nous assurer que nous fournissons un outil fiable à l’équipe.
Là encore, c’est en tirant parti des forces de chacune des équipes qu’il est possible de concevoir les défenses les plus puissantes.