Roteadores Huawei HG532 foram alvos de botnet Satori via falha em TR-064

A exploração de CVE-2017-17215 expôs roteadores domésticos Huawei HG532 ao recrutamento por botnet IoT com capacidade de inundação TCP e UDP.

Componente	Roteadores Huawei HG532 com implementação de TR-064/UPnP exposta pela porta 37215 na interface WAN.
Vetor	Requisições remotas ao serviço DeviceUpgrade abusavam campos de URL de atualização para injetar metacaracteres de shell e acionar execução de comandos no dispositivo vulnerável.
Impacto	Execução remota de comandos para baixar e iniciar um bot identificado como OKIRU/SATORI, variante associada ao ecossistema Mirai, com funções de inundação TCP e UDP.
Prioridade	Aplicar a correção do fornecedor, bloquear exposição WAN da porta 37215, revisar tráfego TR-064/UPnP e caçar sinais de comunicação C2 na porta 7645.
CVE	CVE-2017-17215 foi associada à falha explorada nos roteadores Huawei HG532.
Artefatos	O binário analisado resolvia um domínio C2 codificado, usava XOR simples com valor 0x07 para strings e possuía requisições fixas em protocolo próprio de comunicação.
IoCs	O domínio C2 citado no caso deve ser tratado de forma defangada, como nexusiotsolutions[.]net; a comunicação observada usava TCP com porta 7645 no exemplar pesquisado.

Resumo técnico

Roteadores domésticos Huawei HG532 foram explorados em massa por uma campanha de recrutamento de botnet IoT que abusava de uma falha de execução remota de comandos no serviço de gerenciamento exposto pela porta 37215. A vulnerabilidade recebeu o identificador CVE-2017-17215 e estava ligada à implementação de TR-064 sobre UPnP, mecanismo originalmente destinado a operações administrativas em rede local, como configuração do equipamento e atualização de firmware. O problema crítico era a exposição desse caminho administrativo à WAN, permitindo que requisições vindas da internet alcançassem uma superfície que não deveria aceitar controle remoto não confiável.

A atividade maliciosa foi observada em sensores e honeypots em múltiplas regiões, com destaque para Estados Unidos, Itália, Alemanha e Egito. O volume de tentativas indicava exploração em larga escala e não apenas prova isolada de conceito. A cadeia de ataque buscava acionar o serviço DeviceUpgrade, injetar comandos por campos usados no fluxo de atualização e fazer o equipamento baixar e executar um payload. O malware entregue foi identificado como OKIRU/SATORI, uma variante atualizada relacionada ao ecossistema Mirai, com foco em transformar roteadores vulneráveis em nós de uma botnet capaz de gerar tráfego de negação de serviço por pacotes TCP e UDP construídos manualmente.

O caso combina três fatores de risco comuns em IoT: serviço administrativo exposto fora da rede local, falha de validação em parâmetros usados por rotinas privilegiadas e malware reutilizando ideias de botnets anteriores. Embora a atribuição tenha apontado para o apelido Nexus Zeta, a análise disponível descreve um operador aparentemente menos sofisticado do que o volume inicial sugeria. Isso não reduz a gravidade operacional: quando código de malware vazado, dispositivos com baixa maturidade de segurança e falhas exploráveis se encontram, atacantes com capacidade limitada ainda conseguem produzir tráfego distribuído expressivo e comprometer equipamentos em escala.

Fluxo técnico

O ponto de entrada era a implementação de TR-064/UPnP no Huawei HG532. TR-064 foi projetado para facilitar tarefas administrativas a partir da rede interna, mas nesses dispositivos o serviço estava acessível pela WAN na porta 37215. A enumeração da descrição UPnP indicava a presença do tipo de serviço DeviceUpgrade, usado para executar uma ação de atualização por meio do caminho /ctrlt/DeviceUpgrade_1. Essa ação aceitava parâmetros como NewStatusURL e NewDownloadURL, que deveriam representar URLs de status e download no processo de atualização, mas eram tratados de forma insegura quando recebiam metacaracteres interpretáveis pelo shell.

A exploração consistia em enviar uma requisição manipulada para a rotina de atualização, fazendo com que o dispositivo interpretasse conteúdo controlado pelo atacante como parte de um comando. Em vez de publicar a forma executável do payload, o ponto defensivo essencial é que os campos de URL permitiam alterar o fluxo esperado da atualização e iniciar o download de um binário externo. Após a execução, o roteador retornava a mensagem padrão associada ao HUAWEIUPNP e o processo de atualização era disparado, criando uma aparência de fluxo legítimo enquanto o binário malicioso era iniciado no equipamento.

O payload descrito tinha funcionalidade objetiva: participar de ataques de inundação. Ao iniciar, o bot tentava resolver o endereço IP de um servidor de comando e controle por consulta DNS usando um domínio codificado no próprio binário. Em seguida, extraía endereços da resposta DNS e tentava conexão TCP com uma porta fixa, observada como 7645 no exemplar analisado. O protocolo de C2 era próprio e simples, com duas requisições codificadas usadas para registro e identificação do bot. A resposta do servidor carregava parâmetros de ataque, incluindo destino, quantidade de pacotes e atributos necessários para a geração de tráfego.

As rotinas de ataque aceitavam um endereço IP individual ou uma sub-rede, definida por endereço e quantidade de bits relevantes. Depois de enviar pacotes TCP ou UDP construídos manualmente, o bot não aguardava resposta dos hosts atingidos, comportamento compatível com uma lógica de inundação em que a confirmação do destino não é necessária. O binário também continha strings ofuscadas e em texto claro que não eram usadas, sugerindo reaproveitamento de código, resquícios de versões anteriores ou herança de outro bot. Algumas strings, incluindo uma referência falsa de C2, apareciam no binário sem participar do fluxo real de comunicação.

Superfície afetada

A superfície diretamente exposta era formada por roteadores Huawei HG532 alcançáveis pela internet com a implementação vulnerável de TR-064/UPnP disponível na porta 37215. O risco dependia da possibilidade de uma origem remota atingir o serviço administrativo e enviar requisições ao controle de atualização. Ambientes residenciais eram o alvo natural, mas o mesmo tipo de equipamento também pode aparecer em redes de pequenas empresas, filiais, laboratórios, provedores locais ou instalações em que o roteador doméstico atua como borda real da rede.

O impacto confirmado no caso é execução remota de comandos para instalação de botnet, não um vazamento de dados comprovado. A consequência operacional mais relevante é a perda de controle do roteador como ativo de borda: o dispositivo passa a executar código de terceiros, comunicar-se com infraestrutura C2 e participar de ataques DDoS. Para a rede local, isso também cria um ativo não confiável no caminho de tráfego, ainda que o material disponível não sustente afirmar movimentação lateral, roubo de credenciais internas ou exfiltração de conteúdo. A resposta deve tratar o roteador comprometido como equipamento possivelmente persistente fora dos mecanismos tradicionais de EDR.

A campanha observada tinha alcance internacional e gerava numerosos alertas em sensores distribuídos. O uso de uma falha zero-day à época, somado a múltiplos servidores de ataque, fez o caso parecer inicialmente compatível com operação mais avançada. A atribuição posterior ao apelido Nexus Zeta foi apoiada por vínculos com domínio de C2 e presença pública em fóruns e redes, mas a própria análise indicou limite de confiança sobre identidade real e sobre como a vulnerabilidade chegou ao operador.

• Roteadores Huawei HG532 com TR-064/UPnP exposto à WAN pela porta 37215.
• Serviço DeviceUpgrade acessível por requisições remotas ao caminho /ctrlt/DeviceUpgrade_1.
• Dispositivos que receberam payload OKIRU/SATORI e passaram a buscar C2 via DNS e TCP.
• Redes que dependem do roteador como borda, NAT, gateway residencial ou equipamento de pequena empresa.

Hunting e telemetria

A caça deve começar pela borda. Em logs de firewall, IDS, IPS, proxy reverso ou sensores de rede, o sinal primário é tráfego inbound para a porta 37215 em equipamentos que não deveriam expor UPnP ou TR-064 à internet. Requisições ao caminho de controle de atualização do Huawei HG532, especialmente envolvendo DeviceUpgrade, NewStatusURL e NewDownloadURL, devem ser tratadas como suspeitas quando originadas fora da rede administrativa. Mesmo sem registrar o corpo completo da requisição, picos de tentativas para essa porta, múltiplas origens e respostas anômalas do serviço indicam varredura ou exploração.

No tráfego de saída, a investigação deve procurar roteadores ou endereços de borda realizando resolução DNS para domínios associados ao C2 e conexões TCP para a porta 7645, conforme observado no exemplar analisado. O domínio nexusiotsolutions[.]net aparece como artefato relevante e deve permanecer defangado em relatórios e consultas compartilhadas. A defesa também deve observar padrões de beaconing simples, tentativas repetidas de conexão após boot do equipamento e comunicação que não corresponde ao perfil normal de um roteador doméstico. Como o bot usa protocolo próprio, inspeção baseada apenas em HTTP não cobre a comunicação de comando.

Para detecção de impacto, a telemetria de rede deve medir tráfego de saída UDP e TCP com volume incompatível com o perfil do local, especialmente fluxos sem necessidade de resposta do destino. A botnet aceita parâmetros vindos do C2 e pode direcionar tráfego a um IP ou sub-rede, o que tende a aparecer como rajadas de pacotes para destinos externos concentrados. Em ambientes com NetFlow, sFlow ou registros equivalentes, os sinais mais úteis são aumento abrupto de pacotes por segundo, baixa diversidade de aplicação, destinos definidos por janela curta e origem localizada no próprio roteador ou no endereço público do cliente.

• Tentativas inbound para porta 37215 em roteadores Huawei HG532 ou faixas residenciais gerenciadas.
• Requisições ao serviço DeviceUpgrade e aos parâmetros NewStatusURL ou NewDownloadURL vindas de origem externa.
• Consultas DNS e conexões TCP relacionadas a C2 defangado, incluindo nexusiotsolutions[.]net e porta 7645 no exemplar analisado.
• Aumento de tráfego UDP ou TCP de saída com pacotes construídos em grande volume e sem padrão de aplicação legítima.
• Equipamentos que retornam mensagens HUAWEIUPNP após requisições suspeitas de atualização.

Mitigação

A primeira medida é aplicar a correção disponibilizada para o Huawei HG532 e validar que a versão instalada remove a condição de execução remota associada a CVE-2017-17215. Em paralelo, a exposição WAN de UPnP/TR-064 deve ser bloqueada. A porta 37215 não deve ficar acessível a partir da internet para administração rotineira, e qualquer necessidade de gerenciamento deve ser deslocada para canais autenticados, segmentados e restritos por origem. Quando o roteador foi atingido por exploração, a correção isolada pode não ser suficiente; é necessário reinicializar de forma controlada, restaurar firmware confiável quando aplicável e revisar configurações persistentes.

A contenção deve considerar o roteador como ativo comprometido até prova em contrário. Isso inclui remover conectividade externa não essencial, trocar credenciais administrativas locais, revisar DNS configurado no equipamento, validar regras de NAT e encaminhamento de portas, e confirmar que não há serviços administrativos expostos indevidamente. Em redes de provedores, a resposta deve combinar bloqueio no perímetro, notificação de clientes afetados, telemetria por faixa e distribuição de firmware corrigido. Em empresas que usam equipamentos dessa classe, o roteador deve ser incluído no inventário de ativos de borda e no processo de gestão de vulnerabilidades, não tratado como componente invisível.

Do ponto de vista preventivo, a lição operacional é reduzir superfícies de gerenciamento em IoT. UPnP e TR-064 devem permanecer limitados à rede local somente quando forem necessários, e mesmo nesse cenário precisam de segmentação. Sensores de rede devem manter regras para tentativas de exploração de CVE-2017-17215, padrões de comando contra DeviceUpgrade e comunicação C2 associada à família OKIRU/SATORI. A validação final deve confirmar três estados: serviço administrativo inacessível pela WAN, firmware corrigido e ausência de tráfego de botnet após a remediação.

• Instalar o firmware corrigido para Huawei HG532 e registrar a versão validada no inventário.
• Bloquear acesso externo à porta 37215 e restringir UPnP/TR-064 ao escopo local estritamente necessário.
• Inspecionar roteadores suspeitos para DNS alterado, regras de NAT incomuns, serviços administrativos expostos e tráfego C2.
• Adicionar detecções para exploração de CVE-2017-17215, abuso de DeviceUpgrade e conexões TCP para porta 7645 quando compatíveis com o ambiente.
• Tratar roteadores explorados como ativos comprometidos, com troca de credenciais, restauração controlada e monitoramento pós-correção.