Pas de «game over» pour le groupe Winnti – Bien choisir son serveur d impression

En février 2020, nous avons découvert une nouvelle porte dérobée modulaire, que nous avons nommée PipeMon. Persistant en tant que 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 à Taiwan et développant des jeux MMO (Massively Multiplayer Online). Les jeux vidéo développés par ces sociétés sont disponibles sur les 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 construction d'une victime, ce qui aurait pu conduire à une attaque de la chaîne d'approvisionnement, permettant aux attaquants de trojaniser les exécutables du jeu. Dans un autre cas, les serveurs de jeu ont été compromis, ce qui aurait pu permettre aux attaquants, par exemple, de manipuler des devises dans le jeu pour un gain financier.

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

Attribution au groupe Winnti

De multiples indicateurs nous ont conduit à attribuer cette campagne au groupe Winnti. Certains des domaines C&C utilisés par PipeMon ont été utilisés par les logiciels malveillants de Winnti dans les campagnes précédentes mentionnées dans notre livre blanc sur l'arsenal du groupe Winnti. En outre, des logiciels malveillants Winnti ont également été trouvés en 2019 dans certaines entreprises qui ont ensuite été compromises avec PipeMon.

En plus du malware Winnti, un binaire AceHash (un récolteur d'informations d'identification) 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 à ce moment-là.

Fait intéressant, les modules PipeMon sont installés dans % SYSTEM32% spool prtprocs x64 ; ce chemin a également été utilisé dans le passé pour abandonner la deuxième étape du CCleaner trojanisé.

De plus, compromettre l'environnement de construction d'un développeur de logiciel pour compromettre ultérieurement l'application légitime est un mode de fonctionnement connu du groupe Winnti.

Entreprises ciblées

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

ESET a contacté les entreprises concernées et a fourni les informations nécessaires pour remédier au compromis.

Analyse technique

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

Première étape

La première étape de PipeMon consiste en un exécutable RARSFX protégé par mot de passe intégré dans le .rsrc section 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 aléatoirement 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 *

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

Le contenu du RARSFX est ensuite extrait dans % TMP% RarSFX0 et se compose des fichiers suivants:

• CrLnc.dat – Charge utile cryptée
• Duser.dll – Utilisé pour le contournement UAC
• osksupport.dll – Utilisé pour le contournement UAC
• PrintDialog.dll – Utilisé pour l'initialisation malveillante du processeur d'impression
• PrintDialog.exe – Exécutable Windows légitime utilisé pour charger PrintDialog.dll
• setup.dll – DLL d'installation
• setup.exe – Exécutable principal

Notez qu'en cas de collision de nom de dossier, le numéro à la fin de la RarSFX0 la chaîne est incrémentée jusqu'à ce qu'une collision soit évitée. De plus, tous ces fichiers ne sont pas nécessairement présents dans l'archive, selon le programme d'installation.

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 présenté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. Sinon, il tentera d'obtenir ces privilèges en utilisant l'emprunt d'identité de jeton si la version de Windows est inférieure à Windows 7 build 7601; sinon, il tentera différentes techniques de contournement UAC, permettant l'installation du chargeur de charge utile dans l'une des:

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

selon la variante. Notez que nous n'avons pas pu récupérer des échantillons liés à Interactive.dll.

Tableau 1. setup.exe arguments pris en charge et leur comportement correspondant.

Ce chargeur est stocké crypté dans setup.dll, qui le déchiffrera avant de l'écrire à l'emplacement susmentionné.

Persistance à l'aide des processeurs d'impression Windows

L'emplacement où la DLL malveillante est supprimée n'a pas été choisi au hasard. Il s'agit du chemin d'accès aux processeurs d'impression Windows et setup.dll enregistre le chargeur DLL malveillant en tant que 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"

selon la variante. Notez la faute de frappe dans PrintFiiterPipelineSvc (ce qui n'a aucun impact sur l'installation du processeur d'impression car 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 de spouleur. Notez que le service Spouleur d'impression démarre à chaque démarrage de PC, ce qui garantit la persistance des réinitialisations du système.

Cette technique est vraiment similaire à la technique de persistance du moniteur d'impression (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, extrait du RARSFX est écrit dans le registre à l'emplacement suivant, selon le programme d'installation:

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

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

Figure 1. Stadification et persistance PipeMon

PipeMon

Nous avons nommé ce nouvel implant PipeMon car il utilise plusieurs canaux nommés pour 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. Compte tenu de la première variante, nous n'avons pas pu récupérer le programme d'installation; ainsi, nous ne savons pas avec certitude la technique de persistance qui a été utilisée. Mais étant donné que cette première variante de PipeMon se trouvait également dans le répertoire du processeur d'impression, il est probable que le même mécanisme de persistance ait été utilisé.

Variante originale

PipeMon est une porte dérobée modulaire où chaque module est une seule DLL exportant une fonction appelée IntelLoader et est chargé en utilisant une technique de chargement réfléchissante. Chaque module présente différentes fonctionnalités présentées dans le tableau 2.

Le chargeur, chargé du chargement des modules principaux (ManagerMain et GuardClient) est Win32CmdDll.dll et se trouve dans le répertoire Processeurs d'impression. Les modules sont stockés chiffrés sur le disque au même emplacement 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 cryptés RC4 et la clé de décryptage Com! 123Qasdz est codé en dur dans chaque module. Win32CmDll.dll décrypte et injecte les modules ManagerMain et GuardClient. Le module ManagerMain est responsable du décryptage et de l'injection du module de communication, tandis que le module GuardClient s'assurera que le module de communication est en cours d'exécution et le rechargera si nécessaire. Un aperçu du fonctionnement de PipeMon est illustré à la figure 2.

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

Les candidats de processus pour l'injection du module de communication doivent être dans la table de connexion TCP avec 0.0.0.0 comme adresse locale, ou une connexion ÉTABLIE et possédant un jeton LOCAL SERVICE. Ces conditions sont probablement utilisées pour masquer 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 semble discret et peut-être également sur la liste blanche dans le pare-feu. Si aucun processus ne répond aux exigences précédentes, le ManagerMain module essaie d'injecter le module de communication dans explorer.exe. Processus appartenant aux applications du Windows Store et processus nommés egui.exe (ESET) et avpui.exe (Kaspersky) sont ignorés de la sélection.

Tableau 2. Description 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 canaux nommés utilisés pour communiquer avec eux:

• Écran
• Route
• CMD
• InCmd
• Fichier

Communication inter-modules

La communication inter-modules est effectuée via des canaux nommés, en utilisant deux canaux nommés par canal de communication entre chaque module individuel, un pour l'envoi et un pour la réception. Le tableau 3 répertorie les canaux de communication et leurs canaux nommés correspondants.

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

le % CNC_DEFINED% la chaîne est reçue du serveur C&C et % B64_TIMESTAMP% les variables sont des horodatages codés en base64 tels que ceux indiqués dans le tableau 4.

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

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

Communication C&C

Le module Communication est responsable de la gestion des communications entre le serveur C&C et les autres modules via des canaux nommés, similaire à la porte dérobée PortReuse documentée dans notre livre blanc 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. Il est envoyé au module de communication via un canal 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 avec la bibliothèque HP-Socket. Tous les messages sont cryptés RC4 à l'aide de la clé codée en dur. Si la taille du message à transférer est supérieure ou égale à 4 Ko, il est d'abord compressé à l'aide de l'implémentation Deflate de zlib.

Figure 3. Formats des messages et balises C&C

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

• Version du système d'exploitation
• adresses physiques des adaptateurs réseau connectés concaténés avec% B64_TIMESTAMP%
• adresse IP locale de la victime
• version de la porte dérobée / ID de la campagne; nous avons observé les valeurs suivantes
  • "1.1.1.4beat"
  • «1.1.1.4Bata»
  • «1.1.1.5»
• Nom de l'ordinateur de la victime

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

Le format du message de balise est illustré à la figure 3 et les commandes prises en charge sont présentées au 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 la première étape 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 car la clé et toutes les chaînes codées en dur ont été supprimées. Les canaux nommés utilisés pour la communication inter-modules sont désormais nommés à l'aide de valeurs aléatoires au lieu de noms explicites et sont conformes au format \. pipe % rand%, où %rand% est une chaîne générée de façon pseudo-aléatoire de 31 caractères contenant uniquement des caractères alphabétiques à casse mixte.

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

Tableau 6. Modules mis à jour

L'injection de module n'est plus effectuée en utilisant la technique de chargement réfléchissant avec une fonction d'exportation; le shellcode du chargeur personnalisé est utilisé à la place et est injecté avec le module à charger.

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

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

Fait intéressant, 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 de registre
• Identifiant de campagne
• Adresses IP et noms de domaine C&C
• Horodatage (au format FILETIME) correspondant à la date à partir de laquelle commencer à utiliser un deuxième domaine C&C marqué d'un «#» dans la configuration.

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

Figure 5. Exemple de configuration déchiffrée (avec quelques octets zéro 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 installateurs PipeMon sont tous signés avec le même certificat de signature de code valide qui a probablement été volé lors d'une campagne précédente du groupe Winnti. Le propriétaire du certificat l'a révoqué dès qu'il a été informé du problème.

Figure 6. Certificat de signature de code utilisé pour signer le premier étage et les modules PipeMon avant (en haut) et après (en bas) révocation.

Nous avons trouvé sur une plateforme de partage d'échantillons d'autres outils signés avec ce certificat, tels que HTRan, un videur de connexion, le WinEggDrop scanner de port, Netcat et Mimikatz, qui peuvent également avoir été utilisés par les attaquants.

De plus, une version AceHash personnalisée signée avec un certificat volé Wemade IO déjà mentionné dans notre livre blanc précédent et généralement utilisé 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 une nouvelle porte dérobée modulaire signée avec un certificat de signature de code probablement volé lors d'une campagne précédente et partageant certaines similitudes avec la porte dérobée PortReuse. Ce nouvel implant montre que le groupe Winnti continue de développer activement de nouveaux outils utilisant plusieurs projets open source; ils ne comptent pas uniquement sur leurs portes dérobées phares, ShadowPad et le malware Winnti.

Nous continuerons de surveiller les nouvelles activités du groupe Winnti et publierons des informations pertinentes sur notre blog. Pour toute demande, contactez-nous au menaceintel@eset.com. Les IoC sont également disponibles dans notre référentiel GitHub.

Indicateurs de compromis

Noms de détection ESET

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

Noms de fichiers

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

Tuyaux nommés

\. 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

Enregistrement

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

Première étape

4B90E2E2D1DEA7889DC15059E11E11353FA621A6
C7A9DCD4F9B2F26F50E8DD7F96352AEC7C4123FE
3508EB2857E279E0165DE5AD7BBF811422959158
729D526E75462AA8D33A1493B5A77CB28DD654BC
5663AF9295F171FDD41A6D819094A5196920AA4B

PipeMon

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

Binaires chiffrés PipeMon

168101B9B3B512583B3CE6531CFCE6E5FB581409
C887B35EA883F8622F7C48EC9D0427AFE833BF46
44D0A2A43ECC8619DE8DB99C1465DB4E3C8FF995
E17972F1A3C667EEBB155A228278AA3B5F89F560
C03BE8BB8D03BE24A6C5CF2ED14EDFCEFA8E8429
2B0481C61F367A99987B7EC0ADE4B6995425151C

Des outils supplémentaires

WinEggDrop

AF9C220D177B0B54A790C6CC135824E7C829B681

Mimikatz

4A240EDEF042AE3CE47E8E42C2395DB43190909D

Netcat

751A9CBFFEC28B22105CDCAF073A371DE255F176

HTran

48230228B69D764F71A7BF8C08C85436B503109E

AceHash

D24BBB898A4A301870CAB85F836090B0FC968163

Empreintes SHA-1 du certificat de signature de code

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 C&C

154.223.215[.]116
203.86.239[.]113

Mathieu Tartare et Martin Smolár 21 mai 2020-11: 30 AM