Anatomia dos criptomineradores: análise dos criptomineradores

Esta é a segunda parte da nossa série de publicações de três partes chamada Anatomia dos criptomineradores. Na primeira parte, falamos sobre as criptomoedas em geral, suas principais características e o que torna algumas mais atrativas do que outras para os invasores.

Nesta parte, iremos a fundo na análise de várias amostras de criptomineradores para entender como funcionam. Vamos enfocar criptomineradores que estão explorando Monero e Zephyr, duas das criptomoedas que identificamos como propícias para uso em atividades mal-intencionadas. Nesta publicação do blog, discutiremos:

• O uso da rede blockchain para identificar a comunicação de mineração suspeita de um possível malware de criptomineração

• Quatro exemplos de estudos de caso que usam topologias diferentes para permanecer ativos e persistentes por um longo período

• Um caso intrigante de uma campanha longa e persistente com milhares de vítimas que gera US$ 5,50 por hora

• Invasores que usam várias moedas em uma única campanha

• Detecção pelas atividades de rede e referência cruzada com a rede blockchain

• Detecção pela análise de memória dos processos com a impressão digital do algoritmo de consenso

Também incluímos uma lista de IOCs (list of indicators of compromise, lista de indicadores de comprometimento) dos estudos de caso nesta publicação do blog para ajudar as equipes de segurança a proteger os respectivos ativos.

Por fim, nesta publicação, examinaremos as técnicas de detecção que dependem dos conceitos de algoritmos resistentes a ASIC, bem como da detecção de operações de criptomineração. A detecção se concentra nos fundamentos da mineração e pode ser aplicada no nível da rede ou do sistema operacional. Para saber como conseguimos derrubar campanhas maliciosas de mineração de criptomoedas, confira a terceira parte da nossa série.

Como a rede Monero é uma rede P2P descentralizada de colaboradores individuais, podemos nos conectar facilmente a ela. Ao mapear a rede Monero, podemos obter IOCs confiáveis (como endereços IP de nós) e identificar a potencial atividade dos hubs de nó que estão mais conectados do que outros.

Essas informações podem ser usadas para identificar e investigar operações de mineração, além de permitir a análise da rede em relação a vulnerabilidades e à sua exposição a ataques baseados em blockchain. A Figura 1 é uma representação visual da rede de mineração Monero, na qual o mapa de calor mostra a densidade dos nós por sua área geográfica. Marcamos os nós abertos publicamente com pontos vermelhos.

Usando os diferentes indicadores obtidos com o mapeamento da rede Monero, é possível identificar amostras que interagem com a rede blockchain. Por exemplo, usando o VirusTotal Livehunt, podemos identificar os arquivos que contêm endereços de nó conhecidos. Isso nos ajudará a detectar campanhas ativas de criptomineradores (Figura 2).

Como tudo na área de segurança, essa não é uma técnica de busca que se adequa a todas as situações. Usar somente essa abordagem pode levar a falso-positivos quando o servidor não é um nó de blockchain exclusivo. Isso também pode levar à falta de visibilidade, pois o mapa não está descobrindo todos os nós. No entanto, a combinação dessa técnica com outros indicadores aumentará a taxa de detecção de positivos reais.

O mapa contém nós acessíveis publicamente e nós que se tornaram acessíveis recentemente. Alguns nós são usados para mais de um nó Monero, por exemplo, como espelhos do repositório PyPi do Python ou de outros serviços. A Figura 3 é um exemplo de servidor que presta vários serviços, o que pode causar muita distração no processo de busca. Eliminamos esses servidores da análise para reduzir possíveis falso-positivos.

Como parte desta pesquisa, analisamos diversas amostras de criptomineradores — uma delas foi uma campanha que durou seis anos. Como é comum em campanhas de longa duração, essa parece ser uma operação organizada ou um serviço de distribuição de malware que implanta o criptominerador para terceiros.

A análise dessa amostra indica a presença de vários proxies que, juntos, alcançam uma taxa de hash de 5,6 MH/s, o que equivale a milhares de máquinas comprometidas (Figura 4). Esse é um ataque massivo e persistente e, como a taxa de hash permanece estável, o malware provavelmente permanece não detectado pela maioria de suas vítimas e continua sem impedimentos. Esse tipo de ataque é uma campanha extremamente lucrativa para um invasor.

A campanha está ativa pelo menos desde junho de 2018 e contém indicadores (por exemplo, a linguagem usada nas amostras) que podem apontar para um esforço colaborativo entre os agentes de ameaças russos e chineses. A análise dos servidores de C2 (command and control, comando e controle) também apoiou essa teoria, mas até a data desta publicação, isso não foi totalmente confirmado.

No momento da escrita, o invasor acumulou pelo menos 1.702 XMR, avaliado em aproximadamente US$ 280.000 na taxa de câmbio atual. Ao longo de seis anos, isso equivale a uma média de quase US$ 47.000 arrecadados por ano em uma única campanha.

A maioria das amostras vinculadas a esta campanha usa, como carregador inicial e downloader, uma linguagem de script correspondente ao sistema operacional da vítima. Esse processo depende muito do roteamento e das conexões de rede enganosas, provavelmente na tentativa de dissociar o arquivo mal-intencionado do servidor C2.

Após a análise das amostras da campanha, identificamos que ele usa o PowerShell para instalar um arquivo executável chamado loader de maneira furtiva usando o rootkit r77. Mesmo sem analisar o dropper complexo, podemos ver que há várias versões desse criptominerador.

Em algumas versões, o próprio criptominerador contém o arquivo config.json com as configurações de mineração. Em outras amostras, o script OracleLoader descarta o criptominerador e define a configuração. O malware também tem um mecanismo de atualização que pode recuperar o botnet em caso de comprometimento (Tabela 1).

Tabela 1: Características do Oracle Loader

O malware também escuta na porta 999, expondo o recurso de API HTTP do XMRig. Isso permite que o invasor acesse o minerador da vítima e monitore a mineração. Se o computador da vítima estiver diretamente conectado à internet, sem a proteção de um roteador NAT (Network Address Translation, ou conversão de endereços de rede) ou de um firewall externo, é teoricamente possível identificar essas vítimas por meio de serviços de monitoramento de rede, como o Shodan. A Figura 5 mostra o resultado de uma consulta do Shodan usada para detectar possíveis vítimas.

Usando a aplicação web monitor de trabalho XMRig para monitorar os mineradores das vítimas, podemos descobrir informações sobre eles, como o modelo de CPU e a taxa de hash. Essa interface só nos permite consultar informações. Assim, embora possamos ver a atividade, não podemos controlar o minerador nem o desligar (Figura 6).

Embora existam alguns invasores altamente motivados e sofisticados com campanhas de longo prazo que obtêm enormes lucros, como o estudo de caso 1, eles não compõem a maioria das ameaças. Os criptomineradores que usam pools públicos são os mais comuns. Esses criptomineradores não têm recursos sofisticados, como técnicas de ofuscação ou antianálise. Um modus operandi típico seria entrar em contato com o pool diretamente com um endereço de carteira de texto sem formatação. Eles também geralmente têm menos impacto e lucro.

O mercado de criptomoedas oferece várias opções para os invasores escolherem, com diferentes lucratividades de mineração e valores de moeda. Apesar do aspecto financeiro inerente à criptomineração, a lucratividade da mineração de uma moeda não parece ser o mais importante para muitos invasores. A moeda Zephyr, que é menos rentável que a Monero, é muito comum entre os agentes de ameaças. A volatilidade do mercado de criptomoedas é levada em consideração tanto por invasores quanto por compradores legítimos de criptomoedas. Talvez seja o potencial de valorização no longo prazo que os leve a escolher uma criptomoeda em vez de outra.

A maior campanha da Zephyr que observamos tem mais de 1.400 vítimas ativas, com uma taxa de hash total de 800 Kh/s e um lucro total de 906,3 ZEPH, o equivalente hoje a US$ 2.528.

É possível determinar quando um invasor está direcionando ataques a regiões específicas ao analisar a taxa de hash da botnet ao longo do tempo. Um exemplo é outra campanha observada que combina proxies com malware de conexão direta, aparentemente direcionada a usuários falantes de russo (Figura 7).

Mudanças periódicas podem sugerir que a maioria das vítimas são usuários finais e não servidores, já que computadores pessoais tendem a ser desligados com mais frequência. Ao analisarmos a frequência da taxa de hash, observamos um ciclo com duração de 24 horas e, assumindo que os pontos de menor atividade ocorrem durante a noite, é possível estimar o fuso horário em que vive a maioria das vítimas (Figura 8).

Usamos o mapa da rede Monero para reunir informações sobre mais de 25 mil nós, mas apenas 10% deles eram diretamente acessíveis. Por outro lado, também usamos esse mapa para filtrar criptomineradores conhecidos que não estivessem se comunicando com a rede. Dessa forma, encontramos uma campanha que estava ativa desde abril de 2022. 

A Figura 9 mostra os vetores de ataque do malware: ele usa um proxy de mineração como o XMRig-proxy e distribui o criptominerador por um software pirateado, como o Internet Download Manager (IDM) craqueado.

O fluxo de ataque é semelhante entre as amostras de malware da campanha. Normalmente, ele começa com um ataque Drive-by-Download de crackingcity.com, que aciona uma cadeia de carga útil. Em seguida, na última etapa, ele implanta o criptominerador dlIhost.exe, que se conecta a um proxy hospedado em custompool.xyz. Como uma técnica de evasão, o invasor usa variáveis de ambiente para repassar strings como argumentos ao processo filho, principalmente arquivos em lote. Ele funciona descriptografando arquivos incorporados e executando scripts ou arquivos após manipular a lista de exclusão do defensor.

O invasor registrou o domínio do proxy como custompool.xyz em 29 de abril de 2022, apenas três dias após a primeira detecção no VirusTotal. A primeira amostra, chamada VScan.exe, é um arquivo extraído automaticamente que usa dois arquivos em lote. O primeiro é main.bat, que usa uma senha oculta nas variáveis de ambiente para extrair o arquivo em lote de segundo estágio VS.bat. Podemos extrair as informações ocultas usando um depurador de duas maneiras: quebrar quando uma variável de ambiente chamada "l3" for acessada (Figura 10) ou quebrar em cada modificação das variáveis de ambiente.

Com a senha un#912345678@rar, podemos extrair o carregador de segundo estágio que se conecta ao outro domínio C2, crackingcity.com. No estágio final, o malware executa dlIhost.exe (basicamente, um cliente XMRig modificado com configuração incorporada ao pool custompool.xyz), que, nesse ponto, é o IP direto (Figura 11).

Há uma dúvida sobre o tipo de servidor. É um pool privado? Um proxy de mineração? Ou é algum tipo de nó personalizado que consideramos o mesmo que um pool privado? Para responder a essas perguntas, precisamos conseguir extrair alguns identificadores do servidor. A mineração solo por um nó dedicado exige que o minerador opere no modo daemon, no qual a solicitação RPC é transmitida por HTTP. Como isso não ocorre nesta configuração, fica claro que esse não é o caso.

A estrutura JSON é preservada na serialização, o que nos permite tentar obter respostas do servidor enviando os vários métodos Stratum compatíveis com o XMRig-proxy. Se as respostas do servidor corresponderem à ordem das chaves e valores, essa pode ser uma indicação forte de que o servidor usa XMRig-proxy ou se baseia nele.

O XMRig é compatível com três métodos de protocolo Stratum:

1. Login: a primeira solicitação iniciada pelo trabalhador de mineração, normalmente usando a carteira como login
2. Keepalived: apenas mantém a conexão ativa
3. Submit: envia o resultado quando um compartilhamento válido é encontrado

Quando um método inválido é solicitado, o XMRig-proxy responderá com um erro (Figura 12). Isso pode ajudar a identificar o tipo de servidor, já que outros serviços, como pools, simplesmente ignoram a solicitação incorreta em vez de exibirem um erro. Todas essas informações nos levam à conclusão de que estamos lidando com o XMRig-proxy.

O proxy do protocolo Stratum opera no nível da rede encaminhando solicitações de protocolo Stratum diretamente para outro servidor sem modificar os endereços da carteira. Isso garante que o trabalho de cada minerador seja creditado na respetiva carteira. A implementação de um proxy Stratum pode ser feita por meio de um proxy de rede básico na camada de transporte ou utilizando um proxy de aplicação especializado, capaz de entender e manipular o protocolo.

Encontramos uma campanha ativa que usa essa topologia e se conecta a um pool público por um proxy Stratum. Não foi possível identificar se é um proxy reverso no nível da rede ou se ele intercepta o protocolo Stratum em si e opera como um proxy de aplicativo. De qualquer forma, ele redireciona as mensagens da Stratum para ocultar o pool ou nó de back-end. A verificação de pools públicos mostra que a carteira informada se conecta ao pool público MoneroOcean.

A campanha está ativa há pelo menos quatro meses e seu lucro total é de 1,158 XMR (aproximadamente US$ 180). Sozinha, essa não é uma campanha particularmente bem-sucedida, mas o esforço evidente do agente de ameaças sugere planos mais amplos, envolvendo o desenvolvimento completo da campanha: desde a infraestrutura até o criptominerador e os diversos arquivos maliciosos usados para implantá-lo. Os invasores também distribuem a campanha de forma independente, sem depender de terceiros, e implementam mecanismos de engenharia antirreversão, como criptografia, ofuscação e bloqueio do uso de ferramentas de monitoramento (Figura 13).