Février est maintenant démarré, et Conficker est toujours présent au sein de nombreux réseaux d’entreprise. En effet, la nature des vecteurs de propagation utilisés et la difficulté à identifier les systèmes infectés compliquent grandement son éradication.

Une des caractéristiques des différentes variantes de Conficker est d’utiliser un algorithme interne pour générer chaque jour 250 noms de domaine potentiels sur lesquels le malware pourra par exemple récupérer un nouveau contenu à exécuter. Partant de ce principe, une méthode détournée pour détecter les machines infectées dans un réseau peut consister à observer les requêtes émises à destination de tout ou partie de ces domaines.

A cet effet, et à partir de l’analyse de plusieurs spécimens de Conficker A et B, notre collègue Florent a généré deux listes de noms de domaine, par semaine et jusqu’à fin Février, pour chacune des deux variantes (il ne faudrait pas oublier Conficker.A, qui semble encore bien actif dans certains réseaux) :

Il est par exemple possible d’utiliser les listes dans vos proxies filtrants, ou encore de modifier vos serveurs DNS internes pour rediriger le trafic à destination de ces domaines malveillants vers un serveur Web de l’entreprise (joli pot de miel pour vos machines infectées, toutes vos IPs sont dans vos logs !).

Pour répondre à une autre interrogation concernant la propagation par clefs USB, il est amusant de noter que Conficker s’adapte à la langue du système infecté quand il propose, grâce à la fonctionnalité Autoplay, son frauduleux « Ouvrir le dossier pour afficher les fichiers » :

En effet, il récupère via la fonction GetModuleHandleA un handle sur la bibliothèque shell32.dll, pour charger la chaine de uID « 17154 » de cette même ressource avec la fonction LoadStringA. Sur un système français, cela correspond à « Ouvrir le dossier pour afficher les fichiers ». Sympa, si la chaine obtenue est de taille nulle, il prend alors la chaine par défaut « Open folder to view files » :