Techniques de persistence des malwares
Pour maintenir sa présence sur une machine, les malwares peuvent avoir recours à plusieurs techniques de persistance. Pour les débusquer et les déloger, il est nécessaire de les chercher à plusieurs endroits, pas toujours trivial.
Persistance en clé de registre
Run et RunOnce
Sessionn manager
Winlogon
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinlogonzHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon,
est utilisée au démarrage de Windows afin de lancer les scripts nécessaires à l'authentification. Idéal pour un loger un malware.Clés Startup
Au démarrage de la machine, le contenu des clés suivantes sont également lancées :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Certains malwares se logent à ces endroits pour être lancées au démarrage.
Si le malware possède des privilèges élevés, il peut s'installer dans les mêmes clés de la ruche HKLM.
Services
Les services lancés au démarrage de Windows sont situés dans la clé de registre suivante : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services.
Tâches planifiées
Les tâches planifiées sont aussi une des persistance les plus utilisées par les malware.
Il est possible de détecter la création de nouvelles tâches planifiées dans les journaux d'évènements 4698.
Crédit : microsoft.com
Persistance WMI
WMI est un outil permettant très utilisé pour l'administration de Windows en gérer les ressources du système. WMI permet de monitorer, pousser des scripts d'installation ou même contrôler une machine distante.
Les différents outils utilisés par WMI sont situés dans un répertoir que l'on nomme la WMI Database, située dans %SYSROOT%\system32\wbem\Respository. Ce dossier contient plusieurs fichiers dont la base OBJECTS.DATA.
Le fichier OBJECTS.DATA contient les objets gérés par WMI, typiquement, les bindings (event filter + event consumer). Il est alors possible, en interrogeant cette base de données d'obtenir la liste des scripts exécutés par WMI et donc potentiellement déceler une commande malveillante.
Un évènement WMI est composé de 3 éléments :
- __EventFilter : requête SQL (WQL) qui est la condition du déclanchement de l'évènement
- __EventConsumer : action déclanchée lorsque la condition décrite dans __EventFilter est rencontrée
- __FilterToConsumerBinding : assemble la condition et le déclencheur
Un attaquant créée un event filter, une condition, qui lorsqu'elle est remplie, déclenche l'event consumer, l'action que l'on veut effectuer. Il est courant pour un attaquant d'intégrer dans l'event consumer le code malveillant, encodé en base 64, ainsi aucun fichier n'est stocké sur la machine.
Les conditions de déclenchement de la charge peuvent être la valeur de l'uptime de la machine, pour lancer la charge à chaque boot de la machine, un timer, afin de contacter le serveur de contrôle tous les x temps. Dans ce second cas, il s'agit de vérifier tous x temps si des ordres sont disponibles sur le serveur de contrôle. L'event consumer contiendrait alors une commande permettant d'obtenir un shell et si ce shell venait à être coupé, au prochain déclenchement de l'évènement, un nouveau shell sera créé.
Pour rendre le code persistant au reboot de la machine, l'évènement WMI doit être créé avec un système d'abonnement. Il faut cependant être administrateur de la machine afin de créer un abonnement.
Ci-dessous, le répertoire WBEM a été collecté grâce à l'outil KAPE d'Eric Zimmerman, puis la base OBJECTS.DATA parsée avec PyWMIPersistenceFinder.py de David Pany. Il est possible d'observer le binding SCM Event Log Filter, légitime, et le suivant, contenant l'exécution de cmd.exe malveillante.
Crédit : 13Cubed - The ABCs of WMI - Finding Evil in Plain Sight
L'activité est journalisée dans le journal d'évènement Microsoft-Windows-WMI-Activity/Operational et lors d'une investigation, l'évènement 5861 apparaît lors de la création d'un script WMI (event consumer).
Crédit : Ben Greenberg - Demo 16 - WMI as a Persistence and C2 Mechanism
Afin de détecter l'utilisation de WMI, il est possible de consulter le journal d'évènement WMI mais également en vérifiant les connexions réseau : WMI utilise le port TCP 135.
Egalement, il est possible via Sysmon de surveiller les activité WMI et ainsi détecter les créations d'event consumer suspects.

Installation d'un service
Il est courant qu'un malware, afin de s'installer sur une machine, s'installe sous la forme d'un service sur la machine infectée.
Lorsque cela se passe, l'évènement 4697 est créé , visible comme suit :
Crédit : microsoft.com
La plupart du temps, le nom du service créé usurpera celui d'un processus système Windows pour passer inaperçu tel que svchost, lsass par exemple.
Dans la MBR
Appelés des bootkit, certains malware modifient le secteur de boot contenue dans la MBR du disque afin d'établir sa persistance en évitant les mécanismes anti-virus par exemple, puisqu'il démarre avant l'OS même.
Afin de les détecter et les suprimer, certains outils permettent de scanner la MBR comme GMER ou RogueKiller.
En mémoire
Certains malware n'utilisent pas de fichiers pour leur persistance, limitant ainsi leur détection. Ils s'injectent en mémoire au travers de plusieurs méthodes comme l'injection de code dans un fichier légitime.
Pour cela, le fichier peut être une DLL légitime dont le code est désalloué pour être remplacé par le code malveillant.
Il existe plusieurs type d'injection de code. L'article techniques d'injection de code détaille ces différentes techniques.