Logiciels malveillants sans fichier et attaques par détournement d’outils légitimes

Les logiciels malveillants traditionnels écrivent des fichiers exécutables sur le disque, ce qui permet aux antivirus fondés sur les signatures de les analyser et de les détecter. Les logiciels malveillants sans fichier fonctionnent entièrement en mémoire — ou détournent des outils légitimes déjà installés — et ne laissent aucun fichier malveillant traditionnel que l’AV puisse trouver. Cela réduit considérablement les taux de détection par les outils fondés sur les signatures. Les fournisseurs de solutions de sécurité indiquent que les attaques de logiciels malveillants sans fichier ont 10 fois plus de chances de réussir que les attaques utilisant des fichiers. Le braquage de la Bangladesh Bank en 2016, les variantes de Petya/NotPetya apparues en 2017 et d’innombrables intrusions menées par des États ont utilisé des techniques sans fichier pour maintenir leur persistance et échapper à la détection.

Les attaques Living-off-the-Land (LotL) utilisent des outils et utilitaires légitimes déjà présents sur le système de la victime pour mener des actions malveillantes. Ces outils — PowerShell, WMI, certutil, mshta, regsvr32, rundll32 — sont approuvés par le système d’exploitation et les logiciels de sécurité, car ils ont des fonctions légitimes. Un attaquant qui utilise exclusivement les outils intégrés peut se fondre dans l’activité administrative normale. Pour les défenseurs, le défi consiste à distinguer l’utilisation malveillante de ces outils du travail administratif légitime. C’est pourquoi l’analyse comportementale et la compréhension du contexte sont plus efficaces que la détection par signatures pour les techniques LotL.

PowerShell est l’outil LotL le plus détourné, car il donne accès à l’ensemble du framework .NET, à WMI et aux API Windows, tout en laissant peu de traces lorsqu’il est exécuté en mémoire. Les attaquants téléchargent directement les scripts PowerShell en mémoire sans les écrire sur le disque, encodent les commandes en Base64 pour les dissimuler à la journalisation et utilisent des fonctionnalités comme la réflexion pour charger des assemblys .NET en mémoire. Les frameworks Empire et Cobalt Strike dépendent largement de PowerShell après l’exploitation. Les mesures de défense comprennent le PowerShell Constrained Language Mode, la ScriptBlock Logging (qui journalise le contenu décodé des scripts), la Module Logging et la restriction des personnes autorisées à exécuter PowerShell au moyen de la stratégie de groupe.

WMI (Windows Management Instrumentation) est une fonctionnalité Windows puissante destinée à l’administration des systèmes, que les attaquants détournent pour assurer leur persistance et effectuer des déplacements latéraux. Un abonnement à un événement WMI déclenche une commande lorsqu’un événement donné se produit (par exemple toutes les 5 minutes, lors de l’ouverture de session ou au démarrage d’un processus précis). Ces abonnements survivent aux redémarrages, sont stockés dans le référentiel WMI et n’apparaissent pas comme des tâches planifiées traditionnelles ou des clés d’exécution du registre, ce qui leur permet d’échapper à de nombreux outils de détection de la persistance. Les attaquants peuvent également utiliser WMI pour exécuter des processus sur des systèmes distants via DCOM (port 135), permettant ainsi les déplacements latéraux sans partages réseau.

L’injection de processus permet à un logiciel malveillant d’exécuter du code malveillant dans l’espace d’adressage d’un processus légitime et approuvé (explorer.exe, svchost.exe, notepad.exe). Le code malveillant hérite des privilèges et de l’identité du processus, ce qui donne l’impression que les connexions réseau proviennent d’une application approuvée. Les techniques d’injection courantes comprennent l’injection de DLL (chargement d’une DLL malveillante dans un autre processus), le process hollowing (création d’un processus suspendu, suppression du mappage de son code et remplacement par du code malveillant) et l’injection réflexive de DLL (chargement direct d’une DLL depuis la mémoire sans l’écrire sur le disque). Les outils EDR détectent les injections en surveillant les séquences d’appels d’API (OpenProcess, VirtualAllocEx, WriteProcessMemory, CreateRemoteThread).

De nombreuses chaînes d’attaque sans fichier commencent par un document Office malveillant contenant des macros VBA. Lorsque l’utilisateur ouvre le document et active les macros (souvent incité par un message tel que « Enable Content to view this document »), la macro exécute PowerShell pour télécharger et exécuter une charge utile directement en mémoire. La charge utile ne touche jamais le disque : seul le document Office d’origine y est écrit. C’est pourquoi l’examen Security+ insiste sur la désactivation des macros et le déploiement de règles ASR (Attack Surface Reduction). Les frameworks modernes d’hameçonnage de type « attaquant au milieu » (comme Evilginx2) diffusent également des documents malveillants après la capture des informations d’identification afin de déployer des RAT.

AMSI (Antimalware Scan Interface) est une API Windows qui permet aux applications (PowerShell, VBScript, JScript, Office) de soumettre du contenu au moteur antivirus installé afin qu’il l’analyse lors de l’exécution, même avant que ce contenu ne soit écrit sur le disque. AMSI permet aux fournisseurs d’AV d’analyser le contenu des scripts qui serait autrement invisible pour l’analyse fondée sur les fichiers. Les attaquants tentent de contourner AMSI en modifiant amsi.dll en mémoire afin de renvoyer un résultat « clean » pour toutes les soumissions, ou en obfusquant le contenu des scripts pour échapper à la correspondance des signatures. Les outils EDR surveillent les tentatives de modification d’AMSI comme indicateur d’une activité d’attaque sans fichier.

La détection des logiciels malveillants sans fichier nécessite de passer de la détection fondée sur les fichiers à la surveillance comportementale. Les principales stratégies de détection comprennent : la PowerShell ScriptBlock Logging, qui capture le contenu décodé des scripts même s’il est encodé sur la ligne de commande ; Sysmon, qui journalise la création des processus avec leurs lignes de commande complètes, les connexions réseau avec l’attribution aux processus et les modifications du registre ; les règles comportementales EDR, qui génèrent des alertes sur les relations suspectes entre processus (Word lançant PowerShell, PowerShell lançant cmd, certutil téléchargeant des exécutables) ; et la transmission des événements Windows, qui envoie ces journaux vers un SIEM centralisé pour corrélation et conservation à long terme.

Les organisations peuvent réduire la surface d’attaque LotL en limitant les utilisateurs autorisés à exécuter des outils puissants. Le PowerShell Constrained Language Mode limite les appels .NET, les objets COM et la réflexion dont dépendent les attaquants. AppLocker et WDAC (Windows Defender Application Control) peuvent empêcher l’exécution de certains binaires par les utilisateurs qui ne sont pas administrateurs. Le projet LOLBAS répertorie les binaires LotL connus ainsi que leurs techniques d’attaque, ce qui aide les défenseurs à déterminer quels binaires surveiller ou restreindre. Tous les binaires LotL ne peuvent pas être bloqués (beaucoup sont nécessaires au fonctionnement du système d’exploitation), mais il est possible de surveiller leur utilisation en tenant compte du contexte.

Le framework MITRE ATT&CK documente largement les techniques sans fichier et LotL. Parmi les sous-techniques importantes figurent : T1059.001 (PowerShell), T1047 (exécution WMI), T1055 (injection de processus), T1140 (désobfuscation/décodage de fichiers), T1003.001 (mémoire de LSASS pour l’extraction d’informations d’identification) et T1546.003 (abonnement à un événement WMI pour la persistance). La mise en correspondance de vos capacités de détection avec ces techniques à l’aide d’ATT&CK Navigator révèle les lacunes de couverture et oriente l’élaboration des règles SIEM. Le framework fournit également des recommandations d’atténuation et de détection pour chaque technique.

Une stratégie de défense en profondeur contre les logiciels malveillants sans fichier comprend : l’activation de la journalisation PowerShell (ScriptBlock, Module, Transcription), le déploiement de Sysmon avec une configuration complète, la mise en œuvre d’AMSI avec un moteur AV à jour, l’application du PowerShell Constrained Language Mode via WDAC, la restriction de l’exécution des macros dans les documents Office au moyen de la stratégie de groupe, le déploiement d’un EDR doté de capacités de détection comportementale et la transmission de tous les journaux à un SIEM contenant des règles de détection pour les chaînes de processus connues comme malveillantes. La combinaison de la réduction de la surface d’attaque et de l’amélioration de la visibilité rend les attaques sans fichier beaucoup plus difficiles à exécuter sans être détectées.

Dans cette leçon, vous avez appris que les logiciels malveillants sans fichier fonctionnent en mémoire et détournent des outils légitimes du système d’exploitation comme PowerShell, WMI et certutil pour échapper à la détection fondée sur les signatures ; que les techniques d’injection de processus dissimulent du code malveillant dans des processus approuvés en exploitant les API de gestion de la mémoire Windows ; et que la détection comportementale au moyen de SIEM, Sysmon et EDR, associée à la journalisation PowerShell et à AMSI, constitue la défense la plus efficace contre ces chaînes d’attaque qui échappent aux signatures. Nous allons maintenant étudier la différence entre l’analyse des vulnérabilités et les tests d’intrusion.