LoudMiner: minerador multiplataforma oculto em programas VST “crackeados”

Investigadores da ESET revelam detalhes de um incomum minerador que acompanha as cópias piratas de programas VST de áudio e que faz a mineração de criptomoedas em máquinas virtuais.

O LoudMiner é um caso incomum de um minerador de criptomoedas persistente distribuído para macOS e Windows desde agosto de 2018. Utiliza programas de virtualização – QEMU em macOS e VirtualBox em Windows – para realizar a mineração de criptomoedas numa máquina virtual Tiny Core Linux, fazendo com que se torne multiplataforma. Está incluído em cópias piratas de programas VST (Virtual Studio Technology). O minerador em si é baseado em XMRig (Monero) e utiliza um pool de mineração, pelo que é impossível rastrear potenciais transações.

Distribuição

No momento em que foi escrito este artigo, existiam 137 plugins VST (42 para Windows e 95 para macOS) disponíveis num único site web criado no WordPress com um domínio registado a 24 de agosto de 2018.

O primeiro dos programas VST (Kontakt Native Instruments 5.7 para Windows) foi carregado no mesmo dia. O tamanho das aplicações faz com que seja praticamente impossível de analisar, embora consideremos que podemos assumir com segurança que todas estão cheias de trojans.

As aplicações em si não estão alojadas no site que tem por base o WordPress, mas em 29 servidores externos, os quais podem encontrar-se na secção IoCs. Os administradores do site também atualizam com frequência as aplicações com versões mais recentes, tornando mais difícil rastrear a primeira das versões do minerador.

Independentemente da natureza das aplicações apontadas pelos hackers, é interessante observar que o seu propósito está relacionado com a produção de áudio. Neste sentido, os computadores nos quais estão instaladas estas aplicações VST deveriam contar com um bom poder de processamento, pelo que elevados níveis de consumo do CPU não é algo que surpreenda os utilizadores destes equipamentos. Para além disso, estas aplicações são geralmente complexas, pelo que é algo inesperado para os utilizadores que se tratem de arquivos de grandes dimensões. Da mesma forma, os hackers usam em benefício próprio para camuflar as imagens da máquina virtual (VM). Há ainda que destacar que a decisão de utilizar máquinas virtuais, em vez de uma solução de aprendizagem, é um ponto a destacar e não algo que seja visto com frequência.

De seguida apresentamos alguns exemplos de programas VST, assim como alguns comentários que se podem encontrar no site web.

• Propellerhead Reason
• Ableton Live
• Sylenth1
• Nexus
• Reaktor6
• AutoTune

Relatórios de utilizadores

Temos visto vários tópicos em fóruns em que os utilizadores se queixam acerca do processo quemu-system-x86_64, já que utiliza 100% do seu CPU em Mac:

Um utilizador chamado “Malconi” (https://discussions.apple.com/thread/8602989) disse o seguinte:

“Infelizmente, tive que reinstalar OSX, o problema foi que o Ableton Live 10, o qual descarreguei de um site de Torrent e não do site oficial, também instala um mineiro que corre em segundo plano causando isto”. O mesmo utilizador inclui capturas de ecrã do Activity Monitor de macOS no qual se indicam 2 processos – quemu-system-x86_64 e tools-service – a utilizar 25% dos recursos do CPU e correndo como root.

Análise das aplicações pirateadas

De um modo geral, as análises tanto para macOS como Windows mostram o mesmo:

1. Uma aplicação empacotada com um programa de virtualização, uma imagem Linux e outros arquivos adicionais são utilizados para conseguir persistência.
2. Os utilizadores descarregam as aplicações e seguem as instruções das mesmas sobre a instalação dos programas VST.
3. O LoudMiner é instalado primeiro e de seguida o plugin VST.
4. O LoudMiner esconde-se e volta persistente no arranque.
5. A máquina virtual de Linux é executada e o processo de mineração começa.
6. Os scripts dentro da máquina virtual podem contatar o servidor C&C para atualizar o mineiro (configuração e binários).

Enquanto analisávamos as diferentes aplicações VST, identificámos quatro versões do mineiro, baseadas essencialmente na forma como são empacotadas com o atual programa, o domínio do servidor C&C, e algo que acreditamos ser um string da versão criado pelo autor.

macOS

Até ao momento identificámos três versões para macOS deste malware. Todas elas incluem a necessidade de correr QEMU em installerdata.dmg onde todos os arquivos copiados sobre /usr/local/bin e tem as permissões apropriadas que foram sendo estabelecidas durante o caminho. Cada versão do mineiro pode executar duas imagens de cada vez, cada uma ocupando 128 MB de RAM e um núcleo do CPU. A persistência é conseguida adicionando arquivos plist em /Library/LaunchDaemons com RunAtLoad configurado no true. Também contam com KeepAlive configurado em true, garantindo de que o processo se reiniciará caso seja parado.

Cada uma das versões conta com os seguintes componentes:

1. Imagens QEMU de Linux.
2. Scripts de shell utilizados para executar as imagens QEMU.
3. Daemons utilizados para iniciar os scripts de Shell no arranque e mantê-los a correr.
4. Um script de shell para monitorizar o CPU em conjunto com um daemon que o acompanha e que pode iniciar/deter a mineração consoante o uso do CPU e se o processo Activity Monitor estiver em execução.

O script de monitorização do CPU pode inciar e deter o minerado mediante a carga e remoção do daemon. Se o processo Activity Monitor está a correr, a mineração é parada. Caso contrário, verifica durante quanto tempo o sistema este inativo em segundos:

Se tiver sido superior aos 2 minutos, começa com a mineração. Se foi menor aos 2 minutos verifica o uso do CPU.

… divide isso pelo número de núcleos do CPU:

… e se é superior a 85%, para a mineração. O script em sim mesmo apresenta algumas alterações entre as distintas versões, mas a ideia geral mantém-se igual.

Uma vez que a instalação finalizou, todos os arquivos de instalação que tenham alguma relação com o minerador são eliminados.

Versão 1

Os arquivos do minerador no pacote das aplicações VST descarregadas não são ofuscados nem estão localizados noutro pacote; estão instalados junto do programa VST nas seguintes localizações:

• /Library/Application Support/.Qemusys
  • qemu-system-x86_64 – – limpa o binário QEMU
  • sys00_1-disk001.qcow2 – Imagen Linux (primeira)
  • qemuservice sript de shell que executa a primeira imagem através do binário qemu-system-x86_64  (ver listagem do Script 1)
• /Library/Application Support/.System-Monitor
  • system-monitor.daemon – executa a primeira imagem através do binário system-monitor
• /usr/local/bin
  • Tools-Service
    • sys00_1-disk001.qcow2 – Imagen Linux (segunda)
    • tools-service.daemon – executa a segunda imagem através do binário tools-service
  • cpumonitor –inicia/detém a mineração de acordo com o tempo de inatividade e o uso do CPU
  • system-monitor – cópia do binário qemu-system-x86_64
  • tools-service – cópia do binário qemu-system-x86_64
• /Library/LaunchDaemons
  • buildtools.system-monitor.plist – executa system-monitor.daemon
  • buildtools.tools-service.plist – executa tools-service.daemon
  • modulesys.qemuservice.plist – executa qemuservice
  • systools.cpumonitor.plist – executa cpumonitor

Script 1: shell script qemuservice

Uma vez copiadas as dependências, todos os daemons relacionados com o minerador são executados e, de seguida, é instalado o software real:

• qemuservice não iniciará a imagem se o processo Activity Monitor estiver a ser executado. De facto, se estiver a ser executado, descarregará o plist que lançou.
• tools-service.daemon lançará a imagem apenas quando o processo quemu-system-x86_64 não estiver a ser executado e depois de ficar suspenso durante 45 minutos.
• system-monitor.daemon executará a imagem apenas se detetar o CPU Intel i5, i7 ou i9.

Estes scripts utilizam o mesmo comando para iniciar a imagem QEMU, mas apenas se diferenciam pelos nomes e na rota da imagem.

Encontrámos as seguintes capturas de ecrã relacionada com a versão 1 do minerador:

A imagem de Little Snitch indica que algumas ligações do processo quemu-system-x86_64 foram bloqueadas. Especificamente, hopto[.]org (um serviço de nome de host gratuito) é um C&C utilizado pela versão 1 do minerador.

Versão 2

Os arquivos do minerador estão em data_installer.pkg dentro do pacote da aplicação descarregada. Primeiro é instalado o data_installer.pkg e de seguida o software VST. Antes da instalação, a versão 1 do minerador é eliminada com a execução do comando:

Como se vê na listagem do Script 2, ele só faz isso quando deteta um processo quemu-system-x86_64 em execução

Script 2: data_installer.pkg script de pré-instalação que elimina a versão

Os seguintes arquivos temporais são criados:

• /Users/Shared
  • z1 – binário QEMU
  • z1.daemon – executa a imagem QEMU com o binário QEMU
  • z1.qcow2 – imagem QEMU
  • z1.plist – executa z1.daemon
  • z3 – Script de monitorização do CPU, pequena alteração que respeita à versão 1 cpumonitor
  • z3.plist – utilizado para executar z3
  • randwd – gera nomes aleatórios

Uma vez copiadas as dependências, é instalado o minerador. Desta vez os nomes dos binários QEMU, plist e diretórios de QEMU são aleatórios mediante o script randwd. A instalação do minerador cria duas cópias de z1, z1.daemon, z1.qcow2 e z1.plist. para cada cópia, sucede o seguinte:

• É criado um diretório com um nome aleatório em /Library/Application Support
• O binário QEMU z1 fica com o mesmo nome que o diretório e é copiado para /usr/local/bin
• daemon (ver listagem no Script 3) e z1.qcow2 são copiados neste diretório com nomes aleatórios
• plist é copiado com o mesmo com.<random_name>.plist no /Library/LaunchDaemons

Os arquivos z1.daemon, z1.plist, z3 e z3.plist servem como modelos. Nestes arquivos, as referências a outros scripts, binários, plist, etc. são substituídas pelo correspondente nome aleatório gerado.

É também escolhido um nome aleatório para o script de shell para monitorizar o CPU e para o arquivo plist que o acompanha. z3 é copiado no /usr/local/bin e o plist no /Library/LaunchDaemons com o nome com.<random_name>.plist.

Script 3: shell script z1.daemon

A versão 2 é um pouco mais limpa e/ou simples que a versão 1. Existe apenas uma imagem QEMU, com duas cópias realizadas; o mesmo para os scripts para executar imagens, os daemons e o cpumonitor. Embora a versão 2 crie nomes de arquivos e diretórios de forma aleatória, apenas se pode instalar uma vez porque a instalação verifica os processos na execução com accel = hvf na sua linha de comandos.

Das aplicações da versão 2 que analisámos até agora, o hash SHA1 do data_installer.pkg é sempre 39a7e86368f0e68a86cce975fd9d8c254a86ed93.

Versão 3

Os arquivos do minerador estão num arquivo DMG encriptado chamado do.dmg, dentro do pacote da aplicação. O DMG é montado com o seguinte comando

O minerador DMG contém apenas um pacote: datainstallero.pkg. Este e o pacote do software são instalados.

O conteúdo do pacote de datainstallero.pkg e data_installer.pkg da versão 2 são mais ou menos iguais, mas o datainstallero.pkg agrega dois scripts ofuscados (clearpacko.sh e installpacko.sh) e ofusca um script existente – randwd:

• clearpacko.sh elimina a versão 1 do minerador da mesma forma que o faz com a versão 2.
• installpacko.sh instala o minerador da mesma forma que o faz com a versão 2, exceto os comentários que tenham sido removidos do script.

E1 SHA1 do do.dmg continua a ser o mesmo: b676fdf3ece1ac4f96a2ff3abc7df31c7b867fb9

Executando a imagem Linux

Todas as versões utilizam múltiplos scripts shell para executar a imagem. Os scripts de shell são executados por plists no arranque e mantém-se vivos.

• Versão 1 executa os seguintes binários (cópias de qemu-system-x86_64) para executar as imagens QEMU: qemu-system-x86_64, system-monitor, tools-service.
• A versão 2 e 3 utiliza o mesmo comando, mas tanto o nome de arquivo do binário, o diretório no Appliance Support e o nome de arquivo do QEMU é randomizado.

Todas as versões utilizam os seguintes interruptores:

• – M accel=hvf para utilizar o framework Hypervisor com um acelerador.HVF foi introduzido com o OS X 10.10 e o suporte para HVF foi adicionado ao QEMU 2.12, o qual foi lançado em abril de 2018.
• – display none pelo que a máquina virtual é executada sem uma interface gráfica.

Uma vez que a imagem é executada sem especificar a quantidade de RAM e números de núcleos de CPU, os valores por defeito utilizados são: 1 núcleo CPU e 128MB de RAM. Todas as versões podem executar 2 imagens.

Windows (versão 4)

A partir do string que extraímos da aplicação, definimos a versão 4 como a única que vimos até agora para Windows. Como dissemos anteriormente, a lógica é muito similar à versão para macOS. Cada aplicação para Windows está em pacotes como um instalador MSI que instala a aplicação “crackeada”, e a Figura 8 mostra a janela emergente para a instalação do driver da VirtualBox quando corre o instalador de um VST “crackeado” desde vstcrack[.]com.

A VirtualBox instala-se no seu nome de pasta habitual (C: \ Archivos de programa \ Oracle), no entanto, os atributos do diretório são configurados como “ocultos”. Logo, o instalador copia a imagem do Linux e VBoxVmService (um serviço Windows utilizado para executar uma máquina virtual VirtualBox como um serviço) em C: \ vms, que também é um diretório oculto. Uma vez que se completa a instalação, o instalador executa um script por lotes compilado com BAT2EXE (veja a lista descompactada no Script 4) para importar a imagem do Linux e executar VmServiceControl.exe para iniciar a máquina virtual como um serviço.

Script 4: Script de lotes utilizado para executar a máquina virtual de Linux como serviço

Este método é utilizado para assegurar a persistência do minerador a partir do reinício. De facto, o serviço VboxVmService vem com um arquivo de configuração (ver Script 5) no qual é possível habilitar a opção AutoStart para que máquina virtual seja executada automaticamente com o arranque.

Script 5: Arquivo de configuração para VBoxVmService com o AutoStart ativado

O arquivo OVF incluído na imagem Linux descreve a configuração do hardware da máquina virtual (ver Script 6): utiliza 1GB de RAM e 2 núcleos CPU (com uma utilização máxima de 90%).

Script 6: Configuração do hardware da imagem Linux

Imagem Linux

A imagem Linux é Tiny Core Linux 9.0 configurada para correr XMRig, assim como alguns arquivos e scripts para manter o minerador atualizado de forma continua. Os arquivos mais interessantes são:

• /root/.ssh/{id_rsa, id_rsa.pub} – o par de chaves SSH utilizadas para atualizar o minerador a partir do servidor C&C utilizando o SCP.
• /opt/{bootsync.sh, bootlocal.sh} – os comandos de início de sistema que tentam atualizar o minerador a partir do servidor C&C e executá-lo (ver Scripts 7 e 8):

Script 7: bootsync.sh

Script 8: bootlocal.sh

• /mnt/sda1/tools/bin – principais arquivos e scripts utilizados para atualizar e executar o minerador.
• /mnt/sda1/tools/xmrig – contém o Código fonte de XMRIG (do repositório do GitHub).

A configuração do minerador é guardada em /mnt/sda1/tools/bin/config.json e contem principalmente o nome de domínio e a porta utilizada para o pool de mineração, o qual pode diferir de acordo com a versão (consulte os exemplos na secção IoC).

O mecanismo de atualização é levado adiante através do SCP (Secure File Copy) por três scripts diferentes:

• xmrig_update – atualiza a configuração do minerador (json);
• ccommand – atualiza ccommand_update, xmrig_update (veja Script 9), sh, xmrig;
• ccommand_update – atualiza command.

De acordo com o que temos visto, a configuração do minerador é atualizada uma vez por dia.

Script 9: xmrig_update

Com o objetivo de identificar uma sessão de mineração em particular, um arquivo que contém a direção IP da máquina e a data em foi criado pelo script idgenerator na sua saída, é enviado ao servidor C&C mediante updater.sh.

Proteção

Obviamente, a melhor recomendação para estar protegido perante este tipo de ameaças é não fazer download de cópias piratas de programas pagos. No entanto, existem alguns aspetos que podem ajudá-lo a identificar quando uma aplicação contém um código não desejado:

• Uma janela que aparece de um inesperado instalador “adicional” (neste caso o adaptador de rede da Oracle).
• Elevado consumo do CPU por um processo que não tem instalado (QEMU ou VirtualBox neste caso).
• Um novo serviço adicionado à lista de serviços de início (Windows) ou um novo Daemon de Execução (macOS).
• Ligações de rede com nomes de domínio estranhos (tais como system-update[.]info o system-check[.]services).

Indicadores de Compromisso (IoCs)

Hashes

Aplicações para macOS “crackeadas” (versões 1-3)

Aplicações para Windows “crackeadas” (versão 4)

Imagens Linux

Nomes de arquivo

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

Hostnames

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

Download hosts (via HTTP na porta 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)

Update hosts (via SCP)

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

Mining hosts

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

Técnicas MITRE ATT&CK