Serveur d'impression

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

Le 24 mai 2020 - 26 minutes de lecture

Le célèbre groupe APT continue de jouer l'industrie du jeu vidéo avec encore une autre porte dérobée

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.

À propos de l'appellation «Winnti Group»:

Nous avons choisi de garder le nom de «Groupe Winnti» car c'est le nom utilisé pour la première fois pour l'identifier, en 2013, par Kaspersky. Étant donné que Winnti est également une famille de logiciels malveillants, nous écrivons toujours «Groupe Winnti» lorsque nous parlons des malfaiteurs derrière les attaques. Depuis 2013, il a été démontré que Winnti n'est qu'une des nombreuses familles de logiciels malveillants utilisées par le groupe 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.

Valeur d'argument de ligne de commande Comportement
-x: 0 Chargez le chargeur de charge utile.
-x: 1 Tenter d'activer SeLoadDriverPrivilege pour le processus actuel. En cas de succès, essayez d'installer le chargeur de charge utile; sinon, redémarrez setup.exe avec le –X: 2 argument utilisant l'usurpation de processus parent.
-x: 2 Tenter d'activer SeLoadDriverPrivilege pour le processus actuel. En cas de succès, essayez d'installer le chargeur de charge utile.

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

Nom du module La description Chemin PDB
Win32CmdDll Décrypte et charge les modules ManagerMain et GuardClient. S: Monitor Monitor_RAW Launcher x64 Release Win32CmdDll.pdb
S: Monitor Monitor_RAW libs x64 Release Win32CmdDll.pdb
GuardClient Vérifie périodiquement si le module de communication fonctionne et le charge sinon. S: Monitor Monitor_RAW Client x64 Release GuardClient.pdb
ManagerMain Charge le module de communication lors de son exécution. Contient un domaine C&C chiffré qui est transmis au module de communication via un canal nommé.
Peut exécuter plusieurs commandes en fonction des données reçues du module de communication (principalement la collecte d'informations système, l'injection de charges utiles).
S: Monitor Monitor_RAW Client x64 Release ManagerMain.pdb
la communication Responsable de la gestion de la communication entre le serveur C&C et les modules individuels via des canaux nommés. S: Monitor Monitor_RAW Client x64 Release Communication.pdb
F: PCC trunk CommunicationClient x64 Release Communication.pdb

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

Canal de communication Pipe nommée
Communication, écran \. pipe ScreenPipeRead% CNC_DEFINED%
\. pipe ScreenPipeWrite% CNC_DEFINED%
Communication, Route \. pipe RoutePipeWriite% B64_TIMESTAMP%
Communication, ManagerMain \. pipe MainPipeWrite% B64_TIMESTAMP%
\. pipe MainPipeRead% B64_TIMESTAMP%
GuardClient, ManagerMain \. pipe MainHeatPipeRead% B64_TIMESTAMP%
Communication, InCmd \. pipe InCmdPipeWrite% B64_TIMESTAMP%
\. pipe InCmdPipeRead% B64_TIMESTAMP%
Communication, Fichier \. pipe FilePipeRead% B64_TIMESTAMP%
\. pipe FilePipeWrite% B64_TIMESTAMP%
GuardClient, Communication \. pipe ComHeatPipeRead% B64_TIMESTAMP%
Communication, CMD \. pipe CMDPipeRead
\. pipe CMDPipeWrite

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

% BASE64_TIMESTAMP% Horodatage décodé
MjAxOTAyMjgxMDE1Mzc = 20190228101537
MjAxOTA1MjEyMzU2MjQ = 20190521235624
MjAxOTExMjExMjE2MjY = 20191121121626

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

Type de commande Argument de commande La description
0x02 0x03 Installer le module File
0x03 0x03 Installer le module CMD
0x03 0x0B Installez le module InCmd
0x04 0x02 Commande de file d'attente pour le module Route
0x04 0x03 Installer le module Route
0x05 * Envoyer les informations RDP de la victime au serveur C&C
0x06 0x05 Envoyer des informations sur le système d'exploitation, le processeur, le PC et le fuseau horaire au serveur C&C
0x06 0x06 Envoyer des informations réseau au serveur C&C
0x06 0x07 Envoyer des informations sur le lecteur de disque au serveur C&C
0x07 * Envoyer des informations sur les processus en cours d'exécution au serveur C&C
0x09 * Injection de DLL
0x0C 0x15 Envoyer des noms de canaux et d'événements "InCmd" au serveur C&C
0x0C 0x16 Envoyer le nom du canal "Route" au serveur C&C
0x0C 0x17 Envoyer les noms des canaux "File" au serveur C&C

* 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

Nom du module La description
CoreLnc.dll Chargé par le processeur d'impression malveillant. Responsable uniquement du chargement du Core.dll module intégré dans son .Les données section.
Core.dll Charge le Net.dll module intégré dans son .Les données section. Gère les commandes du serveur C&C et les communications entre les modules individuels et le serveur C&C via des canaux nommés.
Net.dll Nouveau module de communication. Gère la mise en réseau.

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

Chargeur SHA-1 ID de campagne Nom de registre de charge utile IP et domaines C&C Horodatage d'activation de domaine alternatif
6c97039605f93ccf1afccbab8174d26a43f91b20 KOR2 DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8 154.223.215.116
ssl2.dyn-tracker.com
# client.gnisoft.com
0x01d637a797cf0000 (Lundi 1er juin 2020 12:00:00 am)
97da4f938166007ce365c29e1d685a1b850c5bb0 KOR DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8 203.86.239.113 ssl2.dyn-tracker.com # client.gnisoft.com 0x01d637a797cf0000 (Lundi 1er juin 2020 12:00:00 am)
7ca43f3612db0891b2c4c8ccab1543f581d0d10c kor1 DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8 203.86.239.113
www2.dyn.tracker.com (notez la faute de frappe ici: dyn.tracker au lieu de dyn-tracker) # nmn.nhndesk.com
0x01d61f4b7500c000 (Vendredi 1er mai 2020 12:00:00 am)
b02ad3e8b1cf0b78ad9239374d535a0ac57bf27e tw1 A66F35-4164-45FF-9CB4-69ACAA10E52D ssl.lcrest.com

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 [email protected]. 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

Tactique Identifiant Nom La description
Persistance T1013 Moniteur de port PipeMon utilise une technique de persistance similaire à Port Monitor basée sur les processeurs d'impression.
Escalade de privilèges T1134 Manipulation du jeton d'accès Le programme d'installation de PipeMon essaie d'obtenir des privilèges administratifs à l'aide de l'emprunt d'identité de jetons.
T1088 Contourner le contrôle de compte d'utilisateur Le programme d'installation PipeMon utilise des techniques de contournement UAC pour installer la charge utile.
T1502 Usurpation d'identité PID parent Le programme d'installation PipeMon utilise l'usurpation d'identité PID parent pour élever les privilèges.
Evasion de défense T1116 Signature du code PipeMon, son programme d'installation et des outils supplémentaires sont signés avec des certificats de signature de code volés.
T1027 Obscurcir des fichiers ou des informations Les modules PipeMon sont stockés chiffrés sur disque.
T1112 Modifier le registre Le programme d'installation de PipeMon modifie le registre pour installer PipeMon en tant que processeur d'impression.
T1055 Injection de processus PipeMon injecte ses modules dans divers processus en utilisant une charge réfléchissante.
Découverte T1057 Découverte de processus PipeMon parcourt les processus en cours pour trouver une cible d'injection appropriée.
T1063 Découverte de logiciels de sécurité PipeMon vérifie la présence des logiciels ESET et Kaspersky.
Collection T1113 Capture d'écran L'un des modules PipeMon est probablement un capture d'écran.
Commander et contrôler T1043 Ports couramment utilisés PipeMon communique via le port 443.
T1095 Protocole de commande et de contrôle personnalisé Le module de communication PipeMon utilise un protocole personnalisé basé sur TLS sur TCP.
T1032 Protocole cryptographique standard La communication PipeMon est cryptée RC4.
T1008 Canaux de secours La version mise à jour de PipeMon utilise un canal de secours une fois qu'une date particulière est atteinte.


Mathieu Tartare et Martin Smolár

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.