Windows Defender : AMSI.dll

Comment y échapper ?

Posté par Matthieu le 9 Avril 2020

Introduction

La semaine dernière, alors que je préparais une charge pour un exercice RedTeam j’ai été confronté à un problème : une charge que j’avais obfusquée bypassait totalement Windows defender sur ma machine Windows 10 à jour, mais se faisait détecter par ce même Defender sur la machine Windows 10 de test.

Comment se fait ce ? Nous allons y répondre dans cet article.

AMSI.DLL

Cette librairie, Anti Malware Scan Interface, est chargée par powershell.exe à son lancement. Son but est de détecter des comportements malicieux dans l’exécution d’un script Powershell ou Macro office.

La technique repose sur le fait que peu importe le nombre de couche d’obfuscation présente dans votre binaire, la chaine finale sera forcément passée en clair dans la RAM a un moment voulu. C’est à ce moment qu’une fonction exportée par la dll (AmsiScanBuffer) est utilisée par powershell afin de vérifier que cette chaîne est bénigne.

Le problème auquel j’ai été confronté est donc facilement explicable.

Cette fameuse librairie n’existe pas pour Powershell V2 (comme plusieurs autres mécanismes de sécurité), et ma charge force donc l’utilisation de Powershell V2 afin de se défaire de ces sécurités :

Set-StrictMode -Version 2 

Cette technique fonctionne, cependant les installations récentes de windows 10 ne posséderont pas la version 2 de Powershell, ce qui entrainera l’exécution de ma charge par une version plus récente de Powershell et donc la détection de mes chaines obfusquées. C’est exactement ce qui m’est arrivé, la machine que je ciblais était assez récente et ne possédait donc pas Powershell V2

Comment nous en échapper ?

Ce mécanisme permet en effet de détecter beaucoup plus de charges malveillantes car nous n’avons plus la possibilité de nous échapper des signatures via de l’obfuscation. En outre, il n’est pas infaillible. La librairie est chargée par le process de Powershell, il nous est donc possible de patcher cette librairie directement en RAM et de nous affranchir de son analyse.

Ainsi, plusieurs techniques de patch ont vu le jour et certaines sont répertoriées sur ce github.

Essayons avec la technique la plus connues (celle de Matt Graebers) :

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Bon … Évidement les bases virales ont eu vent de cette technique et ont signaturé les différentes techniques de bypass. Affranchissons-nous de ces signatures via Invoke-Obfuscation :

Essayons des techniques basiques de modification de chaine de caractères :

Voici le résultat que nous propose Invoke-Obfuscation, la technique est simple mais elle peut permettre de passer outre certaines signatures. Testons maintenant le payload obfusqué :

Parfait ! Defender n’y a vu que du feu et nous sommes maintenant affranchis de cette sécurité.

Essayons maintenant d’y glisser notre charge (dans le process qui n’est plus surveillé par AMSI bien sûr), pour ma part j’ai opté pour ma charge cobalt strike qui avait alarmé Windows Defender lors de mes tests :

A noter : je n’affiche pas toute la charge car j’ai réécrit la première partie de celle-ci.

Quelques instants plus tard :

W00t ! Un accès sur mon Command & Control ! C’est donc une réussite.

Conclusion

Nous avons donc vu brièvement le fonctionnement de AMSI.dll ainsi que son rôle dans la sécurité de notre machine de travail. Nous avons aussi vu que le jeu du chat et de la souris entre mécanisme de sécurité et bypass est toujours bien présent et qu’une flopée de technique de bypass a vu le jour suite à l'ajout de cette fonctionnalité.

Cet article était volontairement très cours car je profite du confinement pour me consacrer à plein temps a un projet qui sera rendu public une fois terminé. Merci pour votre lecture et Happy Hacking !

34 Coeur(s)