O Nozomi Networks Labs identificou o Cling, um botnet que recruta roteadores, access points, repetidores e DVRs expostos na internet e esconde o canal de comando dentro de tráfego STUN que imita o serviço público do Google. Equipamentos embarcados sem atualização de firmware são o alvo direto, e a ação prioritária é inventariar o que tem endereço público, aplicar correção e caçar os artefatos conhecidos do malware antes que o dispositivo vire munição contra terceiros. A análise, publicada em outubro de 2026, combina telemetria de sensores de clientes com validação controlada do servidor de comando — evidência suficiente para mudar como o tráfego STUN é tratado na borda.
Como o Cling infecta
A porta de entrada mais observada na telemetria foi a exploração da CVE-2021-35394, uma falha de execução remota de código no componente diagnóstico do Realtek Jungle SDK compilado como UDPServer. O componente vem embutido em appliances que raramente recebem atualização, e a exploração é trivial: um datagrama UDP com um marcador fixo seguido de comandos de shell faz o dispositivo baixar e executar o binário do bot, conforme descreve o relatório técnico do Nozomi Networks Labs. O registro da NVD classifica o problema como injeção de comando explorável por atacantes remotos sem autenticação e o mantém no catálogo de vulnerabilidades conhecidas e exploradas da CISA, no qual entrou em dezembro de 2021.
Depois de entrar, o bot amplia o alcance sozinho. O binário MIPS analisado carrega código de exploração para outras sete falhas de injeção de comando em roteadores LB-LINK, Linksys, Eir D1000, FiberHome e China Mobile e em DVRs TBK e MVPower, com identificações que vão de 2014 a 2025. Cada hospedeiro comprometido vira um scanner do espaço IPv4 em busca do próximo dispositivo vulnerável — o mesmo ciclo de recrutamento que sustenta botnets resilientes como o Kimwolf.
No hospedeiro, a persistência é dupla. O malware copia a si mesmo para caminhos ocultos terminados em.cling, grava esses binários em scripts de inicialização como /etc/inittab e /etc/init.d/rcS e ainda substitui o binário wget por uma cópia de si mesmo, preservando o original como wget.r e o caminho em wget.p. Qualquer chamada futura de wget — por tarefa de rotina, manutenção ou outro atacante — reexecuta o malware. Um socket na porta 33957 garante instância única. É persistência tão acomodada quanto a de amostras recentes que se disfarçam para não sair do hospedeiro.
O disfarce no protocolo STUN
O STUN, padronizado na RFC 8489 do IETF, existe para resolver travessia de NAT: o terminal descobre o endereço e a porta que o roteador lhe alocou. Por isso ele é tráfego legítimo de Teams, Zoom, Webex e aplicações WebRTC em qualquer rede corporativa — e é essa normalidade que o Cling explora para esconder o comando.
O fluxo tem quatro passos: o bot envia Binding Requests periódicos a uma lista fixa de 13 servidores STUN públicos, registra as portas mapeadas devolvidas, envia a cada servidor um datagrama UDP de registro fora do protocolo — com a porta externa e a etiqueta do método de infecção — e espera comandos em UDP. Duas escolhas entregam o malware para quem inspeciona: o transaction ID via zerado, em vez de aleatório como manda a especificação, e os comandos do operador chegam codificados exatamente nesse campo de 12 bytes.
Por que a reputação engana
Para localizar o servidor de comando, os pesquisadores anunciaram conjuntos diferentes de portas para cada um dos 13 endereços da lista. Horas depois, comandos chegaram a uma porta divulgada apenas ao servidor 145.249.115[.]184 — prova prática de que ele pertence à operação, e não a um serviço público genuíno. O conjunto de comandos disponíveis no binário inclui execução de payload, varredura com exploração, túnel TCP, proxy e inundação contra alvos escolhidos pelo operador.
O detalhe mais incômodo é a origem aparente: durante dias de monitoração, os pesquisadores receberam ordens de ataque contra quatro alvos, entre eles um provedor sul-coreano, um cluster acadêmico americano e dois servidores de Minecraft, em pacotes de comando que pareciam vir de um endereço associado ao serviço STUN público do Google. Não há forma legítima de fazer um servidor STUN entregar um transaction ID escolhido; a explicação sustentada pelos dados é falsificação do endereço de origem em uma rede que não valida, com diferenças consistentes de TTL entre respostas genuínas e pacotes de comando.
A consequência operacional é direta. Um pacote estranho vindo de um VPS desconhecido gera alerta; o mesmo pacote aparentando vir do Google, depois que o hospedeiro já iniciou atividade STUN, é descartado como ruído de travessia de NAT. Triagem que libera tráfego por reputação de IP descarta exatamente o pacote que carrega a ordem de ataque.
Sinais para caçar na rede
Como a maior parte dos alvos não gera telemetria de hospedeiro, a caça é de rede e de sistema de arquivos. A tabela resume o que priorizar:
| Sinal | Onde procurar | Leitura |
|---|---|---|
| Binding Requests com transaction ID zerado | UDP em portas STUN como 3478 e 19302 | Viola a RFC; servidores conformes esperam valor aleatório |
| Datagramas UDP não-STUN rumo a portas STUN | Mesmas sessões dos equipamentos embarcados | Registro do bot; servidores legítimos ignoram |
| Contato periódico com 13 servidores STUN | Baseline de saída de roteadores e DVRs | Padrão de polling do Cling |
| Arquivos.cling, wget.r e wget.p | Sistema de arquivos de dispositivos gerenciáveis | Persistência ativa do malware |
| Saltos de tráfego de saída em equipamento de borda | Fluxos agregados da borda | Túnel TCP ou proxy habilitado pelo operador |
No hospedeiro, os indicadores publicados incluem o hash SHA-1 do binário MIPS 3b0ac6aaabb3bf8058ca14f9c8ccc613cfa3ea71, o user-agent “clingwashere” nas requisições de download e a regra YARA distribuída junto do relatório — material pronto para entrar no pipeline de detecção e validar a cobertura de telemetria.
Ações priorizadas de contenção
P1 — hoje: inventariar roteadores, access points, DVRs e repetidores com endereço público; aplicar firmware que corrija a CVE-2021-35394 e as demais falhas usadas na propagação; onde não houver correção, remover a exposição e segmentar o equipamento; verificar a presença de.cling, wget.r e wget.p nos dispositivos acessíveis.
P2 — esta semana: criar detecção para Binding Requests com transaction ID zerado e para datagramas não-STUN destinados a portas STUN; baselinar o tráfego STUN por classe de equipamento; tratar qualquer dispositivo de borda comprometido como ponto de entrada da rede corporativa, com resposta de incidente completa, e não como problema isolado do aparelho.