LoudMiner: Exploitation multi-plateforme dans un logiciel VST fissuré – Serveur d’impression

LoudMiner est un cas inhabituel de mineur persistant dans la crypto-monnaie, distribué pour macOS et Windows depuis août 2018. Il utilise un logiciel de virtualisation – QEMU sous macOS et VirtualBox sous Windows – pour exploiter la crypto-monnaie sur une machine virtuelle Tiny Core Linux, la rendant ainsi multiplateforme. Il est livré avec des copies piratées du logiciel VST. Le mineur lui-même est basé sur XMRig (Monero) et utilise un pool d’extraction, il est donc impossible de retracer les transactions potentielles.

Au moment de la rédaction du présent document, 137 applications liées à VST (42 pour Windows et 95 pour macOS) étaient disponibles sur un seul site Web 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é le même jour. La taille des applications rend difficile leur analyse, mais il semble raisonnable de supposer qu'elles sont toutes troyens.

Les applications elles-mêmes ne sont pas hébergées sur le site WordPress, mais sur 29 serveurs externes, disponibles dans la section IoCs. Les administrateurs du site mettent également à jour fréquemment 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 de noter que leur objectif est lié à la production audio; ainsi, les machines sur lesquelles ils sont installés doivent avoir une bonne puissance de traitement et une consommation de processeur élevée ne surprendra pas les utilisateurs. En outre, ces applications étant généralement complexes, il n’est donc pas surprenant qu’elles soient des fichiers volumineux. Les attaquants profitent de cela pour camoufler leurs images de machine virtuelle. 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 des commentaires que vous pouvez trouver sur le site:

• Raison Propellerhead
• Ableton Live
• Sylenth1
• Lien
• Reaktor 6
• AutoTune

Figure 1. Commentaire n ° 1 de l’administrateur

Figure 2. Commentaire n ° 2 de l’administrateur

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

Figure 3. Rapport d'utilisateur n ° 1 (https://discussions.apple.com/thread/250064603)

Figure 4. Rapport utilisateur n ° 2 (https://toster.ru/q/608325)

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

«Malheureusement, nous avons dû réinstaller OSX. Le problème, c’était qu’Ableton Live 10, que je l’avais téléchargé depuis un site torrent et non depuis le site officiel, installait également un mineur, exécuté à l’arrière-plan, ce qui provoquait cet incident.» Le même utilisateur a joint des captures d’écran. du moniteur d'activité indiquant 2 processus – qemu-system-x86_64 et outils-service – utiliser 25% des ressources du processeur et fonctionner en tant que root. ”

L'idée générale des analyses macOS et Windows reste la même:

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

Lors de l’analyse des différentes applications, nous avons identifié quatre versions du mineur, principalement basées sur la manière dont il est intégré au logiciel, au domaine du serveur C & C, et à une chaîne de version créée par l’auteur.

macOS

Nous avons identifié trois versions MacOS de ce logiciel malveillant jusqu'à présent. Tous comprennent les dépendances nécessaires pour exécuter QEMU dans installerdata.dmg à partir duquel tous les fichiers sont copiés sur / usr / local / bin et disposer des autorisations appropriées en cours de route. Chaque version du mineur peut exécuter deux images à la fois, chacune prenant 128 Mo de RAM et un cœur de processeur. La persistance est obtenue en ajoutant des fichiers plist dans / Bibliothèque / LaunchDaemons avec RunAtLoad mis à vrai. Ils ont aussi Rester en vie mis à true, s'assurer que le processus sera redémarré s'il est arrêté. Chaque version a ces composants:

1. Images QEMU Linux.
2. Scripts shell utilisés pour lancer les images QEMU.
3. Les démons lançaient les scripts shell au démarrage et les maintenaient actifs.
4. Un script de shell de moniteur de processeur avec un démon associé qui peut démarrer / arrêter l’extraction en fonction de l’utilisation du Moniteur d'activité processus est en cours d'exécution.

Le script du moniteur de la CPU peut démarrer et arrêter l'extraction en chargeant et en déchargeant le démon. Si la Moniteur d'activité processus est en cours d'exécution, l'extraction s'arrête. Sinon, il vérifie depuis combien de temps le système est inactif:

Si cela fait plus de 2 minutes, l’extraction commence. Si cela fait moins de 2 minutes, il vérifie l’utilisation totale de la CPU:

divise cela par le nombre de cœurs de la CPU:

et s'il est supérieur à 85%, il arrête l'extraction. Le script lui-même est un peu différent selon les versions, mais l'idée générale reste la même.

Une fois l'installation terminée, tous les fichiers d'installation liés à Miner sont supprimés.

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

Figure 6. Polyverse.Music.Manipulator.v1.0.1.macOS.dmg instructions d'installation

Version 1

Les fichiers Miner contenus dans le package d'application téléchargé ne sont aucunement masqués ni placés dans un autre package. ils sont installés à côté du logiciel aux endroits suivants:

• / Bibliothèque / Application Support / .Qemusys
  • qemu-system-x86_64 – binaire QEMU propre
  • sys00_1-disk001.qcow2 – image Linux (première)
  • qemuservice – script shell qui lance la première image via le qemu-system-x86_64 binaire (voir le script 1)
• / Bibliothèque / Application Support / .System-Monitor
  • system-monitor.daemon – lance la première image via moniteur système binaire
• / usr / local / bin
  • .Outils-Service
    • sys00_1-disk001.qcow2 – image Linux (seconde)
    • tools-service.daemon – lance la deuxième image via outils-service binaire
  • cpumonitor – démarre / arrête l'exploration en fonction du temps d'inactivité et de l'utilisation du processeur
  • moniteur système – copie de qemu-system-x86_64 binaire
  • outils-service – copie de qemu-system-x86_64 binaire
• / Bibliothèque / LaunchDaemons
  • buildtools.system-monitor.plist – lancements system-monitor.daemon
  • buildtools.tools-service.plist – lancements tools-service.daemon
  • modulesys.qemuservice.plist – lancements qemuservice
  • systools.cpumonitor.plist – lancements cpumonitor

Script 1. qemuservice script shell

Une fois les dépendances copiées, tous les démons liés aux mineurs sont lancés, puis le logiciel proprement dit est installé:

• qemuservice ne lancera pas l'image si le Moniteur d'activité processus est en cours d'exécution. En fait, s'il fonctionne, il déchargera le plist par lequel il a été lancé.
• tools-service.daemon lancera l'image uniquement lorsque qemu-system-x86_64 processus ne fonctionne pas et après avoir dormi pendant 45 minutes.
• System-monitor.daemon lancera l'image uniquement si le processeur Intel i5, i7 ou i9 est détecté.

Ces scripts utilisent la même commande pour lancer l'image QEMU, seuls les noms et le chemin de l'image diffèrent.

Nous avons trouvé la capture d'écran suivante liée à la version 1 du mineur:

Figure 7. Consommation d'UC de QEMU avec Little Snitch (source: https://imgur.com/a/sc3u6kk)

C’est de Little Snitch qui indique que certaines connexions du processus qemu-system-x86_64 ont été bloqués. Plus précisément, hopto[.]org (un service de nom d’hôte gratuit) est un C & C utilisé par la version 1 du mineur.

Version 2

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

Comme indiqué dans la liste du script 2, il ne le fait que lorsqu'il détecte un qemu-system-x86_64 processus.

Script 2 data_installer.pkg script de préinstallation qui supprime la version 1

Les fichiers temporaires suivants sont créés:

• / Utilisateurs / Partagé
  • z1 – binaire QEMU
  • z1.daemon – lance l'image QEMU avec le binaire QEMU
  • z1.qcow2 – image QEMU
  • z1.plist – lancements z1.daemon
  • z3 – Script de moniteur de processeur, peu de changement par rapport à la version 1 cpumonitor
  • z3.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 fichiers binaires, des listes de plists et des répertoires QEMU sont randomisés avec randwd scénario. L’installation de mineur crée deux copies de z1, z1.daemon, z1.qcow2 et z1.plist. Voici ce qui se passe pour chaque copie:

• Un répertoire avec un nom aléatoire est créé dans / Bibliothèque / Support d'application
• Le binaire QEMU z1 porte le même nom que le répertoire et est copié dans / usr / local / bin
• z1.daemon (voir liste dans le script 3) et z1.qcow2 sont copiés dans ce répertoire sous leurs noms aléatoires
• z1.plist est copié avec le nom com..pliste dans / Bibliothèque / LaunchDaemons

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

Un nom aléatoire est également choisi pour le moniteur de la CPU (z3) shell script et son fichier de plist associé. z3 est copié dans / usr / local / bin et le plist dans / Bibliothèque / LaunchDaemons sous le nom com..pliste.

Script 3. z1.daemon script shell

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 réalisées; même chose pour les scripts de lancement d’image, les démons et le cpumonitor. Même si la version 2 randomise ses noms de fichiers et ses répertoires, elle ne peut être installée qu'une seule fois car l'installation vérifie les processus en cours d'exécution avec accel = hvf dans leur ligne de commande.

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

Version 3

Les fichiers de mineur sont dans un fichier DMG crypté, appelé do.dmg, à l'intérieur du package d'application. Le DMG est monté avec la commande suivante:

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

Le contenu de l'emballage de datainstallero.pkg et data_installer.pkg à partir de la version 2 sont plus ou moins les mêmes, mais datainstallero.pkg ajoute deux scripts obscurcis – clearpacko.sh et installpacko.sh – et obscurcit un script existant – randwd:

• clearpacko.sh supprime la version 1 du mineur comme 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 du do.dmg reste le même: b676fdf3ece1ac4f96a2ff3abc7df31c7b867fb9.

Lancer l'image Linux

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

• La version 1 exécute les fichiers binaires suivants (copies de qemu-system-x86_64) pour lancer les images QEMU: qemu-system-x86_64, moniteur système, outils-service.
• Les versions 2 et 3 utilisent la même commande, mais le nom du fichier binaire, répertoire dans Support d'application et le nom de fichier QEMU est aléatoire.

Toutes les versions utilisent les commutateurs suivants:

• -M accel = hvf utiliser le framework Hypervisor comme accélérateur. HVF a été introduit avec OS X 10.10 et un support pour HVF a été ajouté dans QEMU 2.12, qui a été publié en avril 2018.
• -display aucun de sorte que la machine virtuelle s'exécute sans interface graphique.

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

Windows (version 4)

À partir des chaînes que nous avons extraites de l'application, nous définissons la seule version de Windows vue jusqu'à présent, la version 4. Comme nous l'avons mentionné précédemment, la logique est assez similaire à la version macOS. Chaque application Windows est présentée sous la forme d’un programme d’installation MSI qui installe à la fois l’application «fissurée» et la figure 8 illustre la zone de confiance pour l’installation du pilote VirtualBox lors de l’exécution d’un programme d’installation VST «fissuré» à partir de vstcrack.[.]com.

Figure 8. Fenêtre contextuelle de confiance pour un pilote VirtualBox lors de l'installation d'une application à partir de vstcrack[.]com

VirtualBox est installé dans son nom de dossier habituel (C: Program Files Oracle) cependant, les attributs du répertoire sont réglés sur «masqué». Le programme d’installation copie ensuite 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 de traitement par lots compilé avec BAT2EXE (voir la liste des packages décompressés dans le script 4) pour importer l’image Linux et exécuter VmServiceControl.exe pour démarrer la machine virtuelle en tant que service.

Script 4. Script batch 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 le AutoStart option pour que la machine virtuelle soit automatiquement lancée au démarrage.

Script 5. Fichier de configuration pour VBoxVmService avec AutoStart activée

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

Script 6. Configuration matérielle de l'image Linux

Image de Linux

L'image Linux est Tiny Core Linux 9.0 configuré pour exécuter XMRig, ainsi que certains fichiers et scripts pour maintenir 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 à partir du serveur C & C à l'aide de 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 – les fichiers principaux et les scripts utilisés pour mettre à jour et exécuter le mineur.
• / mnt / sda1 / tools / xmrig – contient le code source de XMRig (à partir du référentiel 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é pour le pool d’extraction, qui peuvent varier en fonction de la version (voir des exemples dans la section IoC).

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

• xmrig_update – met à jour la configuration du mineur (config.json)
• commande – mises à jour ccommand_update, xmrig_update (voir le script 9), updater.sh, xmrig;
• ccommand_update – mises à jour commande;

D'après ce que nous avons vu, la configuration du mineur est mise à jour une fois par jour.

Script 9. xmrig_update

Afin d’identifier une session d’extraction particulière, un fichier contenant l’adresse IP de la machine et la date du jour est créé par le générateur d'énergie Le script et sa sortie sont envoyés au serveur C & C par le updater.sh scénario.

Évidemment, le meilleur conseil à se protéger contre ce type de menace est de ne pas télécharger des copies piratées de logiciels commerciaux. Toutefois, il existe des astuces qui peuvent vous aider à identifier le moment où une application contient du code indésirable:

• Confiance provenant d’un programme d’installation «supplémentaire» inattendu (dans ce cas, la carte réseau Oracle).
• Consommation de processeur é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 system-update[.]info ou vérification du système[.]services ici).

Des hachis

applications «fissurées» macOS (versions 1 à 3)

Applications «fissurées» de Windows (version 4)

Images Linux

Noms de fichiers

macOS

• / Bibliothèque / Application Support / .Qemusys
• / Bibliothèque / Application Support / .System-Monitor
• /usr/local/bin/.Tools-Service, cpumonitor, moniteur système, tools-service
• /Bibliothèque/LaunchDaemons/com.buildtools.system-monitor.plist, com.buildtools.tools-service.plist, com.modulesys.qemuservice.plist, com.systools.cpumonitor.plist

les fenêtres

Noms d'hôtes

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

Hôtes de téléchargement (via HTTP sur le 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[.]hôte (185[.]112.158.44)
• d-d[.]vivre (185[.]112.156.227)
• d-d[.]espace (185[.]112.157.79)
• m-m[.]icu (185[.]112.157.118)

Mettre à jour les hôtes (via SCP)

• aly001[.]hopto.org (192[.]210.200.87, port 22)
• mise à jour du système[.]est (145[.]249.104.109, port 5100)

Mining hôtes

• mise à jour du système[.]info (185)[.]193.126.114, port 443 ou 8080)
• verification du système[.]services (82[.]221.139.161, port 8080)

Michal Malik et ESET Research 20 juin 2019 – 11h00