O sequestro silencioso de tráfego: assim NGINX, Baota e proxy_pass tornam-se ferramentas de atacantes

Pesquisadores em cibersegurança tiraram à luz uma campanha ativa que manipula as instalações de NGINX e painéis de gestão como Baota (BT) para desviar tráfego web legítimo para infra-estruturas controladas por atacantes. A técnica não se concentra em quebrar a criptografia ou em explorar uma falha no navegador do usuário: em seu lugar, modifica a própria configuração do servidor web para que, de forma silenciosa, atue como um proxy para destinos maliciosos.

A equipe de Datadog Security Labs foi um dos primeiros a documentar esta atividade, ligando-a à onda de exploração do falha conhecido como React2Shell (referido no seu relatório como CVE-2025-55182). De acordo com a sua análise, os atacantes injetam blocos de configuração da NGINX que capturam pedidos entrantes em rotas específicas e reenviam através da directiva 'proxy_ 'pass' para servidores sob seu controle, com o que podem inspecionar, modificar ou aproveitar as comunicações dos visitantes. Mais detalhes técnicos e exemplos estão disponíveis no relatório do Datadog aqui e a explicação da directiva proxy_pass na documentação oficial do NGINX pode ser consultada nesta ligação.

O que torna particularmente perigoso para esta campanha é o seu carácter automatizado e a sua persistência: os atacantes lançaram um conjunto de programas que orquestram a busca de objetivos, a modificação de arquivos e a sobrevivência em sistemas comprometidos. Entre os nomes identificados pelos pesquisadores figuram zx.sh, que lança as etapas seguintes e usa utilitários comuns como curl ou wget - ou mesmo conexões TCP cruas se essas ferramentas estiverem bloqueadas -; bt.sh, que aponta especificamente para ambientes com o painel Baota para sobrepor configurações; 4zdh.sh e zdh.sh, que buscam locais habituais de NGINX e afinam o alcance da intrusão; e ok.sh, que gera um relatório das regras maliciosas ativas. Estas peças formam o que os analistas descrevem como um toolkit multinível projetado tanto para descobrir objetivos como para implantar e manter as regras de redireccionamento maliciosas.

Os operadores por trás desta campanha não parecem uniformes em seus objetivos finais. GreyNoise, que monitora atividade de rede hostil em larga escala, identificou que poucas direções IP têm protagonizado a maior parte das tentativas de exploração após a divulgação de React2Shell, e que os pós-exploit payloads variam: alguns recuperam executáveis para criptominería, enquanto outros abrem shells reversos, o que sugere interesse tanto pelo uso automatizado de recursos quanto pelo acesso interativo. A análise de GreyNoise pode ser revista aqui.

Outro dado relevante é o foco geográfico e sectorial dos atacantes. Os padrões observados mostram preferência por domínios de nível superior de determinados países na Ásia (.in, .id, .pe, .bd, .th), infra-estruturas de hospedagem chinesas e espaços institucionais como domínios .edu e .gov. Além disso, esta atividade chega em um contexto de campanhas de reconhecimento em grande escala que têm buscado painéis de acesso de produtos como a Citrix ADC e a Netscaler Gateway através de rotação maciça de proxies residenciais e uso de IPs na nuvem pública, um esforço coordenado que GreyNoise tem documentado em sua análise de reconhecimento aqui.

Quais são os riscos que um NGINX comprometido reencadeie pedidos de infra-estruturas atacantes? As consequências vão desde o roubo de credenciais e a coleta de dados sensíveis até a possibilidade de inserir conteúdo malicioso (por exemplo, scripts que afetem os navegadores dos usuários) ou de encaminhar tráfego para servidores intermediários para operações de espionagem. Também existe a opção de colocar cargas posteriores para mineração ou portas traseiras que facilitem movimentos laterais dentro de uma rede corporativa.

Para aqueles que administram servidores Web, os sinais de compromissos deste tipo são claros se se souber onde olhar: configurações "location" inesperadas que apontam para upstreams externos, incluindo arquivos recentes em /etc/nginx ou rotas equivalentes, recargas repetidas de NGINX fora dos horários habituais, e processos que iniciam conexões salientes persistentes para endereços desconhecidos. Recomenda-se a revisão da integridade dos ficheiros de configuração com as cópias de segurança, auditar mudanças em tempo real onde seja possível e limitar o acesso a painéis de gestão como a Baota através de listas de controlo de acesso e autenticação forte.

Além da detecção e remediação imediata, a defesa requer ações preventivas: manter servidores e painéis de administração atualizados, corrigir vulnerabilidades exploradas publicamente (como as associadas a React2Shell), restringir o tráfego cessante através de regras de egress na rede para impedir comunicações não autorizadas, e monitorar indicadores de compromisso relacionados a cargas típicas pós-explotação (mineros ou shells reversos). Também convém controlar as ferramentas e utilitários de download nos sistemas, pois os atacantes recorrem a curl, wget ou a conexões TCP diretas para trazer seus componentes.

Este incidente lembra que a superfície de ataque não se limita ao código das aplicações web, mas inclui a própria camada de infraestrutura que as serve. Uma mudança sutil na configuração do NGINX pode converter um servidor legítimo em um intermediário malicioso sem que o proprietário o note imediatamente. A recomendação para responsáveis por operações e equipamentos de segurança é agir rapidamente: auditar configurações, verificar a proveniência de mudanças e garantir que as interfaces de gestão estejam protegidas e monitorizadas.

Para aprofundar os achados técnicos e as táticas usadas pelos atacantes, consultar os relatórios de Datadog Security Labs sobre o sequestro de tráfego em NGINX aqui e o acompanhamento de GreyNoise sobre a consolidação de explorações e campanhas de reconhecimento aqui e aqui. Também é útil repassar a documentação oficial do NGINX sobre reverse proxy para entender melhor como a directiva proxy_pass é usada em contextos legítimos nesta ligação.

Em suma, a combinação de vulnerabilidades anteriormente conhecidas, painéis de gestão acessíveis e um toolkit automatizado permitiu aos atacantes escalar uma campanha capaz de redireccionar tráfego em larga escala. A boa notícia É que com controlos básicos de acesso, monitorização focada em mudanças de configuração e políticas rigorosas de egress podem ser significativamente reduzidas as janelas de exploração e detectar intrusões rapidamente.