Axé principalement sur l'Asie, ce nouveau groupe de cyberespionnage utilise des outils non documentés, notamment l'extraction stéganographique des charges utiles PowerShell à partir de fichiers PNG.
Les chercheurs d'ESET ont récemment découvert des attaques ciblées qui utilisaient des outils non documentés contre diverses entreprises et gouvernements locaux de premier plan, principalement en Asie. Ces attaques ont été menées par un groupe d'espionnage jusque-là inconnu que nous avons nommé Worok et qui est actif depuis au moins 2020. L'ensemble d'outils de Worok comprend un chargeur C++ CLRLoad, une porte dérobée PowerShell PowHeartBeat et un chargeur C# PNGLoad qui utilise la stéganographie pour extraire les éléments malveillants cachés. charges utiles à partir de fichiers PNG.
Qui est Worok ?
Pendant le ProxyShell (CVE-2021-34523) divulgation de vulnérabilité au début de 2021, nous avons observé activité de divers groupes APT. L'un présentait des caractéristiques communes avec TA428:
- Temps d'activité
- Secteurs verticaux ciblés
- Utilisation de ShadowPad
Le reste de l'outillage est très différent : par exemple, TA428 a participé au Compromis de bureau capable en 2020. Nous considérons que les liens ne sont pas assez forts pour considérer Worok comme le même groupe que TA428, mais les deux groupes pourraient partager des outils et avoir des intérêts communs. Nous avons décidé de créer un cluster et l'avons nommé Worok. Le nom a été choisi après un mutex dans un chargeur utilisé par le groupe. D'autres activités avec des variantes des mêmes outils ont ensuite été liées à ce groupe. Selon la télémétrie d'ESET, Worok est actif depuis fin 2020 et continue d'être actif à ce jour.
Fin 2020, Worok ciblait les gouvernements et les entreprises de plusieurs pays, en particulier :
- Une entreprise de télécommunications en Asie de l'Est
- Une banque en Asie centrale
- Une entreprise de l'industrie maritime en Asie du Sud-Est
- Une entité gouvernementale au Moyen-Orient
- Une entreprise privée en Afrique australe
Il y a eu une interruption significative des opérations observées de 2021-05 à 2022-01, mais l'activité de Worok est revenue en 2022-02, ciblant :
- Une entreprise énergétique en Asie centrale
- Une entité du secteur public en Asie du Sud-Est
La figure 1 présente une carte thermique visuelle des régions et des marchés verticaux ciblés.
Compte tenu des profils des cibles et des outils que nous avons vus déployés contre ces victimes, nous pensons que l'objectif principal de Worok est de voler des informations.
L'analyse technique
Bien que la majorité des accès initiaux soient inconnus, dans certains cas jusqu'en 2021 et 2022, nous avons vu des exploits utilisés contre les vulnérabilités ProxyShell. Dans de tels cas, des webshells ont généralement été téléchargés après avoir exploité ces vulnérabilités, afin d'assurer la persistance dans le réseau de la victime. Ensuite, les opérateurs ont utilisé divers implants pour acquérir de nouvelles capacités.
Une fois l'accès acquis, les opérateurs ont déployé plusieurs outils de reconnaissance accessibles au public, notamment Mimikatz, Ver de terre, RéGeorget NBTscan, puis ont déployé leurs implants personnalisés : un chargeur de première étape, suivi d'un chargeur .NET de deuxième étape (PNGLoad). Malheureusement, nous n'avons pu récupérer aucune des charges utiles finales. En 2021, le chargeur de premier étage était un assemblage CLR (CLRLoad), tandis qu'en 2022, il a été remplacé, dans la plupart des cas, par une porte dérobée PowerShell complète (PowHeartBeat) - les deux chaînes d'exécution sont représentées dans la figure 2. Ces trois Les outils sont décrits en détail dans les sous-sections suivantes.
Figure 2. Chaînes de compromis de travail
CLRLoad : chargeur d'assemblage CLR
CLLRoad est un Windows PE générique que nous avons vu dans les versions 32 et 64 bits. C'est un chargeur écrit en C++ qui charge l'étape suivante (PNGLoad), qui doit être un Assemblage Common Language Runtime (CLR) Fichier DLL. Ce code est chargé à partir d'un fichier situé sur le disque dans un répertoire légitime, probablement pour induire en erreur les victimes ou les intervenants en cas d'incident en leur faisant croire qu'il s'agit d'un logiciel légitime.
Certains exemples CLLRoad commencent par décoder le chemin complet du fichier dont ils chargeront le contenu à l'étape suivante. Ces chemins de fichiers sont encodés avec un XOR à un octet, avec une clé différente dans chaque échantillon. Décodés ou en clair, ces chemins de fichiers sont absolus, les suivants étant ceux que nous avons rencontrés :
- C:Fichiers de programmeVMwareVMware ToolsVMware VGAuthxsec_1_5.dll
- C:Program FilesUltraViewermsvbvm80.dll
- C:Fichiers de programmeInternet ExplorerJsprofile.dll
- C:Program FilesWinRarRarExtMgt.dll
- C: Fichiers de programme (x86) Logiciel Foxit Foxit Readerlucenelib.dll
Ensuite, un mutex est créé et nous avons vu un nom différent dans chaque échantillon. Le chargeur recherche ce mutex ; s'il est trouvé, il se ferme, car le chargeur est déjà en cours d'exécution. Dans l'un des échantillons, le mutex Wo0r0KGWhYGO a été rencontré, ce qui a donné au groupe son nom de Worok.
CLRLoad charge ensuite un assembly CLR à partir du chemin de fichier éventuellement décodé. En tant que code non géré, CLRLoad y parvient via CorBindToRuntimeEx Appels d'API Windows dans des variantes 32 bits, ou CLRCCréerInstance appels dans des variantes 64 bits.
PowHeartBeat : porte dérobée PowerShell
PowHeartBeat est une porte dérobée complète écrite en PowerShell, masquée à l'aide de diverses techniques telles que la compression, l'encodage et le chiffrement. Sur la base de la télémétrie ESET, nous pensons que PowHeartBeat a remplacé CLRLoad dans les campagnes Worok plus récentes en tant qu'outil utilisé pour lancer PNGLoad.
La première couche du code de porte dérobée se compose de plusieurs morceaux de code PowerShell encodé en base64. Une fois la charge utile reconstruite, elle est exécutée via IEX. Une fois décodé, une autre couche de code obscurci est exécutée, comme nous pouvons le voir sur la figure 3.
Figure 3. Extrait de la fonction principale décodée de la deuxième couche de PowHeartBeat
La deuxième couche de la porte dérobée first base64 décode la couche suivante de son code, qui est ensuite déchiffrée avec triple dés (Mode Radio-Canada). Après déchiffrement, ce code est décompressé à l'aide du gzip algorithme, donnant ainsi la troisième couche de code PowerShell, qui est la véritable porte dérobée. Il est divisé en deux parties principales : la configuration et la gestion des commandes de porte dérobée.
La couche principale de code de porte dérobée est également écrite en PowerShell et utilise HTTP ou ICMP pour communiquer avec le serveur C&C. Il fonctionne comme illustré à la figure 4.
Figure 4. Fonctionnement de PowHeartBeat
configuration
La configuration contient plusieurs champs, y compris le numéro de version, la configuration de proxy facultative et l'adresse C&C. Le tableau 1 décrit les significations des champs de configuration dans les différentes versions que nous avons observées.
Tableau 1. Signification des champs de configuration
| Nom de domaine | Description |
|---|---|
| nouse / ikuyrtydyfg (autres échantillons) |
Inutilisé. |
| Identité du client | Identifiant client, utilisé aux fins suivantes : · En tant que valeur lors de la construction du En-tête de cookie pour les communications C&C. · En tant qu'artefact cryptographique pour le cryptage des données envoyées. |
| Version | Numéro de version de PowHeartBeat. |
| Temps d'exécution | Nombre de tentatives d'exécution autorisées lors de l'émission d'un ExécuterCmd (commande en cours d'exécution). |
| Agent utilisateur | Agent utilisateur utilisé pour les communications C&C. |
| referer | referer en-tête utilisé pour les communications C&C. |
| AcceptEncoding | Inutilisé. |
| IDClientCookie ID de tâche de cookie CookieTerminalId |
Valeurs utilisées pour construire le Cookies en-tête pour les communications C&C. |
| URLHttps | Protocole à utiliser pour les communications C&C. |
| URLDomaine Adresse IP Domaines |
URL, domaine(s) ou adresse IP utilisés comme serveur C&C. Si Domaines n'est pas vide, il est choisi à la place de Adresse IP. Dans d'autres cas, Adresse IP est pris. |
| UrlEnvoyerHeartBeat | Chemin d'URL utilisé lorsque la porte dérobée demande des commandes au serveur C&C. |
| UrlEnvoyerRésultat | Chemin d'URL utilisé lorsque la porte dérobée renvoie les résultats de la commande au serveur C&C. |
| ObtenirUrl | URL complète, utilisée par PowHeartBeat pour demander des commandes au serveur C&C. C'est la concaténation des éléments d'URL ci-dessus. |
| PutUrl | Pareil que ObtenirUrl mais utilisé pour renvoyer les résultats de la commande au serveur C&C. |
| chemincourant | Inutilisé. |
| ProxyEnableFlag | Drapeau indiquant si la porte dérobée doit utiliser un proxy ou non pour communiquer avec le serveur C&C. |
| Proxysg | Adresse du proxy à utiliser si ProxyEnableFlag est fixé à $vrai. |
| intervalle | Durée en secondes pendant laquelle le script dort entre les requêtes GET. |
| BasicConfigPathBasicConfigPath | Chemin d'accès à un fichier de configuration facultatif contenant Temps de disponibilité, Temps d'arrêt, Intervalle par défautet Domaines. Ces valeurs seront remplacées si le fichier est présent. |
| Temps de disponibilité | Heure à partir de laquelle la porte dérobée commence à fonctionner, ce qui signifie qu'elle commence à envoyer des requêtes GET au serveur C&C. |
| Temps d'arrêt | Heure de la journée jusqu'à laquelle la porte dérobée peut fonctionner, c'est-à-dire l'heure à laquelle elle cesse de faire des requêtes au serveur C&C. |
| Index de domaine | Index du nom de domaine actuel à utiliser pour les communications avec le serveur C&C. Dans le cas où une requête renvoie un message d'erreur différent de 304 ("Non modifié"), Index de domaine est augmenté. |
| Clef secrète | Clé utilisée pour déchiffrer/chiffrer la configuration. La configuration est chiffrée avec XOR sur plusieurs octets. |
| SiLog | Inutilisé. |
| IfLogFilePath | Indicateur indiquant si la journalisation est activée. |
| chemin de journalisation | Chemin du fichier journal. |
| ProxyFichier | Chemin d'accès au fichier de la configuration de proxy facultative. S'il est vide ou introuvable dans le système de fichiers, la porte dérobée récupère les paramètres de proxy de l'utilisateur à partir de la valeur de registre HKCULogicielMicrosoftWindowsCurrentVersionParamètres InternetProxyServer . |
| SiConfig | Drapeau indiquant s'il faut utiliser un fichier de configuration. |
La figure 5 montre un exemple de la configuration extraite d'un échantillon PowHeartBeat (SHA-1 : 757ABA12D04FD1167528FDD107A441D11CD8C427).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
$Script:nouse = 100; if(Test-Path $MyInvocation.MyCommand.Path){Remove-item $MyInvocation.MyCommand.Path -Force;} $Script:ClientId = “83”; $Script:Version = “2.1.3.0003”; $Script:ExecTimes = 10; $Script:UserAgent = “Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3487.100 Safari/537.36”; $Script:Referer = “www.adobe.com”; $Script:AcceptEncoding = “text/html,app1ication/xhtml+xml,app1ication/xml;q=0.9,*/*;q=0.8”; $Script:CookieClientId = “s_ecid”; $Script:CookieTaskId = “aam_uuid”; $Script:CookieTerminalId = “AAMC_adobe_0”; $Script:UrlHttps = “http://”; $Script:UrlDomain= ” 118.193.78[.]22:443″; $Script:UrlSendHeartBeat = “/latest/AdobeMessagingClient.js”; $Script:UrlSendResult = “/content/dam/offers-homepage/homepage.jpg”; $Script:GetUrl = $Script:UrlHttps + $Script:UrlDomain + $Script:UrlSendHeartBeat; $Script:PutUrl = $Script:UrlHttps + $Script:UrlDomain + $Script:UrlSendResult; $Script:currentPath = Split-Path -Parent $MyInvocation.MyCommand.Definition; $Script:ProxyEnableFlag = $false; $Script:Proxymsg; $Script:Interval = 10 ; $Script:BasicConfigPath = “C:ProgramDataunins.dat”; $Script:UpTime = 0; $Script:DownTime = 24; $Script:Domains; $Script:DomainIndex; $Script:SecretKey = “###ConfigKey###”; #$Script:IfLog = $true; $Script:IfLogFilePath = “C:ProgramDatatpncp.dat”; $Script:logpath = “C:ProgramDataunins000.dat”; $Script:ProxyFile = “C:ProgramDatahwrenalm.dat”; $Script:IfConfig = $false; |
Illustration 5. Exemple de configuration
Cryptage des données
PowHeartBeat crypte les journaux et le contenu supplémentaire des fichiers de configuration.
Le contenu du fichier journal est chiffré via XOR sur plusieurs octets avec une clé spécifiée en texte clair dans l'exemple. De façon intéressante, identité du client est utilisé comme sel pour l'index dans le tableau de clés. La clé est un tableau de 256 octets, qui était identique dans tous les échantillons que nous avons rencontrés. Le contenu supplémentaire du fichier de configuration est chiffré via XOR à plusieurs octets avec la valeur de Clef secrète comme sa clé.
Communication C&C
PowHeartBeat a utilisé HTTP pour les communications C&C jusqu'à la version 2.4, puis est passé à ICMP. Dans les deux cas, la communication n'est pas cryptée.
HTTP
Dans une boucle infinie, la porte dérobée envoie une requête GET au serveur C&C, demandant une commande à émettre. La réponse chiffrée est déchiffrée par la porte dérobée, qui traite la commande, et écrit la sortie de la commande dans un fichier dont le contenu est ensuite envoyé au serveur C&C via une requête POST.
Le format des requêtes GET est le suivant :
|
GET <UrlSendHeartBeat> HTTP/1.1 User-Agent: <UserAgent> Referer: <Referer> Host: <Domain> Cookie: <CookieClientId>=<ClientId> Connection: close |
Notez que la requête est construite à l'aide des champs de configuration éponymes.
Dans la réponse du serveur C&C, le troisième octet du contenu est l'identifiant de commande qui indique la commande à traiter par la porte dérobée. Nous l'appellerons id_commande. Le contenu restant de la réponse sera transmis en tant qu'argument à la commande qui est traitée. Ce contenu est crypté avec l'algorithme illustré à la figure 6, ID de tâche étant la valeur du cookie nommé d'après ID de tâche de cookiede la valeur de la configuration.
|
1 2 3 4 5 6 7 8 9 10 |
o[int] $pos = $taskId % 256; for ($i = 0; $i -lt $tmpBytes.Value.Length; $i++) { $pos = $pos + $clientId; if ($pos -ge 256) { $pos = $pos % 256; } $tmpBytes.Value[$i] = [byte]($tmpBytes.Value[$i] -bxor $hexEnc[$pos]); } |
Figure 6. Algorithme de chiffrement des données de contenu des requêtes
La réponse du serveur C&C contient également un autre cookie, dont le nom est spécifié par le backdoor CookieTerminalId variables de configuration. La valeur de ce cookie est répétée dans la requête POST de la porte dérobée, et elle ne doit pas être vide. Après avoir exécuté la commande de porte dérobée, PowHeartBeat envoie le résultat sous forme de requête POST au serveur C&C. Le résultat est envoyé sous forme de fichier dont le nom est .png.
ICMP
A partir de la version 2.4 de PowHeartBeat, HTTP a été remplacé par ICMP, envoyait des paquets ayant un timeout de six secondes et étant non fragmenté. La communication via ICMP est très probablement un moyen d'échapper à la détection.
Il n'y a pas de changement majeur dans les versions 2.4 et supérieures, mais nous avons remarqué quelques modifications dans le code :
- PowHeartBeat envoie un paquet de pulsation à chaque boucle contenant la chaîne abcdefghijklmnopqrstuvwxyz, avant de demander une commande. Cela informe le serveur C&C que la porte dérobée est prête à recevoir des commandes.
- Les requêtes pour obtenir des commandes exécutées par la porte dérobée contiennent la chaîne abcdefghijklmnop.
Les paquets Heartbeat ont le format décrit à la Figure 7.
Figure 7. Disposition des paquets Heartbeat
La différence entre identité du client ainsi que indicateur client que identité du client diffère dans chaque échantillon alors que indicateur client est le même dans chaque échantillon qui utilise ICMP. drapeau de battement de coeur indique que la porte dérobée envoie un battement de cœur. La réponse du serveur C&C a le format décrit dans la Figure 8.
Figure 8. Disposition de la réponse du serveur C&C
drapeau indique ici s'il existe une commande à émettre vers la porte dérobée. Les demandes d'obtention de commandes ont le format décrit à la figure 9.
Figure 9. Disposition des requêtes pour obtenir des commandes
Notez que le mode ICMP de la porte dérobée permet de recevoir une quantité illimitée de données, divisées en morceaux, et les variables longueur des données, position actuelle ainsi que longueur totale sont utilisés pour garder une trace des données transmises. Les réponses à ces demandes ont le format décrit à la Figure 10.
Figure 10. Disposition des réponses aux demandes d'obtention de commandes
Comme dans les réponses HTTP, l'identifiant de la commande est le troisième octet de données.
Après sept réponses ICMP consécutives avec un contenu vide ou au format incohérent, les transferts entre la porte dérobée et le serveur C&C sont considérés comme terminés.
Concernant les demandes d'envoi du résultat de la commande émise au serveur C&C, le mode serveur est changé pour le mode post, et la chaîne finale (abcdefghijklmnop) est modifié pour les données de résultat.
Commandes de porte dérobée
PowHeartBeat a diverses capacités, y compris l'exécution de commandes/processus et la manipulation de fichiers. Le tableau 2 répertorie toutes les commandes prises en charge par les différents échantillons analysés.
Tableau 2. Descriptions des commandes PowHeartBeat
| Nom | Identificateur de commande | Description |
|---|---|---|
| Cmd | Assistance | Exécutez une commande PowerShell. |
| Exe | Assistance | Exécuter une commande en tant que processus. |
| Téléchargement de fichiers | Assistance | Télécharger un fichier sur la machine victime. Le contenu du fichier est compressé avec gzip. |
| Téléchargement de fichier | Assistance | Téléchargez un fichier à partir de la machine victime et renvoyez le chemin du fichier, la longueur du fichier, l'heure de création, les temps d'accès et le contenu du fichier au serveur C&C. |
| FichierAfficher | 0x0A | Obtenir des informations sur les fichiers d'un répertoire spécifique, en particulier : · Noms de fichiers · Attributs de fichier · Dernières heures d'écriture · Contenu du fichier |
| FichierSupprimer | 0x0C | Supprimer un fichier. |
| RenommerFichier | 0x0E | Renommer ou déplacer un fichier. |
| ChangerRep | Assistance | Modifiez l'emplacement de travail actuel de la porte dérobée. |
| Info | Assistance | Récupère une catégorie d'informations en fonction de l'argument spécifié : · "Informations de base": Identité du client, Version, nom d'hôte, adresses IP, explorer.exe informations de version et de taille, OS (architecture et drapeau indiquant si la machine est un serveur), intervalle, répertoire courant, informations sur le lecteur (nom, type, espace libre et taille totale), heure actuelle · « Informations sur l'intervalle de temps » : intervalle et l'heure actuelle · « Informations sur le domaine » : contenu décrypté du fichier de configuration |
| Config | Assistance | Mettez à jour le contenu du fichier de configuration et rechargez la configuration. |
| N/D | Assistance | Sortie par la porte dérobée. |
En cas d'erreurs du côté de la porte dérobée, la porte dérobée utilise un identifiant de commande spécifique 0x00 dans la requête POST au serveur C&C, indiquant ainsi qu'une erreur s'est produite.
Notez qu'avant de renvoyer les informations au serveur C&C, les données sont compressées avec gzip.
PNGLoad : chargeur stéganographique
PNGLoad est la charge utile de deuxième étape déployée par Worok sur des systèmes compromis et, selon la télémétrie ESET, chargée soit par CLRLoad soit par PowHeartBeat. Bien que nous ne voyons aucun code dans PowHeartBeat qui charge directement PNGLoad, la porte dérobée a la capacité de télécharger et d'exécuter des charges utiles supplémentaires à partir du serveur C&C, ce qui est probablement la façon dont les attaquants ont déployé PNGLoad sur des systèmes compromis avec PowHeartBeat. PNGLoad est un chargeur qui utilise des octets de fichiers PNG pour créer une charge utile à exécuter. Il s'agit d'un exécutable .NET 64 bits - masqué par Réacteur .NET – qui se fait passer pour un logiciel légitime. Par exemple, la figure 11 montre les en-têtes CLR d'un échantillon se faisant passer pour une DLL WinRAR.
Figure 11. Exemple d'une fausse DLL WinRAR
Une fois désobscurci, une seule classe est présente. Dans cette classe, il y a un Chemin principal attribut contenant le chemin du répertoire que la porte dérobée recherche, y compris ses sous-répertoires, pour les fichiers avec un . Png extension, comme le montre la figure 12.
Figure 12. . Png liste de fichiers
Chaque . Png fichier localisé par cette recherche de Chemin principal est ensuite vérifié pour le contenu intégré stéganographiquement. Tout d'abord, le bit le moins significatif des valeurs R (rouge), G (vert), B (bleu) et A (alpha) de chaque pixel est extrait et assemblé dans un tampon. Si les huit premiers octets de ce tampon correspondent au nombre magique illustré à la figure 13 et que la valeur de huit octets suivante, control, n'est pas nulle, le fichier passe la vérification de contenu stéganographique de PNGLoad. Pour de tels fichiers, le traitement se poursuit avec le reste du tampon déchiffré avec un XOR à plusieurs octets, en utilisant la clé stockée dans PNGLoad's Octets de clé secrète , puis le tampon déchiffré est décompressé par gzip. Le résultat devrait être un script PowerShell, qui est exécuté immédiatement.
Figure 13. Format du tampon créé par PNGLoad à partir du traitement . Png fichiers
Fait intéressant, les opérations effectuées par PNGLoad sont enregistrées dans un fichier dont le chemin est stocké dans la variable Chemin du fichier journal. Les opérations ne sont journalisées que si un fichier est présent dont le chemin est spécifié par la variable interne IfLogFilePath.
Nous n'avons pas pu obtenir d'échantillon . Png fichier utilisé avec PNGLoad, mais la façon dont PNGLoad fonctionne suggère qu'il devrait fonctionner avec des fichiers PNG valides. Pour masquer la charge utile malveillante, Worok utilise des objets Bitmap en C #, qui ne prennent que les informations de pixel des fichiers, pas les métadonnées du fichier. Cela signifie que Worok peut masquer ses charges utiles malveillantes dans des images PNG valides et d'apparence inoffensive et ainsi se cacher à la vue de tous.
Conclusion
Worok est un groupe de cyberespionnage qui développe ses propres outils, tout en exploitant les outils existants, pour compromettre ses cibles. Selon nous, voler des informations à leurs victimes est ce que les opérateurs recherchent, car ils se concentrent sur des entités de premier plan en Asie et en Afrique, ciblant divers secteurs, à la fois privés et publics, mais avec un accent particulier sur les entités gouvernementales. Les temps d'activité et l'ensemble d'outils indiquent des liens possibles avec TA428, mais nous faisons cette évaluation avec une faible confiance. Leur ensemble d'outils personnalisés comprend deux chargeurs - un en C++ et un en C# .NET - et une porte dérobée PowerShell. Bien que notre visibilité soit limitée, nous espérons que faire la lumière sur ce groupe encouragera d'autres chercheurs à partager des informations sur ce groupe.
ESET Research propose désormais également des rapports de renseignement APT privés et des flux de données. Pour toute demande concernant ce service, rendez-vous sur Intelligence des menaces ESET .
COI
Fichiers
| SHA-1 | Nom de fichier | Nom de détection ESET | Commentaires |
|---|---|---|---|
| 3A47185D0735CDECF4C7C2299EB18401BFB328D5 | scénario | PowerShell/PowHeartBeat.B | PowHeart Beat 2.4.3.0003. |
| 27ABB54A858AD1C1FF2863913BDA698D184E180D | scénario | PowerShell/PowHeartBeat.A | PowHeart Beat 2.4.3.0003. |
| 678A131A9E932B9436241402D9727AA7D06A87E3 | scénario | PowerShell/PowHeartBeat.B | PowHeart Beat 2.4.3.0003. |
| 757ABA12D04FD1167528FDD107A441D11CD8C427 | scénario | PowerShell/PowHeartBeat.B | PowHeart Beat 2.1.3.0003. |
| 54700A48D934676FC698675B4CA5F712C0373188 | scénario | PowerShell/PowHeartBeat.A | PowHeart Beat 1.1.3.0002. |
| C2F53C138CB1B87D8FC9253A7088DB30B25389AF | scénario | PowerShell/PowHeartBeat.A | PowHeart Beat 1.1.3.0002. |
| C2F1954DE11F72A46A4E823DE767210A3743B205 | tmp.ps1 | PowerShell/PowHeartBeat.B | PowHeart Beat 2.4.3.0004. |
| CE430A27DF87A6952D732B4562A7C23BEF4602D1 | tmp.ps1 | PowerShell/PowHeartBeat.A | PowHeart Beat 2.1.3.0004. |
| EDE5AB2B94BA85F28D5EE22656958E4ECD77B6FF | scénario | PowerShell/PowHeartBeat.A | PowHeart Beat 2.4.3.0003. |
| 4721EEBA13535D1EE98654EFCE6B43B778F13126 | vix64.dll | MSIL/PNGLloader.A | Chargeur PNG. |
| 728A6CB7A150141B4250659CF853F39BFDB7A46C | RarExtMgt.dll | MSIL/PNGLloader.A | Chargeur PNG. |
| 864E55749D28036704B6EA66555A86527E02AF4A | Jsprofile.dll | MSIL/PNGLloader.A | Chargeur PNG. |
| 8DA6387F30C584B5FD3694A99EC066784209CA4C | vssxml.dll | MSIL/PNGLloader.A | Chargeur PNG. |
| AA60FB4293530FBFF00D200C0D44EEB1A17B1C76 | xsec_1_5.dll | MSIL/PNGLloader.A | Chargeur PNG. |
| B2EAEC695DD8BB518C7E24C4F37A08344D6975BE | msvbvm80.dll | MSIL/PNGLloader.A | Chargeur PNG. |
| CDB6B1CAFEE098615508F107814179DEAED1EBCF | lucenelib.dll | MSIL/PNGLloader.A | Chargeur PNG. |
| 4F9A43E6CF37FF20AE96E564C93898FDA6787F7D | vsstrace.dll | Win64/CRLLoad.C | CLRCharger. |
| F181E87B0CD6AA4575FD51B9F868CA7B27240610 | ncrypt.dll | Win32/CRLLoad.A | CLRCharger. |
| 4CCF0386BDE80C339EFE0CC734CB497E0B08049C | ncrypt.dll | Win32/CRLLoad.A | CLRCharger. |
| 5CFC0D776AF023DCFE8EDED5CADA03C6D7F9C244 | wlbsctrl.dll | Win64/CRLLoad.E | CLRCharger. |
| 05F19EBF6D46576144276090CC113C6AB8CCEC08 | wlbsctrl.dll | Win32/CRLLoad.A | CLRCharger. |
| A5D548543D3C3037DA67DC0DA47214B2C2B15864 | secur32.dll | Win64/CRLLoad.H | CLRCharger. |
| CBF42DCAF579AF7E6055237E524C0F30507090F3 | dbghelp.dll | Win64/CRLLoad.C | CLRCharger. |
Chemins de fichier
Une partie de la Chemin principal, Chemin du fichier journal ainsi que IfLogFilePath valeurs que nous avons rencontrées dans les exemples PNGLoad :
| Chemin principal | Chemin du fichier journal | IfLogFilePath |
|---|---|---|
| C:Fichiers de programmeVMwareVMware Tools | C:Fichiers de programmeVMwareVMware ToolsVMware VGAuthreadme.txt | C:Fichiers de programmeVMwareVMware ToolsVMware VGAuthVMWSU_V1_1.dll |
| C:Fichiers de programmeWinRar | C:Program FilesWinRarrarinstall.log | C:Program FilesWinRardes.dat |
| C:Program FilesUltraViewer | C:Program FilesUltraViewerCopyRights.dat | C:Program FilesUltraVieweruvcr.dll |
Réseau
| Domaine | IP |
|---|---|
| Aucun | 118.193.78[.]22 |
| Aucun | 118.193.78[.]57 |
| avion.voyage-publicités[.]agence | 5.183.101[.]9 |
| central.suhypercloud[.]org | 45.77.36[.]243 |
Mutex
Dans les exemples CLRLoad, les noms de mutex que nous avons rencontrés sont :
aB82UduGX0EX
ad8TbUIZl5Ga
Mr2PJVxbIBD4
oERiQtKLgPgK
U37uxsCsA4Xm
Wo0r0KGWhYGO
xBUjQR2vxYTz
zYCLWBekRX3t
3c3401ad-e77d-4142-8db5-8eb5483d7e41
9xvzMsaWqxMon
Une liste complète des indicateurs de compromission (IoC) et des exemples sont disponibles dans notre référentiel GitHub.
Techniques d'ATT&CK D'ONGLET
Ce tableau a été construit avec Version 11 du cadre MITRE ATT&CK.
| Tactique | ID | Nom | Description |
|---|---|---|---|
| Reconnaissance | T1592.002 | Recueillir des informations sur l'hôte de la victime : logiciel | PowHeartBeat rassemble explorer.exe </br>L’Information. |
| T1592.001 | Recueillir les informations sur l'hôte de la victime : matériel | PowHeartBeat rassemble des informations sur les lecteurs. | |
| T1590.005 | Recueillir des informations sur le réseau des victimes : adresses IP | PowHeartBeat rassemble les adresses IP de l'ordinateur compromis. | |
| Développement des ressources | T1583.004 | Acquérir une infrastructure : serveur | Workok utilise ses propres serveurs C&C. |
| T1588.002 | Obtenir des capacités : outil | Workok a déployé plusieurs outils accessibles au public sur les machines compromises. | |
| T1583.001 | Acquisition d'infrastructure : domaines | Worok a enregistré des domaines pour faciliter la communication et la mise en scène C&C. | |
| T1588.005 | Obtenir des capacités : exploits | Workok a utilisé la vulnérabilité ProxyShell. | |
| T1587.001 | Développer des capacités : logiciels malveillants | Worok a développé ses propres malwares : CLRLoad, PNGLoad, PowHeartBeat. | |
| T1587.003 | Développer des capacités : certificats numériques | Worok a créé des certificats SSL Let's Encrypt afin de permettre l'authentification mutuelle TLS pour les logiciels malveillants. | |
| Internationaux | T1059.001 | Interpréteur de commandes et de scripts : PowerShell | PowHeartBeat est écrit en PowerShell. |
| Persistence | T1505.003 | Composant logiciel serveur : Web Shell | Workok utilise le webshell RéGeorg. |
| Évasion défensive | T1140 | Désobscurcir/décoder des fichiers ou des informations | Worok utilise divers schémas personnalisés basés sur XOR pour chiffrer les chaînes et les journaux dans PowHeartBeat, PNGLoad et CLRLoad. |
| T1036.005 | Masquage : correspond à un nom ou à un emplacement légitime | Les exemples PNGLoad sont déployés dans des répertoires VMWare d'apparence légitime. | |
| Accès aux informations d'identification | T1003.001 | Vidage des informations d'identification du système d'exploitation : mémoire LSASS | Worok utilise Mimikatz pour vider les informations d'identification de la mémoire LSASS. |
| Découverte | T1082 | Découverte des informations système | PowHeartBeat rassemble des informations sur le système d'exploitation. |
| T1083 | Découverte de fichiers et de répertoires | PowHeartBeat peut lister les fichiers et les répertoires. | |
| T1046 | Découverte des services réseau | Utilisations de travail NbtScan pour obtenir des informations réseau sur les machines compromises. | |
| T1124 | Découverte de l'heure système | PowHeartBeat recueille les informations temporelles de la victime. | |
| Collection | T1005 | Données du système local | PowHeartBeat rassemble les données du système local. |
| T1560.002 | Archiver les données collectées : archiver via la bibliothèque | PowHeartBeat compresse gzip les données avant de les envoyer au serveur C&C. | |
| Commander et contrôler | T1071.001 | Protocole de couche d'application : protocoles Web | Certaines variantes de PowHeartBeat utilisent HTTP comme protocole de communication avec le serveur C&C. |
| T1090.001 | Proxy : Proxy interne | PowHeartBeat gère la configuration du proxy sur la machine de la victime. | |
| T1001.002 | Obfuscation des données : stéganographie | PNGLoad extrait les valeurs de pixel de . Png fichiers pour reconstruire les charges utiles. | |
| T1573.002 | Canal crypté : cryptographie asymétrique | PowHeartBeat gère les communications HTTPS avec le serveur C&C. | |
| T1095 | Protocole de couche non applicative | Certaines variantes de PowHeartBeat utilisent ICMP comme protocole de communication avec le serveur C&C. | |
| T1132.001 | Codage des données : Codage standard | Worok utilise l'encodage XOR dans PowHeartBeat et PNGLoad. | |
| T1132.002 | Codage des données : codage non standard | Worok utilise des algorithmes de codage XOR qui utilisent un sel supplémentaire. | |
| exfiltration | T1041 | Exfiltration sur le canal C2 | PowHeartBeat utilise son canal de communication C&C pour exfiltrer des informations. |
- blockchain
- cognitif
- portefeuilles de crypto-monnaie
- cryptoexchange
- la cyber-sécurité
- les cybercriminels
- Cybersécurité
- département de la Sécurité intérieure
- portefeuilles numériques
- Recherche ESET
- pare-feu
- Kaspersky
- malware
- Mcafee
- NexBLOC
- Platon
- platon ai
- Intelligence des données Platon
- Jeu de Platon
- PlatonDonnées
- jeu de platogamie
- VPN
- Nous vivons la sécurité
- la sécurité d'un site web
- zéphyrnet
