Rencontre avec le malware Karagany

Nous allons disséquer un malware découvert sur un poste compromis. Peu importe comment a été découvert le maliciel dans ce cas, le but de cet article n'étant pas de proposer des moyens de découverte ou d’acquisition de logiciels malveillants mais bien de comprendre le trafic généré, ceci permettant de proposer une analyse de risques détaillée.

Peu étonnant, le binaire découvert est « packé ». Nous allons donc le « dé-packer » pour découvrir qu'en fait il s'agit d'un « dropper » permettant de placer n'importe quel binaire. Le deuxième malware qui, dans ce cas, a infecté la victime est un « ransomware » qui sera également analysé afin de savoir si des fonctionnalités avancées de « rootkit » ou de capture de frappe clavier (« keylogger ») existent.

1. Analyse comportementale

La première phase de l'analyse passe par l'analyse comportementale. Celle-ci comprend un laboratoire avec plusieurs machines (souvent virtuelles) permettant de simuler un environnement réel, mais sans connexions extérieures effectives (ceci afin d'éviter au logiciel de se répandre, d'infecter d'autres systèmes ou d'envoyer du spam par exemple). Nous infectons volontairement plusieurs machines tournant sous Windows XP et enregistrons le comportement de ces machines.

1.1 Détection de la souche

Afin de savoir à quoi nous avons affaire, nous scannons le fichier avec VirusTotal [vt]. Il est important de noter que VirusTotal partage les hashes et les fichiers avec les éditeurs d'antivirus ou autres constructeurs de systèmes de sécurité. Il ne convient donc pas à tous les cas de recourir à ce service. Il est en revanche toujours possible de chercher le hash sur VirusTotal afin de vérifier s'il s'agit d'un sample connu ou non.

Le résultat semble montrer que nous sommes en présence d'un malware au doux nom de « Karagany » ou « Dapato » (extrait du résultat de VirusTotal) :

1.2 Capture réseau

Lors de la capture réseau, nous découvrons plusieurs requêtes HTTP (GET et POST).

Tout d'abord les requêtes POST :

La requête contient des données binaires ne nous fournissant pas plus d'informations pour le moment. Le but sera de déterminer ce qui se cache à l'intérieur de ce « blob » binaire par ingénierie inverse.

Voyons voir de plus près les requêtes GET :

Et tout de suite après :

Les requêtes GET se retrouvent régulièrement plusieurs fois par minute, contrairement aux requêtes POST qui ne se retrouvent que lors de l'infection initiale. Nous pouvons déjà deviner que les requêtes en direction de « google.com » sont certainement des tests afin de vérifier si la victime peut atteindre un site Internet.

1.3 Capture système

Pour ce type de capture, il existe plusieurs outils ; notre préférence se tourne vers « Process Monitor » de Microsoft (anciennement « Sysinternals ») [sysint].

La capture système nous fournit quelques pistes sur les modifications faites sur notre hôte Windows XP, comme par exemple une entrée dans la base de registre permettant de s'ouvrir au démarrage : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.

La création de deux dossiers : C:\Documents and Settings\[]\Local Settings\Application Data\Microsoft\VSComponentset C:\Documents and Settings\[]\Local Settings\Application Data\Microsoft\Windows\xxxx. La référence à « xxxx » semblant être un nombre au hasard sur quatre chiffres.

Dans le dernier dossier, nous trouvons notre binaire (copié depuis la source de l'infection), ainsi qu'un fichier sans extension qui semble contenir des données chiffrées ou obfusquées.

 

 

Jusqu'ici, nous sommes en face de comportements standards associés à la plupart des logiciels malveillants.

2. Analyse dynamique et statique

Nous tentons d'extraire les chaînes de caractères imprimables, mais nous remarquons rapidement que le spécimen est « packé ». Un article expliquant comment « dé-packer » une variante de « Karagany » existe [rootbsd], mais malheureusement, cette marche à suivre ne fonctionne pas pour cette variante. En effet, la fonction VirtualAlloc()n'est pas chargée au démarrage de l'application, mais certainement pendant l'exécution. Nous allons donc, malgré tout, nous inspirer de la méthode de « rootbsd » pour déchiffrer cette variante.

2.1 « Unpacking »

Après l'analyse des premières fonctions, nous remarquons un appel étrange sur le registre « ECX » :

Nous mettons un breakpoint sur cet appel et nous lançons notre « malware ». Le breakpoint est atteint et nous remarquons que ce CALL nous amène dans une région de la mémoire qui a été allouée pendant l'exécution :

Nous suivons le saut (JMP), nous nous retrouvons dans une fonction comportant un nombre assez important d'appels.

Après un certain temps à suivre les différents appels, nous trouvons la fonction utilisée pour la copie du binaire en mémoire :

Les paramètres de la fonction sont les suivants :

Nous allons donc pointer sur la région « 00157E48 » et sauvegarder cette zone mémoire. Nous cherchons la chaîne de caractères contenant « MZ » et qui correspond au début d'un binaire Windows  (This program cannot be run in DOS).

2.2 Ingénierie inverse

Le nouveau binaire ainsi extrait semble plus intéressant qu’auparavant sous la loupe d'IDA. En effet, nous remarquons tout de suite les appels aux fonctions (Imports qui n'étaient pas présentes avant) permettant de faire des requêtes HTTP comme : InternetOpenA dans wininet.dllet HttpSendRequestA dans wininet.dll.

En revanche, nous ne trouvons pas les URL découvertes durant l'analyse comportementale. En effet, ces URL sont obfusquées dans une ressource comme nous le verrons plus bas.

Nous remarquons effectivement une nouvelle ressource dans le fichier extrait, nommée « RCData » et contenant des données chiffrées ou obfusquées.

 

 

Rappelons que notre but, dans ce cas, est de trouver quelles sont les fonctionnalités de ce malware et comment déchiffrer le trafic (principalement dans les requêtes POST vues dans l'analyse comportementale).

Nous retrouvons les fonctions permettant la création des dossiers découverts précédemment dans l'analyse comportementale :

- Création du dossier Microsoft :

- Création du dossier VSComponents :

- Création du dossier Windows :

Nous remarquons une fonction qui semble intéressante (que nous avons renommée ci-dessous XOR_Loop) comprenant une boucle avec une opération « XOR » :

Les paramètres (au nombre de trois), correspondent à :

1. Le résultat d'une fonction calculant la longueur d'une chaîne de caractères,

2. 0x0e en hexadécimal,

3. Un pointeur sur une chaîne de caractères (la même chaîne dont la longueur a été calculée au point 1).

Nous nous rendons rapidement compte que cette fonction « XOR » cette chaîne de caractères (500 octets) avec une clé de longueur 5 octets. Voici le code Python de cette fonction :

La clé commence avec la valeur 0x0e puis s'incrémente jusqu'à atteindre 0x12 (raison pour laquelle la clé fait 5 octets). Chaque byte est « XOR » avec la clé correspondante. Il est intéressant de regarder de plus près cette chaîne de caractères passée dans la boucle d'obfuscation. Voici un extrait :

 

 

Nous pouvons voir que, ce qui semble être une chaîne de 500 caractères, est en fait plusieurs chaînes mises à la suite. La raison pour laquelle l'utilitaire strings n'a pas découvert ces chaînes, est qu'elles ne sont pas terminées par l'octet de terminaison d'une chaîne en C (0x00). En effet, après désobfuscation, nous retrouvons les terminaisons (0x10 xor 0x10 donne 0x00) et cette grande chaîne devient plusieurs chaînes obfusquées (qu'il faudra de nouveau repasser à travers la routine « XOR » pour la voir en clair).

 

 

Puis, en bouclant à travers ces chaînes de caractères, la fonction permet de prendre une autre chaîne au hasard et de la repasser dans la mécanique de désobfuscation pour utiliser cette chaîne de caractères dans le nom du futur exécutable qui va être créé par la suite. Il sera possible, par exemple, de prévoir tous les noms des possibles exécutables créés par « Karagany ».

 

 

Puisque nous avons découvert la fonction d'obfuscation, essayons de voir comment celle-ci est utilisée dans le binaire. Peut-être est-ce la même pour toutes les ressources ?

Nous trouvons la fonction qui lit la ressource découverte plus haut (Fig. 1) :

Armés de cette fonction de désobfuscation et de la structure du fichier de configuration, nous pouvons déchiffrer toutes les ressources présentes avec ce binaire. En effet, nous avons remarqué également que les 32 premiers octets des ressources ne sont pas inclus dans la routine de désobfuscation. Voici donc le script permettant de désobfusquer toutes les ressources de « Karagany » :

Nous commençons par la ressource découverte après avoir « dépacké » le malware :

Voici le domaine et l'URL que nous cherchions !

Testons la désobfuscation sur les données du trafic capturé dans la requête POST :

Nous découvrons des identifiants uniques (d8464750-4f77f475 générés d'après le nom d'utilisateur), ainsi que ce qui semble être un numéro de version 1.0.0.

Allons encore plus loin et regardons ce qui se trouve dans le fichier créé dans le même dossier que le binaire et qui semblait être obfusqué :

Voilà qui est très intéressant, nous découvrons un binaire Windows ! Enlevons les premiers octets avant le « MZ » et vérifions avec VirusTotal à quoi correspond ce binaire :

Il s'agit en fait d'un malware « droppé » par « Karagany ». C'est un type de « ransomware », affichant un message voulant faire peur à l'utilisateur et bloquant l'écran par exemple, obligeant l'utilisateur à payer une rançon pour retrouver ses données [xylitol].

Avant de regarder plus en détails ce nouveau spécimen, finissons de regarder les fonctionnalités de « Karagany ». Dans le fichier désobfusqué, nous pouvons également trouver l'utilité de plusieurs octets.

Les octets 5 et 6 correspondent aux fonctionnalités que peut fournir le « dropper » :

 

 

En effet, nous nous retrouvons face à une fonction permettant d'analyser les octets 5 et 6 du fichier de configuration ou de la réponse du serveur (réponse aux requêtes « POST » vues plus haut).

Extrait des sauts conditionnels :

Le tableau 1, résume les fonctions possibles fournies par ce malware.

 

Octets (hex)	Fonctions
3001	Télécharge un fichier
3002	Télécharge un fichier + crée un processus (CreateProcessW())
3003	Télécharge un fichier + « runas » (ShellExecuteW())
3004	Télécharge un fichier + charge une librairie (LoadLibraryW())
3005	Écrit les données reçues dans un fichier + « open » (ShellExecuteW())
3006	Écrit les données reçues dans un fichier + crée un processus (CreateProcessW())
3007	Écrit les données reçues dans un fichier + « runas » (ShellExecuteW())
3008	Écrit les données reçues dans un fichier + charge une librairie (LoadLibraryW())
3009	Télécharge un fichier + « open » (ShellExecuteW())
300C	Injection d'un processus
3019	Télécharge un fichier + charge une librairie (LoadLibraryW()) (idem 3004)
301B	Télécharge un fichier + crée un processus (CreateProcessW()) (idem 3002)
301C	Écrit les données reçues dans un fichier + Injection d'un processus
301D	Écrit les données reçues dans un fichier (XOR)
301E	Écrit les données reçues dans un fichier (XOR)
301F	Vérifie que les premiers octets correspondent à « MZ » et « PE »
3021	Définit un événement (SetEvent())
6002	Injection d'un processus
6001	Aucune fonction

2.3 Analyse du « Ransomware »

En ayant extrait les données du fichier obfusqué, nous nous retrouvons en face d'un nouveau type de logiciel malveillant. Nous n'allons pas nous attarder sur celui-ci étant donné qu'un grand nombre d'articles ont déjà été publiés décrivant comment fonctionnent ces maliciels.

Nous nous concentrons sur le processus nécessaire pour analyser ce type de malware.

Ce binaire comprend quelques fonctions basiques visant à se protéger de l'analyse automatisée. Pour ce faire, il vérifie si les chaînes « vbox », « VM », « VirtualBox », « Oracle », « Virtual » ou « ware » se trouvent dans les clés de registre suivantes :

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System

HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0

HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 1\Scsi Bus 0\Target Id 0\Logical Unit Id 0

Puis, il scanne tous les processus en cours et vérifie s'il découvre les chaînes de caractères suivantes dans les noms des processus :

iptools

HttpAnalyzerStdV

snif

traf

wireshark

VBox

vmtools

mstsc

rdpclip

Nous trouvons également les URL suivantes :

http://ngoodiny50.in/image/gate.php

http://ngoodiny60.in/image/gate.php

http://ngoodiny70.in/image/gate.php

http://ngoodiny80.in/image/gate.php

http://ngoodiny90.in/image/gate.php

Souvenons-nous, les requêtes que nous avions observées étaient de la forme suivante :

Voici la description des valeurs :

Le champ user correspond certainement à l'utilisateur vendant ces services en tant que Pay-per-install [PPI].

Lorsque nous lançons ce maliciel dans les bonnes conditions (depuis le bon chemin et sans activer les « anti-vm »), nous nous retrouvons avec un écran gris (plein écran) bloquant la combinaison de touches [Alt]+[Tab] et qui nous oblige à entrer un code. Si nous entrons le bon code, l'écran est débloqué.

Notons au passage que l'écran gris provient certainement du fait que les domaines ne sont plus accessibles à l'heure actuelle, et donc de l'impossibilité du malware à télécharger les ressources correspondantes. Il existe un foisonnement de ressources en ligne pour avoir une idée des images affichées [scareware].

 

 

Pour nous permettre de trouver un code correct, nous patchons ce malware, ceci nous permettant de facilement suivre les fonctions de vérification du « voucher » et ainsi éviter d'être bloqué par le malware.

Le premier « patch » permet d'éviter que les touches [Alt]+[Tab] soient bloquées :

Celui-ci permet de modifier le style de la fenêtre (évite que la fenêtre soit en plein écran et impossible à déplacer) :

Rend les vérifications « anti-vm » (voir plus haut) inactives. En mettant le résultat (« eax ») à 0 :

Une boucle infinie (while 1) permet de s'injecter dans plusieurs processus. Ce patch ne le laisse s'injecter qu'une seule fois :

Ces modifications permettent de facilement voir que le « ransomware » fait des requêtes HTTP afin de vérifier les « vouchers » et renvoie des commandes afin de débloquer l'écran.

L'analyse plus en détails de ce type de malware sera laissée comme exercice au lecteur. En effet, nous pouvons d'ores et déjà répondre aux questions qui avaient été énoncées au début de l'article.

Conclusion

L'étude approfondie du logiciel malveillant nous permet de répondre aux questions soulevées lors de la découverte de l'infection.

Quels sont les risques réels inhérents à cette infection ? Était-ce une attaque ciblée ?

Sans prendre trop de risque, nous pouvons affirmer que la charge malveillante (à savoir le « ransomware ») ne correspond pas à une attaque ciblée. En effet, le but de ce type de logiciel n'est pas, par exemple, de voler des informations confidentielles, mais bien d'infecter le maximum d'utilisateurs (particulièrement des utilisateurs finaux) et de recevoir des paiements afin de débloquer la machine infectée.

En revanche, il est important de noter que le cheval de Troie « Karagany » n'est pas aussi « inoffensif ». Effectivement, en analysant la liste des fonctions possibles de la part de ce « dropper » (voir tableau 1), il serait aisé d’utiliser ce « malware » afin de perpétrer des crimes présentant une menace accrue pour un environnement d'entreprise. Il serait donc prioritaire de vérifier que ce cheval de Troie ne soit pas présent sur d'autres machines du système d'information.

Est-ce que des données ont été volées ?

Grâce à la découverte de la routine de désobfuscation et armés de notre script Python, nous pouvons sortir tous les logs contenant du trafic Internet (proxy, firewall,…), extraire les requêtes pointant sur les domaines découverts dans les binaires et ainsi, savoir exactement quelles données et commandes ont été exécutées sur le ou les poste(s) compromis.

Remerciements

Merci à François Deppierraz et à « cam0 » pour leurs relectures attentives.

Notes

[vt] https://www.virustotal.com

[sysint] http://technet.microsoft.com/en-us/sysinternals/bb545027

[rootbsd] http://code.google.com/p/malware-lu/wiki/en_unpack_Karagny_L

[xylitol] http://www.xylibox.com/2012/08/gangstaservice-winlock-affiliate.html

[PPI] www.usenix.org/events/sec11/tech/full_papers/Caballero.pdf

[scareware] https://www.botnets.fr/index.php/Casier