A l’intérieur des root kits en mode utilisateur

mis en oeuvre dans \windows\system32\ kernel32.dll. Une application telle que Windows Explorer ou l’invite de commande qui veut utiliser l’API, l’importe à partir de kernel32.dll, statiquement ou dynamiquement.

ADLL n’est chargé dans un processus que quand un exécutable tournant dans le processus nécessite les API exportées par le DLL. Quand un exécutable importe une API statiquement, l’image de l’exécutable contient les références au DLL et aux API dans une section appelée table d’importation, que le chargeur d’OS évalue pendant le démarrage du processus. Le chargeur charge chaque DLL figurant dans la table d’importation, dans l’espace d’adresse du processus et connecte les références des images aux fonctions référencées, comme le montre la figure 3.

Une importation dynamique se produit quand un processus déjà en action utilise la fonction Windows LoadLibrary pour charger un DLL, et la fonction GetProcAddress pour demander à l’OS l’adresse d’une fonction exportée par DLL. Vous pouvez utiliser l’outil Dependency Walker à partir de http://www.dependencywalker.com pour visualiser les importations et exportations statiques d’une image et même lancer un exécutable profilé de manière à capturer ses importations dynamiques. La figure 4 montre comment Notepad importe FindFirstLine.

L’une des méthodes qu’utilisent de nombreux root kits pour cacher le malware, consiste à scanner la table d’importation d’un processus et à remplacer les références aux fonctions DLL système clés par des pointeurs vers des fonctions root kit qu’il met en oeuvre dans son propre DLL ou qu’il a écrites directement dans l’espace d’adresse du processus. Dès lors qu’un processus a été relié de cette manière, appelée DLL import hooking, un appel qu’il adresse à FindNextFile, par exemple, conduit au code du root kit. Le code du root kit invoque la fonction originale dans Kernel 32 mais reprend le contrôle des opérations dès que la fonction est terminée. Le root kit examine ensuite la sortie et en extrait les données associées aux fichiers et aux répertoires que le root kit dissimule. Pour affronter le « liage » dynamique, le root kit doit relier GetProcAddress et renvoyer à l’appelant un pointeur vers la fonction hook du kit racine, au lieu de la fonction que l’appelant veut utiliser. Le root kit Vanquish utilise cette technique, illustrée dans la figure 5.

La plupart des API Windows liées aux fichiers, aux mémoires et aux processus, s’appuient sur des API de niveau inférieur exportées par \windows\system32\ntdll.dll, qui fournit des interfaces avec l’API native en mode utilisateur qui est exposée par le noyau (kernel) de l’OS. Task Manager utilise l’API NtQuerySystemInformation mise en oeuvre dans Ntdll pour interroger les processus actifs, donc un root kit qui veut dissimuler un processus peut relier cette fonction et triturer sa sortie pour extraire les processus malware. Les API de listing de fichiers Windows mentionnées utilisent NtQueryDirectoryFile de Ntdll, de sorte que la manipulation des données renvoyées par NtQueryDirectoryFile affecte les données renvoyées par FindFirstFile et FindNext- File. Les root kits relient souvent les fonctions de plus haut niveau – ne reliant Ntdll que quand c’est nécessaire – parce c’est généralement plus facile et que de nombreux utilitaires système n’utilisent que les fonctions de plus haut niveau.

Une autre technique de root kit en mode utilisateur consiste à « patcher » les fonctions API Windows et API natives en mode utilisateur. Le fameux root k i t Hacker Defender pratique cette méthode. Le patching consiste à écrire le code du root kit dans un processus cible et à modifier les premiers octets des fonctions perverties dans ce processus, afin qu’elles transfèrent le contrôle au code du root kit. Dès que le code du root kit a pris les commandes, il invoque une version non modifiée de la fonction et manipule les résultats avant de les renvoyer à l’appelant.