Les premiers root kits procédaient de manière plutôt rudimentaire. Elle consistait à remplacer les utilitaires du noyau du système par des versions qui cachaient les fichiers et les processus malware. Par exemple, la version root kit de l’utilitaire Unix servant à lister les processus actifs, ps, a omis le processus
Principes de base des root kits
![Principes de base des root kits Principes de base des root kits](https://www.itpro.fr/wp-content/uploads/2015/09/6bce4675de918d342f3a57df43a94269.jpg)
malware de la liste de ceux obtenus à partir du kernel et l’utilitaire de listing des répertoires Unix, ls, a fait de même pour les fichiers malware dans les listings de répertoires.
Au fur et à mesure que les utilitaires système se sont sophistiqués et que les utilitaires tierce partie et les solutions antivirus ont proliféré, la simple technique du remplacement des fichiers pour les root kits est devenue inopérante. Ecrire des logiciels de remplacement pour Task Manager, Tasklist, et tous les autres outils de listing de processus couramment utilisés sur des systèmes Windows demanderait beaucoup de travail à l’auteur du root kit. Et tout ce travail se ferait en pure perte si un utilisateur exécutait un utilitaire non compromis, comme un scanner de virus ou un outil de listing de processus différent.
Les développeurs de root kits sont donc montés d’un cran dans la sophistication, en attaquant non pas des applications spécifiques, mais les API qu’elles utilisent pour obtenir l’information. En interceptant l’API par laquelle une application obtient la liste des processus actifs et en supprimant le processus malware de la liste renvoyée à l’application, le root kit se dissimule lui-même aux yeux de Task Manager et des autres utilitaires de listing de processus qui utilisent l’API directement ou indirectement. Les root kits modernes procèdent ainsi pour cacher fichiers, répertoires, clés de registres et valeurs, services Windows, et drivers de périphériques, ports TCP/IP, comptes utilisateur et processus. Bien entendu, les root kits ôtent généralement les processus malware de la vue système modifiée, afin que le malware ait la maîtrise complète du système.
La figure 1 montre le root kit bien connu Hacker Defender en action. Il est constitué d’un fichier de configuration et d’une image exécutable. Quand vous exécutez hxdef.exe, il dissimule les fichiers, les répertoires, les drivers, les services, les processus et les ports TCP/IP que vous listez dans le fichier de configuration. Le fichier de configuration par défaut dissimule ceux de ces éléments dont le nom contient la chaîne hxdef. Et donc, dans le second listing, le répertoire semble vide.
Comme le montre la figure 2, Windows a plusieurs couches API, et différents root kits attaquent des couches différentes, selon le niveau de sophistication du root kit. Les API de plus haut niveau sont mieux documentées et plus faciles à intercepter par les root kits, tandis que l’interception des API de niveau inférieur, fournit une dissimulation plus poussée. Ainsi, un root kit qui se dissimule au niveau de la couche API Windows n’est pas efficace contre une application qui obtient son information directement de l’API native.
Les root kits en mode utilisateur peuvent dissimuler tout processus qui s’exécute dans le compte dans lequel le malware se lance, mais sont plus efficaces quand on les exécute dans un compte doté du privilège Debug Programs. Le groupe Administrators a ce privilège par défaut, ce qui permet aux root kits d’infecter tout ou partie des processus du système, y compris ceux qui pourraient s’exécuter dans le compte Local System, comme les processus antivirus et anti logiciel espion. Par conséquent, les root kits plaident eux aussi pour la pratique prudente qui consiste à fonctionner comme un utilisateur non privilégié dans la mesure du possible.
Les root kits les plus puissants sont ceux en mode kernel. Toutefois, ils exigent que le malware s’exécute dans un compte qui a la possibilité d’installer un driver de périphérique, et par conséquent ils ne fonctionneront pas à partir d’un compte utilisateur privilégié de la même manière que les root kits en mode utilisateur le peuvent. Il faut une grande compétence pour mettre en oeuvre des root kits en mode kernel et il faut les coder très soigneusement, parce qu’un bogue détruira l’OS. Un auteur de root kit ne veut certainement pas attirer l’attention sur le root kit en lui faisant détruire une application ou un ordinateur.
Téléchargez cette ressource
![Guide inmac wstore pour l’équipement IT de l’entreprise](https://www.itpro.fr/wp-content/uploads/2024/04/Guide-inmac-wstore-Juillet-2024.jpg)
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre nouveau dossier thématique sur l’éco-conception et les bonnes pratiques à adopter pour réduire votre impact environnemental.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Guide des certifications Microsoft
- Transition vers le Cloud : l’approche stratégique pour répondre aux exigences de cybersécurité NIS 2
- Vers une meilleure qualité de données : l’IA vient en renfort
- Stimuler l’innovation durable grâce à la transformation numérique et aux principes ESG
- Retour au bureau avec Copilot M365
![Revue Smart DSI](https://www.itpro.fr/wp-content/uploads/2024/07/SMART-DSI-Numero-34-Juin-2024.jpg)