Bypass runtime / AMSI

Le runtime, ou environnement d'exécution, est un ensemble de logiciels et de bibliothèques qui permettent à un programme informatique de s'exécuter. Lorsqu'un code ou une application est exécuté, il passe généralement par un runtime, qui peut être spécifique à un langage de programmation particulier comme .NET.

Par exemple, le CLR (Common Language Runtime) et le DLR (Dynamic Language Runtime) sont des runtimes couramment utilisés avec .NET. Ils peuvent analyser le code avant son exécution pour détecter les comportements suspects ou malveillants.

AMSI, ou Anti-Malware Scan Interface, est une mesure de détection au runtime intégrée nativement à Windows. Contrairement aux antivirus traditionnels qui analysent les fichiers sur le disque, l'AMSI analyse le code directement en mémoire au moment de son exécution. Cela lui permet de détecter les menaces potentielles plus efficacement, car il peut surveiller le comportement du code en temps réel.

En résumé, le runtime est l'environnement d'exécution dans lequel le code s'exécute, tandis que l'AMSI est une interface de détection de logiciels malveillants intégrée à Windows, qui analyse le code en mémoire au moment de son exécution pour détecter les menaces potentielles.


🔙 Rétrogradation de PowerShell :

Généralement la version 2.0, qui ne dispose pas des fonctionnalités de sécurité des versions plus récentes:

PowerShell -Version 2

Cette attaque est activement exploitée dans des outils tels que Unicorn. Par exemple:

full_attack = '''powershell /w 1 /C "sv {0} -;sv {1} ec;sv {2} ((gv {3}).value.toString()+(gv {4}).value.toString());powershell (gv {5}).value.toString() (\\''''.format(ran1, ran2, ran3, ran1, ran2, ran3) + haha_av + ")" + '"'

Détection et atténuation :

Pour se protéger contre cette attaque, il est recommandé de supprimer le moteur PowerShell 2.0 du périphérique ou de limiter l'accès à PowerShell 2.0 via des restrictions d'application.


🔄 Relfexion powershell - AMSI

La réflexion en informatique permet à un programme d'examiner et de modifier sa propre structure interne pendant son exécution, plutôt qu'à la phase de compilation. Cela inclut la capacité à accéder à des éléments internes normalement inaccessibles, comme des classes, des méthodes ou des attributs non publics d'une assembly .NET spécifique.

Nous l'utilisons pour accéder et modifier une fonctionnalité interne liée à AMSI. En utilisant la réflexion, le code peut accéder à des éléments non publics d'une assembly .NET spécifique, en l'occurrence l'assembly contenant les utilitaires AMSI de PowerShell. Cela permet de contourner les restrictions normalement imposées par AMSI en modifiant une propriété interne de manière à indiquer que l'initialisation d'AMSI a échoué. Cela trompe Windows Defender en l'empêchant de scanner le script ou le code malveillant, car il pense que l'AMSI n'est pas fonctionnel ou n'a pas été correctement initialisé.

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

Cette commande effectue les actions suivantes :

  1. Obtient le type de l'utilitaire AMSI dans l'assembly.

  2. Récupère le champ interne "amsiInitFailed".

  3. Définit sa valeur sur "true", contournant ainsi l'AMSI.


🔥 AmsiScanBuffer

Une fois que la fonction a examiné le contenu du , elle rapporte les résultats à la bibliothèque amsi.dll. Cette bibliothèque utilise des techniques de scan et des signatures antivirus pour déterminer si le contenu du buffer est malveillant.

La vulnérabilité réside dans le fait que l'on peut potentiellement contrôler le contenu du buffer avant que la fonction AmsiScanBuffer ne l'analyse. Cela signifie qu'un attaquant pourrait remplacer le contenu du buffer avec un code spécifique qui indique un résultat propre ou non malveillant.

Nous pouvons utiliser ce script pour contourner AmsiScanBuffer.

Ce code modifie dynamiquement la fonction AmsiScanBuffer dans la bibliothèque amsi.dll chargée dans le processus PowerShell. Cela permet de désactiver la fonction de numérisation de l'AMSI, ce qui peut permettre l'exécution de scripts malveillants sans détection.


🛑 AMSI.fail

AMSI.fail génère des extraits PowerShell obscurcis qui interrompent ou désactivent AMSI pour le processus en cours. Les extraits sont sélectionnés aléatoirement parmi un petit pool de techniques/variations avant d’être obscurcis.

Chaque extrait de code est obscurci au moment de l'exécution ou de la demande, afin qu'aucune sortie générée ne partage les mêmes signatures.

Après avoir obscurci le code à l'aide d'amsi.fail, vous pouvez l'attacher au début de n'importe lequel de vos scripts malveillants comme avec les contournements précédents ou l'exécuter dans la même session avant l'exécution.


🖱️ AMSITrigger

AMSITrigger est un outil utilisé pour identifier automatiquement les chaînes de caractères qui signalent des signatures potentielles dans les fichiers (script malveillant). Il permet de les modifier et de les casser, ce qui les rend inefficaces pour les mécanismes de détection d'AMSI.

Syntaxe:

-i, --inputfile=VALUE       Powershell filename
-u, --url=VALUE             URL eg. https://10.1.1.1/Invoke-NinjaCopy.ps1
-f, --format=VALUE          Output Format:
                              1 - Only show Triggers
                              2 - Show Triggers with Line numbers
                              3 - Show Triggers inline with code
                              4 - Show AMSI calls (xmas tree mode)
-d, --debug                 Show Debug Info
-m, --maxsiglength=VALUE    Maximum signature Length to cater for,
                              default=2048
-c, --chunksize=VALUE       Chunk size to send to AMSIScanBuffer,
                              default=4096
-h, -?, --help              Show Help

Exemple :

Supposons que vous ayez un script malveillant PowerShell appelé bypass.ps1 que vous souhaitez analyser à l'aide d'AMSITrigger. Voici comment vous pouvez le faire :

AMSITrigger.exe -i "chemin_vers_bypass.ps1" -f 3

Ensuite, vous pouvez examiner les chaines de caractères détecté pour voir quelles parties de votre code pourraient être détectées par AMSI.

Vous pouvez ainsi modifier ces parties du script pour les rendre moins détectables par les mécanismes de sécurité, comme en changeant les noms de variables, en ajoutant des caractères d'échappement, ou en obscurcissant le code.


Last updated