Anatomia dos criptomineradores: análise dos criptomineradores
Resumo executivo
Esta é a segunda parte da nossa série de publicações de três partes chamada Anatomia dos criptomineradores. Nesta primeira parte, discutimos criptomoedas em geral, os vários atributos delas o que torna algumas mais atraentes do que outras para agentes de ameaças.
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 longa e persistente campanha 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 de mineração e pode ser aplicada no nível da rede ou do sistema operacional.
Análise da rede Monero
A rede Monero é criada usando o protocolo Levin para implementar a comunicação P2P (peer-to-peer, ponto a ponto) pelos nós de rede. A rede usa o protocolo para distribuir operações de blockchain, como novas transações e novos blocos. O protocolo também permite que a rede seja autossustentável de forma descentralizada, graças à publicação de nós de pares e a capacidade de eliminar ataques com algoritmos de consenso.
Embora tenhamos usado a Monero como exemplo, a descoberta de rede de um blockchain deve ser possível na maioria das criptomoedas. Isso se deve à natureza distribuída das redes blockchain, e mais detalhes podem ser encontrados em nosso blog anterior.
Descoberta de rede
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.
Fig. 1: A graphical mapping of the Monero network (as of March 2025)
Como a rede é feita de nós de pares distribuídos, qualquer criptominerador deve interagir, de forma direta ou indireta, com um dos cerca de 30 mil servidores do mundo que podem ser encontrados em nosso mapa. Como veremos, o mapa se revelou muito valioso para a busca de amostras de criptomineradores, bem como para a detecção de conexões diretas de rede com os blockchains. (Você encontra mais informações em nosso repositório do GitHub, incluindo o código-fonte para rastreamento de blockchain e geração de mapas.)
Referência cruzada entre criptomineradores e a rede
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 arquivos que contêm endereços de nó conhecidos, o que nos ajudará a detectar campanhas ativas de criptomineradores (Figura 2).
Fig. 2: An example of a VirusTotal Livehunt YARA rule
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, servindo como um espelho do repositório PyPi de Python ou qualquer outro serviço. 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.
Fig. 3: Example of a node in the Monero network that serves multiple services (VirusTotal)
A qualificação de amostras irrelevantes é tão importante na busca de ameaças quanto a qualificação de amostras relevantes. A análise de rede, quando combinada com uma abordagem de correlação cruzada, pode expor criptomineradores e até campanhas inteiras de mineração orquestradas por botnets. Ao aplicar técnicas adicionais de análise estática, como a correspondência de endereços de carteira codificados, podemos nos concentrar de forma eficiente nas amostras mal-intencionadas mais relevantes.
Análise de amostras de criptomineradores
Devido à natureza ruidosa da criptomineração, pode ser fácil detectar o funcionamento dela mesmo a "olho nu". Um profissional de TI atento pode detectar as anomalias geradas por criptomineradores sem a necessidade de ferramentas antimalware sofisticadas. Mesmo usuários sem conhecimentos técnicos geralmente reconhecem o desempenho habitual de seus computadores e, caso percebam uma lentidão incomum, tendem a procurar um profissional, que provavelmente identificará facilmente a causa raiz do problema. Por isso, muitos criptomineradores não se preocupam em proteger o malware contra análise e detecção, mas seguem uma estratégia de infeção em massa não direcionada.
Nos estudos de caso a seguir, abordaremos algumas das amostras de criptomineradores que identificamos e examinaremos alguns dos detalhes mais interessantes sobre a operação e o comportamento deles. Dois fatores principais foram usados para encontrar esses estudos de caso: (1) uma moeda relevante, conforme descrito na primeira publicação do blog nesta série, e (2) a topologia de mineração que eles exploram.
Estudo de caso 1: Uma campanha persistente e massiva
Como parte desta pesquisa, analisamos diversas amostras de criptomineradores, uma delas uma campanha de 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 revela que ela tem vários proxies que se acumulam a 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.
Fig. 4: The campaign’s Nanopool dashboard reveals the total hashrate
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 por ano de 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 ela usa o PowerShell para implantar um arquivo executável chamado loader de uma forma 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 , no qual está a configuração 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).
Característica |
Valor |
Observação |
|---|---|---|
Nome do malware |
Oracle Loader |
|
Versão atual |
1.1.72.0 |
<5.133.65.53>/Oracle/ver$77_loader.exe.txt |
Componentes relacionados |
|
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 o processo de 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.
Fig. 5: Shodan results for potential victims (Source: http://shodan.io)
Usando o aplicativo web do monitor de trabalho XMRig para monitorar os mineradores das vítimas, podemos revelar informações sobre elas, como modelo de CPU e 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).
Fig. 6: Remote access to the victim machine using the worker monitor
Como podemos ver no painel de pool de mineração, a taxa constante de hash sugere que as vítimas estão em todo o mundo. Caso contrário, esperaríamos uma taxa de hash alternada com base nas horas ativas do fuso horário. Outra explicação pode ser que o invasor esteja direcionando servidores, e não consumidores, como outras campanhas de criptomineradores fazem.
Estudo de caso 2: Topologia de pool público usada por um criptominerador de Zephyr
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 da criptomineração, a lucratividade da mineração de uma moeda não parece ser a consideraçã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. Pode ser o possível valor a longo prazo que os atraia para uma criptomoeda em detrimento da outra.
A maior campanha da Zephyr que vimos tem mais de 1.400 vítimas ativas com uma taxa de hash total de 800 Kh/s e lucro total de 906,3 ZEPH, que é atualmente igual 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 disso está em outra campanha observada. A campanha usa proxies combinados com malware de conexão direta que parecem estar direcionados a usuários falantes de russo (Figura 7).
Fig. 7: Cryptominer hashrate graph over time (Source: https://zephyr.hashvault.pro/en/)
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).
Fig. 8: Time zone map identifies the location of the majority of the victims (Source: https://www.timeanddate.com/time/map/)
Os intervalos de tempo, por si só, não constituem evidência suficiente para determinar a localização da vítima; no entanto, nossa hipótese foi corroborada pelo recurso de geolocalização de IPs disponibilizado pelo pool Hashvault. Ao combiná-lo com a análise de malware e os nomes de entrega de malware relacionados a jogos, como Fortnite, Solara executor para Roblox e outros, podemos chegar a uma suposição mais sólida: o malware está fingindo ser um mecanismo de trapaça, tentando os jogadores a encontrá-lo. Também suspeitamos que ele se espalhe em redes sociais e aplicativos de mensagens, como Telegram e Discord.
Estudo de caso 3: Criptominerador usando uma topologia de proxy de mineração
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. Inversamente, também usamos esse mapa para filtrar qualquer criptominerador conhecido que não estivesse entrando em contato com a rede, que é como encontramos uma campanha 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.
Fig. 9: Visualization of cryptominer using a cracked program for initial access
O fluxo de ataque é semelhante entre as amostras de malware da campanha. Normalmente, ele começa com um download drive-by de crackingcity.com, que inicia 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. O invasor usa variáveis de ambiente para passar strings como argumentos ao processo filho, principalmente arquivos em lote, como uma técnica de evasão. 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 proxy com o nome 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 autoextraído 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.
Fig. 10: Dynamic analysis reveals the encrypted compression password
Usando 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).
Fig. 11: Intercepting configuration data through static analysis
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 nó dedicado requer que o minerador opere no modo daemon (no qual a solicitação RPC é transmitida por HTTP), que não está presente nessa configuração, portanto, esse claramente 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:
- Login : a primeira solicitação iniciada pelo trabalhador de mineração, que geralmente contém a carteira como o login
- Keepalived : apenas mantém a conexão ativa
- Submit : envia o resultado quando um compartilhamento válido for encontrado
Quando um método inválido é solicitado, o XMRig-proxy responderá com um erro (Figura 12). Isso pode ser indicativo do tipo de servidor, porque outros serviços, como pools, simplesmente ignoram a solicitação incorreta, em vez exibirem um erro. Todas essas informações nos levam à conclusão de que estamos lidando com o XMRig-proxy.
Fig. 12: XMRig-proxy response as baseline
Dividimos o método de envio em três casos que devem retornar erros explícitos de um proxy XMRig (Tabela 2).
Um compartilhamento de baixa dificuldade é quando o minerador envia um hash com um valor inferior ao esperado.
Um nonce inválido é o resultado de nonce fora do intervalo de acordo com o design de nicebash.
Um hash de dificuldade máxima é o hash especialmente criado que provavelmente satisfará o destino de qualquer trabalho. Com esse caso, estamos ignorando a validação de dificuldade do proxy XMRig e transmitindo diretamente para o pool, o que retorna o erro do pool.
Solicitação |
XMRig-proxy |
MoneroOcean |
HashVault |
Nanopool |
SupportXMR |
C3Pool |
Login |
(linha de base) |
✕ |
✕ |
✕ |
✕ |
✕ |
Keepalived |
(linha de base) |
≈ |
✅ |
≈ |
✕ |
≈ |
Desconhecido |
(linha de base) |
✕ |
✕ |
✕ |
✕ |
✕ |
Enviar – baixa dificuldade |
(linha de base) |
✕ |
✕ |
✕ |
✕ |
✕ |
Enviar – nonce inválido |
(linha de base) |
NA – IP bloqueado |
✕ |
✕ |
✕ |
✕ |
Enviar – máxima dificuldade |
Repita a mensagem de resposta do pool |
NA – IP bloqueado |
✅ |
✕ |
✅ |
✅ |
Tabela 2: Comparação das solicitações de protocolo da Stratum entre o XMRig-proxy e vários pools públicos: ✅ denota o mesmo que a linha de base, ✕ denota dados diferentes e ≈ denota a mesma ordem de dados diferentes
Não só podemos distinguir o XMRig-proxy dos pools comumente usados, mas também podemos distinguir entre os próprios pools. Essas informações podem ser úteis quando roteamos para um pool por outros componentes de rede, como proxy reverso. Nesse caso, quando enviamos resultados de mineração com o máximo de dificuldade, obtemos o erro do pool de back-end em vez do proxy. Ao usar essas informações, podemos identificar que o invasor usa NanoPool, mas como não temos o endereço da carteira, não podemos obter uma avaliação da contagem de vítimas nem o lucro dessa campanha.
Estudo de caso 4: Comunicação oculta de blockchain usando uma topologia de proxy da Stratum
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 para a carteira fornecida revela que ela entra em contato com o 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).
Fig. 13: Persistent cryptominer uses Stratum proxy to hide the back-end pool
Embora a campanha possa ser preguiçosa, podemos ver uma execução cuidadosa do malware, principalmente no processo de ofuscação. O malware tenta ocultar a carga baixando um arquivo durante o tempo de execução e rodando processos com nomes de arquivos legítimos do sistema.
Detecções
Há vários caminhos diferentes que você pode seguir quando se trata de detecções em geral. Cada método pode não ser suficiente sozinho, mas será usado em conjunto com outros mecanismos de detecção. Os criptomineradores não são uma exceção; na verdade, eles podem ser partes difíceis de malware para detectar por causa de suas caraterísticas benignas. Eles usam a única coisa que não requer uma permissão especial na maioria dos sistemas operacionais: computação (tempo da CPU).
Conexões com a rede
Para detectar esses mineradores, podemos fazer referência cruzada com a rede blockchain (como a rede Monero que usamos anteriormente) com os dados que obtemos de uma ferramenta de visibilidade de rede, como uma solução de firewall ou segmentação. Como cada nó ou pool precisa se comunicar com o blockchain do Monero, isso oferece aos administradores de rede informações valiosas sobre o tráfego que está sendo gerado e saindo da rede. Quando somado a portas de rede, isso torna a detecção muito mais fácil, uma vez que a maioria dos criptomineradores usa números de porta distintos, como 999, 3333 ou 7777. Embora a Monero seja usada neste estudo de caso, o mapeamento de rede blockchain pode ser usado em todas as redes baseadas em PoW (proof-of-work, prova de trabalho).
É importante observar, no entanto, que nem todo o tráfego direcionado para os nós Monero está necessariamente relacionado à criptomineração, uma vez que esses nós às vezes oferecem mais de um serviço. Por exemplo, IP 157[.]90[.]212[.]53 encontra-se no nosso mapa de rede Monero, mas também é um nó de saída para a rede Tor. Há várias possíveis explicações para o fato de um nó Monero oferecer outros serviços: ele pode estar comprometido ou, simplesmente, ter sido configurado intencionalmente para ser multifuncional. De qualquer forma, usar a conexão com a rede sem informações adicionais pode ser uma indicação fraca de conexão com o blockchain e gerar falso-positivos. Esse é outro motivo pelo qual as informações do número da porta são cruciais para obter detecções precisas.
Outro motivo para falso-positivos pode ser uma baixa taxa de atualização do mapa. Um servidor legítimo pode ser atribuído a um endereço IP que foi usado anteriormente por um nó Monero e causar um falso positivo se o mapa não estiver atualizado.
Esta detecção não é suficiente sozinha, mas pode ser usada como um gatilho para uma lógica de detecção ou investigação mais abrangente. Qualquer operação do criptominerador deve incluir a comunicação com um servidor Stratum para uma atribuição de tarefa de mineração. Geralmente, ele opera com pools de mineração conhecidos publicamente, mas em alguns casos, isso pode ser oculto usando um proxy, que não aparecerá no mapa de rede.
Detecção de execução de algoritmo
Os criptomineradores usam intensamente os recursos de computação da vítima, portanto, monitorar picos de uso no sistema pode indicar uma infeção. Porém, assim como na referência cruzada do mapa de rede, essa sozinha não é uma detecção precisa.
A combinação de vários IOCs detectáveis aumentará a taxa de confiança de detecção, ou seja, reduzirá falso-positivos. Para que uma operação de mineração seja bem-sucedida, existem contrapartes essenciais. Os criptomineradores devem minar a moeda escolhida usando o algoritmo de consenso como prova do trabalho. Cada algoritmo desse tipo deixa uma impressão digital única no sistema durante sua execução, e a extração dessas características pode servir como base para um método robusto de detecção de criptomineradores mal-intencionados.
Algoritmos resistentes a ASIC, como RandomX, geralmente implementam um conjunto complexo de operações que podem ser identificadas exclusivamente. Por exemplo, o desenvolvedor do RandomX criou uma ferramenta de detecção com base exatamente nessa suposição. Ao iterar as threads em execução no sistema, podemos sondar o estado da thread, incluindo os valores dos registros da CPU. Como o RandomX é implementado usando muitos dos modernos recursos de CPUs, usar as configurações do Rounding Control como na ferramenta de detecção pelo desenvolvedor do RandomX é uma maneira de fazer isso.
Na verdade, combiná-lo com outros indicadores, como operações AES de hardware e configuração de hugepage , melhorará a taxa de detecção. Em resumo, a detecção pode ser obtida procurando chaves AES exclusivas nos registros SSE ou consultando os privilégios de token de acesso da thread, respectivamente.
Também podemos estender esses métodos a outros sistemas operacionais, porque a maioria dos criptomineradores tem como objetivo ser independente de plataforma e deve se comportar da mesma maneira, mesmo em diferentes sistemas operacionais. Não ser colocada em um sistema operacional permite que uma campanha seja potencialmente mais bem-sucedida, pois os números-alvo aumentam drasticamente dessa forma.
Localização da carteira na memória do processo
Quando os criptomineradores se comunicam diretamente com o pool de mineração em vez de por um proxy, a carteira do minerador deve residir na memória do processo. Isso ocorre porque o protocolo Stratum requer que o minerador autentique o servidor e informe qual conta deve ser recompensada em envios de compartilhamento válidos. Normalmente, ele usará um endereço de carteira e, para a mineração Monero, especificamente, o minerador provavelmente será baseado no software XMRig. Com base nessas suposições, podemos localizar e interceptar a carteira no momento em que ela é enviada ao pool por meio da conexão com diversas APIs de soquete ou, teoricamente, aplicar um ataque do tipo MITM (machine-in-the-middle, ou máquina no meio) para capturar a mensagem de autenticação transmitida pelo minerador.
Também podemos usar uma pesquisa Regex simples sobre toda a memória alocada do processo para encontrar o endereço de carteira de 95 caracteres, como isso segue um formato estrito. Ele começa com 4 ou 8 e consiste em BASE58 caracteres válidos. Então, o padrão /[48][1-9A-HJ-NP-Za-km-z]{94}/ Pode ser suficiente para essa tarefa e também pode ser incorporado a uma regra YARA. A verificação pode ser feita a qualquer momento após a primeira conexão do criptominerador com o pool, já que o minerador precisa manter o endereço da carteira acessível para possíveis reconexões..
Finalmente, podemos usar qualquer uma das técnicas mencionadas para encontrar outras strings relacionadas ao protocolo Stratum e analisar a carteira de dentro. Esses indicadores podem diminuir falso-positivos, pois a estrutura JSON do protocolo é muito mais exclusiva. Por exemplo, veja a solicitação de login na Figura 14; podemos criar uma assinatura mais forte que contenha várias chaves para obter uma detecção mais precisa.
{
"id": 1,
"jsonrpc": "2.0",
"method": "login",
"params": {
"login": "<wallet address>",
"pass": "<Usually the worker name>",
"agent": "<Usually xmrig agent>",
"algo": [
"rx/0"
]
}
}
Fig. 14: Um exemplo de solicitação de login: a correspondência do padrão pode assegurar uma detecção mais precisa
Conclusões
Os pesquisadores da Akamai continuarão a expor campanhas mal-intencionadas e os respectivos agentes de ameaça, além de identificar IOCs com o objetivo de proteger nossos clientes e o público em geral.
Nesta segunda parte da nossa série de três publicações sobre criptomineradores, apresentamos diversas técnicas para revelar informações mais detalhadas sobre várias campanhas, como a identificação de um pool de mineração oculto por trás de um proxy ou a localização geográfica da operação, por meio da análise da taxa de hash da botnet do criptominerador ao longo do tempo, entre outras abordagens.
Vimos criptomineradores mal-intencionados que usavam Zephyr ao lado da famosa Monero. Usando as diferentes topologias de mineração, os criptomineradores conseguiram ocultar informações e minimizar o número de identificações e indicadores comprometedores.
Depois de perceber a anatomia dos diferentes criptomineradores e o processo de mineração, em geral, foi levantada uma pergunta: Podemos interromper a operação de mineração do botnet do criptominerador? Parar a operação de mineração de modo eficaz desligará os criptomineradores que infetam os computadores das vítimas e consumem os recursos deles. Exploraremos essa pergunta na última parte da nossa série.
Para acompanhar esta série e outras inovadoras pesquisa sobre segurança, confira nossa página de pesquisa de segurança e siga-nos nas redes sociais.
Indicadores de comprometimento
