Bring Your Own Script Interpreter
Ceci n’est qu’un fichier “txt”.
Récemment, j’ai effectué l’analyse d’un programme de type stealer. Le programme n’est pas détecté comme une menace parmi les solutions de sécurité. Son code source et son comportement ne laissait aucun doute sur la nature du programme. Alors pourquoi ce programme n’était pas détecté comme une menace ?
L’exemple du stealer
Le stealer en question s’installe via une charge écrite en batch. Le Batch est un fichier script qui permet de lancer des enchainements de plusieurs commandes. Celui-ci utilisait PowerShell afin de télécharger un fichier archive de type zip. Le script installait le contenu de l’archive et exécutait un programme dans ce contenu. Heureusement, cette partie était bien détectée par les solutions de sécurité. La suite de la charge malveillante ne l’est malheureusement pas !
Le programme installé est un interpréteur de langage de programmation. Ce programme lit un ensemble de fichier et exécute les actions du fichier comme à la manière d’un fichier batch. Dans le contexte du stealer, l’interpréteur était Python. Très connu des développeurs, ce programme interpréteur permet d’écrire de nombreux scripts dans des domaines variés (IA, réseau, site web, bureautique, base de données, etc). Ce programme est légitime. Il n’est pas malveillant en soi. Cependant, son usage ne l’est pas toujours ! Comme tout programme compilé, il est nécessaire d’obtenir une télémétrie sur des programmes interpréteurs. Cette télémétrie pourra à l’avenir détecter des comportements suspects.
Le script du stealer quant à lui piochait ses informations dans de nombreux fichiers des navigateurs web. Il récoltait les mots de passe enregistrés ainsi que les numéros de carte de crédit ! Malgré une évidence dans le comportement malveillant de ce programme, les solutions de sécurité de catégorie Endpoint Dectection Response (abrégé EDR) n’ont émis aucune alerte !
Les EDR et Antivirus
Pourquoi les solutions de sécurité n’ont pas détecté ce programme malveillant ? La cause est que ce programme est lancée par un interpréteur de script.
Analyse statique
La partie analyse statique des EDR et Antivirus se font berner par la nature d’un script. Un script est un fichier de type texte. Depuis un certain temps, les solutions de sécurité ont intégré les scripts batch, JavaScript et PowerShell comme des fichiers pouvant être suspects. Ses fichiers sont par nature de type texte et possèdent une extension. Pour les scripts de divers interpréteurs de commande, il existe une convention, mais il n’y a pas besoin de les respecter. Un fichier python peut très bien avoir une extension “.txt”, “.random”, etc. Le contenu de celui peut être obscurci (en: obfuscation) rendant la nature de l’identification difficile. En soi, une solution de sécurité ne peut pas détecter si un fichier texte abrite du code valide pour des interpréteurs. Du moins, il faudrait complexifier l’analyse statique.
Analyse Dynamique
L’analyse dynamique offre beaucoup plus d’opportunité de détection. La télémétrie comportementale peut ainsi aisément détecter l’ouverture de fichier sensible par des programmes inhabituels. Dans le cas du stealer, le processus python aurait dû être détecté comme suspect ! Il n’en est rien. Et ceux parce que la télémétrie a été sciemment désactivé par la solution comportementale.
Les programmes sur Windows possèdent une signature qui permet de vérifier l’authenticité de l’origine de celui-ci. Le programme python possède une signature valide et conforme. Il n’est en rien suspect, car il est légitime. Cette légitimité applique une règle de liste blanche sur le processus python. Ainsi, le stealer profite de cette légitimité pour être indétectable. Cette technique se nomme : “Bring Your Own Script Interpreter”.
Une autre explication est possible. Le volume de télémétrie est bien trop important lors de l’usage d’interpréteur. Les solutions de sécurité sont incapables de faire de la prise de décision sur les comportements illégitimes.
À vos indicateurs de compromission
Toute l’utilité de la télémétrie est d’être envoyée au sein d’un SIEM qui lui alertera sur des comportements suspects. Il est nécessaire d’appliquer des indicateurs de compromission correspondant au système d’information plutôt que de se reposer sur l’efficacité des solutions de sécurité avec des prises de décision automatique.
Quand on y réfléchit, la philosophie de protéger l’amont sans prendre en compte l’avale d’une attaque me fait persister à dire que les solutions de détection sont aussi loin d’être magiques.
Source :
Malware support group : lien du projet sur github
