ProHoster > Blog > administration > RATKing : nouvelle campagne avec des chevaux de Troie d'accès à distance
RATKing : nouvelle campagne avec des chevaux de Troie d'accès à distance
Fin mai, nous avons découvert une campagne visant à distribuer des chevaux de Troie d'accès à distance (RAT), des programmes permettant aux attaquants de contrôler à distance un système infecté.
Le groupe que nous avons examiné se distinguait par le fait qu’il n’avait sélectionné aucune famille RAT spécifique pour l’infection. Plusieurs chevaux de Troie ont été repérés lors d'attaques au cours de la campagne (qui étaient toutes largement disponibles). Avec cette particularité, le groupe nous rappelle le roi des rats, un animal mythique composé de rongeurs aux queues entrelacées.
L'original est tiré de la monographie de K. N. Rossikov « Souris et rongeurs ressemblant à des souris, les plus importants économiquement » (1908)
En l'honneur de cette créature, nous avons nommé le groupe que nous envisageons de RATKing. Dans cet article, nous expliquerons en détail comment les attaquants ont mené l'attaque, les outils qu'ils ont utilisés, et partagerons également nos réflexions sur l'attribution de cette campagne.
Progression de l'attaque
Toutes les attaques de cette campagne ont eu lieu selon l'algorithme suivant :
L'utilisateur a reçu un e-mail de phishing contenant un lien vers Google Drive.
À l'aide du lien, la victime a téléchargé un script VBS malveillant qui spécifiait une bibliothèque DLL pour charger la charge utile finale dans le registre Windows et a lancé PowerShell pour l'exécuter.
La bibliothèque DLL a injecté la charge utile finale - en fait, l'un des RAT utilisés par les attaquants - dans le processus système et a enregistré un script VBS en exécution automatique afin de prendre pied dans la machine infectée.
La charge utile finale a été exécutée dans un processus système et a donné à l'attaquant la possibilité de contrôler l'ordinateur infecté.
Schématiquement, cela peut être représenté ainsi :
Ensuite, nous nous concentrerons sur les trois premières étapes, puisque nous nous intéressons au mécanisme de diffusion des logiciels malveillants. Nous ne décrirons pas en détail le mécanisme de fonctionnement du malware lui-même. Ils sont largement disponibles – soit vendus sur des forums spécialisés, soit même distribués sous forme de projets open source – et ne sont donc pas propres au groupe RATKing.
Analyse des étapes d'attaque
Étape 1. E-mail de phishing
L'attaque a commencé lorsque la victime a reçu une lettre malveillante (les attaquants ont utilisé différents modèles de texte ; la capture d'écran ci-dessous montre un exemple). Le message contenait un lien vers un référentiel légitime drive.google.com, ce qui aurait conduit à une page de téléchargement de documents PDF.
Exemple d'e-mail de phishing
Cependant, en réalité, ce n'est pas du tout un document PDF qui a été chargé, mais un script VBS.
Lorsque vous avez cliqué sur le lien de l'e-mail dans la capture d'écran ci-dessus, un fichier nommé Cargo Flight Details.vbs. Dans ce cas, les attaquants n’ont même pas essayé de faire passer le fichier pour un document légitime.
Parallèlement, dans le cadre de cette campagne, nous avons découvert un script nommé Cargo Trip Detail.pdf.vbs. Il pourrait déjà passer pour un PDF légitime car Windows masque les extensions de fichiers par défaut. Certes, dans ce cas, les soupçons pourraient encore être éveillés par son icône, qui correspondait au script VBS.
A ce stade, la victime pourrait reconnaître la tromperie : il suffit d'examiner de plus près les fichiers téléchargés pendant une seconde. Cependant, dans de telles campagnes de phishing, les attaquants s’appuient souvent sur un utilisateur inattentif ou précipité.
Étape 2. Opération de script VBS
Le script VBS, que l'utilisateur pouvait ouvrir par inadvertance, enregistrait une bibliothèque DLL dans le registre Windows. Le script était obscurci : les lignes qu'il contenait étaient écrites sous forme d'octets séparés par un caractère arbitraire.
Exemple de script obscurci
L'algorithme de désobscurcissement est assez simple : un caractère sur trois a été exclu de la chaîne obscurcie, après quoi le résultat a été décodé de la base 16 dans la chaîne d'origine. Par exemple, à partir de la valeur 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (mis en évidence dans la capture d'écran ci-dessus), la ligne résultante était WScript.Shell.
Pour désobscurcir les chaînes, nous avons utilisé la fonction Python :
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Ci-dessous, aux lignes 9 et 10, nous mettons en évidence la valeur dont la désobscurcissement a abouti à un fichier DLL. C'est lui qui a lancé l'étape suivante en utilisant PowerShell.
Chaîne avec DLL obscurcie
Chaque fonction du script VBS a été exécutée au fur et à mesure que les chaînes étaient désobscurcies.
Après avoir exécuté le script, la fonction a été appelée wscript.sleep — il a été utilisé pour effectuer une exécution différée.
Ensuite, le script a fonctionné avec le registre Windows. Pour cela, il a utilisé la technologie WMI. Avec son aide, une clé unique a été créée et le corps du fichier exécutable a été écrit dans son paramètre. Le registre a été accessible via WMI à l'aide de la commande suivante :
Une entrée faite dans le registre par un script VBS
Étape 3. Fonctionnement de la bibliothèque DLL
Lors de la troisième étape, la DLL malveillante chargeait la charge utile finale, l'injectait dans le processus système et garantissait que le script VBS démarrait automatiquement lorsque l'utilisateur se connectait.
Exécuter via PowerShell
La DLL a été exécutée à l'aide de la commande suivante dans PowerShell :
reçu des données de valeur de registre avec le nom rnd_value_name — ces données étaient un fichier DLL écrit sur la plateforme .Net ;
chargé le module .Net résultant dans la mémoire du processus powershell.exe en utilisant la fonction [System.Threading.Thread]::GetDomain().Load()(description détaillée de la fonction Load() disponible sur le site de Microsoft);
rempli la fonction GUyyvmzVhebFCw]::EhwwK() - l'exécution de la bibliothèque DLL a commencé avec - avec des paramètres vbsScriptPath, xorKey, vbsScriptName. Paramètre xorKey stocké la clé pour déchiffrer la charge utile finale et les paramètres vbsScriptPath и vbsScriptName ont été transférés afin d'enregistrer un script VBS en exécution automatique.
Description de la bibliothèque DLL
Sous forme décompilée, le bootloader ressemblait à ceci :
Chargeur sous forme décompilée (la fonction avec laquelle l'exécution de la bibliothèque DLL a commencé est soulignée en rouge)
Le chargeur de démarrage est protégé par le protecteur .Net Reactor. L'utilitaire de4dot fait un excellent travail en supprimant ce protecteur.
Ce chargeur :
injecté la charge utile dans le processus système (dans cet exemple, il svchost.exe);
J'ai ajouté un script VBS à l'exécution automatique.
Injection de charge utile
Examinons la fonction appelée par le script PowerShell.
Fonction appelée par le script PowerShell
Cette fonction a effectué les actions suivantes :
décrypté deux ensembles de données (array и array2 dans la capture d'écran). Ils ont été initialement compressés à l'aide de gzip et chiffrés avec l'algorithme XOR avec la clé xorKey;
données copiées dans les zones de mémoire allouées. Données de array - vers la zone mémoire pointée intPtr (payload pointer dans la capture d'écran); données de array2 - vers la zone mémoire pointée intPtr2 (shellcode pointer dans la capture d'écran);
appelé la fonction CallWindowProcA(description Cette fonction est disponible sur le site de Microsoft) avec les paramètres suivants (les noms des paramètres sont listés ci-dessous, dans la capture d'écran ils sont dans le même ordre, mais avec des valeurs de travail) :
lpPrevWndFunc - pointeur vers les données de array2;
hWnd — pointeur vers une chaîne contenant le chemin d'accès au fichier exécutable svchost.exe;
Msg - pointeur vers les données de array;
wParam, lParam — paramètres du message (dans ce cas, ces paramètres n'étaient pas utilisés et avaient des valeurs de 0) ;
créé un fichier %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlOù <name> - ce sont les 4 premiers caractères du paramètre vbsScriptName (dans la capture d'écran, le fragment de code avec cette action commence par la commande File.Copy). De cette manière, le logiciel malveillant ajoutait un fichier URL à la liste des fichiers à exécution automatique lorsque l'utilisateur se connectait et s'attachait ainsi à l'ordinateur infecté. Le fichier URL contenait un lien vers le script :
Pour comprendre comment s'est déroulée l'injection, nous avons décrypté les tableaux de données array и array2. Pour ce faire, nous avons utilisé la fonction Python suivante :
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
En conséquence, nous avons découvert que :
array était un fichier PE - c'est la charge utile finale ;
array2 était le shellcode nécessaire pour effectuer l’injection.
Shellcode à partir d'un tableau array2 passé comme valeur de fonction lpPrevWndFunc dans une fonction CallWindowProcA. lpPrevWndFunc — fonction de rappel, son prototype ressemble à ceci :
Ainsi, lorsque vous exécutez la fonction CallWindowProcA avec paramètres hWnd, Msg, wParam, lParam le shellcode du tableau est exécuté array2 avec des arguments hWnd и Msg. hWnd est un pointeur vers une chaîne contenant le chemin d'accès au fichier exécutable svchost.exeEt Msg — pointeur vers la charge utile finale.
Le shellcode a reçu des adresses de fonction de kernel32.dll и ntdll32.dll basé sur les valeurs de hachage de leurs noms et injecté la charge utile finale dans la mémoire du processus svchost.exeen utilisant la technique Process Hollowing (vous pouvez en savoir plus à ce sujet dans ce article). Lors de l'injection du shellcode :
créé un processus svchost.exe en état suspendu à l'aide de la fonction CreateProcessW;
puis masqué l'affichage de la section dans l'espace d'adressage du processus svchost.exe en utilisant la fonction NtUnmapViewOfSection. Ainsi, le programme a libéré la mémoire du processus original svchost.exepour ensuite allouer de la mémoire pour la charge utile à cette adresse ;
mémoire allouée pour la charge utile dans l'espace d'adressage du processus svchost.exe en utilisant la fonction VirtualAllocEx;
Début du processus d'injection
a écrit le contenu de la charge utile dans l'espace d'adressage du processus svchost.exe en utilisant la fonction WriteProcessMemory (comme dans la capture d'écran ci-dessous) ;
repris le processus svchost.exe en utilisant la fonction ResumeThread.
Terminer le processus d'injection
Malware téléchargeable
À la suite des actions décrites, l'un des nombreux logiciels malveillants de classe RAT a été installé sur le système infecté. Le tableau ci-dessous répertorie les logiciels malveillants utilisés dans l'attaque, que nous pouvons attribuer en toute confiance à un groupe d'attaquants, puisque les échantillons ont accédé au même serveur de commande et de contrôle.
Nom du malware
Vu la première fois
SHA-256
C & C
Le processus dans lequel l'injection est effectuée
Exemples de logiciels malveillants distribués avec le même serveur de contrôle
Deux choses sont ici remarquables.
Premièrement, le fait même que les attaquants ont utilisé plusieurs familles de RAT différentes à la fois. Ce comportement n'est pas typique des cybergroupes bien connus, qui utilisent souvent à peu près le même ensemble d'outils qui leur sont familiers.
Deuxièmement, RATKing a utilisé des logiciels malveillants soit vendus sur des forums spécialisés à bas prix, soit même un projet open source.
Une liste plus complète des logiciels malveillants utilisés dans la campagne, avec une mise en garde importante, est donnée à la fin de l'article.
À propos du groupe
Nous ne pouvons attribuer la campagne malveillante décrite à aucun attaquant connu. Pour l’instant, nous pensons que ces attaques ont été menées par un groupe fondamentalement nouveau. Comme nous l'avons écrit au début, nous l'avons appelé RATKing.
Pour créer le script VBS, le groupe a probablement utilisé un outil similaire à l'utilitaire VBS-Crypter du développeur NYAN-x-CAT. Ceci est indiqué par la similitude du script créé par ce programme avec celui des attaquants. Plus précisément, ils :
effectuer une exécution différée à l'aide de la fonction Sleep;
utiliser WMI ;
enregistrer le corps du fichier exécutable en tant que paramètre de clé de registre ;
exécutez ce fichier en utilisant PowerShell dans son propre espace d'adressage.
Pour plus de clarté, comparez la commande PowerShell pour exécuter un fichier du registre, qui est utilisé par un script créé à l'aide de VBS-Crypter :
Notez que les attaquants ont utilisé un autre utilitaire de NYAN-x-CAT comme l'une des charges utiles : ChauxRAT.
Les adresses des serveurs C&C indiquent une autre particularité de RATKing : le groupe privilégie les services DNS dynamiques (voir la liste des C&C dans le tableau IoC).
IdC
Le tableau ci-dessous fournit une liste complète des scripts VBS qui peuvent très probablement être attribués à la campagne décrite. Tous ces scripts sont similaires et exécutent à peu près la même séquence d'actions. Tous injectent des logiciels malveillants de classe RAT dans un processus Windows fiable. Tous ont des adresses C&C enregistrées à l’aide des services Dynamic DNS.
Cependant, nous ne pouvons pas prétendre que tous ces scripts ont été distribués par les mêmes attaquants, à l'exception des échantillons avec les mêmes adresses C&C (par exemple, kimjoy007.dyndns.org).
Nom du malware
SHA-256
C & C
Le processus dans lequel l'injection est effectuée