Firmware modificado para roteadores TP-Link WR940N adiciona backdoor, watchdog, armazenamento oculto de C2 e recursos de shell remoto, transferência de arquivos e tunelamento.
| Componente | Imagens de firmware modificadas para roteadores TP-Link WR940N v4 e v6, com componentes adicionados ao sistema de arquivos SquashFS customizado. |
| Vetor | O método inicial de infecção não foi confirmado; a hipótese técnica é acesso prévio ao roteador por vulnerabilidades conhecidas ou credenciais padrão, fracas ou previsíveis, seguido de instalação de firmware adulterado. |
| Impacto | O implante Horse Shell mantém persistência no roteador, oferece shell remoto, transferência de arquivos e tunelamento, e pode transformar dispositivos domésticos em nós de infraestrutura anônima para comunicação com C2. |
| Prioridade | Validar integridade do firmware, atualizar roteadores a partir de imagens oficiais, trocar credenciais administrativas, revisar exposição da interface de gerenciamento e procurar processos e arquivos associados ao udhcp adulterado. |
| Versões | As imagens analisadas declaravam compatibilidade com TP-Link WR940N em versões de hardware v4 e v6. |
| Artefatos | Arquivos e caminhos relevantes incluem udhcp, timer, sheel, /etc/rc.d/rcS, /dev/mtdblock4, /var/udhcp, /var/udhcp.cnf e SoftwareUpgradeRpm.htm. |
| IoCs | O domínio padrão observado foi m.cremessage[.]com, usado na configuração do implante com comunicação pela porta 80. |
A análise descreve um firmware malicioso preparado para roteadores TP-Link WR940N, com imagens separadas para as versões de hardware v4 e v6. O núcleo e o uBoot das imagens comparadas permaneceram iguais aos componentes legítimos, mas o sistema de arquivos foi alterado. A adulteração adicionou binários e modificou arquivos de inicialização e interface administrativa, indicando que o objetivo não era substituir todo o sistema operacional do roteador, mas inserir uma camada persistente dentro de um firmware que ainda preservava partes estruturais do original.
O componente principal recebeu o nome interno Horse Shell e foi inserido como o binário udhcp, compilado para arquitetura MIPS32 big-endian. O implante fornece três capacidades confirmadas: shell remoto, transferência de arquivos e tunelamento. Esse conjunto permite que o operador mantenha presença no dispositivo e use o roteador como nó intermediário entre infecções e infraestrutura de comando e controle. O material também inclui um bind shell protegido por senha na porta 14444 e um mecanismo de watchdog que relança o implante principal em intervalos definidos.
O caso é relevante para equipes de segurança porque roteadores domésticos e de pequeno escritório raramente entram no mesmo ciclo de inventário, telemetria e validação de integridade aplicado a servidores, endpoints e cargas em nuvem. A presença de um implante no firmware muda o escopo da resposta: reiniciar o equipamento ou remover um processo suspeito não elimina a persistência se o sistema de arquivos adulterado continuar instalado. A defesa precisa tratar o firmware como artefato de confiança, verificar a origem da imagem instalada e considerar substituição ou reinstalação a partir de arquivo oficial quando houver suspeita.
A cadeia observada começa em imagens de firmware modificadas. A comparação com firmware oficial do mesmo modelo mostrou que a adulteração estava concentrada no sistema de arquivos, extraído de uma implementação customizada de SquashFS. Foram identificados arquivos adicionados e alterações em componentes existentes. Uma das mudanças ocorreu em SoftwareUpgradeRpm.htm, página associada à atualização manual de firmware na interface web do roteador. A modificação inseriu uma propriedade CSS que oculta o formulário de atualização. A função não é removida do HTML, mas deixa de ficar visível para o usuário comum, dificultando a descoberta e a execução de uma atualização manual legítima.
A segunda alteração importante está em /etc/rc.d/rcS, script executado no processo de inicialização do sistema. O arquivo foi modificado para iniciar três binários adicionados ao firmware. Como esse script roda cedo no boot, a mudança garante que os componentes maliciosos sejam carregados automaticamente sempre que o roteador for reiniciado. Essa persistência é reforçada pelo binário timer, que funciona como watchdog: ele tenta executar udhcp periodicamente e depende do arquivo /var/udhcp como indicador de instância ativa. Quando o implante já está em execução, o arquivo bloqueado impede duplicação; quando não está, o binário principal cria o arquivo, grava seu identificador de processo e continua a inicialização.
O binário sheel atua como utilitário de configuração e leitura. Ele não foi associado diretamente ao script de inicialização, o que sugere uso manual pelo operador ou por etapas anteriores da operação. Sua função técnica é ler e gravar dados em /dev/mtdblock4, partição que, nesse modelo, corresponde à área ART, normalmente reservada a dados de calibração do chipset Wi-Fi. O uso dessa partição para armazenar endereços de C2 reduz a visibilidade para administradores que esperariam encontrar configuração operacional em arquivos convencionais do sistema de arquivos. O utilitário comporta até cinco servidores C2, o que dá ao implante uma lista dinâmica de pares além do domínio padrão embutido.
Durante a execução, Horse Shell ignora sinais como SIGPIPE, SIGINT e SIGABRT, chama sua rotina principal e se destaca do terminal para operar como daemon. O implante verifica /var/udhcp para evitar múltiplas instâncias e cria /var/udhcp.cnf com uma instrução operacional para encerrar seu próprio processo; o propósito exato desse arquivo não foi confirmado, mas ele pode facilitar controle manual pelo operador. A configuração combina valores codificados no binário com dados gravados em /dev/mtdblock4. O domínio padrão observado foi m.cremessage[.]com, com comunicação pela porta 80, e os pares não padrão são resolvidos e testados antes da continuidade da inicialização.
A comunicação usa HTTP com cabeçalhos fixos, mas o conteúdo não corresponde a tráfego web comum. As mensagens são criptografadas por um esquema customizado ou modificado baseado em rede de substituição-permutação. O implante usa a biblioteca libev e opera em modelo orientado a eventos, sem múltiplas threads, mantendo estruturas separadas para pares conectados, callbacks de leitura e escrita, temporizadores e conexões ativas. Após estabelecer comunicação, envia repetidamente informações sobre o dispositivo comprometido, incluindo dados que indicam funcionalidades suportadas e arquitetura de CPU. A presença desses campos sugere que a família pode comportar variantes para outros dispositivos, mas a análise fornecida confirma apenas a instância MIPS associada às imagens modificadas.
A superfície confirmada envolve roteadores TP-Link WR940N com firmware adulterado para as versões de hardware v4 e v6. O texto analisado afirma que os componentes foram escritos de forma independente do firmware e não dependem estritamente de um único fornecedor, mas não apresenta evidência concreta de implantação em outros modelos ou marcas. Portanto, a avaliação defensiva deve separar o que foi confirmado, que são as imagens TP-Link alteradas, do risco condicionado de reutilização em outros firmwares de dispositivos embarcados.
O método de comprometimento inicial não foi determinado. As hipóteses técnicas citadas são exploração de vulnerabilidades já conhecidas em dispositivos expostos ou autenticação com senhas padrão, fracas ou facilmente previsíveis. Esse limite é importante: não há CVE, versão vulnerável específica, falha de interface web ou exploração ativa documentada no material recebido. A exposição real depende de como o roteador é administrado, se a interface de gerenciamento está acessível por redes não confiáveis, se as credenciais foram trocadas e se o firmware instalado corresponde a uma imagem oficial.
O alvo operacional parece ser a construção de uma cadeia de nós intermediários, e não necessariamente a exploração direta dos proprietários dos roteadores. Dispositivos residenciais podem ser usados como infraestrutura de anonimização, ponto de retransmissão ou túnel, reduzindo a distância aparente entre operador e infraestrutura principal. Mesmo assim, o impacto para a rede local não deve ser minimizado: um roteador com shell remoto e tunelamento controlado por terceiros fica em posição privilegiada para observar tráfego, alterar rotas, intermediar conexões e facilitar acesso a serviços internos se outras condições estiverem presentes.
- Roteadores TP-Link WR940N v4 e v6 com firmware que não corresponda ao pacote oficial do fornecedor.
- Sistemas de arquivos SquashFS modificados contendo
udhcp,timer,sheele alterações em/etc/rc.d/rcS. - Interfaces administrativas nas quais o formulário de atualização manual associado a
SoftwareUpgradeRpm.htmesteja oculto por alteração de CSS. - Ambientes nos quais credenciais administrativas de roteador permaneçam padrão, fracas, reutilizadas ou expostas em redes não confiáveis.
A investigação deve começar pela integridade do firmware e por artefatos persistentes no sistema de arquivos. Em roteadores suspeitos, a defesa deve comparar a imagem instalada com firmware oficial do mesmo modelo e versão de hardware, verificando diferenças em scripts de boot, páginas administrativas e binários adicionados. Como o núcleo e o bootloader podem permanecer legítimos, uma validação limitada a esses componentes não é suficiente. A adulteração relevante está no sistema de arquivos e nos pontos de execução automática.
No host embarcado, os sinais mais fortes são a presença de udhcp fora do comportamento esperado, execução automática a partir de /etc/rc.d/rcS, criação ou bloqueio de /var/udhcp, existência de /var/udhcp.cnf e gravação incomum em /dev/mtdblock4. Essa partição normalmente contém dados de calibração de rádio; uso como armazenamento bruto de servidores C2 é anômalo. Em ambientes nos quais a coleta direta no roteador é limitada, a telemetria de rede pode complementar a análise com conexões HTTP periódicas para domínios ou pares incomuns, especialmente pela porta 80, com cabeçalhos repetitivos e padrões de beacon.
A detecção também deve considerar o bind shell na porta 14444 em todas as interfaces IPv4. A porta aberta, por si só, não identifica necessariamente a família, mas em combinação com firmware alterado, binários MIPS desconhecidos e comunicação para m.cremessage[.]com defangado aumenta a confiança. O tráfego do implante é criptografado em nível de aplicação, então a inspeção deve priorizar metadados, periodicidade, destino, cabeçalhos HTTP fixos e comportamento de conexões persistentes ou recorrentes, em vez de depender de conteúdo legível.
- Diferenças entre firmware instalado e firmware oficial no sistema de arquivos, mesmo quando núcleo e
uBootforem idênticos. - Referências a
udhcp,timeresheelem scripts de inicialização, diretórios incomuns ou processos ativos no roteador. - Arquivo
/var/udhcpcriado como marcador de instância e arquivo/var/udhcp.cnfassociado ao processo do implante. - Gravações ou conteúdo anômalo em
/dev/mtdblock4, especialmente valores que se pareçam com hosts de C2. - Conexões HTTP periódicas para
m.cremessage[.]comou para pares definidos dinamicamente, com uso observado da porta 80. - Serviço escutando na porta 14444 em interfaces IPv4 do roteador.
A resposta deve priorizar restauração de confiança no dispositivo. Quando houver suspeita de firmware adulterado, reinicialização simples e remoção manual de processo não resolvem a persistência. A ação mais segura é reinstalar firmware oficial compatível com o modelo e a versão de hardware, obtido diretamente do fornecedor, ou substituir o equipamento se não houver forma confiável de validar e regravar a imagem. Como a página de atualização pode ter sido ocultada, a equipe deve considerar métodos administrativos alternativos documentados pelo fabricante e evitar imagens de origem desconhecida.
Depois da recuperação, credenciais administrativas devem ser trocadas por senhas fortes e únicas, e o acesso à interface de gerenciamento deve ser restrito a redes confiáveis. A exposição remota do painel administrativo deve ser desativada quando não for estritamente necessária. Também é importante revisar se outros dispositivos da rede dependem do roteador como ponto de saída, DNS ou gateway, porque a presença de um implante nesse ponto pode afetar visibilidade, roteamento e controle de tráfego. Logs de firewall, DNS, proxy e NetFlow devem ser preservados para determinar se houve comunicação recorrente com infraestrutura suspeita.
Em redes corporativas ou laboratórios que contenham roteadores semelhantes, o caso deve motivar inventário de firmware, verificação de checksums quando disponíveis e documentação do estado aprovado dos dispositivos. A defesa deve tratar roteadores como ativos gerenciados, com ciclo de atualização, política de senha, segmentação e monitoramento básico. Para equipamentos domésticos usados por funcionários, a orientação defensiva deve enfatizar atualização a partir de fontes oficiais, troca de credenciais padrão e redução de exposição administrativa, sem assumir que todo dispositivo infectado foi escolhido por causa do usuário final.
- Regravar o roteador com firmware oficial correspondente ao modelo e à versão de hardware, ou substituir o dispositivo quando a integridade não puder ser garantida.
- Remover exposição remota da interface administrativa e limitar gerenciamento a redes confiáveis.
- Trocar credenciais administrativas e eliminar senhas padrão, previsíveis ou reutilizadas.
- Comparar scripts de boot e sistema de arquivos contra imagem oficial, procurando alterações em
/etc/rc.d/rcSe binários adicionados. - Bloquear e investigar comunicação com o domínio defangado
m.cremessage[.]come outros destinos anômalos associados ao roteador. - Monitorar a porta 14444 e conexões HTTP periódicas originadas do roteador para identificar persistência residual ou reinfecção.
0 Comentários