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

C'est la technique de persistance la plus commune et la plus basique. Le malware se loge dans le répertoire de programmes lancés au démarrage en créant une entrée dans la clé de registre HKCU\Software\Microsoft\Windows\CurrentVersion\Run ou HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce.

Si le malware possède des privilèges élevés, il pourrait également modifier  clés de registre Run et RunOnce de la ruche HKLM, rendant le malware persistant pour tous les utilisateurs de la machine.
 

Sessionn manager

Lors du démarrage d'une machine, le smss, chargé de la gestion des sessions, est lancé. Ce dernier charge le contenu de la clé HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Session Manager.
Certains malware peuvent s'y loger afin d'être exécuté au boot.

Pour se protéger de ce type de persistance, il est conseillé d'activer la valeur autocheck, vérifiant l'intégrité des systèmes de fichiers. Cette valeur doit être l'unique entrée dans ce registre.

Winlogon

La clé de registre UserInit

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.

Windows Server: How to Detect Who Created a Scheduled Task in Real Time -  TechNet Articles - United States (English) - TechNet Wiki 

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.

Pour se débarrasser d'une persistence WMI, il est possible de la supprimer via Autoruns de Sysinternals ou via Powershell avec Get-WMIObject puis Remove-WMIObject.
 
 
Crédit : Threat Punter - Detecting & Removing an Attacker’s WMI Persistence

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.