Configurações maliciosas no NGINX desviam tráfego web em campanha ativa

Operadores abusam de diretivas de proxy em servidores NGINX e painéis Baota para redirecionar requisições legítimas por infraestrutura controlada pelo atacante.

Componente	Instalações NGINX, configurações de location e ambientes com painel de gerenciamento Baota (BT).
Vetor	Scripts em múltiplos estágios inserem arquivos de configuração maliciosos e usam a diretiva proxy_pass para encaminhar caminhos de URL predefinidos a domínios controlados pelo atacante.
Impacto	Requisições legítimas podem ser interceptadas no caminho do proxy e roteadas por servidores de backend sob controle do operador, sem evidência contextual de vazamento confirmado.
Prioridade	Auditar configurações NGINX recém-alteradas, validar diretivas location e proxy_pass, revisar painéis Baota expostos e investigar possível acesso inicial associado a exploração de CVE-2025-55182.
Artefatos	O conjunto citado inclui zx.sh, bt.sh, 4zdh.sh, zdh.sh e ok.sh, com funções de orquestração, persistência, enumeração de caminhos e geração de relatório de regras ativas.
IoCs	Exemplos defangados relacionados a atividade de exploração e reconhecimento incluem 193.142.147[.]209, 87.121.84[.]24 e 52.139.3[.]76.

Resumo técnico

Uma campanha ativa de sequestro de tráfego web tem como alvo instalações NGINX e ambientes administrados por painéis Baota. O comportamento central não depende de uma alteração visível no conteúdo da aplicação, mas de mudanças na camada de proxy reverso: configurações inseridas no NGINX capturam requisições destinadas a caminhos específicos e as encaminham para backends controlados pelo operador. Esse tipo de comprometimento é relevante para equipes de infraestrutura porque o tráfego continua parecendo chegar ao domínio legítimo, enquanto a decisão de roteamento passa a ocorrer em uma configuração adulterada no servidor intermediário.

A atividade foi associada, com confiança moderada, a acesso inicial obtido após exploração de React2Shell, rastreado como CVE-2025-55182 e descrito no contexto com pontuação CVSS 10.0. A atribuição do operador não foi detalhada. O escopo observado inclui TLDs asiáticos como .in, .id, .pe, .bd e .th, além de infraestrutura chinesa com Baota Panel e domínios governamentais ou educacionais como .gov e .edu. A prioridade defensiva é tratar alterações de configuração no NGINX como possível indicador de pós-exploração, especialmente quando houver rotas novas, diretivas de proxy incomuns ou arquivos de configuração criados por processos não esperados.

Fluxo técnico

O conjunto operacional descrito usa scripts de shell para descobrir o ambiente, localizar arquivos de configuração do NGINX e gravar diretivas maliciosas. As regras inseridas usam blocos location para selecionar caminhos de URL previamente definidos e a diretiva proxy_pass para encaminhar essas requisições a domínios sob controle do atacante. Em um servidor comprometido, isso permite que parte do tráfego legítimo seja desviada sem exigir mudança no DNS público do domínio, no certificado TLS apresentado ao usuário ou na aplicação original, desde que o ponto de decisão esteja no proxy reverso adulterado.

O artefato zx.sh atua como orquestrador e aciona estágios posteriores por utilitários legítimos de transferência, como curl ou wget; quando esses programas estão bloqueados, o fluxo cria uma conexão TCP bruta para enviar uma requisição HTTP, sem que seja necessário publicar comando operacional. O bt.sh mira ambientes Baota para sobrescrever configurações NGINX. O 4zdh.sh enumera locais comuns de configuração e reduz falhas durante a criação de novos arquivos. O zdh.sh aplica um recorte mais restrito para Linux ou NGINX em contêineres, com foco em TLDs como .in e .id. O ok.sh gera um relatório das regras de sequestro de tráfego que permanecem ativas.

A telemetria relacionada a React2Shell também indica continuidade de tentativas de exploração após a divulgação pública. Entre 26 de janeiro e 2 de fevereiro de 2026, foram observados 1.083 endereços IP únicos envolvidos em exploração de React2Shell, com dois endereços respondendo por 56% das tentativas vistas no período: 193.142.147[.]209 e 87.121.84[.]24. O contexto também registra dois padrões de pós-exploração distintos: um fluxo busca binários de mineração de criptomoedas em servidores de preparação, enquanto outro abre shells reversos diretamente para o IP do scanner, sugerindo interesse em acesso interativo em parte da atividade.

Superfície afetada

A superfície mais exposta envolve servidores NGINX que atuam como proxy reverso ou balanceador de carga e que aceitam alterações de configuração por contas administrativas, painéis web, automações de implantação ou scripts locais. Ambientes com Baota Panel exigem atenção adicional porque um dos estágios foi descrito especificamente para esse ecossistema. Instalações em Linux e NGINX conteinerizado também aparecem no recorte dos scripts, o que amplia o risco para hosts tradicionais, imagens persistentes e volumes montados que armazenam configurações compartilhadas.

O risco operacional é maior quando o servidor NGINX pode ser alterado após acesso inicial sem revisão de integridade, quando o painel de gerenciamento está exposto à internet ou quando arquivos de configuração são carregados por includes amplos. Como o desvio ocorre por caminhos de URL específicos, testes superficiais no domínio raiz podem não detectar o problema. A validação precisa cobrir todos os arquivos incluídos pelo NGINX, rotas de aplicação sensíveis e alterações recentes feitas fora do pipeline autorizado.

• Instalações NGINX com blocos location novos ou alterados sem mudança registrada em controle de versão.
• Painéis Baota (BT) que administram arquivos de configuração NGINX em infraestrutura hospedada.
• Ambientes Linux ou conteinerizados com caminhos comuns de configuração enumeráveis por scripts locais.
• Domínios em TLDs citados no contexto, incluindo .in, .id, .pe, .bd, .th, .edu e .gov.

Hunting e telemetria

A investigação deve começar pela comparação entre a configuração efetiva do NGINX e a configuração esperada em repositório, imagem base ou ferramenta de gerenciamento. Procure blocos location inseridos recentemente, diretivas proxy_pass apontando para domínios externos não documentados, arquivos novos incluídos por include e mudanças em diretórios comuns do NGINX. O objetivo não é apenas confirmar sintaxe válida, mas identificar rotas que desviam tráfego para backends sem relação com a aplicação.

Em endpoint, a equipe deve correlacionar processos de shell que modificaram arquivos de configuração, execuções de utilitários de transferência, conexões TCP incomuns feitas por scripts e recarregamentos do serviço NGINX próximos a eventos de exploração. Em rede, vale procurar tráfego originado do proxy para domínios ou endereços não previstos, principalmente quando a requisição de entrada veio de usuário legítimo e a saída subsequente aponta para infraestrutura desconhecida. Em exposição externa, requisições exploratórias contra React2Shell e varreduras de painéis de login devem ser tratadas como sinais de pressão ativa sobre a borda.

• Diferenças entre configuração NGINX em produção e artefatos aprovados no pipeline.
• Diretivas proxy_pass para destinos externos, recém-criados ou sem justificativa operacional.
• Processos de shell gravando arquivos em diretórios de configuração do NGINX ou Baota.
• Recarregamentos do NGINX imediatamente após atividade suspeita de exploração ou autenticação administrativa.
• Conexões de saída do proxy para infraestrutura desconhecida após requisições em caminhos específicos.

Mitigação

A resposta deve preservar evidências antes de remover artefatos. Colete a configuração efetiva do NGINX, registre metadados dos arquivos alterados, capture processos relacionados e correlacione eventos de autenticação administrativa ou exploração. Depois, remova ou isole regras de proxy não autorizadas, recarregue o serviço de forma controlada e valide que os caminhos afetados retornam ao backend legítimo. Se houver indício de acesso inicial por React2Shell, a contenção precisa incluir o componente vulnerável e não apenas o arquivo de configuração alterado.

A correção deve combinar atualização do software afetado, revisão de credenciais administrativas, restrição de acesso ao painel Baota e bloqueio de alteração direta em produção fora do fluxo aprovado. Em ambientes conteinerizados, reconstrua imagens e volumes quando não for possível garantir a integridade do estado persistente. Para reduzir recorrência, monitore mudanças de arquivos NGINX como evento de segurança, imponha revisão de configuração por controle de versão e alerte quando um proxy reverso passar a conversar com destinos externos não cadastrados.

• Aplicar correções disponíveis para componentes expostos a React2Shell e verificar se CVE-2025-55182 não permanece explorável.
• Restringir painéis Baota à administração interna, com autenticação forte e revisão de contas privilegiadas.
• Remover diretivas location e proxy_pass não autorizadas após coleta de evidências.
• Revalidar todos os includes do NGINX e comparar a configuração ativa com a versão aprovada.
• Monitorar criação, alteração e recarga de configurações NGINX como evento de alta prioridade.