Investigação do ressurgimento da campanha do Mexals
Resumo executivo
Comentários editoriais e adicionais por Tricia Howard
A Pesquisa de Segurança da Akamai vem rastreando e analisando o ressurgimento do Mexals, uma provável campanha de cryptojacking baseada na Romênia.
A campanha está ativa desde pelo menos 2020 e foi abordada anteriormente em um relatório da Bitdefender em julho de 2021.
A mais nova onda de ataques e melhorias de malware parece ter começado em outubro de 2022. Agora eles se autonomeiam Diicot, que também é o nome da agência romena contra o terrorismo e o crime organizado.
Os pesquisadores de segurança da Akamai começaram a analisar a campanha após uma detecção de DNS mal-intencionado em um cliente da Akamai. Todos os clientes afetados da Akamai foram notificados rapidamente e as devidas contramedidas foram tomadas.
Os invasores usam uma longa cadeia de cargas úteis antes de finalmente derrubar um cryptominer Monero.
Os novos recursos incluem o uso de um módulo de worm Secure Shell Protocol (SSH), maior geração de relatórios, melhor ofuscação da carga útil e um novo módulo de distribuidor de LAN.
Analisando o pool do minerador, estimamos que os invasores extraíram moedas XMR no valor de aproximadamente US$ 10.000.
Nós fornecemos estratégias de atenuação, ferramentas de detecção e um completo repositório de indicadores de comprometimento (IOC). Também chegamos às vítimas com essas ferramentas antes do lançamento deste blog.
Introdução
Os pesquisadores de segurança da Akamai estão pesquisando uma campanha ativa de cryptojacking, que acreditamos ser um ressurgimento da campanha coberta pela Bitdefender de 2021. Embora houvesse várias correlações com o relatório original, esse malware aumentou de nível desde então.
Uma das alterações entre as duas campanhas é o nome delas: O grupo anteriormente conhecido como Mexals (veja a página deles na Figura 1) agora se chama Diicot, e uma de suas ferramentas tem o mesmo nome. Diicot também é o nome da agência romena antiterrorismo; em um esforço para evitar uma confusão, referiremos ao grupo de ameaças como Mexals. Durante a análise do modus operandi, da cadeia de carga útil e dos IOCs, ficou claro que, apesar da mudança de nome, essas duas campanhas estavam relacionadas.
Fig. 1: A página da Web padrão mostrada no domínio do invasor que também hospeda suas cargas úteis
Nesta campanha, vimos uma melhor ofuscação, nomes de arquivos mais discretos e proxies de pool de mineração personalizados que não estavam presentes na iteração anterior. A cadeia de ataque começa com a força bruta de credenciais do SSH. Em seguida, vem uma longa cadeia de cargas úteis ofuscadas, que eventualmente derruba um cryptominer XMRig. Uma das cargas úteis reduzidas é um módulo wormable que acreditamos ter estado ativo neste ressurgimento.
Também acreditamos que seus próprios servidores de ataque são hospedados em VPS com base na Holanda, e suas vítimas estão espalhadas por todo o mundo. Estimamos que os invasores conseguiram extrair mais de US$ 10.000 em moedas XMR.
Alguns hackers têm um kit de ferramentas. Essas pessoas parecem ter uma rede
Encontramos oito executáveis em nossa análise da rede de infecção dos invasores. Esses executáveis não parecem diferir muito do que foi visto pela Bitdefender, exceto pelos nomes de arquivos e caminhos e alguns novos recursos (Figura 2).
Nome da carga útil |
Uso |
|---|---|
História |
Um script bash. Verifica se Atualizar está em execução. Executa-a se não estiver. |
Atualizar |
Uma script bash compilado. Notifica os invasores por meio de um webhook do Discord e executa uma verificação de rede em uma rede IP de classe B aleatória para máquinas com SSH aberto. Fornece os resultados para aliases. |
Chrome/ps |
Um scanner de rede. Aceita um intervalo de rede classe B (255.255.0.0) e uma porta. Verifica o intervalo de rede de máquinas com essa porta aberta e salva os resultados em um arquivo. |
Um módulo de worm SSH escrito em Golang. Executa carga útil. |
|
O principal módulo pós-violação. Com base nos recursos disponíveis para a vítima, ele instala um backdoor, um cryptominer ou um worm LAN SSH. |
|
.diicot |
Um script bash compilado. Baixa Opera, um cryptominer. Também instala outra backdoor na forma de um novo usuário e chave SSH. |
Opera |
Um cryptominer XMRig. |
Um script bash compilado. É o início do módulo do distribuidor de LAN. Executa um scanner de porta SSH no intervalo de IP da LAN interna e, em seguida, chama a rede para tentar violar máquinas com SSH. |
|
Rede |
Outra variante de aliases com menos recursos. Executa um ataque de dicionário SSH na LAN local, salva informações em máquinas danificadas (e as credenciais de trabalho) em um arquivo de texto. |
Fig. 2: Um resumo das diferentes cargas úteis empregadas pelos invasores
Geração binária e ofuscação
A mudança mais significativa que vimos é a ofuscação da carga útil. Anteriormente, a maioria das cargas úteis executáveis era, na verdade, scripts bash que eram compilados com shc, mas agora esses scripts bash compilados também foram compactados com UPX, e o cabeçalho UPX foi removido para impedir a análise e a descompactação (Figura 3).
Fig. 3: Um executável compactado não pode ser descompactado pelo UPX devido a um cabeçalho removido
Felizmente, podemos contar com uma ferramenta criada pelo pesquisador da Akamai, Larry CashDollar, como parte de um alerta de SIRT anterior. Isso nos permitiu restaurar facilmente o cabeçalho UPX, descompactar os executáveis ELF e extrair os scripts bash contidos nele.
Depois, ficamos com um binário totalmente desmontado e estaticamente compilado, sem uma maneira de distinguir entre o código do malware e o código do glibc (Figura 4).
Fig. 4: O ponto de entrada do binário removido
Podemos contar com o código-fonte do glibc para entender como é o ponto de entrada. A função principal real é a função carregada no rdi. Em uma análise, podemos encontrar uma string de erro bem específica: E: neither argv[0] nor $_ works., que podemos pesquisar na Web. Como resultado, temos shc. Infelizmente, não há descompilação facilmente disponível. Em vez de fazer engenharia reversa e criar um descriptografador, o que seria muito complicado, podemos depurar a carga e pausar a execução após um segundo. O script de shell descriptografado residirá na memória do malware, que podemos descarregar e analisar.
Rede de infecção
Fig. 5: A cadeia de carga útil completa
Cada cadeia de carga útil se une de forma relativamente simples, com vários métodos de configuração do próximo link. Por exemplo, eliminar mineradores concorrentes ou processos pesados de CPU, limpar o histórico do bash ou instalar persistência e, em seguida, baixar e executar a próxima carga útil (Figura 5).
Análise técnica de cargas úteis principais
aliases
Este é um binário de Golang, que não foi removido para que pudéssemos encontrar facilmente toda a lógica do malware. O malware lê dois arquivos, que foram criados nas etapas anteriores – protocolos (lista de palavras de senha de usuário eliminada por Atualizar) e bios.txt (lista de IP de destino de máquinas com SSH aberto, criada por Chrome). Em seguida, ele executa um ataque de dicionário em cada destino e, após a autenticação bem-sucedida, executa carga útil e outros comandos para traçar o perfil do sistema violado.
O último comando a ser executado é uname -s -v -n -r -m, e sua saída é analisada. Especificamente, ele procura nomes de SO dentro dessa saída que possam indicar destinos interessantes. Para a maioria dos nomes de SO que ele procura, ele não faz nada, mas se a máquina de destino estiver executando OpenWrt, ele executa outro comando bash nele para baixar e executar outro script shell do 107.182.129.219, o que deixaria cair alguma variante do Mirai. Pensamos que o foco no OpenWrt é porque ele está instalado em dispositivos incorporados e pode servir como um vetor de acesso inicial às redes organizacionais. Com isso, os invasores mostram que estão interessados em mais do que apenas outra campanha de criptografia e estão procurando ativamente por novas pastagens.
Depois que o malware termina sua tentativa de violação, ele se reporta aos invasores por meio de um webhook do Discord (uma prática de ataque que está ganhando popularidade). Existem quatro webhooks diferentes, com finalidades diferentes (Figura 6).
Fig. 6: Uma interceptação dos webhooks do Discord chamados pelo malware
O primeiro webhook é de uma função chamada toDiscord, e isso relega os resultados dos vários comandos de perfilamento executados na máquina de destino. Os nomes dos próximos dois tem origem nas funções toAPIlogs e toDisc, e ambos relegam as mesmas informações – o IP do destino e o usuário e a senha que podem se autenticar com ele.
Finalmente, se a vítima estava executando o OpenWrt, o nome da outra função é toMirai, e envia as mesmas informações para outro webhook. Há alguma redundância aqui, que presumimos ser para os invasores rastrearem diferentes métricas mais facilmente, ou pode servir como uma separação para diferentes partes de sua campanha de ataque (Mirai como um botnet/IAB versus o uso regular do Mirai como um cryptominer).
carga útil
Embora seja "apenas" um script bash compilado, carga útil é interessante porque está repleta de comentários e mensagens de progresso, que podem nos ensinar sobre os processos de pensamento dos operadores de malware.
Os comentários e as mensagens de progresso estão em romeno, o que reforça a suposição de que os invasores são romenos (o domínio de comando e controle/download do malware literalmente se traduz em "arquivo do hacker").
O script também verifica a presença de outros cryptominers conhecidos e elimina seus processos, entre eles dhpcd e ksmdx. Isso mostra que os invasores estão cientes de seu ecossistema e não estão apenas tentando a sorte no mundo da criptomineração.
Depois de eliminar os concorrentes e outros processos pesados de CPU, o script verifica quantos núcleos de CPU a máquina tem – se tiver menos de quatro, ele instala Histórico e Atualização e um trabalho cron para eles. (Os dois executáveis são responsáveis pelo download de aliases de carga útil e estão programados para execução em uma reinicialização da máquina vítima.) Se houver quatro ou mais núcleos, o script também baixa e executa o .diicot, um script bash compilado que baixa e executa um cryptominer XMRig.
Por fim, se houver oito ou mais núcleos de CPU, o script baixa e executa o retea, o distribuidor de LAN.
retea
O módulo do distribuidor de LAN apresenta um novo recurso na rede de invasores. É outro script de shell compilado, que extrai todos os usuários configurados no sistema e cria um arquivo chamado .usrs. O arquivo é usado para um ataque de dicionário SSH e é preenchido usando os usuários extraídos e uma lista de senhas padrão codificada. Em seguida, ele baixa e executa um scanner de rede na rede LAN, que detecta máquinas com portas SSH abertas e grava a saída em um arquivo. Em seguida, ele baixa e executa Rede, que é uma versão menor de aliases, com menos recursos. Em vez de instalar uma carga mal-intencionada ou relatar um webhook Discord, ele simplesmente salva a saída das máquinas violadas em um arquivo, que pode ser posteriormente captado pelos invasores.
Conheça as vítimas
Ou será que são?
Como os invasores têm uma carga útil wormable, é difícil distinguir qual IP de origem capturado em nossos sensores de ameaça é a infraestrutura do invasor – e qual é uma vítima. Nesta seção, tentaremos dissecar a infraestrutura do invasor e encontrar vítimas reais.
Extraímos todos os IPs invasores que detectamos (50 endereços IP exclusivos) e os mapeamos geograficamente para sua localização geográfica no mundo. Além dos IPs invasores, também encontramos evidências de infecção em alguns dos clientes da Akamai, portanto, eles também foram incluídos em nossa lista de vítimas. A distribuição geográfica das vítimas/infraestruturas é mostrada na Figura 7.
Fig. 7: Mapa-múndi com geolocalização de IPs invasores
Embora a maioria dos locais mostre pouca atividade, temos alguns focos na Europa Ocidental. O pico na atividade lá (Figura 8) nos leva à hipótese de que o foco são, na verdade, máquinas controladas por invasores, enquanto o restante são máquinas vítimas assumidas pelo módulo wormable. Parece que o módulo wormable não está particularmente ativo, pois vemos muito poucas máquinas ativas ao mesmo tempo. Isso faz sentido, porque o aliases é executado apenas uma vez por execução de trabalho cron, em uma classe B aleatória. O cron está programado para ser executado na reinicialização da máquina, o que provavelmente acontece com pouca frequência, dada a natureza das máquinas vítimas (ou seja, servidores Linux abertos à Internet).
Fig. 8: Número de IPs que atacam nossos sensores de ameaça simultaneamente ao longo do tempo
Analisando os endereços IP que mais registraram em nossos honeypots, que supomos serem infraestrutura de invasor, podemos ver uma distribuição clara de hosts (Figura 9). Endereços IP mais antigos eram hospedados no DigitalOcean. Endereços mais novos (do recente ressurgimento) parecem ter sido hospedados no Serverion, um VPS e um provedor de hospedagem na Web da Holanda (seu ASN está realmente registrado em sua empresa-mãe, Des Capital B.V., uma agência imobiliária, que nos confundiu inicialmente).
Data do ataque |
Contagem de ataques |
IP do invasor |
Nome da organização de hospedagem |
|---|---|---|---|
2023-02-01 |
14 |
185.225.74.231 |
Des Capital B.V. |
2022-10-01 |
72 |
45.139.105.222 |
Des Capital B.V. |
2022-10-01 |
62 |
212.193.30.11 |
Des Capital B.V. |
2022-03-01 |
22 |
195.133.40.157 |
Des Capital B.V. |
2021-12-01 |
43 |
134.209.95.47 |
DigitalOcean, LLC (DO-13) |
2021-12-01 |
37 |
134.209.195.231 |
DigitalOcean, LLC (DO-13) |
2021-12-01 |
34 |
104.248.85.104 |
DigitalOcean, LLC (DO-13) |
2021-12-01 |
27 |
134.209.198.229 |
DigitalOcean, LLC (DO-13) |
2021-12-01 |
27 |
167.71.48.128 |
DigitalOcean, LLC (DO-13) |
2021-12-01 |
74 |
188.166.60.8 |
DigitalOcean, LLC |
Fig. 9: Os principais IPs de ataque, que presumimos serem a infraestrutura do invasor, não apenas das vítimas
Antes do lançamento desta publicação no blog, chegamos aos clientes afetados da Akamai com informações sobre os ataques, bem como aos e-mails abusados registrados para cada endereço IP de ataque.
O que acha de me dar dinheiro lá fora?
Parece que os invasores mudaram sua configuração de mineração desde a campanha anterior. No passado, eles apontaram seus mineradores para trabalhar com supportxmr.com diretamente, mas os mineradores que analisamos recentemente se comunicam com endereços IP que provavelmente estão no controle dos invasores. Temíamos que esses fossem pools privados, o que significaria que não conseguiríamos acompanhar os pagamentos, mas nossos medos não foram fundados – supportxmr ainda rastreou os pagamentos de mineração para a carteira, portanto, presumimos que seus servidores sejam apenas proxies para o pool hospedado pelo supportxmr. Essa pode ser uma maneira de evitar o bloqueio e a detecção de DNS não alcançando diretamente o pool.
Conseguimos extrair dois endereços de carteira diferentes das cargas úteis do XMRig que vimos durante a investigação da campanha. Esses endereços de carteira são diferentes daqueles vistos pela Bitdefender, mas de acordo com seu histórico de pagamento, eles parecem ter sido ativos durante esse tempo também.
Podemos ver que os montantes dos pagamentos variavam muito antes de novembro de 2021 (até atingindo duas vezes um XMR completo), mas tornaram-se muito mais frequentes e consistentes depois (Figura 10). Isso pode ser devido a uma alteração no esquema de pagamento ou devido à adição de mais mineradores, o tempo corresponde a outros picos de atividade de malware que detectamos.
Fig. 10: O histórico de pagamentos de mineração para a carteira dos invasores, extraído do supportxmr
Ao todo, estimamos que os invasores conseguiram extrair o XMR que vale mais de US$ 10.000 durante toda a campanha, com mais de 75% sendo minerado desde seu ressurgimento. A quantia real minerada provavelmente é ainda maior do que a nossa estimativa, julgando pela contagem exclusiva de trabalhadores relatada pelo supportxmr, vimos apenas metade das cargas úteis e configurações do XMRig (Figura 11).
Fig. 11: Os mineradores associados a uma das carteiras dos invasores
Resumo
A cadeia de carga útil empregada pelos agentes de ameaça é certamente impressionante e fala de um agente de ameaças bastante sofisticado. Normalmente, também não vemos uma cadeia tão longa de cargas úteis e acreditamos que existem alguns motivos pelos quais os invasores optaram por usar tantas cargas úteis.
Ofuscação – quanto mais peças móveis no sistema, mais difícil é analisá-las e acompanhá-las. O fato de os binários serem ofuscados apenas reforça essa hipótese.
Há várias pessoas por trás do grupo de ameaças. Embora não tenhamos informações reais sobre os agentes de ameaça por trás da campanha, vimos diferenças de código notáveis entre diferentes amostras dos mesmos scripts, que só podemos atribuir ao fato de terem sido desenvolvidos por pessoas diferentes.
A campanha de malware foi criada para evoluir ao longo do tempo. Vemos evidências disso nos novos recursos e na ofuscação adicional que foram adicionados, bem como em algumas redundâncias no código que foram criadas como base para uso futuro.
Melhorias e adições de sua operação anterior
Compactação UPX e remoção da plataforma UPX.
Recurso de atualização automática movido de dentro da carga útil para scripts externos (Histórico e Atualização.)
Nomes de arquivo mais discretos (Chrome, Opera – mimetizando navegadores)
Relatórios adicionais de malware sobre o Discord
OpenWRT comportamento específico (e provavelmente mais surgirão)
Uso de proxies de pool de mineração personalizados em vez de pools públicos
Arquivo do Defender
Proteção do perímetro e da rede
O malware não tem nenhuma técnica nova ou sofisticada para se distribuir. Ele simplesmente usa um ataque de dicionário no SSH. Como tal, apenas as máquinas que estão abertas para SSH a partir da Internet estão em risco. Bloquear o SSH no perímetro da rede ou movê-lo para trás de uma VPN pode reduzir consideravelmente os riscos que esses ataques representam.
Além disso, o uso de credenciais não padrão ou senhas complicadas reduz significativamente o risco de um ataque de dicionário, como aquele empregado por esse malware. Também recomendamos o uso de chaves SSH para autenticação, pois elas são ainda mais seguras do que senhas (elas são impossíveis de adivinhar, e o "segredo" nunca é transmitido pela conexão).
Por fim, também precisamos considerar o módulo do distribuidor de LAN. Como ele também está usando SSH para movimento lateral, segmentar sua rede pode atenuar esse risco com segurança. Se considerarmos servidores abertos à Internet como a zona desmilitarizada (DMZ), então impedir o tráfego SSH (e geralmente outro tráfego que pode ser usado para movimento lateral, como RDP, MS-RPC ou WinRM) da DMZ para o restante da rede é a coisa lógica a fazer. Se, por algum motivo, você precisar de um desses servidores para ter acesso SSH à rede interna (por servir como um jumbox, por exemplo), movê-lo para fora da DMZ e sob a VPN deve ser o método preferido. Apenas não exponha os servidores à Internet e permita que os invasores saltem dela internamente – reduza o raio de explosão e os caminhos de propagação.
Detecção de infecções
Criamos um Repositório do GitHub para ferramentas que podem ajudá-lo a detectar infecções dessa campanha mal-intencionada. Lá, você encontrará um script bash, uma lista completa de consultas de IOCs e consultas OSQuery que os clientes da Akamai Guardicore Segmentation podem usar. Você também pode encontrar o script de detecção e uma Lista parcial de IOCs no final desta postagem.
Além dessas ferramentas, também gostaríamos de recomendar uma maneira geral de detectar cryptominers que pode ser aplicada nesse caso, detectando o tráfego de saída para os pools de mineração olhando para a porta de destino. Às vezes, as portas padrão para pools de mineração são bastante exclusivas, portanto, manter-se atento a elas pode ser benéfico. Por exemplo:
A porta TCP 4242 é a porta padrão para essa implementação de pool
As portas TCP 3333, 5555, 7777, 9000 são as portas padrão na implementação de pool nodejs
É claro que os mineradores também podem se comunicar com seu pool via HTTP e HTTPS, caso em que a detecção seria muito mais difícil. Ainda assim, vale a pena procurar essas portas.
Script de detecção
O script de detecção procura vários IoCs que podem indicar a presença passada ou atual da campanha de ataque. Ele procura artefatos no crontab, seus caminhos de arquivo, bem como processos em execução e o backdoor da chave SSH maliciosa. Para executá-lo, basta baixá-lo na máquina que deseja verificar e executá-lo. Ele digitalizaria a máquina e imprimiria seu veredito:
Figura 12: Executando o script de detecção para procurar artefatos do Mexals.
Indicadores de comprometimento
Esta é uma lista parcial de IOCs. A lista completa está disponível em nosso Repositório do GitHub.
Caminhos
/var/tmp/.update-logs/
/var/tmp/Documents/
/var/tmp/.ladyg0g0/
/dev/shm/.x/
/dev/shm/.magic/
Nomes de arquivos
protocolos
bios.txt
Atualizar
História
aliases
carga útil
retea
.usrs
IPs
107.182.129.219
45139105222
185.225.74.231
212.193.30.11
Domínios e URIs
arhivehaceru[.]com
discord[.]com/api/webhooks/954295081765072926/Zu7Vu-LpfgRqSmCyFvz3BCkR1Lt7clYOJeayCFzZwtPmZlVn9og_6mPS_BJY-374m5Y3
discord[.]com/api/webhooks/1036206037373571082/9bs01KrT-TrcbSAPI_i-adV1Bhn56A4X4fxzCYEw3zMq95H1mFvlKWb6-KYzvEoVfTnS
discord[.]com/api/webhooks/1036205058456563722/1_saZM0fE7nLgYG668LmDfNmSvrWpD-6Z8nIXljm0qlm6YyMxAyYuZIu4LhN2gHsgSQy
discord[.]com/api/webhooks/965651135102865479/PFdU4u8yZrn0XhzIKShcaxL3_IaBjsstYmFEXlThF2_1XCnwXSAjKos3ptwKYpPyGqvI
discord[.]com/api/webhooks/848592916951203860/WeWBGYSVreTlE0aO_6alVN3Qrj6_aRxnaDpq4_6wD04V2aHlMFvgik2Z2h78Dstg9fZY
discord[.]com/api/webhooks/1036225255049531422/qyOrT3SxHaOC-9yS2NQiPxlSMYmRFFIpU-rMKzmcDv9pQyP4uaZEiZXDXioUtf0DJLUB
