--- title: "Malware Cling usa tráfego STUN do Google para esconder ataques contra dispositivos IoT" author: "Lígia Lemos Maia" date: "2026-10-05 09:15:00-03" category: "Segurança & Privacidade" url: "http://desbugados.scale.press/portal/desbugados/post/2026/10/05/malware-cling-usa-trafego-stun-do-google-para-esconder-ataques-contra-dispositivos-iot/md" --- ## Resumo - A botnet Cling foi identificada em outubro de 2026 por pesquisadores da Nozomi Networks. - O malware usa tráfego STUN e pacotes com ID de transação zero para disfarçar o canal de comando e controle. - A infecção explora a vulnerabilidade CVE-2021-35394, uma falha de injeção de comando no Realtek Jungle SDK associada à porta UDP/9034. - A Cling mantém persistência em dispositivos MIPS ao alterar scripts de inicialização e copiar arquivos para caminhos ocultos. - O malware substitui o executável wget legítimo e renomeia o original para wget.r. - Após a infecção, a botnet pode executar comandos remotamente, baixar payloads, fazer varreduras de rede, criar túneis TCP e realizar ataques DoS. --- Em outubro de **2026**, investigadores da **Nozomi Networks** identificaram a botnet Cling, uma ameaça que transforma o tráfego aparentemente comum de dispositivos IoT em uma cortina para esconder comunicações de comando e controle. O malware explora a vulnerabilidade **CVE-2021-35394**, ligada ao Realtek Jungle SDK, e usa o protocolo STUN para fazer seus contatos parecerem parte de uma comunicação legítima. STUN é um mecanismo utilizado para ajudar dispositivos a atravessar estruturas de rede que traduzem endereços, o que torna esse tipo de tráfego familiar em muitos ambientes. A Cling ainda envia pacotes com ID de transação zero e utiliza servidores STUN, incluindo um controlado pelos invasores, para registrar aparelhos e receber comandos. A seguir, o problema será traduzido em sinais concretos para quem administra redes e sistemas Linux embarcados, porque uma mensagem que parece banal pode carregar as instruções de uma máquina comprometida. ## A camuflagem escondida em uma linguagem conhecida da rede O disfarce começa pela escolha do **STUN**, protocolo frequentemente usado para atravessar o NAT, mecanismo que reorganiza a comunicação entre endereços de uma rede interna e a internet. Segundo o [relatório técnico da Nozomi Networks](https://www.nozominetworks.com/blog/a-stunning-disguise-cling-malware-masquerades-as-google-), a Cling aproveita esse tipo de tráfego para ocultar o canal que conecta o dispositivo infectado ao seu servidor de comando e controle, conhecido pela sigla C2. A técnica se aproxima de uma falsificação de identidade: o pacote não precisa parecer uma ordem estranha se puder ser confundido com uma conversa esperada entre aplicações conectadas. O malware envia esses pacotes com **ID de transação zero**, característica que aparece como uma das pistas descritas pelos pesquisadores. A sutileza está justamente em ocupar uma passagem que administradores já esperam encontrar aberta para comunicações legítimas. Essa estratégia ganha outra camada quando a Cling utiliza **servidores STUN** para registrar os dispositivos infectados e receber instruções, incluindo pelo menos um servidor operado pelos próprios invasores. Na prática, o aparelho comprometido passa a anunciar sua presença e a aguardar tarefas por meio de um protocolo que não nasceu para transportar uma botnet. O relatório também descreve a capacidade de forjar tráfego STUN legítimo e, em alguns casos, simular pacotes relacionados à infraestrutura do **Google**, uma escolha que pode dificultar a leitura automática feita por firewalls e sistemas de monitoramento. Para o administrador, a pergunta deixa de ser apenas se há tráfego STUN na rede e passa a envolver a forma como esse tráfego é construído, para onde ele vai e qual comportamento acompanha a comunicação. É nessa mudança de perspectiva que a camuflagem começa a revelar suas costuras. ## A vulnerabilidade que abre a porta para a infecção Por trás da aparência legítima existe uma porta de entrada conhecida: a **CVE-2021-35394**, uma falha de injeção de comando no Realtek Jungle SDK. O problema está associado à porta de comunicação **UDP/9034**, e o monitoramento reunido nas fontes descreve essa vulnerabilidade como vetor para execução remota de código em dispositivos afetados. Em termos simples, a injeção permite que uma entrada especialmente preparada seja interpretada pelo equipamento como uma instrução, em vez de permanecer como um dado comum. Essa diferença transforma uma interface exposta em uma oportunidade de controle para quem consegue explorar o erro. A Cling usa essa abertura para iniciar sua presença no dispositivo antes de estabelecer o mecanismo de comunicação camuflado. A mesma porta de entrada também aparece associada a outras famílias de botnets, como **Condi** e **RondoDox**, segundo o monitoramento do CVE-2021-35394. Isso ajuda a separar duas etapas que costumam ser confundidas: a vulnerabilidade permite a entrada inicial, enquanto cada família define o que fará depois da infecção. No caso da Cling, a diferença está na combinação entre o acesso ao dispositivo e o uso do STUN para esconder o C2, criando uma cadeia que começa com uma falha de comando e termina em comunicação disfarçada. O repositório que acompanha esse vetor observa justamente o comportamento e a infraestrutura empregados por cada família após a invasão. Para as equipes responsáveis por dispositivos conectados, a falha precisa ser lida como o primeiro capítulo de uma operação que pode mudar de forma depois que o invasor entra. ## Persistência: o malware tenta sobreviver ao reinício Depois da entrada, o Cling procura permanecer no equipamento mesmo quando o sistema é reiniciado. Em dispositivos baseados na arquitetura de processadores **MIPS**, o malware se copia para os caminhos **/root/.cling** e **/usr/local/bin/.cling**, além de alterar arquivos de inicialização como **/etc/inittab** e **/etc/init.d/rcS**. Esses arquivos participam da sequência que prepara o sistema para funcionar, portanto a alteração faz o código voltar à atividade durante o processo de inicialização. A persistência, nesse caso, não depende de o invasor repetir manualmente a exploração a cada queda de energia ou reinício do dispositivo. O equipamento passa a carregar consigo a instrução de recuperar a presença do malware, como uma marca escondida no roteiro de funcionamento do próprio sistema. A interferência também alcança o **wget**, utilitário usado para obter arquivos pela rede em sistemas Linux. A Cling substitui o executável legítimo por uma cópia de si mesma e renomeia o original para **wget.r**, uma alteração que pode deixar o caminho habitual associado a um comportamento malicioso. O contexto inclui scripts de inicialização SysV e BusyBox, conjunto de ferramentas presente na organização de sistemas Linux embarcados descrita no relatório. Para quem investiga um aparelho, a presença de um wget modificado deixa de ser um detalhe de manutenção e passa a ser uma pista sobre a sequência da infecção. O sequestro do utilitário mostra como o malware tenta se misturar às rotinas administrativas que normalmente seriam usadas para baixar componentes e executar tarefas no equipamento. ## O que a Cling consegue fazer depois da infecção Com o canal de comando estabelecido, a Cling consegue executar **comandos remotamente** e baixar novos payloads, termo usado para designar componentes entregues ao dispositivo comprometido. O malware também realiza varreduras de rede, procurando outros equipamentos que possam ser alcançados a partir do ponto já invadido. Essa combinação amplia o valor do primeiro dispositivo infectado, que deixa de ser um aparelho isolado e passa a funcionar como uma base para novas ações dentro da rede. O relatório da Nozomi Networks descreve essas capacidades como parte do funcionamento observado da ameaça, e não como uma hipótese sobre uma campanha futura. A consequência prática é que a investigação precisa olhar além do equipamento em que o primeiro sinal apareceu. A lista de capacidades inclui ainda a criação de **túneis TCP**, canais que transportam comunicações por uma conexão de rede, e ataques de proxy relay, nos quais o dispositivo comprometido pode ser usado para encaminhar tráfego. A Cling também é capaz de realizar inundações **DoS**, sigla para negação de serviço, técnica que sobrecarrega um alvo com grande volume de solicitações. Essas funções indicam que a botnet não foi construída apenas para manter um canal silencioso de controle, mas também para transformar dispositivos vulneráveis em ferramentas operacionais. O mesmo código pode servir para alcançar outros pontos, intermediar conexões ou interromper serviços, de acordo com as ordens recebidas. Por isso, a camuflagem STUN deve ser analisada junto das ações executadas no aparelho, e não como um evento de rede isolado. ## Como traduzir os sinais para a investigação da rede Os indicadores descritos nas fontes formam uma sequência que pode orientar a análise de administradores: pacotes STUN com **ID de transação zero**, comunicação com servidores que registram dispositivos e alterações no executável **wget**. Cada pista pertence a uma camada diferente do problema, mas todas se conectam ao mesmo comportamento: o dispositivo recebe uma capacidade de controle, tenta preservá-la após o reinício e usa uma linguagem de rede que pode parecer familiar. A presença de tráfego STUN, sozinha, não aparece nas fontes como prova de infecção, mas a combinação entre o formato dos pacotes, os destinos utilizados e os arquivos modificados desenha uma investigação mais precisa. O administrador pode, portanto, comparar esses elementos em vez de procurar somente nomes óbvios de malware ou conexões claramente suspeitas. A própria arquitetura do ataque sugere que a defesa precisa acompanhar o comportamento completo do aparelho. O próximo passo é tratar o **CVE-2021-35394** como ponto de partida para uma verificação mais ampla, observando tanto a porta UDP/9034 quanto os sinais posteriores de persistência e comunicação. A análise deve considerar os caminhos **/root/.cling** e **/usr/local/bin/.cling**, os arquivos de inicialização alterados e a possibilidade de o wget original ter sido renomeado para wget.r, sempre confrontando esses indícios com o funcionamento esperado de cada equipamento. A descoberta da Cling mostra que a superfície de um dispositivo IoT não termina na interface que o usuário enxerga: ela inclui scripts, utilitários, arquitetura de processador e protocolos que parecem cotidianos. Quando esse conjunto é observado como uma história única, o disfarce perde parte de sua força e a investigação passa a enxergar a máquina que existe por trás do pacote aparentemente comum.