LoudMiner : Exploitation minière multiplateforme via un logiciel VST trafiqué | WeLiveSecurity

LoudMiner : Exploitation minière multiplateforme via un logiciel VST trafiqué

L'histoire d'un mineur Linux livré avec des copies craquées de logiciels VST (Virtual Studio Technology) pour Windows et macOS

L’histoire d’un mineur Linux livré avec des copies craquées de logiciels VST (Virtual Studio Technology) pour Windows et macOS

Introduction

LoudMiner est un cas inhabituel de mineur de cryptomonnaie persistant, distribué pour macOS et Windows depuis août 2018. Il utilise un logiciel de virtualisation – QEMU sous macOS et VirtualBox sous Windows – pour extraire des cryptomonnaie sur une machine virtuelle Tiny Core Linux, ce qui la rend multiplateforme. Il est livré avec des copies piratées de logiciels VST. Le mineur lui-même est basé sur XMRig (Monero) et utilise un pool minier, il est donc impossible de retracer les transactions potentielles.

Distribution

Au moment de la rédaction du présent rapport, 137 applications VST (42 pour Windows et 95 pour MacOS) sont disponibles sur un seul site Web basé sur WordPress avec un domaine enregistré le 24 août 2018. La première application – Kontakt Native Instruments 5.7 pour Windows – a été téléchargée le même jour. La taille des applications ne permet pas de les analyser toutes, mais il semble sûr de supposer qu’elles sont toutes troyanisées.

Les applications elles-mêmes ne sont pas hébergées sur le site basé sur WordPress, mais sur 29 serveurs externes, que vous pouvez trouver dans la section IoCs. Les administrateurs du site mettent aussi fréquemment à jour les applications avec des versions plus récentes, ce qui rend difficile le suivi de la toute première version du mineur.

En ce qui concerne la nature des applications visées, il est intéressant d’observer que leur finalité est liée à la production audio; ainsi, les machines sur lesquelles elles sont installées devraient avoir une bonne puissance de traitement et une consommation CPU élevée ne surprendra pas les utilisateurs. En outre, ces applications sont généralement complexes, il n’est donc pas surprenant qu’il s’agisse de fichiers volumineux. Les attaquants l’utilisent à leur avantage pour camoufler l’image de VM. De plus, la décision d’utiliser des machines virtuelles au lieu d’une solution allégée est tout à fait remarquable et ce n’est pas quelque chose que nous voyons régulièrement.

Voici quelques exemples d’applications, ainsi que quelques commentaires que vous pouvez trouver sur le site :

  • Propellerhead Reason
  • Ableton Live
  • Sylenth1
  • Nexus
  • Reaktor 6
  • AutoTune

Figure 1 – Commentaire #1 de « admin »

Figure 2 – Commentaire #2 de « admin »

Rapports des utilisateurs

Nous avons trouvé plusieurs discussions de forum d’utilisateurs se plaignant d’un processus qemu-system-x86_64 prenant 100 % de leur CPU sur leur Mac:

Figure 3 – Rapport de l’utilisateur #1 (https://discussions.apple.com/thread/250064603)

Figure 4 – Rapport de l’utilisateur #2 (https://toster.ru/q/608325)

Un utilisateur nommé Macloni (https://discussions.apple.com/thread/8602989) a déclaré ce qui suit :

« Malheureusement, j’ai dû réinstaller OSX, le problème était qu’Ableton Live 10, que j’ai téléchargé depuis un site torrent et non depuis le site officiel, installe aussi un mineur, s’exécutant en arrière-plan à l’origine. Le même utilisateur a joint des captures d’écran du Activity Monitor indiquant 2 processus – qemu-system-x86_64 et tools-service – prenant 25 % des ressources CPU et fonctionnant comme root. »

Analyse des applications piratées

L’idée générale des analyses MacOS et Windows demeure la même :

  1. Une application est fournie avec un logiciel de virtualisation, une image Linux et des fichiers supplémentaires utilisés pour obtenir la persistance;
  2. L’utilisateur télécharge l’application et suit les instructions jointes pour l’installer;
  3. LoudMiner est installé en premier, puis le logiciel VST proprement dit;
  4. LoudMiner se cache et devient persistant au redémarrage;
  5. La machine virtuelle Linux est lancée et l’exploitation minière commence;
  6. Les scripts à l’intérieur de la machine virtuelle peuvent contacter le serveur C&C pour mettre à jour le mineur (configuration et binaires).

En analysant les différentes applications, nous avons identifié quatre versions du mineur, principalement basées sur la façon dont il est livré avec le logiciel, le domaine du serveur C&C, et quelque chose que nous pensons être une chaîne de version créée par l’auteur.

macOS

Nous avons identifié jusqu’à présent trois versions MacOS de ce malware. Tous incluent des dépendances nécessaires à l’exécution de QEMU dans le fichier installdata.dmg à partir duquel tous les fichiers sont copiés dans /usr/local/bin et ont les permissions appropriées définies en cours de route. Chaque version du mineur peut exécuter deux images à la fois, chacune prenant 128 Mo de RAM et un processeur central. La persistance est obtenue en ajoutant des fichiers plist dans /Library/LaunchDaemons avec RunAtLoad défini sur true. Ils ont également réglé KeepAlive sur true, ce qui garantit que le processus redémarrera s’il est arrêté. Chaque version possède les composants suivants :

  1. QEMU Linux images;
  2. Les scripts shell utilisés pour lancer les images QEMU;
  3. Les daemons avaient l’habitude de démarrer les scripts shell au démarrage et de les faire tourner;
  4. Un script shell de moniteur CPU avec un daemon d’accompagnement qui peut démarrer/arrêter l’exploitation minière en fonction de l’utilisation du CPU et de l’exécution du processus Activity Monitor.

Le script du moniteur CPU peut démarrer et arrêter l’extraction en chargeant et déchargeant le daemon. Si le processus Activity Monitor est en cours d’exécution, l’exploitation minière s’arrête. Sinon, il vérifie pendant combien de temps le système est resté inactif en quelques secondes :

Si ça fait plus de 2 minutes, l’exploitation minière débute. Si cela fait moins de 2 minutes, il vérifie l’utilisation totale du CPU :

divise cela par le nombre de CPU cores:

et si c’est supérieur à 85 %, ça arrête l’exploitation minière. Le script lui-même est un peu différent d’une version à l’autre, mais l’idée générale reste la même.

Une fois l’installation terminée, tous les fichiers d’installation relatifs aux mineurs sont supprimés.

Figure 5. – Installation de Polyverse.Music.Manipulator.v1.0.1.macOS.dmg

Figure 6 – Instructions de configuration de Polyverse.Music.Manipulator.v1.0.1.macOS.dmg 

Version 1

Les fichiers des mineurs dans le paquet d’application téléchargé ne sont en aucun cas obscurcis ou placés dans un autre paquet; ils sont installés à côté du logiciel dans les endroits suivants :

  • /Library/Application Support/.Qemusys
    • qemu-system-x86_64– nettoie le binaire QEMU
    • sys00_1-disk001.qcow2– Image Linux (première)
    • qemuservice– shell script qui lance la première image via le binaire qemu-system-x86_64 (voir binaire 1)
  • /Library/Application Support/.System-Monitor
    • system-monitor.daemon– qui lance la première image via le binaire system-monitor
  • /usr/local/bin
    • .Tools-Service
      • sys00_1-disk001.qcow2– image Linux (deuxième)
      • tools-service.daemon– lance la deuxième image via le binaire tools-service
    • cpumonitor– démarre et arête le minage selon le temps mort et l’image CPU
    • system-monitor– copie du binaire qemu-system-x86_64
    • tools-service– copie du binaire qemu-system-x86_64
  • /Library/LaunchDaemons
    • system-monitor.plist– lance system-monitor.daemon
    • tools-service.plist– lance tools-service.daemon
    • qemuservice.plist– lance qemuservice
    • cpumonitor.plist– lance cpumonitor

Script 1 – shell script  qemuservice

Une fois les dépendances copiées, tous les daemons liés au minage sont lancés, puis le logiciel proprement dit est installé :

  • qemuservice ne lancera pas l’image si le processus Activity Monitor est en cours d’exécution. En fait, s’il est en marche, il déchargera le plist par lequel il a été lancé.
  • tools-service.daemon lancera l’image uniquement lorsque le processus qemu-system-x86_64 n’est pas exécuté et après 45 minutes de sommeil.
  • System-monitor.daemon ne lancera l’image que si Intel i5, i7 ou i9 CPU est détecté.

Ces scripts utilisent la même commande pour lancer l’image QEMU, et seuls leurs noms et chemins d’image diffèrent.

Nous avons trouvé la capture d’écran suivante concernant la version 1 du mineur :

Figure 7 – Consommation CPU de QEMU avec Little Snitch (source: https://imgur.com/a/sc3u6kk)

C’est grâce à des indications données par Little Snitch que certaines connexions du processus qemu-system-x86_64 ont été bloquées. Plus précisément, hopto[.]org (un service de nom d’hôte gratuit) est un serveur C&C utilisé par la version 1 du mineur.

Version 2

Les fichiers Miner sont dans data_installer.pkg à l’intérieur du paquet d’application téléchargé. C’est data_installer.pkg qui est installé en premier, puis le logiciel VST. Avant l’installation, la version 1 du mineur est supprimée avec l’exécution de la commande :

Comme on peut le voir dans la liste du Script 2, il ne le fait que lorsqu’il détecte un processus qemu-system-x86_64 en cours.

Script 2 –  Le script de préinstallation data_installer.pkgqui supprime la version 1

Les fichiers temporaires suivants sont créés :

  • /Users/Shared
    • z1– binaire QEMU
    • daemon– lance l’image QEMU avec le binaire QEMU
    • qcow2– image QEMU
    • plist– lance z1.daemon
    • z3– Script du CPU du moniteur, avec peu de changements par rapport au cpumonitor de la version 1
    • plist– utilisé pour lancer z3
    • randwd– génère des noms aléatoires

Une fois les dépendances copiées, le mineur est installé. Cette fois, les noms des binaires, plists et répertoires de QEMU sont randomisés avec le script randwd. L’installation du mineur crée deux copies de z1, z1.daemon, z1.qcow2 et z1.plist. Pour chaque copie, voici ce qui se produit :

  • Un repertoire ayant un nom aléatoire est créé dans /Library/Application Support
  • Le binaire QEMU z1 porte le même nom que le répertoire et est copié dans /usr/local/bin
  • daemon (voir la liste dans le Script 3) et z1.qcow2 sont copiés dans le répertoire sous leurs noms aléatoires
  • plist est copié avec le nom com.<nom_aléatoire>.plist dans /Library/LaunchDaemons

Les fichiers z1.daemon, z1.plist, z3 and z3.plist  servent de modèles. Les références à d’autres scripts, binaires, plists, etc. dans ces fichiers sont remplacées par leur nom aléatoire généré correspondant.

Un nom aléatoire est également choisi pour le script shell du moniteur CPU (z3) et son fichier plist. z3 est copié dans /usr/local/bin et le plist dans /Library/LaunchDaemons sous le nom com.<random_name>.plist.

Script 3. Script shell z1.daemon

La version 2 est un peu plus propre et/ou plus simple que la version 1. Il n’y a qu’une seule image QEMU, avec deux copies faites; de même pour les scripts de lancement d’image, les daemons et le cpumonitor. Bien que la version 2 randomise ses noms de fichiers et répertoires, elle ne peut être installée qu’une seule fois car l’installation vérifie l’exécution des processus avec accel=hvf dans leur ligne de commande.

Depuis la version 2 des applications que nous avons vérifiées jusqu’à présent, le hachage SHA1 du fichier data_installer.pkg est toujours 39a7e86368f0e68a86cce975fd9d8c254a86ed93.

Version 3

Les fichiers des mineurs se trouvent dans un fichier DMG crypté, appelé do.dmg, à l’intérieur du paquet d’application. La DMG est montée avec la commande suivante :

Le mineur DMG contient un seul paquet : datainstallero.pkg. Ceci et le paquet de logiciel sont ensuite installés.

Le contenu des paquets datainstallero.pkg et data_installer.pkg de la version 2 sont plus ou moins les mêmes, mais datainstallero.pkg ajoute deux scripts obscurcis – clearpacko.sh et installpacko.sh – et masque un script existant – randwd :

  • clearpacko.sh supprime la version 1 du mineur comme le fait la version 2.
  • installpacko.sh installe le mineur de la même manière que la version 2, sauf que les commentaires ont été supprimés du script.

Le SHA1 de do.dmg reste le même : b676fdf3ece1ac4f96a2ff3abc7ff31c7b867fb9.

Lancement de l’image Linux

Toutes les versions utilisent plusieurs scripts shell pour lancer les images. Les scripts shell sont exécutés par plists au démarrage et sont maintenus en vie.

  • La version 1 exécute les binaires suivants (copies de qemu-system-x86_64) pour lancer les images QEMU : qemu-system-x86_64, system-monitor, tools-service.
  • Les versions 2 et 3 utilisent la même commande, à part le nom de fichier du binaire dans le répertoire Application Support, et le nom de fichier QEMU est aléatoire.

Toutes les versions utilisent les interrupteurs suivants :

  • -M accel=hvf pour utiliser le framework Hypervisor comme accélérateur. La RPLP a été introduite avec OS X 10.10 et la prise en charge de la RPLP a été ajoutée dans QEMU 2.12, qui est sorti en avril 2018.
  • -display none, pour que la machine virtuelle fonctionne sans interface graphique.

Puisque l’image est lancée sans spécifier la quantité de RAM et le nombre de cœurs CPU, les valeurs par défaut sont utilisées : 1 noyau CPU et 128 Mo de RAM. Toutes les versions peuvent lancer 2 images.

Windows (version 4)

A partir des chaînes que nous avons extraites de l’application, nous définissons la seule version de Windows vue jusqu’à présent comme la version 4. Comme nous l’avons mentionné précédemment, la logique est assez similaire à celle de la version macOS. Chaque application Windows est packagée sous la forme d’un programme d’installation MSI qui installe à la fois l’application piratée et la Figure 8 montre le popup de confiance pour installer le pilote VirtualBox lorsque vous exécutez un programme d’installation VST piratée depuis vstcrack[..]com.

Figure 8 – Fenêtre popup Trust pour un pilote VirtualBox lors de l’exécution de l’installation d’une application depuis vstcrack[.]com

VirtualBox est installé dans son nom de dossier habituel (C:\Program Files\Oracle); cependant, les attributs du répertoire sont définis comme « cachés » (ou « hidden »). Ensuite, le programme d’installation copie l’image Linux et VBoxVmService (un service Windows utilisé pour exécuter une machine virtuelle VirtualBox en tant que service) dans C:\vms, qui est aussi un répertoire caché. Une fois l’installation terminée, le programme d’installation exécute un script batch compilé avec BAT2EXE (voir la liste décompressée dans le script 4) pour importer l’image Linux et lance VmServiceControl.exe pour démarrer la machine virtuelle comme un service.

Script 4 – Lot de scripts utilisé pour exécuter la machine virtuelle Linux en tant que service

Cette méthode est utilisée pour assurer la persistance du mineur après le redémarrage. En effet, VboxVmService est livré avec un fichier de configuration (voir Script 5) dans lequel il est possible d’activer l’option AutoStart pour que la machine virtuelle soit lancée automatiquement au démarrage.

Scénario 5 – Fichier de configuration pour VBoxVmService avec AutoStart activé.

Le fichier OVF inclus dans l’image Linux décrit la configuration matérielle de la machine virtuelle (voir Script 6) : il utilise 1 Go de RAM et 2 cœurs CPU (avec une utilisation maximale de 90 %).

Script 6 – Configuration matérielle de l’image Linux

Image Linux

L’image Linux est Tiny Core Linux 9.0 configuré pour exécuter XMRig, ainsi que certains fichiers et scripts pour garder le mineur à jour en permanence. Les fichiers les plus intéressants sont :

  • /root/.ssh/{id_rsa, id_rsa.pub} – la clé de paire SSH utilisée pour mettre à jour le mineur du serveur C&C en utilisant SCP.
  • /opt/{bootsync.sh, bootlocal.sh} – les commandes de démarrage du système qui tentent de mettre à jour le mineur à partir du serveur C&C et de l’exécuter (voir Scripts 7 et 8) :

Script 7. bootsync.sh

Script 8. bootlocal.sh

  • /mnt/sda1/tools/bin –principaux fichiers et scripts utilisés pour mettre à jour et exécuter le mineur.
  • /mnt/sda1/tools/xmrig – comprend le code source de XMRig (depuis le dépôt GitHub).

La configuration du mineur est stockée dans /mnt/sda1/tools/bin/config.json et contient principalement le nom de domaine et le port utilisés pour le pool de minage, qui peuvent différer selon la version (voir exemples dans la section IoCs).

Le mécanisme de mise à jour s’effectue via SCP (Secure File Copy) par trois scripts différents :

  • xmrig_update – met à jour la configuration du mineur (json);
  • ccommand – met à jour ccommand_update, xmrig_update (voir Script 9), sh, xmrig;
  • ccommand_update – met à jour ccommand.

D’après ce que nous avons observé, la configuration des mineurs est mise à jour une fois par jour.

Script 9. xmrig_update

Afin d’identifier une session d’exploration particulière, un fichier contenant l’adresse IP de la machine et la date du jour est créé par le script idgenerator et sa sortie est envoyée au serveur C&C par le script updater.sh.

Protection

Évidemment, le meilleur conseil pour se protéger contre ce genre de menace est de ne pas télécharger de copies piratées de logiciels commerciaux. Il y a, cependant, quelques conseils qui peuvent vous aider à déterminer si une application contient du code non indésirable :

  • Une fenêtre contextuelle de confiance provenant d’un installateur « supplémentaire » inattendu (dans ce cas, l’adaptateur réseau Oracle).
  • Consommation CPU élevée par un processus que vous n’avez pas installé (QEMU ou VirtualBox dans ce cas).
  • Un nouveau service ajouté à la liste des services de démarrage (Windows) ou un nouveau Démon de lancement (macOS).
  • Connexions réseau à des noms de domaine curieux (tels que les services system-update[.]info ou system-check[.]info ici).

Indicateurs de compromission (IoCs)

Hashes

Applications macOS « craquées » (versions 1-3)

SHA-1FilenameESET detection nameVersion number
71030028c4e1b844c85138bd77ddea96a190ec2cVirtual_DJ_8_Pro_Infinity_macOS.pkgOSX/LoudMiner.A1
32c80edcec4f7bb3b494e8949c6f2014b7f5db65Native Instruments Massive Installer.pkgOSX/LoudMiner.A1
7dc9f8ca07cd8e0247cf15cd8d2da2190a02fc90Massive_v1.5.5_Installer_macOS.dmgOSX/LoudMiner.B2
0b40bd0754637d5be2ada760ff0ecfda7afe03d7Native_Instruments_Effects_Series_Mod_Pack.dmgOSX/LoudMiner.B2
88efc767a32299e922f1b41f82c8d584585e2161Spectrasonics_Omnisphere_2.5_OSx.dmgOSX/LoudMiner.C3
e9c9d17d006fb03d67b736c0826df0af8ca6d5fdLennar_Digital_Sylenth1_2.2.1.dmgOSX/LoudMiner.C3

Applications Windows « craquées » (version 4)

SHA-1FilenameESET detection name
23faacfc23cfef65504d7fa20854030b96a9df91Ableton.Live.Suite.10.0.6.Multilingual.x64.WIN.zipWin32/LoudMiner.A
5a8682eae69b2e11d45980941a972bd734630207Infected-Mushroom-Manipulator-V1.0.3.zipWin32/LoudMiner.A
60a8f1d4a028153271093e815e8267bd25fde852Sonic_Academy_ANA_2.0.3_x86_x64.msiWin32/LoudMiner.A
7c7876058783da85d5502b9406f7fb4d26f66238SoundToys_5.0.1_x64-SetupFiles.rarWin32/LoudMiner.A
a1a1dc7876d71749a8bc5690c537451770ef4ab8Valhalla-DSP-Full-Bundle-setupfiles.zipWin32/LoudMiner.A

Images Linux

SHA-1FilenameVersion number
dd9b89a3c5a88fb679f098e2c2847d22350e23b1sys00_1-disk001.qcow21
d1e42e913da308812dd8da1601531b197c1a09a1sys00_1-disk001.qcow21
39a7e86368f0e68a86cce975fd9d8c254a86ed93z1.qcow2 (renamed with a randomized name)2
59026ffa1aa7b60e5058a0795906d107170b9e0fz1.qcow2 (renamed with a randomized name)3
fcf5c3b560295ee330b97424b7354fd321757cc6sys00_1.ova4
fc60431a0172d5b8cf4b34866567656467cf861csys00_1.ova4

Noms de fichiers

macOS

  • /Library/Application Support/.Qemusys
  • /Library/Application Support/.System-Monitor
  • /usr/local/bin/{.Tools-Service, cpumonitor, system-monitor, tools-service}
  • /Library/LaunchDaemons/{com.buildtools.system-monitor.plist, com.buildtools.tools-service.plist, com.modulesys.qemuservice.plist, com.systools.cpumonitor.plist}

Windows

  • C:\vms

Hôte

vstcrack[.]com (137[.]74.151.144)

Hôtes de téléchargement (via HTTP au port 80)

  • 185[.]112.156.163
  • 185[.]112.156.29
  • 185[.]112.156.70
  • 185[.]112.157.102
  • 185[.]112.157.103
  • 185[.]112.157.105
  • 185[.]112.157.12
  • 185[.]112.157.181
  • 185[.]112.157.213
  • 185[.]112.157.24
  • 185[.]112.157.38
  • 185[.]112.157.49
  • 185[.]112.157.53
  • 185[.]112.157.65
  • 185[.]112.157.72
  • 185[.]112.157.79
  • 185[.]112.157.85
  • 185[.]112.157.99
  • 185[.]112.158.112
  • 185[.]112.158.133
  • 185[.]112.158.186
  • 185[.]112.158.190
  • 185[.]112.158.20
  • 185[.]112.158.3
  • 185[.]112.158.96
  • d-d[.]host (185[.]112.158.44)
  • d-d[.]live (185[.]112.156.227)
  • d-d[.]space (185[.]112.157.79)
  • m-m[.]icu (185[.]112.157.118)

Hôtes de mise à jour (via SCP)

  • aly001[.]hopto.org (192[.]210.200.87, port 22)
  • system-update[.]is (145[.]249.104.109, port 5100)

Hôte de minage

  • system-update[.]info (185[.]193.126.114, port 443 or 8080)
  • system-check[.]services (82[.]221.139.161, port 8080)

Techniques MITRE ATT&CK

TacticIDNameDescription
ExecutionT1035Service ExecutionOn Windows, the Linux image is run as a service with VboxVmService.
PersistenceT1050New ServiceInstall the Linux virtual machine as a service with VboxVmService.
T1062HypervisorInstall a type-2 hypervisor on the host (VirtualBox or QEMU) to run the miner.
T1160Launch DaemonThe macOS versions use a Launch Daemon to ensure the persistence.
Defense EvasionT1027Obfuscated Files or InformationSome shell scripts are obfuscated, and some installers are encrypted in macOS versions.
T1045Software PackingUse BAT2EXE to pack batch script in Windows versions.
T1158Hidden Files and DirectoriesThe VirtualBox installation folder and the directory containing the Linux image are hidden.
Command and ControlT1043Commonly Used PortUse TCP ports 443 and 8080 for mining pool communication.
T1105Remote File CopyUse SCP (port 22 or 5100) to copy files from/to the C&C server.
ImpactT1496Resource HijackingUse victim machines to mine cryptocurrency (Monero).
et

Discussion