Analyse du comportement du cheval de Troie Pegasus sur le réseau

Le code source du cheval de Troie bancaire Pegasus a récemment été publié . Malgré la mention du groupe Carbanak au nom des archives, les chercheurs de Minerva Labs ont nié l' implication du cheval de Troie dans ce groupe et ont prouvé leur implication dans le groupe Buhtrap (Ratopak). À l'intérieur des archives se trouve une brève description du travail du cheval de Troie, ses codes sources, une description du système de paiement bancaire et les données des employés de nombreuses banques russes.

L'architecture du code source de ce malware est assez intéressante. La fonctionnalité est divisée en modules assemblés en un seul «binpack» au stade de la compilation. Le processus de compilation comprend également la signature de fichiers exécutables avec un certificat du fichier tric.pfx, qui n'est pas dans l'archive.

Non moins curieuse est l'activité réseau de Pegasus, qui, après infection, essaie de se propager au sein du domaine et sait comment proxyer des données entre des machines utilisant des pipes et le transport Mailslot. Nous nous sommes concentrés sur l'étude des fonctionnalités de l'activité réseau du cheval de Troie et avons rapidement ajouté les détections Pegasus au produit PT Network Attack Discovery . Cela permettra à tous ses utilisateurs de détecter en temps opportun l'activité de ce cheval de Troie et ses modifications sur leur réseau. Dans cet article, je donnerai une description détaillée des mécanismes de distribution réseau et de l'interaction entre les copies de Pegasus.



Intro


Une fois sur la machine, le module principal InstallerExe injecte le code dans svchost.exe en utilisant la technique Process Hollowing et, après avoir initialisé les modules principaux, Pegasus démarre plusieurs processus parallèles:

  1. Réplication de domaine - est engagée dans l'intelligence du réseau et tente de se propager à d'autres machines Windows.
  2. Le Mailslot Listener écoute les messages diffusés dans le bac de courrier, via lesquels Pegasus envoie des comptes minés. Le nom de l'emplacement est généré au moment de la compilation.
  3. L'écouteur du serveur de tuyaux écoute le tuyau Windows avec le nom généré au nom de la machine. Ces canaux sont principalement utilisés pour détecter d'autres copies Pegasus sur le réseau et leur interaction.
  4. Logon Passwords périodiquement toutes les quelques minutes essaie de vider les données du compte avec un module de Mimikatz.
  5. La connectivité réseau est responsable de la communication avec le serveur CnC et de la messagerie périodique.

// start transports which links data with our CB-manager pwInitPipeServerAsync(dcmGetServerCallback()); mwInitMailslotServer(dcmGetServerCallback()); ... // start broadcasting creds to other machines cmStartupNetworkBroadcaster(); 

Réplication de domaine


L'un des sous-systèmes de Pegasus est responsable du mouvement latéral sur un réseau Windows. La distribution est divisée en deux étapes importantes:

  1. Détection des voitures voisines.
  2. Tentative de réplication sur une machine.

La découverte des machines voisines dans un domaine se fait via deux appels API:

NetServerEnum, qui nécessite le service Browser et appelle WNetOpenEnum / WNetEnumResource.
Toutes les machines trouvées dans le domaine doivent être analysées si elles sont déjà infectées. Pegasus interroge le nom du canal généré toutes les 200 millisecondes plus de 20 fois de suite. Nous avons utilisé ce comportement anormal comme l'un des indicateurs de l'activité de Pegasus dans le domaine. N'ayant détecté aucun signe d'infection, le malware passe à l'étape suivante - la tentative de réplication.

La réplication est la suivante. En utilisant les comptes trouvés (KM) sur l'hôte, Pegasus tente de se connecter aux boules IPC $ et ADMIN $ sur la machine via SMB, et s'il y a accès à IPC $ et qu'il n'y a pas d'accès à ADMIN $, alors Pegasus conclut qu'il a raison le compte est insuffisant et doit être marqué comme invalide. Ayant accédé à la boule ADMIN $, qui est un alias pour le dossier% windir%, le malware essaie de déterminer l'architecture de la machine afin d'utiliser le module approprié à l'avenir.

L'algorithme de détermination de l'architecture est basé sur les en-têtes de fichiers PE sur la machine distante. En tant que tel fichier, Pegasus essaie de lire les 4 premiers kilo-octets de notepad.exe à partir du dossier% windir%. Un inconvénient évident de cette méthode est que sur Windows Server 2012, le bloc-notes se trouve sur le chemin% windir% \ System32.

Emplacement notepad.exe sur Windows 7:

 C:\Users\Administrator>where notepad.exe C:\Windows\System32\notepad.exe C:\Windows\notepad.exe 

Sur Windows Server 2012:

 C:\Users\Administrator>where notepad.exe C:\Windows\System32\notepad.exe 

S'il ne détecte pas notepad.exe, Pegasus ne peut pas infecter le serveur, même s'il dispose des informations de compte avec les droits nécessaires. La simple absence de bloc-notes dans% windir% peut arrêter la distribution de Pegasus sur Windows Server 2012. L'utilisation de regedit.exe à cet égard est plus fiable.

Après avoir défini avec succès l'architecture du serveur cible, Pegasus charge un petit compte-gouttes RSE (Remote Service Exe) d'environ 10 kilo-octets, dont la tâche est de charger le binpack des modules Pegasus via le canal sous forme claire et de transférer le contrôle au module Shellcode. Le nom du compte-gouttes est composé de manière pseudo-aléatoire et se compose d'une chaîne de caractères hexadécimaux de 8 à 15 caractères. Le générateur pseudo-aléatoire est initialisé en fonction du nom de la machine cible et sera le même entre les démarrages pour éviter un encombrement possible de% windir% avec les copies précédentes du compte-gouttes.



L'intégrité et la suppression éventuelle du compte-gouttes sont vérifiées par l'antivirus, après quoi il est lancé par l'un des deux mécanismes implémentés - SCM ou WMI, et tout d'abord Pegasus tente de démarrer RSE via le mécanisme WMI, et seulement ensuite en utilisant le Service Control Manager (SCM). En effet, SCM laisse plus de traces dans les journaux Windows. Les créateurs de Pegasus ont également prévu d'autres méthodes de distribution - Wsh Remote, Powershell remoting, Task Scheduler et un module pour exécuter des commandes via RDP était en cours de développement.

Comme mentionné ci-dessus, après un lancement réussi, le compte-gouttes vérifie et ouvre le canal d'écoute et transfère le contrôle à la charge utile entrante.



Le code Pegasus étant injecté par la méthode Process Hollowing dans le processus svchost.exe, ni le module InstallerExe d'origine ne doit rester sur le disque en cas d'infection primaire, ni le compte-gouttes RSE en cas de distribution. Si le compte-gouttes est toujours accessible par un chemin connu, Pegasus le supprime à sa manière:

  1. écraser le contenu du fichier avec des données aléatoires;
  2. écraser avec des données vides (zéros);
  3. renommer le fichier;
  4. suppression de fichier.



Après une infection réussie, le processus de distribution de réplication de domaine redémarre.

Mailslot fonctionne


Une fois que Pegasus aura accès aux données du compte à partir d'une autre copie de Pegasus ou du module mod_LogonPasswords, il commencera à diffuser les données américaines par domaine. La distribution est effectuée à l'aide du mécanisme SMB basé sur Mailslot, qui permet la diffusion unidirectionnelle d'une petite partie des données à travers un domaine. La distribution a lieu selon un nom d'emplacement généré de manière aléatoire et pour que toutes les machines infectées du domaine puissent envoyer et recevoir des données par un seul nom, le générateur pseudo-aléatoire de noms est initialisé à partir de la variable TARGET_BUILDCHAIN_HASH spécifiée dans la configuration lors de la génération.

Étant donné que le mécanisme Mailslot impose une limite à la taille maximale des paquets, un seul KM ​​est envoyé à la fois selon le principe de la dernière heure d'envoi: parmi tous les KM disponibles, le domaine dont la dernière date d'envoi est la plus ancienne est envoyé par domaine.

Les données dans Mailslot ne sont pas transmises en texte clair, mais enveloppées dans trois couches de cryptage XOR, et les clés sont transmises avec les données. La première couche de données est l'enveloppe NetMessageEnvelope avec vérification de l'intégrité des données par l'algorithme SHA1, utilisée pour toutes les données transmises sur le réseau local. 4 octets de données au début du paquet sont la clé, qui est modifiée par des décalages binaires de 5 bits vers la droite par cycle. À l'intérieur de l'enveloppe se trouve une structure de données codée XOR avec des champs américains directs et la date à laquelle ils ont été ajoutés. La clé de 8 octets est également située au début de la structure, mais est appliquée sans décalage. Après décodage de la structure KM, il ne reste plus qu'à désérialiser les champs individuels des structures ENC_BUFFER tels que le nom de l'ordinateur, le nom de domaine, le nom d'utilisateur et le mot de passe. Ces champs sont chiffrés avec une clé de 8 octets avec décalages. Le script pour décrypter le paquet Mailslot et un exemple d'un tel paquet peuvent être trouvés ici: script , PCAP .

La période d'envoi des messages Mailslot dans la version finale varie de 20 secondes à 11 minutes.

 // some random wait before making next step DbgPrint("going to sleep"); #ifdef _DEBUG // debug - 2-5 s Sleep(rg.rgGetRnd(&rg, 2000, 5000)); #else // release - 20 - 650 s //Sleep(rg.rgGetRnd(&rg, 2000, 65000) * 10); Sleep(rg.rgGetRnd(&rg, 2000, 15000)); #endif 

En plus d'échanger des comptes, le mécanisme Mailslot est utilisé pour rechercher une machine infectée avec accès à Internet et pour annoncer l'accès à Internet. L'enveloppe NetMessageEnvelope stocke le type de message envoyé. L'échange de données entre la machine sans accès et la machine avec accès Internet se fait par les canalisations.

Travaux de tuyauterie


Pour la communication bidirectionnelle ou le transfert de grandes quantités de données, les copies Pegasus utilisent des canaux comme canal de communication. Le nom du canal, bien qu'il soit également généré par un générateur pseudo-aléatoire, mais dépend du nom de la machine et de la construction et, ainsi, permet aux parties client et serveur d'utiliser le même nom.

Dans une communication unidirectionnelle, par exemple, lors du transfert de binpack pendant la réplication vers une autre machine, les données ne sont pas cryptées et transmises en clair. Binpack commence par une structure SHELLCODE_CONTEXT d'une longueur de 561 octets.



Pendant la transmission bidirectionnelle, par exemple, le proxy de données entre une copie Pegasus sans accès Internet et un serveur CnC, la même structure d'enveloppe NetMessageEnvelope avec cryptage XOR est utilisée comme dans le cas de Mailslot, car il vous permet de distinguer les différents types de messages dans le champ id.

D'un point de vue architectural, le proxy de données est effectué via une demande de transfert d'une partie des données (PMI_SEND_QUERY), de réception de l'ID de demande en réponse et d'interrogation de l'état de la tâche par ID (PMI_CHECK_STATUS_QUERY). En règle générale, une autre structure d'enveloppe est transférée en tant que charge, ajoutant diverses fonctionnalités et une autre couche de chiffrement.

De plus, travailler avec des tuyaux ne se termine pas sur l'interaction entre les machines infectées. Le module mod_KBRI_hd injecte du code dans les processus cmd.exe qui intercepte les appels MoveFileExW et analyse toutes les données copiées, car cela fait partie du processus de paiement. Si le fichier copié contient des données qui intéressent les attaquants - des données avec des paiements, une notification à ce sujet est envoyée au serveur CnC. La communication entre le module mod_KBRI injecté dans cmd.exe et une copie de Pegasus est effectuée à l'intérieur de la machine infectée via un tube dont le nom n'est pas généré mais est codé en dur dans le code source:

 \.\pipe\pg0F9EC0DB75F67E1DBEFB3AFA2 

La fonctionnalité du module comprend également la substitution des comptes de données à la volée selon le modèle. Un exemple de modèles à rechercher dans la capture d'écran.

Trafic cnc


Un flux distinct est responsable de l'échange de données direct avec le serveur CnC, qui vérifie la file d'attente des blocs de données des processus internes ou d'autres copies de logiciels malveillants toutes les quelques minutes et les envoie au serveur.

Lors de l'initialisation du module mod_NetworkConnectivity, il effectue une vérification en plusieurs étapes de la connexion réseau:

1) Détection des paramètres du serveur proxy et tentative de connexion à www.google.com :

  • Dans la branche du registre \\ Software \\ Microsoft \\ Windows \\ CurrentVersion \\ Internet Settings.
  • Via WPAD (appelez WinHttpGetProxyForUrl).
  • Via la configuration du proxy pour l'utilisateur actuel (appelez WinHttpGetIEProxyConfigForCurrentUser).

2) Vérification de la connexion avec les serveurs de mise à jour Microsoft et les données renvoyées ( authrootseq.txt , authrootstl.cab , rootsupd.exe )

3) Test des connexions HTTPS avec l'une des 6 adresses:


Ce n'est qu'après avoir passé tous les contrôles, Pegasus estime qu'il a l'accès nécessaire au réseau externe et peut l'annoncer via le domaine Mailslot avec un message. De plus, Pegasus peut se déguiser et communiquer avec le serveur CnC uniquement pendant les heures de bureau - de 9 h à 19 h, heure locale.

Pegasus envoie des morceaux de données enveloppés dans une enveloppe avec le calcul du hachage du montant sous forme cryptée en utilisant le cryptage DES en mode CRYPT_MODE_CBC / PKCS5_PADDING. La clé de cryptage dépend uniquement de la variable lors de la compilation, et nous pouvons donc décrypter le trafic entre le malware et le serveur en ne connaissant que son BUILDCHAIN_HASH. Dans le code source à l'intérieur de l'archive, cette variable avait la valeur 0x7393c9a643eb4a76. Un script pour déchiffrer l'enregistrement sur le serveur et un exemple d'un tel package peuvent être trouvés ici: script , PCAP .

Il transfère ce contenu (structure INNER_ENVELOPE) au serveur CnC lors de l'enregistrement, ou avec toutes les données. Initialement, il y a 28 octets d'une enveloppe avec un champ de longueur et une somme SHA1.



Les mêmes données sont transférées entre les machines pendant le proxy via des canaux, mais enveloppées dans l'enveloppe NetMessageEnvelope que nous connaissons avec une somme de hachage et un cryptage XOR.

L'opérateur CnC peut envoyer des commandes pour exécution à des copies et des messages Pegasus avec des commandes ou d'autres données, par exemple, EID_CREDENTIALS_LIST peut contenir leurs propres couches de chiffrement de champ, comme nous l'avons vu dans l'exemple des comptes de diffusion.

Détection


Tout d'abord, nous voulions détecter l'activité de Pegasus sur le réseau et, après avoir soigneusement étudié les codes source et exécuté dans l'environnement de test, nous avons découvert ces anomalies et artefacts du réseau qui indiquent clairement la présence de ce malware complexe sur le réseau. Pegasus peut vraiment être qualifié de polyvalent - il utilise activement le protocole SMB pour envoyer des messages et établir une communication avec d'autres copies, se propage à d'autres machines et communique avec le serveur CnC de sa propre manière. En installant un réseau peer-to-peer dans le domaine, des copies de Pegasus ouvrent la voie au réseau externe et communiquent avec le serveur CnC en procurant du trafic entre eux. L'utilisation de certificats pour signer des fichiers exécutables et l'accès aux ressources Microsoft et Mozilla pendant la vérification de la connexion rend difficile la détection de son activité et de sa détection sur l'hôte.

Le projet de code source de Pegasus est assez bien structuré et décrit, donc dans un avenir proche, nous pouvons nous attendre à l'emprunt de parties de son code par d'autres programmes malveillants et à l'apparition de modifications.

De nombreux mécanismes pour exécuter à distance des commandes et rechercher des données de compte n'étaient pas encore réalisés, les développeurs allaient également ajouter la possibilité de modifier le shellcode lors de la mise en œuvre à la volée. Et ce ne sont pas toutes leurs idées.

Nous avons développé plusieurs signatures pour PT NAD et IDS Suricata, qui nous permettent d'identifier l'activité du réseau spécifique à Pegasus à différentes étapes, à partir des toutes premières secondes de son activité. Vous pouvez trouver des signatures ouvertes pour Suricata IDS sur notre github et Twitter , ils accéderont automatiquement à votre Suricata si vous utilisez le mécanisme de mise à jour de suricata.

Vous pouvez voir comment les signatures pour l'activité Pegasus fonctionnent dans la capture d'écran ci-dessous. Voici notre nouveau produit PT Network Attack Discovery qui identifie les incidents et aide à les enquêter:



De plus, les indicateurs de compromis (IC) suivants peuvent être utilisés pour la détection:

  MAILSLOT \ 46CA075C165CBB2786 
 pipe \ pg0F9EC0DB75F67E1DBEFB3AFA2

 hxxp: //denwer/pegasus/index.php
 hxxp: //mp3.ucrazy.org/music/index.php
 hxxp: //support.zakon-auto.net/tuning/index.asp
 hxxp: //video.tnt-online.info/tnt-comedy-tv/stream.php 

Publié par Cyril Shipulin de @attackdetection, Twitter | Télégramme

Source: https://habr.com/ru/post/fr418017/


All Articles