Comment l’interface de scan anti-malware (AMSI) vous aide à vous défendre contre les logiciels malveillants
Pour une introduction à l’interface de scan anti-malware (AMSI) de Windows, veuillez consulter la section Interface de scan anti-malware (AMSI).
En tant que développeur d’applications, vous pouvez participer activement à la défense contre les logiciels malveillants. Plus précisément, vous pouvez aider vos clients à se protéger contre les logiciels malveillants (malware) basés sur des scripts dynamiques et contre les attaques cybernétiques par voies non traditionnelles.
Prenons un exemple où votre application est scriptable : elle accepte un script arbitraire et l’exécute via un moteur de script. Au moment où un script est prêt à être fourni au moteur de script, votre application peut appeler les API AMSI de Windows pour demander un scan du contenu. De cette façon, vous pouvez déterminer de manière sécurisée si le script est malveillant ou non avant de décider de l’exécuter.
Ceci est vrai même si le script a été généré à l’exécution. Les scripts (malveillants ou non) peuvent subir plusieurs passes de débrouillage. Mais vous devez finalement fournir au moteur de script un code clair, non brouillé. C’est à ce moment-là que vous invoquez les API AMSI.
Voici une illustration de l’architecture AMSI, où votre propre application est représentée par l’un des cadres « Autres applications ».
L’interface AMSI de Windows est ouverte. Cela signifie que n’importe quelle application peut l’appeler et n’importe quel moteur anti-malware enregistré peut traiter le contenu soumis.
Il n’est pas nécessaire de limiter la discussion aux moteurs de script. Il est possible que votre application soit une application de communication, et qu’elle scanne les messages instantanés pour détecter les virus avant de les montrer à vos clients. Ou alors votre logiciel est un jeu qui valide les plugins avant de les installer. Il existe de nombreuses possibilités et scénarios pour utiliser AMSI.
AMSI en action
Regardons de plus près AMSI en action Prenons un exemple où Windows Defender est l’application qui appelle les API AMSI. Vous pouvez cependant appeler les mêmes API depuis votre propre application.
Voici un exemple de script utilisant la technique de codage XOR pour cacher son intention (que celle-ci soit bénigne ou non). Pour cet exemple, nous pouvons imaginer que ce script a été téléchargé sur Internet.
Pour rendre les choses plus intéressantes, nous pouvons saisir ce script manuellement dans la ligne de commande de sorte qu’il n’y ait pas de fichier réel à surveiller. Cela reflète ce qu’on appelle une « menace sans fichier ». Ce n’est pas aussi simple que de scanner les fichiers sur disque. La menace pourrait être une porte dérobée qui ne se trouve que dans la mémoire d’une machine.
Ci-dessous, nous voyons le résultat de l’exécution du script dans Windows PowerShell. Vous verrez que Windows Defender est capable de détecter l’échantillon de test AMSI dans ce scénario complexe, simplement en utilisant la signature standard de l’échantillon de test AMSI.
Intégration d’AMSI avec JavaScript/VBA
Le workflow illustré ci-dessous décrit le flux de bout en bout d’un autre exemple, dans lequel nous démontrons l’intégration d’AMSI avec l’exécution de macros dans Microsoft Office.
- L’utilisateur reçoit un document contenant une macro (malveillante), qui échappe aux analyses antivirus statiques en utilisant des techniques telles que le brouillage, les fichiers protégés par mot de passe, etc.
- L’utilisateur ouvre alors le document contenant la macro (malveillante). Si le document s’ouvre en mode Protégé, l’utilisateur clique sur Activer la modification pour quitter le mode Protégé.
- L’utilisateur clique sur Activer les macros pour permettre l’exécution des macros.
- Lorsque la macro s’exécute, le runtime VBA utilise un buffer circulaire pour enregistrer [1] les données et les paramètres liés aux appels aux API Win32, COM et VBA.
- Lorsque des API Win32 ou COM spécifiques considérées à haut risque (également connues sous le nom de déclencheurs) [2] sont observées, l’exécution de la macro est interrompue et le contenu du buffer circulaire est passé à AMSI.
- Le fournisseur de services anti-malware AMSI enregistré répond avec un verdict pour indiquer si le comportement de la macro est malveillant ou non.
- Si le comportement n’est pas malveillant, l’exécution de macro se poursuit.
- Si au contraire le comportement est malveillant, Microsoft Office ferme la session en réponse à l’alerte [3], et l’AV peut mettre le fichier en quarantaine.
Qu’est-ce que cela signifie pour vous ?
Pour les utilisateurs de Windows, tout logiciel malveillant qui utilise des techniques de brouillage et d’évasion sur les hôtes de script intégrés à Windows est automatiquement inspecté à un niveau beaucoup plus profond qu’auparavant, offrant des niveaux de protection supplémentaires.
Pour vous en tant que développeur d’application, envisagez de faire appel à l’interface AMSI de Windows si vous souhaitez bénéficier (et protéger vos clients avec) d’analyses et d’analyses supplémentaires de contenu potentiellement malveillant.
En tant que fournisseur de logiciels antivirus, vous pouvez envisager d’implémenter le support pour l’interface AMSI. Lorsque vous le faites, votre moteur aura une vision beaucoup plus approfondie des données que les applications (y compris les hôtes de script intégrés à Windows) considèrent comme potentiellement malveillantes.
Plus d’informations sur les menaces sans fichier
Vous pourriez être curieux d’en savoir plus sur les types de menaces sans fichier contre lesquelles Windows AMSI est conçu pour vous aider à vous défendre. Dans cette section, nous examinerons le classique jeu du chat et de la souris qui se déroule dans l’écosystème des logiciels malveillants.
Nous utiliserons PowerShell comme exemple. Mais vous pouvez utiliser les mêmes techniques et processus que nous allons démontrer avec n’importe quel langage dynamique - VBScript, Perl, Python, Ruby etc.
Voici un exemple de script PowerShell malveillant.
Bien que ce script écrive simplement un message à l’écran, les logiciels malveillants sont généralement plus néfastes. Mais vous pourriez facilement écrire une signature pour détecter celui-ci. Par exemple, la signature pourrait rechercher la chaîne « Write-Host 'pwnd!' » dans tout fichier que l’utilisateur ouvre. Excellent : nous avons détecté notre premier logiciel malveillant !
Après avoir été détecté par notre première signature, cependant, les auteurs de logiciels malveillants répondront. Ils répondent en créant des scripts dynamiques comme cet exemple.
Dans ce scénario, les auteurs de logiciels malveillants créent une chaîne représentant le script PowerShell à exécuter. Mais ils utilisent une simple technique de concaténation de chaînes pour briser notre signature précédente. Si vous consultez la source d’une page Web chargée de publicités, vous pourrez voir de nombreux exemples de cette technique utilisée pour éviter les logiciels de blocage de publicités.
Enfin, l’auteur de logiciels malveillants passe cette chaîne concaténée au mécanisme cmdlet—PowerShell Invoke-Expression pour évaluer les scripts composés ou créés à l’exécution.
En réponse, les logiciels anti-malware commencent à faire une émulation de langage basique. Par exemple, si nous voyons deux chaînes être concaténées, alors nous émulons la concaténation de ces deux chaînes, puis nous exécutons nos signatures sur le résultat. Malheureusement, c’est une approche assez fragile, car les langages ont tendance à avoir beaucoup de façons de représenter et de concaténer des chaînes.
Ainsi, après avoir été attrapé par cette signature, les auteurs de logiciels malveillants passeront à quelque chose de plus compliqué - par exemple, en codant le contenu du script en Base64, comme dans cet exemple suivant.
La plupart des moteurs anti-malware étant ingénieux, ils implémentent également l’émulation de décodage Base64. Ainsi, puisque nous implémentons également l’émulation de décodage Base64, nous sommes en avance pendant un certain temps.
En réponse, les auteurs de logiciels malveillants passent au brouillage algorithmique - comme un simple mécanisme de codage XOR dans les scripts qu’ils exécutent.
À ce stade, nous sommes généralement au-delà de ce que les moteurs antivirus émuleront ou détecteront, donc nous ne détecterons pas nécessairement ce que fait ce script. Cependant, nous pouvons commencer à écrire des signatures contre les techniques de brouillage et de codage. En fait, c’est ce qui représente la grande majorité des signatures pour les logiciels malveillants basés sur des scripts.
Mais que se passe-t-il si le brouilleur est si trivial qu’il ressemble à de nombreux scripts au comportement sans reproche ? Une signature pour cela générerait un nombre inacceptable de faux positifs. Voici un exemple de script stager trop bénin pour être détecté à lui seul.
Dans cet exemple, nous téléchargeons une page Web et invoquons du contenu. Voici l’équivalent en script Visual Basic.
Ce qui aggrave les choses dans ces deux exemples, c’est que le moteur antivirus inspecte les fichiers ouverts par l’utilisateur. Si le contenu malveillant vit uniquement en mémoire, l’attaque peut potentiellement passer inaperçue.
Cette section a montré les limites de la détection à l’aide de signatures traditionnelles. Mais, alors qu’un script malveillant peut passer par plusieurs passes de débrouillage, il doit finalement fournir au moteur de script un code clair, non brouillé. Et à ce moment-là - comme nous l’avons décrit dans la première section ci-dessus - les hôtes de script intégrés à Windows appellent les API AMSI pour demander un scan de ce contenu non protégé. Et votre application peut faire la même chose.