Toutes les Menaces

Virus

Hackers

Spams

Whole site    Viruses
  
Encyclopédie Virus
Alertes
Analyses
Actualité
Glossaire

 
Calendrier

<< 2014  
Jan Feb Mar
Apr May Jun
Jul Aug Sep
Oct Nov  
Les Analyses les plus Populaires



Rapport de Kaspersky Lab sur les cybermenaces mobiles : les attaques visant Android sous stéroïdes



Courrier indésirable en août 2014



10 astuces simples pour renforcer la sécurité de votre Mac



Enquête sur un incident : vol dans une banque électronique



Gains assurés ou le véritable visage de la Chance déguisée
 
 

  Page d'accueil / Analyses

Rootkit, Rustock et tout le reste

15.07.2008   |   comment

Alexander Gostev
Expert Antivirus Senior, Kaspersky Lab

L'outil de dissimulation d'activité « insaisissable »

En décembre 2006, une rumeur sur la création d'un « outil de dissimulation d'activité absolument insaisissable » baptisé Rustock.C commença à circuler dans certains milieux d'étude de la problématique des outils de dissimulation d'activité (tels que blackhat et whitehat). Selon celle-ci, aucun des logiciels antivirus ou des solutions de lutte contre ces outils nommés Rootkit ne pouvaient l'identifier.

Les longues recherches sur cet « outil de Rootkit » ne donnèrent aucun résultat. La situation était telle que toute information relative à « Rustock.C » était considérée comme une blague par les spécialistes. Il en fut ainsi jusqu'en mai 2008.

Diagnostic du « médecin »

Au début du mois de mai, la société russe DrWeb annonça aux milieux spécialisés dans la lutte contre les virus que ses experts avaient découvert l'outil de Rootkit Ntlrdbot, qui était en fait Rustock.C. Cette nouvelle fut toute aussi mauvaise que sensationnelle.

A en croire les déclarations des représentants de DrWeb, cet outil de Rootkit était resté « sous le radar » de tous les éditeurs de logiciels antivirus depuis octobre 2007. Certains avancèrent même l'idée que Rustock.C avait contribué à la mise en place d'un des réseaux de zombies les plus puissants actuellement et destiné à la diffusion de courrier indésirable. Des liens vers les résultats d'une étude réalisée par la société Secure Works furent fournis. Selon cette étude, le réseau de zombies créé par Rustock occuperait la troisième place parmi les réseaux les plus importants et serait capable de diffuser chaque jour jusqu'à 30 milliards de messages non sollicités (source DrWeb).

Il est toutefois fort peu probable que les estimations de Secure Works concernent d'une manière ou d'une autre l'outil de Rootkit identifié car ce dernier était littéralement inconnu jusqu'en mai 2008. Plus probablement, les spécialistes de Secure Works pensaient au réseau créé par des versions antérieures de Rustock, à savoir les versions A et B (Costrat et SpamTool.Win32.Mailbot selon le classement de Kaspersky Lab).

D'après les informations publiées par d’un autre éditeur, un exemplaire de Rustock.C est tombé entre les mains des experts à la fin du mois de mars 2008 et plus d'un mois fut nécessaire pour analyser le code de l'outil de dissimulation et créer et diffuser les moyens de le détecter et de le supprimer. Ce n'est qu'après cela que les autres éditeurs de logiciels antivirus furent alertés.

La description de l'outil de Rootkit fournie était loin de répondre à toutes les questions. Tout d'abord, rien ne permettait de voir comment et quand cet outil de Rootkits était répandu et pourquoi il n'avait pas pu être découvert depuis octobre 2007.

L'exemplaire du corps de l'outil de Rootkitdiffusé était un pilote du système d'exploitation Windows d'une taille de 244 448 octets.

Malheureusement, le « dropper », ce fichier responsable de l'installation de l'outil dans le système, n'était pas présent. Il aurait pu faciliter considérablement la tâche des autres laboratoires antivirus au moment de l'analyse et de l'ajout de procédures complémentaires pour la découverte de Rustock.C et la neutralisation de ses effets et il aurait peut-être aussi apporté des éléments de réponses sur la diffusion initiale de cet outil de dissimulation d'activité.

Il manquait aussi des informations fiables sur la présence de cet outil de Rootkitdans la « nature ». Tout semblait indiquer que Rustock.C était un développement de « collection » et qu'il n'était pas vraiment diffusé, ce qui pouvait expliquer pourquoi tant de temps s'était écoulé avant sa découverte.

Analyse en laboratoire

Le 12 mai, Kaspersky Lab entama l'analyse détaillée du code de l'outil de dissimulation d'activité. La tâche qui attendait nos spécialistes était particulièrement complexe. Tout le code du Rootkit était chiffré selon une méthode inconnue et ne se prêtait pas aux méthodes traditionnelles d'analyse de code compacté et d’émulation. Le problème était accentué par le fait que chaque fichier de l'outil était en quelque sorte lié à une partie matérielle de l'ordinateur infecté et que l'outil ne pouvait être exécuté et analysé sur d'autres ordinateurs ou machines virtuelles.

Ceci étant dit, nos experts parvinrent à surmonter ces difficultés en deux jours et à déchiffrer une partie considérable du corps du virus à l'aide de la clé décryptée. Au soir du 14 mai, nous avions déchiffré des segments du code véritable de Rustock.C.

Conjointement à la résolution de ce problème technique complexe, nous avions lancé des tentatives de découverte du fichier qui installait l'outil de Rootkit dans le système. La découverte de ce fichier devait permettre non seulement d'accélérer l'analyse mais aussi d'identifier les sources de la diffusion de Rustock.C.

Nos recherches nous permirent de découvrir 599 fichiers de Rustock.C. Une partie d'entre eux présentaient ce qu'on appelle le « corps propre » du code Rootkit tandis que l'autre était composée des pilotes systèmes infectés. En fait, tous les fichiers étaient le résultat d'un polymorphisme appliqué au même code.

Quand ce Rootkit fut-il créé ?

Nous étions désormais en possession de six cents fichiers qui se distinguaient par leur taille et la date à laquelle ils avaient été capturés par nos pièges. Tous les fichiers trouvés étaient tombés dans le piège entre le 10 septembre 2007 et le 14 mai 2008. En sautant aux conclusions, je dirai que nous n'avons découvert aucun exemplaire de Rustock.C créé avant septembre 2007. Il n'est pas exclu que des versions plus anciennes aient apparu avant cette date telles que des versions d'évaluation ou des preuves de concept de l'auteur. Mais l'outil baptisé Ntldrbot par DrWeb possède une date de naissance claire : septembre 2007.

Où placer dans ce contexte les rumeurs sur l'existence de Rustock.C à la fin de l'année 2006 ? Nous pensons que Rustock.C n'existait pas à cette époque. Il fut créé bien après sa campagne de publicité particulière parmi les analystes d'outils de dissimulation d'activité, peut-être en guise de réaction face à l'hystérie liée aux recherches. Cette conclusion peut être confirmée indirectement par le fait que le code de l'outil de Rootkit contient le nom du programme malveillant « Rustock.C », ce qui correspond au nom donné par l'auteur aux versions Rustock.A et Rustock.B (« spambot » et numéro de la version). Le nom « Rustock » fut utilisé par la société Symantec pour désigner la première version de l'outil de Rootkit qui remonte à 2005 et 2006. Il était commun parmi les spécialistes de la problématique des outils de Rootkitet par analogie aux versions Rustock.A et .B déjà connues, la version « insaisissable » fut baptisée Rustock.C. Il se peut dès lors que l'auteur décida de nommer son nouvel outil de Rootkitde cette manière afin de confirmer les rumeurs sur son existence.

D'une manière ou d'une autre, les premières versions « fonctionnelles » de Rustock.C virent le jour en septembre 2007 et selon toute vraisemblance, le développement commença quelques mois auparavant.

Modifications

L'analyse de 599 fichiers mis en évidence de nombreux détails intéressants inconnus jusqu'alors.

Nous avons identifié 4 modifications de Rustock C.

Nous pensons que la version C1 fut créée le 10 septembre 2007. Le « corps propre » de l'outil de Rootkit a une taille comprise entre 244 440 et 244 512 octets et contient un pilote et une DLL. C'est cette version qui fut étudiée par les experts de DrWeb et présentée aux autres éditeurs de logiciels antivirus.

La version C2 remonte au 26 septembre. Sa taille est comprise entre 158 432 et 158 464 octets.

Les versions C3 et C4 ont été créées le 9 et le 10 octobre 2007. Leur taille est comprise entre 158 400 et 158 496 octets.

Bien que la version C1 diffère des versions suivantes de près de 100 Ko, il n'existe pas vraiment de grandes différences entre celles-ci. L'auteur a simplement optimalisé l'algorithme du corps de l'outil de dissimulation d'activité. Toutes les versions présentent des différences infimes au niveau du code de la DLL (spambot).

Spambot

Nous avons analysé l'outil de Rootkit durant cinq jours : il fut complètement décompacté et exécuté sur des machines virtuelles (malgré l'absence du « dropper »). Ceci nous permit d'accéder au code DLL (spambot) dont l'existence et la protection sont le but principal de Rustock.C.

Pendant son fonctionnement, l'outil de Rootkit extrait la DLL et l'exécute dans la mémoire système en s'infiltrant dans le processus winlogon.exe. Cette DLL n'existe jamais sous la forme d'un fichier sur le disque et se trouve uniquement dans la mémoire de l'ordinateur. Sa tâche est de diffuser du courrier indésirable depuis l'ordinateur infecté. Pour remplir son rôle, elle contacte le serveur 208.66.194.215 et reçoit les modèles des lettres à diffuser. L'adresse IP appartient au fournisseur d'hébergement MCCOLO qui abrite depuis longtemps déjà des programmes malveillants et les sites de groupes de cybercriminels.

Détection et réparation

Bien que l'auteur applique des outils de protection du corps de Rustock.C (protecteur, chiffreur, clé de chiffrement), l'ajout de la détection de cet outil de Rootkit dans les bases antivirus de Kaspersky Lab ne posa aucun problème. Il semblerait que l'auteur était tellement convaincu de l'efficacité du chiffrement de son oeuvre qu'il n'a pas vraiment prêté attention aux méthodes de résistance offertes par les logiciels antivirus. Le but qu'il poursuivait était de compliquer au maximum et de repousser au plus loin possible l'analyse du code (aussi bien par les éditeurs de logiciels antivirus que par les auteurs de virus) et les technologies de cryptographie employées allaient dans ce sens.

La réparation des systèmes de fichiers infectés par l'outil de Rootkit est un peu plus complexe. Le principe de fonctionnement d'un outil de Rootkit repose sur l'infection uniquement des pilotes Windows créés par Microsoft et chargés au lancement du système d'exploitation. C'est ainsi que l'outil de Rootkit peut prendre les commandes et dissimuler sa présence dans le système. Le pilote infecté original se trouvait dans la dernière section du corps de l'outil de Rootkit. Il était également chiffré.

L'algorithme permettant à l'outil de Rootkitde chiffrer le corps du pilote infecté était assez simple et ne dépendait pas d'une partie matérielle de l'ordinateur infecté. Nous avons pu ainsi détecter et réparer complètement les fichiers infectés.

L'outil de Rootkit reçu la classification Virus.Win32.Rustock.a. Il est rangé parmi les virus car Rustock est un virus de fichier à part entière qui fonctionne dans le noyau du système d'exploitation.

Les procédures de détection et de réparation des fichiers infectés furent diffusées par Kaspersky Lab le 20 mai 2008 (8 jours après le début de l'enquête).

La version la plus récente de notre logiciel antivirus, KAV/KIS 2009, est parfaitement capable de détecter un outil de Rootkit actif dans le système infecté et de réparer les fichiers infectés. Les utilisateurs des autres versions peuvent rechercher la présence éventuelle de Rustock sur leur ordinateur à l'aide de Rescue Disk et de n'importe quelle version de notre logiciel antivirus. Ils peuvent également identifier et réparer les fichiers suspects en l'absence d'une infection active.

Questions et réponses

On aurait pu croire que la tâche était terminée : l'outil de Rootkit a été dévoilé et les victimes disposent d'une solution fiable pour neutraliser le problème. Toutes les questions fondamentales étaient toujours sans réponses : comment Rustock s'était-il diffusé et existe-t-il vraiment « dans la nature » ? Répondre à ces questions et mettre les points sur les « i » étaient pour nous une question d'honneur.

Diffusion de Rustock

Pendant plusieurs jours, nous avons analysé en détail tous les échantillons de l'outil de Rootkit qui étaient en notre possession afin de définir leurs « paramètres matériels ». Cette analyse devait donner au moins une représentation approximative de l'ampleur de la diffusion de Rustock. Toutes les données correspondent aux dates de découverte des échantillons.

Ainsi, sur les 599 échantillons, 590 avaient été capturés par nos pièges entre le 10 septembre et le 23 novembre 2007. Contre 9 seulement entre le 23 novembre 2007 et le milieu du mois de mai 2008.

Ces statistiques furent utilisées pour définir les objets de la recherche et établir les relations entre les fichiers et les quatre versions de l'outil de Rootkit que nous connaissions.

Le tableau était le suivant :

Variantes Date de découverte Périodes d'apparition Nombre de fichiers
C1 10.09.2007 Du 10 au 13 septembre 2007 321
C2 26.09.2007 Du 27 septembre au 9 octobre 2007;
Du 12 au 22 novembre 2007
199
C3 Du 9 au 10 octobre 2007 Du 9 au 17 octobre 2007;
Du 12 au 22 novembre 2007
31
C4 9 au 10 octobre 2007 9-17 octobre 2007;
Du 12 au 22 novembre 2007
48

Entre le 17 octobre et le 12 novembre 2007, aucun cas d'apparition de Rustock ne fut enregistré. Toutefois, entre le 12 novembre et le 22 novembre, une nouvelle vague d'activité fut enregistrée, principalement liée à la version C2 (à partir du 26 septembre) avec des ajouts insignifiants des versions C3 et C4.

A partir du 23 novembre 2007, nous entrons dans une longue période de calme (ou de « mort » ?) de Rustock pendant quelques mois.

Ces données étaient vraiment intéressantes mais nous ne savions toujours rien de l'ampleur de la diffusion de Rustock et des moyens utilisés. Malgré tous les efforts déployés, nous n'avions pas encore trouvé le « dropper » de l'outil de dissimulation d'activité.

La chance allait nous sourire. Nous avions découvert encore 500 fichiers de l'outil de dissimulation d'activité, dont le chaînon manquant.

Rootkit et réseau de zombies

Nos conclusions qui indiquaient que la diffusion active de Rustock avait débuté le 10 septembre 2007 furent confirmées. Nous sommes désormais en mesure d'indiquer les serveurs d'où il était téléchargé et d'expliquer comment il s'installait dans le système. Nous trouvé la réponse aux questions « Où est le « dropper » et « Les utilisateurs de logiciels antivirus étaient-ils vraiment sans défense contre cet outil de Rootkit« insaisissable » qui s'est diffusé pendant au moins trois mois ? ».

Malheureusement, le mode de diffusion et les canaux utilisés par Rustock ont inquiété les experts de la sécurité informatique. Voici des noms bien connus de tout expert de la lutte contre les virus :

CoolWebSearch / IFrameBiz / Trafficadvance / LoadAdv.

Oui, nous sommes une fois de plus confrontés à un des groupes de cybercriminels les plus connus sur Internet et auquel sont associés ces noms. Ils désignent leurs sites et leurs programmes malveillants. La bande existe au moins depuis le début de l'année 2004 et est toujours en activité. Parmi les « œuvres » les plus connues et les plus diffusées de ce groupe, citons des chevaux de Troie tels que Harnig, Tibs, Femad, LoadAdv et diverses versions de Trojan-Downloader.Agent et Small, ainsi que le cheval de Troie Inject.

Ces individus capables ont toujours été à l'avant-garde de la création de virus : ils furent les premiers à utiliser les chevaux de Troie téléchargeurs dans les fichiers chm et c'est sur leurs serveurs que furent découvertes les premières versions des codes d'exploitation des vulnérabilités dans le traitement des fichiers ANI et ICO. Ils ont utilisé des chevaux de Troie écrit en Java (Trojan-Downloader.Java.ClassLoader) et ils ont lancé la mode des scripts de téléchargement.

La « signature » du groupe IFrameBiz fut pendant tout un temps des domaines dans la zone .biz et des noms de fichiers du style loadadv*.exe.

Les traces de ce groupe nous mènent en Russie. C'est dans ce pays que vivent la majorité des membres du groupe. A ses débuts, le groupe utilisait beaucoup de ressources d'hébergement à Saint-Pétersbourg. Il a également collaboré avec le tristement célèbre réseau RBN (Russia Business Network) que de nombreux spécialistes associent également à cette ville.

En quatre années d'existence, le groupe a créé un des systèmes de diffusion de programmes malveillant les plus puissants au monde. Son réseau de zombies, composée de millions d'ordinateurs infectés par divers chevaux de Troie téléchargeurs (en premier lieu, Tibs et Femad) est capable de charger sur les machines infectées n'importe quel nouveau programme malveillant en un laps de temps assez court. Cette technique est une alternative efficace à la diffusion de code malveillant par courrier indésirable, une méthode contre laquelle les éditeurs de logiciels antivirus ont appris à se battre efficacement.

Le réseau de zombies IFrameBiz intervient beaucoup dans la diffusion de nouveaux programmes malveillants. Le commanditaire paie pour une période de temps pendant laquelle son cheval de Troie sera diffusé à l'aide du réseau de zombies. Le « déversement » du programme peut alors commencer. Souvent, un téléchargeur (par exemple Tibs) installe plusieurs chevaux de Troie de différents commanditaires. Le service est très demandé et l'exécution simultanée de plusieurs commandes ne choque pas les clients.

Les créateurs de nombreux logiciels publicitaires ont recouru ou recourent aux services d'IFrameBiz tout comme les personnes désireuses de créer leur propre réseau de zombies, les diffuseurs de courrier indésirable, les organisateurs d'attaques par déni de service, etc. Si l'on souhaite dresser un parallèle avec RBN, alors nous pouvons dire que RBN est la façade matérielle et technique de l'activité des auteurs de virus tandis qu'IFrameBiz, c'est le programme et le bouton de lancement pour un grand nombre de programmes malveillants contemporains.

Et c'est précisément vers IFrameBiz que les auteurs de Rustock.C se sont tournés durant l'été 2007 afin de commander une diffusion. Soit les chevaux de Troie d'IframeBiz n'étaient pas capables d'activer discrètement Rustock dans les systèmes, soit les auteurs de l'outil de Rootkitne ne souhaitaient pas confier à l'exécutant le code de l'outil de Rootkitafin que les idées et les technologies ne puissent être volées, mais toujours est-il qu'un module totalement séparé fut créé pour le « déversement » via les canaux d'IFrameBiz !

Reconstitution des événements

Prenons un exemple concret afin de voir ce qui s'est passé à la fin du mois de septembre 2007 sur un des ordinateurs infectés appartenant au réseau de zombies IFrameBiz.

Le cheval de Troie téléchargeur (probablement Tibs) installé dans le système contacte un des serveurs du réseau de zombies dans la zone .hk (Croatie, les domaines de cette zone ont commencé à être utilisés par le groupe en 2007) et tente de télécharger le fichier loadadv351.exe.

Ce fichier est un module amélioré du réseau de zombies. Selon le classement de Kaspersky Lab, il s'agit de Trojan.Win32.Inject.mt. Le nom indique le but de l'action du programme malveillant : il s'introduit dans le processus Explorer.exe et contourne ainsi de nombreux pare-feu et peut dès lors télécharger des fichiers dans le système sans contrôle.

Le cheval de Troie envoie aux serveurs d'IFrameBiz des informations qui confirment la réussite de l'installation et reçoit des instructions sur les fichiers à télécharger et depuis quel endroit. C'est ainsi que fonctionne le système élémentaire de statistiques du réseau de zombies qui permet aux propriétaires du réseau de suivre le nombre de programmes malveillants dont le téléchargement a réussi et d'offrir des rapports aux commanditaires.

Le cheval de Troie télécharge dans le système plusieurs fichiers depuis divers serveurs appartenant aux commanditaires ou depuis les ressources qu'ils utilisent sur les serveurs d'IFrameBiz. Dans le cas qui nous occupe, les fichiers sont téléchargés depuis les ressources des clients louées sur IFrameBiz (http:// *.biz/progs/*). La collecte et l'envoi de données relatives à l'ordinateur infecté (système d'exploitation, disque dur, etc.) a lieu en même temps. Ces données sont requises pour tenir compte de l'état du réseau de zombies, sa répartition géographique, etc.

Quelques autres fichiers supplémentaires apparaissent dans le système dont deux, que nous appellerons « 1.exe » et « 2.exe » qui nous intéressent tout particulièrement. Pour commencer, nous allons nous pencher sur 1.exe (nous reviendrons sur 2.exe plus tard).

Il s'agit également d'un téléchargeur, mais inhabituel. Le premier exemplaire fut découvert par Kaspersky Lab le 10 septembre 2007, le jour de l'apparition des premières versions de Rustock. Cette coïncidence ne semble plus si étonnante, n'est-ce-pas ? Le même jour, nous avons découvert ce téléchargeur en tant que Trojan-Downloader.Win32.Agent.ddl.

Ce programme malveillant contient un pilote qui se charge dans le noyau du système d'exploitation (nous sommes en fait déjà confrontés à un outil de Rootkit!). Le code du pilote est chiffré à l'aide d'un algorithme complexe qui évoque beaucoup l'algorithme utilisé pour chiffrer Rustock.

Après avoir enlevé toutes les couches de protection du pilote, nous arrivons au point le plus intéressant : ce téléchargeur de Rustock est tout aussi « mythique » que l'outil de Rootkiten lui-même.

Le chaînon manquant

Alors que les rumeurs sur l'outil de Rootkit circulaient depuis décembre 2006, la seule et unique mention du téléchargeur et son existence remontent à la fin du mois d'octobre 2007, près de deux mois après sa découverte et son ajoute à nos bases antivirus. Faut-il préciser qu'en raison du caractère « insaisissable » de Rustock.C à l'époque, personne n'avait envisagé l'existence de son téléchargeur.

Toutefois, même après la découverte de Rustock.C, alors qu'il fallait trouver son « dropper », certains éditeurs de logiciels antivirus ne poussèrent pas leur recherche plus loin et se contentèrent de détecter l'outil de dissimulation d'activité. Ils ne voulaient pas perdre de temps pour comprendre comment l'outil de Rootkit était arrivé sur les ordinateurs ou pour savoir si les utilisateurs étaient vraiment sans défense face à « l'outil de Rootkitinsaisissable ».

Notre étude nous a permis de répondre à ces deux questions. A partir du 10 septembre 2007, depuis le tout premier jour de la diffusion via le réseau de zombies IFrameBiz de Rustock.C, Kaspersky Anti-Virus avait détecté son « compagnon », à savoir Trojan-Downloader.Win32.Agent.ddl. Plus tard, plusieurs autres éditeurs de logiciels antivirus allaient découvrir également ce cheval de Troie.

Pendant plusieurs mois, la seule manière de protéger les ordinateurs contre une infection pour l'outil de Rootkit« insaisissable » était de déceler en temps opportuns la présence de son téléchargeur.

Malheureusement, même à l'heure actuelle (au début du mois de juin 2008), certains logiciels antivirus sont toujours incapables de repérer Agent.ddl.

Téléchargeur

Comme nous l'avons dit plus haut, le cheval de Troie comprend deux composants : le corps et le pilote. Le pilote recueille les informations sur le système : identificateurs des fabricants et modèles des périphériques sur la carte mère, date d'installation et version exacte du système d'exploitation. Ensuite, ces informations sont chiffrées et transmises au serveur de l'auteur de Rustock (ou des commanditaires) : 208.66.194.215.

Contenu du tampon transmis au serveur
sous forme chiffrée (TEA) :
TSC, Bridge0, Bridge1, InstallDate, Version, ProductID.

Le serveur vers lequel les données sont envoyées (208.66.194.215) est le même que celui que nous avons rencontré dans l'outil de RootkitDLL (spambot). C'est de là que Rustock reçoit les messages pour les diffusions. Toutefois, la méthode d'interaction du pilote du téléchargeur avec le serveur diffère de la méthode utilisée dans le spambot.

Le pilote Agent.ddl travaille directement avec les périphériques TCP/IP depuis le cercle zéro, ce qui signifie que le trafic sortant de la machine victime d'une infection active ne peut être découvert à l'aide de certains sniffeurs/pare-feu. Agent.ddl établit la connexion sur le port 443 et tente de masquer les données sous les paquets du protocole HTTPS. Par conséquent, le chercheur, même s'il intercepte le trafic au niveau de la passerelle, ne comprend pas tout de suite qu'il ne s'agit pas de quelque chose en rapport avec HTTPS mais simplement des données chiffrées recueillies sur l'ordinateur infecté.

Voici un exemple de paquet d'une machine infectée présenté sous la forme de données HTTPS :

Qui plus est, la clé de chiffrement change à chaque exécution du pilote. La complexité de la découverte tient au fait que l'observateur externe ne connaisse pas l'algorithme et la clé de chiffrement.

Il convient de remarquer que les auteurs du cheval de Troie téléchargeur ont clairement essayé de compliquer au maximum la vie des individus souhaitant étudier le code du pilote.

L'adresse IP du serveur central ainsi que le port utilisé pour communiquer avec le pilote sont protégés dans le corps du programme afin de dissimuler leur présentation évidente :

push 00000BB01 ; port – 443
push 0E00C04E1
sub d,[esp],00849C211; Différence égale 0xD7C242D0, à savoir adresse IP
208.66.194.215

Les auteurs se sont également concentrés sur l'obfuscation du code. Voici, à titre d'exemple, une simple opération

mov [eax], ecx

qui ressemble à ceci après l'obfuscation :

push ebx
mov ebx, 0x03451b8c
sub ebx,eax
sub ebx, 0x03451b8c
neg ebx
mov [ebx], ecx
pop ebx

Ce qui au départ n'était qu'une instruction est devenu 7 instructions. On peut aisément s'imaginer ce que réserve les « entrailles » du pilote !

Revenons à la communication de réseau. Le code malveillant a envoyé un paquet contenant les données relatives à l'ordinateur infecté. En réponse à ces données, le serveur a envoyé un fichier spécialement chiffré pour cette machine avec une clé correspondant au matériel de l'ordinateur à l'origine de la requête.

C'est ainsi que les auteurs ont réglé la question du dropper qui aurait pu être découvert, étudié ou exécuté et qui aurait évité aux enquêteurs de devoir « craquer » la clé pour analyser le code de l'outil de dissimulation d'activité.

Le fichier généré de l'outil de dissimulation d'activité, le « corps propre », est chargé sur l'ordinateur de la victime où Agent.ddl l'active dans le système. Rustock.C infecte son premier pilote système et le réseau de zombies de diffusion de courrier indésirable compte un ordinateur de plus.

A l'heure actuelle, le serveur est bloqué. Tous les paquets qui lui sont envoyés sont filtrés par des routeurs de réseau. Cela signifie certainement que les autorités compétentes se sont déjà intéressées à l'adresse IP citée.

Conclusion

La reconstitution des événements à laquelle nos experts se sont livrés prouve la propagation active de ce Rootkit entre septembre et octobre 2007. D'un côté, l'utilisation à cette fin du réseau IFrameBiz pouvait en effet lui garantir une large diffusion. D'un autre côté, les faits avancés prouvent que le caractère « insaisissable » de l'outil de Rootkitétait uniquement lié au haut degré de chiffrement du code et à l'utilisation d'une multitude d'astuces pour lutter contre le débogage, ce qui compliquait le travail d'analyse des experts.

Les éditeurs de logiciel antivirus possédaient l'outil de Rootkitdepuis son apparition « dans la nature ». Son activité lors de l'installation dans le système et les composants responsables de son installation et de sa diffusion étaient identifiés depuis longtemps par la grande majorité des logiciels antivirus, à de rares exceptions près. Son apparition dans le système pouvait être interceptée au tout début du processus à l'aide de quelques outils de surveillance des modifications du système de fichiers.

Tout cela s'est produit avec Rustock des dizaines de fois, mais ce n'est qu'en mai 2008 qu'une analyse détaillée du code fut réalisée.

Rustock.C existe bel et bien et n'est pas un mythe. Le mythe, c'est son caractère « insaisissable » qui ne repose sur aucun principe surnaturel de dissimulation intégré dans l'outil mais uniquement sur les rumeurs lancées à la fin de l'année 2006 et qui faisaient uniquement le jeu des auteurs du programme malveillant.

N'importe quel outil de Rootkit créé en tenant compte des outils de détection actuels trouvera un moyen de contourner la protection que ces outils offrent. L'issue de la lutte au niveau du noyau du système d'exploitation tient en fin de compte à la réponse à une question : qui obtiendra la gestion le premier : l'outil de Rootkit ou le logiciel de lutte contre ces outils.

L'auteur de Rustock ne voulait pas créer un outil de Rootkitindétectable mais compliquer au maximum le processus d'analyse de l'outil après sa découverte. C'est précisément cet élément qui aurait pu garantir un gain temporaire entre la période de diffusion et le début de la détection du programme malveillant.

Une seule question est toujours sans réponse : pourquoi l'auteur de Rustock a-t-il interrompu l’amélioration de l’outil et la diffusion de nouvelles versions à la mi-octobre 2007 ? Cela ne voudrait-il pas dire qu'il s'est impliqué dans un nouveau projet et qu'il existe peut-être quelque part « Rustock.D » ?

Nous ne possédons pas la réponse. Quoi qu'il en soit, l'existence même d'un programme malveillant unique, même s'il n'est pas découvert pendant quelques mois, n'a aucune influence sur l'apparition chaque jour de dizaines de milliers d'autres programmes malveillants éliminés avec succès par les éditeurs de logiciels antivirus.

Tant qu'IframeBiz et d'autres groupes similaires, responsables de la diffusion quotidienne de centaines de nouveaux programmes malveillants, de l'intrusion dans de nombreux sites Internet et de dizaines d'épidémies, continueront à exister sur Internet nous ne pourrons pas célébrer les victoires remportées dans une bataille locale.

P.S. : nous avons dit plus haut que Trojan.Win32.Inject.mt installait dans le système deux fichiers : 1.exe et 2.exe. Nous n'avons pas expliqué ce qu'était le deuxième fichier.

Il s'agissait d'une autre version du cheval de Troie espion Sinowal. Ce même Sinowal qui quelques mois après les événements décrits représenta un autre problème d'envergure pour les éditeurs de logiciels antivirus et qui est entré dans l'histoire en tant que « bootkit ».

Rustock et Sinowal se sont propagés simultanément et via le même réseau de zombies. Les nouvelles versions de Rustock ont cessé d'apparaître au milieu du mois d'octobre 2007. Les premiers exemplaires du bootkit ont été découverts un mois plus tard, en novembre 2007.

S'agit-il d'une simple coïncidence ?

Peut-être obtiendrons-nous un jour la réponse à cette question.

Source:
Kaspersky Lab
 

Copyright © 1996 - 2014
Kaspersky Lab
Industry-leading Antivirus Software
All rights reserved
 

Email: webmaster@viruslist.com