En février 2020, nous avons découvert une nouvelle porte dérobée modulaire, que nous avons appelée PipeMon. Persistant comme un processeur d'impression, il a été utilisé par le groupe Winnti contre plusieurs sociétés de jeux vidéo basées en Corée du Sud et à Taïwan et développant des jeux MMO (Massivement Multijoueurs en Ligne). Les jeux vidéo développés par ces sociétés sont disponibles sur des plateformes de jeux populaires et comptent des milliers de joueurs simultanés.

Dans au moins un cas, les opérateurs de logiciels malveillants ont compromis le système de compilation d'une victime, ce qui aurait pu conduire à une attaque de la chaîne d'approvisionnement, permettant aux attaquants de créer des exécutables de jeux à l'aide de chevaux de Troie. Dans un autre cas, les serveurs de jeu ont été compromis, ce qui aurait pu permettre aux attaquants de manipuler, par exemple, les devises du jeu à des fins financières.

Le groupe Winnti, actif depuis au moins 2012, est responsable d'attaques de la chaîne d'approvisionnement très médiatisées contre l'industrie du logiciel, conduisant à la distribution de logiciels troyens (tels que CCleaner, ASUS LiveUpdate et plusieurs jeux vidéo) qui sont ensuite utilisés pour compromettre d'autres victimes. Récemment, les chercheurs d'ESET ont également découvert une campagne du groupe Winnti ciblant plusieurs universités de Hong Kong avec le ShadowPad et le logiciel malveillant Winnti.

Attribution au groupe Winnti

De multiples indicateurs nous ont amenés à attribuer cette campagne au groupe Winnti. Certains des domaines C&C utilisés par PipeMon ont été utilisés par le logiciel malveillant Winnti lors de campagnes précédentes mentionnées dans notre white paper sur l'arsenal du groupe Winnti. En outre, un logiciel malveillant Winnti a également été découvert en 2019 dans certaines des entreprises qui ont ensuite été compromises avec PipeMon.

En plus du logiciel malveillant Winnti, un binaire AceHash (qui subtilise les informations d’accès) personnalisé trouvé chez d'autres victimes du groupe Winnti, et signé avec un certificat volé bien connu utilisé par le groupe (Wemade IO), a également été utilisé pendant cette campagne.

Le certificat utilisé pour signer l'installateur PipeMon, les modules et les outils supplémentaires est lié à une société de jeux vidéo qui a été compromise lors d'une attaque de la chaîne d'approvisionnement fin 2018 par le groupe Winnti et a probablement été volée à cette époque.

Il est intéressant de noter que les modules PipeMon sont installés dans %SYSTEM32%\spool\prtprocs\x64\. Ce chemin a également été utilisé dans le passé pour déposer la deuxième étape du CCleaner trojanisé.

En outre, compromettre l'environnement de compilation d'un développeur de logiciels pour compromettre ensuite une application légitime est un modus operandi connu du groupe Winnti.

Entreprises ciblées

Les entreprises visées par cette campagne sont des développeurs de jeux vidéo, produisant des jeux MMO et basées en Corée du Sud et à Taïwan. Dans au moins un cas, les attaquants ont pu compromettre le serveur d'orchestration de la société, leur permettant ainsi de prendre le contrôle des systèmes de construction automatisés. Cela aurait pu permettre aux attaquants d'inclure le code arbitraire de leur choix dans les exécutables des jeux vidéo.

ESET a contacté les entreprises concernées et leur a fourni les informations nécessaires pour remédier à cette compromission.

Analyse technique

Deux variantes différentes de PipeMon ont été trouvées dans les entreprises visées. Ce n'est que pour la variante la plus récente que nous avons pu identifier la première étape qui est responsable de l'installation et de la persistance de PipeMon.

Premier niveau

Le premier niveau de PipeMon consiste en un exécutable RARSFX protégé par un mot de passe et intégré dans la section .rsrc  de son lanceur. Le lanceur écrit le RARSFX dans setup0.exe dans un répertoire nommé avec une chaîne ASCII de huit caractères générée de manière aléatoire et située dans le répertoire renvoyé par GetTempPath. Une fois écrit sur le disque, le RARSFX est exécuté avec CreateProcess  en fournissant le mot de passe de déchiffrement dans un argument, comme suit :

setup0.exe -p*|T/PMR{|T2^LWJ*

Notons que le mot de passe est différent pour chaque échantillon.

Le contenu du RARSFX est ensuite extrait en %TMP%\RarSFX0, qui est composé des fichiers suivants :

• CrLnc.dat – Encrypted payload
• Duser.dll – Used for UAC bypass
• osksupport.dll – Used for UAC bypass
• PrintDialog.dll – Used for the malicious print processor initialization
• PrintDialog.exe – Legitimate Windows executable used to load PrintDialog.dll
• setup.dll – Installation DLL
• setup.exe – Main executable

Notez qu'en cas de collision de noms de dossiers, le nombre à la fin de la chaîne RarSFX0 est incrémenté jusqu'à ce qu'une collision soit évitée. En outre, tous ces fichiers ne sont pas nécessairement présents dans l'archive, selon l'installateur.

Une fois extrait, setup.exe est exécuté sans arguments. Son seul but est de charger setup.dll en utilisant LoadLibraryA. Une fois chargé, setup.dll vérifie si un argument au format -x:n (où n est un entier) a été fourni; le mode de fonctionnement sera différent selon la présence de n. Les arguments pris en charge et leur comportement correspondant sont indiqués dans le tableau 1, setup.exe, est exécuté sans arguments par le RARSFX, et vérifie s'il fonctionne avec des privilèges élevés. Si ce n'est pas le cas, il tentera d'obtenir ces privilèges en utilisant l'usurpation de token d'identité si la version de Windows est inférieure à Windows 7 build 7601. Sinon, il tentera différentes techniques de contournement de l'UAC, permettant l'installation du chargeur de charge utile :

• C:\Windows\System32\spool\prtprocs\x64\DEment.dll
• C:\Windows\System32\spool\prtprocs\x64\EntAppsvc.dll
• C:\Windows\System32\spool\prtprocs\x64\Interactive.dll

en fonction de la variante. Notez que nous n'avons pas pu récupérer les échantillons liés à Interactive.dll.

Tableau 1. Les arguments supportés par setup.exe et leur comportement correspondant.

Ce loader est stocké chiffré dans setup.dll, qui le déchiffrera avant de l'écrire à l'endroit mentionné ci-dessus.

Persistance utilisant Windows Print Processors

L'endroit où la DLL malveillante est déposée n'a pas été choisi au hasard. C'est le chemin où se trouvent les Windows Print Processors et setup.dll enregistre le chargeur de DLL malveillante comme processeur d'impression alternatif en définissant l'une des valeurs de registre suivantes :

HKLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Print Processors\PrintFiiterPipelineSvc\Driver = “DEment.dll”

ou

HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Print Processors\lltdsvc1\Driver = “EntAppsvc.dll”

en fonction de la variante. Notez la faute de frappe dans PrintFiiterPipelineSvc (qui n'a pas d'impact sur l'installation du processeur d'impression puisque n'importe quel nom peut être utilisé).

Après avoir enregistré le processeur d'impression, PipeMon redémarre le service de spouleur d'impression (spoolsv.exe). Par conséquent, le processus d'impression malveillant est chargé au démarrage du service spooler. Notez que le service de spooler d'impression démarre à chaque démarrage du PC, ce qui garantit la persistance des réinitialisations du système.

Cette technique est vraiment similaire à la technique de persistance Print Monitor (utilisée par DePriMon, par exemple) et, à notre connaissance, n'a pas été documentée auparavant.

De plus, la charge utile chiffrée, CrLnc.dat, extraite du RARSFX est inscrite dans le registre à l'emplacement suivant, selon l'installateur :

• HKLM\SOFTWARE\Microsoft\Print\Components\DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8
• HKLM\SOFTWARE\Microsoft\Print\Components\A66F35-4164-45FF-9CB4-69ACAA10E52D

Cette charge utile chiffrée du registre est ensuite chargée, déchiffrée et exécutée par la bibliothèque du processeur d'impression préalablement enregistrée. L'ensemble de la mise en place et de la persistance de PipeMon est illustré à la figure 1.

Figure 1. PipeMon staging and persistence

PipeMon

Nous avons nommé ce nouvel implant PipeMon parce qu'il utilise plusieurs tuyaux dédiés à la communication inter-modules et selon son chemin PDB, le nom du projet Visual Studio utilisé par son développeur est « Monitor ».

Comme mentionné précédemment, deux variantes différentes de PipeMon ont été trouvées. En ce qui concerne la première variante, nous n'avons pas pu récupérer l'installateur ; nous ne sommes donc pas sûrs de la technique de persistance utilisée. Mais étant donné que cette première variante de PipeMon se trouvait également dans le répertoire « Print Processor », il est probable que le même mécanisme de persistance a été utilisé.

Variante originale

PipeMon est une porte dérobée modulaire où chaque module est une DLL unique exportant une fonction appelée IntelLoader et est chargé en utilisant une technique de chargement réflective. Chaque module présente des fonctionnalités différentes qui sont indiquées dans le tableau 2.

Le chargeur, responsable du chargement des modules principaux (ManagerMain et GuardClient) est Win32CmdDll.dll et se trouve dans le répertoire des processeurs d'impression. Les modules sont stockés de manière chiffrée sur le disque au même endroit avec des noms d'apparence inoffensive tels que :

• banner.bmp
• certificate.cert
• License.hwp
• JSONDIU7c9djE
• D8JNCKS0DJE
• B0SDFUWEkNCj.logN

Notez que .hwp est l'extension utilisée par le traitement de texte Hangul de Hangul Office, qui est très populaire en Corée du Sud.

Les modules sont chiffrés en RC4 et la clé de déchiffrement Com!123Qasdz est codée en dur dans chaque module. Win32CmDll.dll déchiffre et injecte les modules ManagerMain et GuardClient. Le module ManagerMain est chargé de déchiffrer et d'injecter le module Communication, tandis que le module GuardClient s'assure que le module Communication fonctionne et le recharge si nécessaire. Un aperçu du fonctionnement de PipeMon est présenté à la figure 2.

Win32CmDll.dll essaie d'abord d'injecter les modules ManagerMain et GuardClient dans un processus portant l'un des noms suivants : lsass.exe, wininit.exe ou lsm.exe. Si cela échoue, il tente d'injecter dans un des processus enregistrés des services Windows, à l'exclusion des processus nommés spoolsv.exe, ekrn.exe (ESET), avp.exe (Kaspersky) ou dllhost.exe. En dernier lieu, si tout le reste a échoué, il tente d'utiliser les processus taskhost.exe, taskhostw.exe ou explorer.exe.

Les candidats au processus d'injection du module de communication doivent se trouver dans la table de connexion TCP avec soit 0.0.0.0 comme adresse locale, soit une connexion ÉTABLIE et possédant un jeton de SERVICE LOCAL.  Ces conditions sont probablement utilisées pour dissimuler le module de communication dans un processus qui communique déjà sur le réseau, de sorte que le trafic provenant du module de communication passe inaperçu et peut également figurer sur une liste blanche dans le pare-feu. Si aucun processus ne répond aux exigences précédentes, le module ManagerMain tente d'injecter le module Communication dans explorer.exe. Les processus appartenant aux applications du magasin Windows et les processus nommés egui.exe (ESET) et avpui.exe (Kaspersky) sont ignorés de la sélection.

Tableau 2. Descriptions des modules PipeMon et leurs chemins PDB respectifs

Des modules supplémentaires peuvent être chargés à la demande à l'aide de commandes dédiées (voir ci-dessous), mais malheureusement, nous n'avons pu en découvrir aucun. Les noms de ces modules sont une supposition éclairée basée sur les tuyaux nommés utilisés pour communiquer avec eux :

• Screen
• Route
• CMD
• InCmd
• File

Communication inter-modules

La communication inter-modules s'effectue par le biais de tuyaux nommés, en utilisant deux tuyaux nommés par canal de communication entre chaque module individuel, un pour l'envoi et un pour la réception. Le tableau 3 énumère les canaux de communication et les tuyaux nommés correspondants.

Tableau 3. Canal de communication PipeMon et leurs tuyaux nommés respectifs

La chaîne %CNC_DEFINED% est reçue du serveur C&C et les variables %B64_TIMESTAMP% sont des horodatages encodés en base 64 tels que ceux présentés dans le tableau 4.

Tableau 4. Exemples d'horodatages utilisés avec des tuyaux nommés

Figure 2. Schéma de l'IPC PipeMon (variante originale de PipeMon)

Communication C&C

Le module Communication est chargé de gérer les communications entre le serveur C&C et les autres modules via des tuyaux nommés, similaires à la porte dérobée PortReuse documentée dans notre white paper sur l'arsenal Winnti.

Son adresse C&C est codée en dur dans le module ManagerMain et chiffrée à l'aide de RC4 avec la clé codée en dur Com!123Qasdz. Elle est envoyée au module de communication par le biais d'un tuyau nommé.

Un canal de communication distinct est créé pour chaque module installé. Le protocole de communication utilisé est TLS sur TCP. La communication est gérée par la bibliothèque HP-Socket library. Tous les messages sont codés en RC4 à l'aide de la clé codée en dur. Si la taille du message à transférer est supérieure ou égale à 4KB, il est d'abord compressé en utilisant l'implémentation Deflate de zlib.

struct CCMSG
{
    BYTE is_compressed;
    CMD cmd;
};

struct CMD
{
    QWORD cmd_type;
    DWORD cmd_size;
    DWORD cmd_arg;
    BYTE data[cmd_size - 16];
};

struct beacon_msg
{
    BYTE isCompressed = 0;
    CMD cmd_hdr;
    WCHAR win_version[128];
    WCHAR adapters_addrs[128];
    WCHAR adapters_addrs[64];
    WCHAR local_addr[64];
    WCHAR malware_version[64];
    WCHAR computer_name[64];
}

Figure 3. Formats des messages C&C et des balises

Pour initier la communication avec le serveur C&C, un message de balise est d'abord envoyé qui contient les informations suivantes :

• Version du système d'exploitation
• adresses physiques des adaptateurs de réseau connectés concaténées avec %B64_TIMESTAMP%.
• adresse IP locale de la victime
• version backdoor/identification de la campagne; nous avons observé les valeurs suivantes
• “1.1.1.4 battement"
• "1.1.1.4Bata"
• “1.1.1.5”
• Nom de l'ordinateur de la victime

Les informations concernant la machine de la victime sont collectées par le module ManagerMain et envoyées au module Communication via le tuyau nommé. La version backdoor est codée en dur dans le module de communication en texte clair.

Le format du message de la balise est présenté à la figure 3 et les commandes prises en charge sont indiquées dans le tableau 5.

Tableau 5. Liste des commandes

* L'argument fourni pour ce type de commande est ignoré

Variante mise à jour

Comme mentionné précédemment, les attaquants utilisent également une version mise à jour de PipeMon pour laquelle nous avons pu récupérer le premier niveau décrite ci-dessus. Tout en présentant une architecture très similaire à la variante originale, son code a probablement été réécrit à partir de zéro.

Le code RC4 utilisé pour déchiffrer les modules et les chaînes a été remplacé par un simple XOR avec 0x75E8EEAF comme clé et toutes les chaînes codées en dur ont été supprimées. Les tuyaux nommés utilisés pour la communication inter-modules sont maintenant nommés en utilisant des valeurs aléatoires au lieu de noms explicites et se conforment au format \\.\pipe\%rand%, où %rand% est une chaîne de 31 caractères générée de façon pseudo-aléatoire contenant uniquement des caractères alphabétiques en majuscules.

Ici, seul le chargeur principal (c'est-à-dire la DLL malveillante installée comme processeur d'impression) est stocké sous forme de fichier sur le disque; les modules sont stockés dans le registre par l'installateur (à partir du fichier  CrLnc.dat) et sont décrits dans le tableau 6.

Tableau 6. Modules mis à jour

L'injection de modules n'est plus effectuée par la technique de chargement par réflexion avec fonction d'exportation; un shellcode de chargement personnalisé est utilisé à la place et est injecté avec le module à charger.

Le format du message C&C a également été modifié et est présenté à la figure 4.

struct CCMSG
{
    BYTE is_compressed;
    CMD cmd;
};

struct CMD
{
    QWORD cmd_type;
    DWORD cmd_size;
    DWORD cmd_arg;
    BYTE data[cmd_size - 16];
};

struct CCMSG
{
    DWORD signature = 0xFA149DEB;
    DWORD not_used;
    WORD buff_size;
    WORD msgcode;
    BYTE buff[buff_size];
};

Figure 4. Format du message C&C précédent (en haut) et mis à jour (en bas)

Il est intéressant de noter que la configuration de la porte dérobée est chiffrée et intégrée dans la DLL du chargeur. La configuration contient :

• Nom de la valeur du registre
• Identifiant de la campagne
• Adresses IP ou noms de domaine C&C
• Horodatage (au format FILETIME ) correspondant à la date de début d'utilisation d'un second domaine C&C marqué d'un « # » dans la configuration.

Un exemple de dump de configuration intégré dans la DLL du chargeur est présenté à la figure 5. Les configurations extraites de plusieurs DLL de chargement sont présentées dans le tableau 7.

Figure 5. Exemple de configuration déchiffrée (avec quelques zéros octets supprimés en raison de la taille de l'image)

Tableau 7. Configuration extraite de plusieurs chargeurs

Certificat de signature de code volé

Les modules et les installateurs PipeMon sont tous signés avec le même certificat de signature de code valide qui a probablement été volé lors d'une précédente campagne du groupe Winnti. Le propriétaire du certificat l'a révoqué dès qu'il a été informé de son émission.

Figure 6. Certificat de signature de code utilisé pour signer la première étape et les modules de PipeMon avant (en haut) et après (en bas) la révocation.

Nous avons trouvé sur un échantillon de plate-forme de partage d'autres outils signés avec ce certificat, tels que HTRan, un bouncer de connexion, le scanner de port WinEggDrop, Netcat et Mimikatz, qui ont pu être utilisés par les attaquants également.

En outre, une version personnalisée d'AceHash signée avec un certificat Wemade IO volé, déjà mentionnée dans notre précédent white paper et habituellement utilisée par le groupe Winnti, a été trouvée sur certaines machines compromises avec PipeMon.

Conclusion

Une fois de plus, le groupe Winnti a ciblé les développeurs de jeux vidéo en Asie avec un nouveau backdoor modulaire signé d'un certificat de signature de code probablement volé lors d'une campagne précédente et partageant certaines similarités avec le backdoor PortReuse. Cette nouvelle implantation montre que le groupe Winnti continue à développer activement de nouveaux outils en utilisant de multiples projets open source ; il ne s'appuie pas uniquement sur ses backdoors phares, ShadowPad et le logiciel malveillant Winnti.

Nous continuerons à surveiller les nouvelles activités du groupe Winnti et publierons des informations pertinentes sur notre blog. Pour toute question, contactez-nous à l'adresse suivante : threatintel@eset.com. Les IoC sont également disponibles dans notre dépôt GitHub.

Indicateurs de compromission

Noms de détection d'ESET

Win64/PipeMon.A
Win64/PipeMon.B
Win64/PipeMon.C
Win64/PipeMon.D
Win64/PipeMon.E

Noms de fichier

100.exe
103.exe
Slack.exe
setup.exe
%SYSTEM32%\spool\prtprocs\x64\DEment.dll
%SYSTEM32%\spool\prtprocs\x64\EntAppsvc.dll
%SYSTEM32%\spool\prtprocs\x64\Interactive.dll
%SYSTEM32%\spool\prtprocs\x64\banner.bmp
%SYSTEM32%\spool\prtprocs\x64\certificate.cert
%SYSTEM32%\spool\prtprocs\x64\banner.bmp
%SYSTEM32%\spool\prtprocs\x64\License.hwp
%SYSTEM32%\spool\prtprocs\x64\D8JNCKS0DJE
%SYSTEM32%\spool\prtprocs\x64\B0SDFUWEkNCj.log
%SYSTEM32%\spool\prtprocs\x64\K9ds0fhNCisdjf
%SYSTEM32%\spool\prtprocs\x64\JSONDIU7c9djE
%SYSTEM32%\spool\prtprocs\x64\NTFSSSE.log
AceHash64.exe
mz64x.exe

Noms de tuyaux

\\.\pipe\ScreenPipeRead%CNC_DEFINED%
\\.\pipe\ScreenPipeWrite%CNC_DEFINED%
\\.\pipe\RoutePipeWriite%B64_TIMESTAMP%
\\.\pipe\MainPipeWrite%B64_TIMESTAMP%
\\.\pipe\MainPipeRead%B64_TIMESTAMP%
\\.\pipe\MainHeatPipeRead%B64_TIMESTAMP%
\\.\pipe\InCmdPipeWrite%B64_TIMESTAMP%
\\.\pipe\InCmdPipeRead%B64_TIMESTAMP%
\\.\pipe\FilePipeRead%B64_TIMESTAMP%
\\.\pipe\FilePipeWrite%B64_TIMESTAMP%
\\.\pipe\ComHeatPipeRead%B64_TIMESTAMP%
\\.\pipe\CMDPipeRead
\\.\pipe\CMDPipeWrite

Registre

HKLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Print Processors\PrintFiiterPipelineSvc\Driver = “DEment.dll”

HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Print Processors\lltdsvc1\Driver = “EntAppsvc.dll”

HKLM\SOFTWARE\Microsoft\Print\Components\DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8
HKLM\SOFTWARE\Microsoft\Print\Components\A66F35-4164-45FF-9CB4-69ACAA10E52D

Échantillons

Premier niveau

4B90E2E2D1DEA7889DC15059E11E11353FA621A6
C7A9DCD4F9B2F26F50E8DD7F96352AEC7C4123FE
3508EB2857E279E0165DE5AD7BBF811422959158
729D526E75462AA8D33A1493B5A77CB28DD654BC
5663AF9295F171FDD41A6D819094A5196920AA4B

PipeMon

23789B2C9F831E385B22942DBC22F085D62B48C7
53C5AE2655808365F1030E1E06982A7A6141E47F
E422CC1D7B2958A59F44EE6D1B4E10B524893E9D
5BB96743FEB1C3375A6E2660B8397C68BEF4AAC2
78F4ACD69DC8F9477CAB9C732C91A92374ADCACD
B56D8F826FA8E073E6AD1B99B433EAF7501F129E
534CD47EB38FEE7093D24BAC66C2CF8DF24C7D03

Binaires PipeMon chiffrés

168101B9B3B512583B3CE6531CFCE6E5FB581409
C887B35EA883F8622F7C48EC9D0427AFE833BF46
44D0A2A43ECC8619DE8DB99C1465DB4E3C8FF995
E17972F1A3C667EEBB155A228278AA3B5F89F560
C03BE8BB8D03BE24A6C5CF2ED14EDFCEFA8E8429
2B0481C61F367A99987B7EC0ADE4B6995425151C

Outils additionnels

WinEggDrop

AF9C220D177B0B54A790C6CC135824E7C829B681

Mimikatz

4A240EDEF042AE3CE47E8E42C2395DB43190909D

Netcat

751A9CBFFEC28B22105CDCAF073A371DE255F176

HTran

48230228B69D764F71A7BF8C08C85436B503109E

AceHash

D24BBB898A4A301870CAB85F836090B0FC968163

Empreintes des certificats de signature de code SHA-1

745EAC99E03232763F98FB6099F575DFC7BDFAA3
2830DE648BF0A521320036B96CE0D82BEF05994C

Domaines C&C

n8.ahnlabinc[.]com
owa.ahnlabinc[.]com
ssl2.ahnlabinc[.]com
www2.dyn.tracker[.]com
ssl2.dyn-tracker[.]com
client.gnisoft[.]com
nmn.nhndesk[.]com
ssl.lcrest[.]com

Adresses IP des C&C IP

154.223.215[.]116
203.86.239[.]113

Techniques MITRE ATT&CK