Guia prático sobre o malware AryStinger em roteadores Linux. Aprenda a detectar, analisar e remover essa botnet com comandos reais, além de estratégias de hardening para proteger sua infraestrutura de borda
Em março de 2026, pesquisadores do QiAnXin XLab detectaram uma campanha incomum: mais de 4.300 roteadores Linux baseados em chipsets Realtek RTL819X haviam sido comprometidos não para DDoS, mas para formar uma rede de reconhecimento e proxy distribuído.
Batizada de AryStinger, essa botnet representa uma mudança de paradigma no uso de dispositivos de borda comprometidos.
O diferencial do AryStinger está em seu propósito: não se trata de uma botnet para derrubar serviços, mas sim de uma infraestrutura de reconnaissance pré-intrusão.
Cada dispositivo infectado—denominado Executor—recebe tarefas de varredura, tunelamento de tráfego e execução remota de comandos, transformando roteadores esquecidos em pontos de apoio para ataques mais sofisticados.
Este artigo aborda a arquitetura técnica do AryStinger, seus mecanismos de persistência e comunicação, e — mais importante — apresenta um conjunto de procedimentos práticos para detecção, contenção e prevenção em ambientes que ainda utilizam hardware de borda baseado em Linux.
Pré-requisitos
Para acompanhar os procedimentos deste guia, você precisará de:
Passo a Passo
1. Compreendendo a Arquitetura do AryStinger
Antes de qualquer ação de detecção ou remediação, é fundamental entender como o AryStinger opera.
1.1 Duas Variantes, Dois Alvos
O AryStinger existe em duas variantes distintas:
1.2 Cadeia de Infecção Típica
O fluxo de infecção segue um padrão bem definido:
1. Escaneamento: Atacantes identificam dispositivos expostos com vulnerabilidades conhecidas.
2. Exploração: Entrega de um ELF Linux com detecção zero em engines de antivírus.
3. Comunicação C2: O malware se conecta via HTTP/HTTPS ao servidor de comando e controle.
4. Autenticação: Troca de identificador único com o C2;.
5. Aguardando tarefas: O dispositivo entra em standby até receber instruções.
1.3 Mecanismos de Persistência
O AryStinger emprega duas estratégias principais para se manter ativo:
- Dropbear (porta 2332): Um servidor SSH leve instalado nos roteadores infectados
- gs-netcat (variante NAS): Conexão reversa para gerenciamento remoto
Ambos os mecanismos são acompanhados de modificações nas regras de firewall para garantir acesso contínuo.
. Detecção: Identificando Infecções Ativas
A detecção proativa é a primeira linha de defesa. Os procedimentos abaixo assumem que você tem acesso shell ao dispositivo suspeito.
2.1 Verificação de Processos Suspeitos
O AryStinger, em sua variante C, geralmente não altera o comportamento visível do roteador—ele continua roteando tráfego normalmente. Isso torna a detecção por observação de desempenho ineficaz.
Comando:
# Lista todos os processos com detalhes completos $ ps auxfww | grep -E "dropbear|[A]ry|2332|[s]shd" # Saída esperada em um sistema limpo: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 123 0.0 0.1 1500 800 ? Ss Mar01 0:00 /usr/sbin/dropbear -p 22
O que procurar:
- Processos dropbear escutando em portas não-padrão (especialmente 2332)
- Binários ELF com nomes ofuscados ou localizados em diretórios incomuns (/tmp, /dev/shm, /var/run)
- Processos com alta atividade de rede, mas baixo consumo de CPU
Por que isso funciona: O AryStinger utiliza o Dropbear como backdoor SSH. Em roteadores legítimos, o Dropbear (quando presente) normalmente escuta na porta 22. Qualquer instância na porta 2332 é um forte indicador de comprometimento.
2.2 Inspeção de Conexões de Rede
O AryStinger mantém comunicação persistente com seus C2s via HTTP/HTTPS, utilizando Protobuf com camada XOR.
Comando:
# Lista todas as conexões TCP estabelecidas $ ss -tunap | grep -E "ESTAB|SYN-SENT" # Ou, para sistemas mais antigos: $ netstat -tunap | grep ESTABLISHED # Saída suspeita (exemplo): tcp ESTAB 0 0 192.168.1.100:45678 185.234.xxx.xxx:443 users:(("dropbear",pid=1421,fd=3))
O que procurar:
- Conexões de saída para IPs em ranges suspeitos (blocos conhecidos de hospedagem, VPS baratas)
- Conexões persistentes em portas HTTP/HTTPS com padrões de tráfego intermitentes
- Múltiplas conexões para o mesmo destino a partir de diferentes processos
Por que isso funciona: O AryStinger utiliza comunicação C2 baseada em HTTP/HTTPS. Diferentemente de tráfego de atualização legítimo (que geralmente ocorre em horários específicos), o tráfego C2 tende a ser constante e com padrões de heartbeat regulares.
2.3 Análise de Arquivos e Integridade
O AryStinger é entregue como um ELF Linux que, inicialmente, não era detectado por engines de antivírus. A verificação de integridade de arquivos pode revelar alterações.
Comando
# Verifica arquivos modificados recentemente em diretórios críticos $ find / -type f -mtime -30 -exec ls -la {} \; 2>/dev/null | grep -vE "(/proc|/sys|/dev)" # Verifica bins suspeitos em /tmp e /dev/shm $ ls -la /tmp /dev/shm /var/tmp /var/run # Calcula hashes de bins conhecidos para comparação $ sha256sum /usr/sbin/dropbear /bin/busybox /usr/bin/ssh
O que procurar:
- Binários ELF em /tmp ou /dev/shm (pontos de montagem temporários frequentemente usados para entrega de malware)
- Alterações em binários do sistema (especialmente dropbear, sshd, iptables)
- Arquivos com timestamps incompatíveis com a data de instalação do firmware
Por que isso funciona: A variante C do AryStinger é projetada para hardware com recursos limitados e, portanto, tende a ser pequena e frequentemente armazenada em diretórios temporários para evitar persistência em flash.
2.4 Inspeção de Regras de Firewall
O AryStinger modifica o firewall para garantir acesso remoto contínuo.
Comando:
# Para sistemas com iptables $ iptables -L -n -v # Para sistemas com nftables (mais recentes) $ nft list ruleset # Verifica regras de encaminhamento de porta $ iptables -t nat -L -n -v
O que procurar:
- Regras que abrem portas incomuns (2332, 4443, etc.)
- Regras de redirecionamento de porta que não fazem parte da configuração original
- Regras de saída que permitem tráfego para IPs específicos sem justificativa
2.5 Script de Detecção Automatizada
Para ambientes com múltiplos dispositivos, o seguinte script pode ser adaptado:
#!/bin/bash # detect_arystinger.sh - Scanner básico para indicadores de comprometimento echo "[*] Verificando processos suspeitos..." ps auxf | grep -E "dropbear.*2332|[A]ry" && echo "[!] ALERTA: Processo suspeito detectado!" echo "[*] Verificando conexões de rede..." ss -tunap | grep -E "ESTAB" | awk '{print $5}' | cut -d: -f1 | sort -u | while read ip; do # Verifica se o IP está em lista de C2 conhecidos (a ser mantida) echo " Conexão para: $ip" done echo "[*] Verificando arquivos em /tmp..." find /tmp /dev/shm -type f -executable 2>/dev/null | while read file; do echo " Binário executável em: $file" md5sum "$file" 2>/dev/null done echo "[*] Verificando regras de firewall suspeitas..." iptables -L -n | grep -E "2332|4443|ACCEPT.*any/any" && echo "[!] ALERTA: Regra suspeita!"
3. Análise Forense Detalhada
Uma vez identificado um possível comprometimento, a análise forense deve ser conduzida em um ambiente controlado.
3.1 Captura de Tráfego de Rede
O AryStinger utiliza comunicação Protobuf com XOR, mas a captura ainda pode revelar padrões.
# Captura tráfego para análise (ajuste a interface conforme necessário) $ tcpdump -i br0 -w arystinger_capture.pcap -s 0 port 80 or port 443 or port 2332 # Análise rápida em tempo real $ tcpdump -i br0 -n -A port 443 | head -100
O que observar: O tráfego Protobuf tem características binárias específicas—pacotes com tamanhos consistentes, padrões de bytes repetidos (devido à codificação XOR com chave fixa sh_#@!_2024_secret).
3.2 Extração e Análise do Binário
Se o binário for localizado, ele deve ser extraído para análise em ambiente seguro:
# Localiza o binário (exemplo) $ find / -type f -executable -size -500k -mtime -30 2>/dev/null | xargs file | grep ELF # Copia para análise (NUNCA execute em produção) $ scp usuario@roteador:/tmp/.hidden /analise/arystinger_sample # Verifica strings (pode revelar indicadores) $ strings /analise/arystinger_sample | grep -E "http|C2|dropbear|2332|sh_#@"
Indicadores a procurar nas strings:
- URLs de C2 (ex: http://[IP]/[caminho])
- A chave XOR hardcoded: sh_#@!_2024_secret
- Referências a dropbear e porta 2332
Nomes de funções ou caminhos de projeto (ex: Ary-Attack)
4. Remediação e Limpeza
A remediação de um dispositivo infectado pelo AryStinger requer uma abordagem cautelosa.
4.1 Isolamento Imediato
Antes de qualquer ação, isole o dispositivo da rede para evitar que continue atuando como proxy ou recebendo novas instruções.
# No firewall/roteador upstream, bloqueie o dispositivo $ iptables -I FORWARD -s 192.168.1.100 -j DROP # Ou, se tiver acesso ao dispositivo, desabilite a interface de WAN $ ifconfig eth0 down # CUIDADO: você perderá acesso remoto
4.2 Coleta de Evidências (para análise posterior)
# Coleta informações críticas antes da limpeza $ mkdir /tmp/forensics_$(date +%Y%m%d) $ cp /var/log/messages /tmp/forensics_$(date +%Y%m%d)/ $ ps auxf > /tmp/forensics_$(date +%Y%m%d)/ps.txt $ netstat -tunap > /tmp/forensics_$(date +%Y%m%d)/netstat.txt $ iptables-save > /tmp/forensics_$(date +%Y%m%d)/iptables.txt $ find / -type f -mtime -30 > /tmp/forensics_$(date +%Y%m%d)/modified_files.txt
4.3 Limpeza do Sistema
Atenção: Em dispositivos embarcados, a única forma confiável de remediação é o reflash completo do firmware. Qualquer tentativa de "limpeza manual" pode deixar resíduos.
Procedimento recomendado:
- Backup da configuração (se aplicável e seguro)
- Download do firmware original do fabricante (verifique se ainda é suportado)
- Reflash via interface de recuperação (TFTP, serial, ou web recovery)
- Reset de fábrica após o reflash
- Reconfiguração com hardening aplicado
Para dispositivos sem suporte oficial (EOL): A substituição do hardware é a única solução segura.
5. Prevenção e Hardening
A prevenção é infinitamente mais eficaz que a remediação.
5.1 Inventário e Ciclo de Vida
O primeiro passo é saber o que está na sua rede:
# Mapeamento de dispositivos de borda $ nmap -sn 192.168.0.0/24 | grep -E "Nmap scan|MAC" # Identificação de fabricantes via OUI $ nmap -O 192.168.0.0/24 | grep -E "MAC|Device type"
Política recomendada: Dispositivos com mais de 5 anos ou em EOL (End of Life) devem ser substituídos.
5.2 Desativação de Serviços Desnecessários
# Desativa administração remota via WAN # (comando varia conforme o fabricante - exemplo para OpenWrt) $ uci set uhttpd.main.listen_http='0.0.0.0:80' $ uci set uhttpd.main.listen_https='0.0.0.0:443' $ uci commit uhttpd $ /etc/init.d/uhttpd restart # Desativa Telnet $ uci set dropbear.enable='1' # Mantém SSH, desativa Telnet $ uci commit
Por que isso importa: Muitas vulnerabilidades exploradas pelo AryStinger afetam serviços expostos na interface WAN. Reduzir a superfície de ataque é a medida de maior impacto.
5.3 Monitoramento Contínuo
Dispositivos de borda devem ser monitorados como qualquer outro ativo crítico:
# Script de monitoramento de conexões suspeitas (cron a cada 5 min) #!/bin/bash # /etc/cron.d/arystinger_watch CONNECTIONS=$(ss -tunap | grep ESTAB | grep -vE ":(80|443|53|22)" | wc -l) if [ $CONNECTIONS -gt 10 ]; then logger "ALERTA: Alto número de conexões estabelecidas em portas não-padrão" # Envia alerta para SIEM ou e-mail fi
5.4 Atualizações de Firmware
Mesmo que o dispositivo esteja em EOL, verifique se há atualizações de segurança disponíveis:
# Para OpenWrt $ opkg update && opkg list-upgradable # Verifica versão atual $ cat /etc/openwrt_release
📘 Indicação de Leitura
Esse livro é um guia prático e abrangente sobre a segurança do sistema operacional Linux como um todo. O livro ensina a pensar como um atacante para fortalecer a defesa do servidor, abordando tópicos fundamentais como:
- Ferramentas de rede: Nmap, Netcat, knockd.
- Monitoramento: de arquivos e sistemas de arquivos.
- Defesas: contra malware e ataques DDoS.
- Descoberta de vulnerabilidades: como invasores encontram pontos fracos.
Eu ganho uma comissão quando você faz uma compra.
Troubleshooting
Problema 1: O roteador parece estar funcionando normalmente, mas há conexões suspeitas
Sintoma: Conexões de saída para IPs desconhecidos em portas 80/443, mas o roteador continua roteando tráfego.
Causa provável: O AryStinger não interfere no roteamento principal, operando em segundo plano.
Solução:
1. Capture o tráfego com tcpdump para identificar padrões.
2. Bloqueie os IPs suspeitos no firewall.
3. Execute a verificação de processos descrita na Seção 2.1.
4. Se confirmado, proceda com o reflash do firmware.
Problema 2: A porta 2332 está aberta, mas não há processo dropbear visível
Sintoma: netstat -tunap | grep 2332 mostra a porta aberta, mas ps aux | grep dropbear não retorna nada.
Causa provável: O malware pode estar usando um binário renomeado ou executando via inetd/xinetd.
# Verifica todos os processos com bind à porta $ lsof -i :2332 # Verifica xinetd $ grep -r "2332" /etc/xinetd.d/ # Busca por qualquer binário que escute na porta $ find / -type f -executable -exec grep -l "2332" {} \; 2>/dev/null
Problema 3: O reflash do firmware não removeu o malware
Sintoma: Após o reflash, as conexões suspeitas retornam.
Causa provável:
O malware pode residir em uma partição persistente não sobrescrita pelo reflash padrão
O dispositivo pode estar sendo reinfectado via WAN (outro dispositivo na rede)
Solução:
1. Realize um reset de fábrica completo após o reflash
2. Altere as credenciais padrão imediatamente
3. Verifique se há outros dispositivos comprometidos na rede
4. Considere a substituição do hardware se o problema persistir
Problema 4: O dispositivo não tem suporte para ferramentas de diagnóstico
Sintoma: Comandos como ss, lsof, tcpdump não estão disponíveis no sistema embarcado.
Solução:
- Utilize ferramentas estáticas compiladas para a arquitetura do dispositivo (ex: busybox com opções extras).
- Em último caso, utilize a interface web de administração para verificar status de conexões (se disponível).
- Para análises mais profundas, pode ser necessário extrair a flash e analisar em outro sistema.
Conclusão
O AryStinger representa uma evolução preocupante no cenário de malware para dispositivos de borda.
Diferentemente de botnets tradicionais focadas em DDoS, ele constrói uma infraestrutura de reconhecimento e proxy que serve como springboard para ataques mais complexos.
A lição mais importante que este incidente nos traz é que dispositivos de borda não são "configure e esqueça". Eles exigem o mesmo nível de atenção que servidores e estações de trabalho:
1. Inventário rigoroso: Saiba exatamente o que está conectado à sua rede
2. Ciclo de vida definido: Substitua hardware em EOL antes que ele se torne um passivo de segurança
Nenhum comentário:
Postar um comentário