Bibliothèque
Ma bibliothèque

+ Ajouter à la bibliothèque

Contacter-nous !
Support 24/24 | Rules regarding submitting

Nous téléphoner

0 825 300 230

Forum

Vos requêtes

  • Toutes : -
  • Non clôturées : -
  • Dernière : le -

Nous téléphoner

0 825 300 230

Profil

Revenir vers la liste d'actualités

Trojan.Mayachok.2: analyse du premier bootkit VBR

Le 12 juillet 2011

Selon nos statistiques récentes, la modification du MBR lors du processus de contamination est une nouvelle tendance chez les pirates. Le Trojan.Mayachok.2 infecte le Volume Boot Record et perturbe le fonctionnement des navigateurs.

L'infection du système

Avant de commencer l'attaque, un dropper analyse le système pour voir s’il est déjà infecté ou pas. Pour ce faire, un CLSID est crée à la base du numéro de série du volume système: si la clé HKLM\Software\Classes\CLSID n'est pas encore dans le registre, l'infection continue.

Dans les OS Windows Vista et Windows 7, le trojan cherche à augmenter ses droits. Cette méthode a déjà été utilisée par d'autres programmes malveillants: le programme redémarre sans arrêt en demandant plus de droits. Un utilisateur avancé peut facilement arrêter ce processus dans le Gestionnaire des tâches.

L'arrêt d'une tâche du trojan dans le Gestionnaire des tâches.

Le dropper possède un driver de 32- et de 64- bits, qui peut ensuite assurer le lancement de toutes les fonctionnalités pirates du programme. L'un des driver est enregistré en fonction du système, il peut être enregistré au début du disque (avant la première partition active) s’l y a assez de place, ainsi qu’ à la fin du disque. Il est facile de voir l'erreur dans la « logique » du trojan, ainsi si la première partition n’est pas celle de boot, le driver réenregistre des données aléatoires de n'importe quelle partition entre le début et la partition de boot, car le choix de l’emplacement pour l’écriture est hasardeuse et n’est limité que par des secteurs libres (du point de vue du trojan).

Ensuite, commence la contamination du VBR (Volume Boot Record). Le programme malveillant n'infecte pas le système si le format des fichiers n'est pas NTFS. Analysant l'entrée de démarrage, le trojan trouve un endroit où se placer et écrase le code original de cet emplacement. Le code d’origine est compressé avec la bibliothèque aplib (http://www.ibsensoftware.com) et enregistré tout de suite après le code du virus. Le numéro du secteur et la taille du secteur sur le disque où le driver a été enregistré auparavant sont également enregistrés dans le VBR infecté.

Il faut noter le mécanisme spécial de l'infection. Les virus modifiant le MBR (Master Boot Record) et les secteurs BOOT sont apparus à l'époque de DOS, et les nouveaux OS offrent encore plus d'opportunités pour les pirates. Dans le cas analysé, le secteur BOOT est le premier secteur VBR, qui pour la partie NTFS occupe 16 secteurs. Ainsi l'analyse classique du secteur de lancement ne permet pas de détecter l'objet malveillant, car il se trouve plus loin dans le VBR.

Suite à la contamination du système, le Trojan.Mayachok.2 installe une petite application sur le disque qui sert à faire redémarrer le système automatiquement. Il faut noter qu’un autre bootkit, Trojan.Hashish, agit de la même façon. A la fin, le trojan cherche à « brouiller les pistes » et à se supprimer.

Lancement depuis le VBR

Comparaison des premiers secteurs VBR d’un système « propre » et d’un système infecté. La différence est montrée en rouge – le code d'installateur de virus.

Au moment où l'installateur commence à contrôler la gestion, il agit selon le schéma classique pour les virus MBR/BOOT. Il « mord » un bout de la mémoire, s'installe dedans et intercepte l’interruption 13h pour examiner le contenu des secteurs du disque. Ensuite, il lance entièrement son driver et décompresse à sa place le code VBR. La gestion est de nouveau contrôlée par l'installateur système.

Ensuite on observe une série d'installations et de désinstallations des interceptions dans les modules chargés, comme par exemple ntldr, bootmgr, osloader.exe, winload.exe etc. , en fonction de l’installateur utilisé par l’OS. Il faut noter qu’en plus des interceptions habituelles (splicing) les registres debug (dr0-dr7) et le traçage (le code est exécuté par étapes) sont aussi utilisés. Tout cela rend le trojan polyvalent et représente un moyen d’outrepasser le système de protection de l’intégrité de certains modules de boot. Au final, le driver de virus prêt à fonctionner est chargé dans la mémoire du noyau.

Le driver d'installation

Le point de sortie du driver du trojan est adressé deux fois. Alors que le code du VBR infecté ne fait que 2078 octets, l’auteur du Trojan a décidé d’implémenter certaines fonctions dans le corps du driver.  Au premier appel le driver s'ajoute à la liste LOADER_PARAMETER_BLOCK : dans LoadOrderList en tant que copie du premier module (kernel de l'OS) et dans BootDriverList en tant que driver d'installation qui est soit disant enregistré dans \Registry\Machine\System\CurrentControlSet\Services\null. Ainsi le programme imite son lancement en tant que simple driver boot.

Le driver est lancé pour la deuxième fois par l'OS même qui croit l'avoir téléchargé lui-même. Toutes ses manipulations provoquent des conséquences.

Ainsi le driver Null apparait dans le système mais en regardant attentivement on voit qu'il a été crée par le kernel (ntoskrnl.exe).

En même temps il existe un autre kernel dans les modules téléchargés, où les paramètres DllBase et SizeOfImage appartiennent au driver de virus.

Pour voir si le système est infecté, vous pouvez taper la commande simple «echo hello >nul», si le système est infecté, la commande ne sera pas effectuée et le système affichera une erreur.

La tâche du driver consiste à injecter son code dans les processus en cours.

Le driver de 64- bits, les bibliothèques aplib sont en rouge.

L'intégration du code est réalisée par l'installation les notifications via les fonctions PsCreateProcessNotifyRoutine et PsCreateProcessNotifyRoutine avec un appel ultérieure de la fonction asynchrone via le mécanisme APC. Lors de l'étude nous avons appris que le driver de 64- bits a deux bibliothèques.

Seule la première est utilisée, la deuxième est prévue pour l'avenir.

Le driver de 32- bits intégrant un shell code dans les processus.

Aujourd'hui le mécanisme de contamination de Trojan.Mayachok.2 est unique. Les spécialistes Doctor Web estiment que ce mécanisme sera sans doute bientôt utilisé dans d'autres programmes malveillants.

Votre avis nous intéresse

Pour poser une question sur une news aux administrateurs du site, mettez @admin au début de votre commentaire. Si vous postez une question à l'attention de l'auteur d'un commentaire, mettez le symbole @.avant son nom.


Other comments