Investigação do ressurgimento da campanha do Mexals

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.

Fig. 2: Um resumo das diferentes cargas úteis empregadas pelos invasores

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.

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

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

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.

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.

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

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

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.

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.

Indicadores de comprometimento

Esta é uma lista parcial de IOCs. A lista completa está disponível em nosso Repositório do GitHub.