Servidores NGINX são alvo de nova onda de ataques com redirecionamento de tráfego
Pesquisadores de segurança cibernética identificaram uma campanha inédita de ataques na qual criminosos digitais estão comprometendo servidores NGINX para manipular o fluxo de acesso na web e desviá‑lo, de forma silenciosa, para estruturas totalmente controladas pelos invasores. O objetivo é usar a própria infraestrutura legítima das vítimas como canal de distribuição de golpes, coleta de dados e disseminação de malware, muitas vezes sem gerar sinais claros de comprometimento.
O vetor central dessa campanha é a exploração de uma vulnerabilidade crítica catalogada como CVE 2025 55182, já reconhecida por permitir execução remota de código. Ao explorar essa falha, os atacantes conseguem acesso suficiente para alterar diretamente os arquivos de configuração do NGINX e inserir regras maliciosas, moldando o comportamento do servidor conforme seus interesses.
Um dos alvos mais frequentes, segundo os pesquisadores, são servidores que utilizam painéis de gerenciamento como o Baota (BT), muito popular em ambientes de hospedagem web na Ásia. Esses painéis, por facilitarem a administração de múltiplos sites e serviços, tornam-se um ponto de entrada atrativo: basta explorar uma falha no painel ou em um componente associado para atingir vários ambientes de uma só vez.
Depois de obter acesso, os invasores manipulam a lógica de roteamento do NGINX, transformando o servidor em um proxy invisível a serviço de atividades maliciosas. O servidor, que deveria apenas encaminhar requisições legítimas para as aplicações corretas, passa a interceptar e redirecionar parte desse tráfego para domínios controlados pelos operadores do ataque, sem que o usuário final perceba qualquer anomalia aparente.
Esse redirecionamento silencioso permite uma ampla gama de abusos: captura de credenciais de login, sequestro de sessões de usuários, monitoração de padrões de navegação, realização de golpes de phishing com páginas visualmente idênticas às oficiais e até a entrega camuflada de arquivos infectados. Tudo isso ocorre em cima de uma conexão que, para o usuário, muitas vezes continua aparecendo como “segura” (com HTTPS e certificado válido).
A técnica se apoia principalmente na diretiva padrão `proxy_pass` do NGINX, amplamente usada para implementar proxies reversos e balanceamento de carga. Em vez de configurar esse recurso para distribuir tráfego entre serviços legítimos, os atacantes injetam trechos de configuração que desviam requisições específicas — como acessos a páginas de login, formulários sensíveis ou áreas de pagamento — para servidores maliciosos. Como essas regras podem ser muito pontuais e condicionais, o comportamento suspeito passa despercebido tanto por usuários quanto por muitos administradores.
Os pesquisadores relataram ainda o uso de scripts automatizados capazes de localizar, em segundos, os arquivos de configuração do NGINX e, em seguida, inserir blocos com diretivas maliciosas sem intervenção manual. Em alguns casos, esses scripts também alteram permissões de arquivos, criam cópias de configuração “de backup” já adulteradas ou adicionam tarefas agendadas para reescrever as regras maliciosas sempre que alguém tenta removê‑las, garantindo persistência mesmo após reinicializações dos serviços ou tentativas de correção.
Embora correções para a vulnerabilidade CVE 2025 55182 tenham sido disponibilizadas em dezembro de 2025, a superfície de ataque continua ampla. Milhares de servidores permanecem expostos por não aplicarem atualizações de forma regular, por utilizarem versões antigas de painéis de controle ou por estarem diretamente expostos à internet, sem camadas extras de proteção como WAFs (firewalls de aplicação web), segmentação de rede ou mecanismos robustos de autenticação administrativa.
O potencial de impacto é elevado. Como o desvio de tráfego é realizado de maneira discreta e na própria infraestrutura das vítimas, credenciais de acesso, tokens de sessão, dados de cartões de pagamento e outras informações sensíveis podem ser comprometidos sem que haja sintomas óbvios, como lentidão significativa ou erros constantes. Muitas organizações só percebem o problema depois de denúncias de usuários, incidentes financeiros ou descobertas em auditorias de segurança.
Além do risco direto às vítimas finais, esses servidores sequestrados também podem ser reutilizados como parte de cadeias maiores de ataque. Um NGINX comprometido pode atuar como ponto intermediário em campanhas de fraude, como nó de distribuição de malware ou como camada de ofuscação para esconder a real origem de ataques a terceiros. Isso amplia o dano potencial, pois empresas com reputação consolidada podem ver seus domínios associados a operações criminosas sem terem total consciência do que está acontecendo.
Para administradores de sistemas e equipes de segurança, o cenário exige uma postura mais proativa. Não basta apenas aplicar patches quando surgem alertas: é fundamental revisar periodicamente as configurações do NGINX, monitorar alterações em arquivos críticos, implementar controle de versão para as configurações e restringir ao máximo quem pode editá‑las. A adoção de ferramentas de detecção de integridade de arquivos e de monitoramento de comportamento anômalo em servidores web torna-se um elemento-chave para identificar mudanças sorrateiras em diretivas sensíveis como `proxy_pass`.
Outro ponto sensível é a dependência excessiva de painéis de gerenciamento amigáveis, como o Baota (BT) e soluções similares. Embora esses sistemas facilitem o dia a dia da administração, também ampliam a superfície de ataque quando mal configurados ou desatualizados. É recomendável proteger o acesso a esses painéis com autenticação forte, limitar por IP, ativar logs detalhados de acesso administrativo e desativar módulos ou plugins desnecessários que possam introduzir novas vulnerabilidades.
Em termos de boas práticas, organizações que utilizam NGINX em ambientes críticos devem considerar:
– Políticas rígidas de atualização de software, com janelas de manutenção regulares.
– Ambiente de homologação para testar patches de segurança antes de levá-los à produção.
– Auditorias periódicas de configuração, buscando regras de redirecionamento suspeitas ou pouco documentadas.
– Segmentação de funções, evitando que o mesmo servidor acumule painel de gerenciamento, banco de dados e serviços de produção.
– Registro e análise contínua de logs, com correlação de eventos para identificar picos incomuns de redirecionamento ou acessos a domínios desconhecidos.
Também é importante integrar testes de invasão (pentests) recorrentes ao ciclo de vida da infraestrutura. Antes de contratar ou implantar qualquer software em ambientes sensíveis, organizações deveriam exigir testes independentes de segurança, simulando justamente cenários como exploração remota de falhas de configuração em servidores web. Isso ajuda a descobrir brechas, rotas alternativas de acesso e erros de implementação que dificilmente seriam percebidos apenas em revisões internas.
No contexto mais amplo da transformação digital e da adoção acelerada de tecnologias, a integração de inteligência artificial ao processo de desenvolvimento de software traz benefícios evidentes de velocidade e escala, mas também novos riscos. Ferramentas de IA que geram código, por exemplo, podem introduzir configurações inseguras ou trechos vulneráveis em aplicações e scripts de automação de servidores, inclusive em arquivos de configuração do NGINX. Se não houver revisão humana especializada, falhas críticas podem ir para produção sem que ninguém perceba.
Outro desafio é o uso de IA para automatizar decisões de segurança sem transparência suficiente. Modelos mal treinados ou mal configurados podem ignorar sinais sutis de comprometimento em servidores web, privilegiando alertas mais óbvios e deixando campanhas como essa, baseadas em redirecionamentos discretos, atuarem por longos períodos. Equipes de segurança precisam enxergar a IA como apoio, não como substituto da análise humana qualificada.
No Brasil, a situação torna-se ainda mais sensível pelo fato de o país ainda não contar com um marco robusto e bem definido de responsabilização por incidentes cibernéticos envolvendo infraestruturas críticas. A ausência de regras claras sobre deveres de proteção, prazos de notificação, padrões mínimos de segurança e sanções em caso de negligência dificulta a criação de uma cultura efetiva de prevenção. Em ambientes que sustentam serviços essenciais — energia, transporte, saúde, finanças — um simples redirecionamento silencioso de tráfego pode ter consequências em cadeia.
Esse vácuo regulatório não exime organizações de responsabilidade, mas torna o cenário mais fragmentado: cada empresa define seus próprios padrões, muitas vezes reagindo a incidentes em vez de preveni-los. Em um contexto no qual campanhas avançadas visam justamente componentes críticos da infraestrutura, como servidores NGINX amplamente utilizados em gateways e front-ends de aplicações, a falta de diretrizes unificadas favorece a manutenção de práticas frágeis de segurança.
A partir desse quadro, especialistas alertam para a necessidade de um alinhamento entre tecnologia, governança e cultura organizacional. Medidas técnicas de proteção — correções em dia, endurecimento de configurações, segmentação de rede, monitoramento contínuo — precisam caminhar em paralelo a políticas internas claras, treinamentos de equipes e definição de responsabilidades em todos os níveis da empresa, da área de desenvolvimento à alta gestão.
Em última instância, a campanha de ataques contra servidores NGINX com redirecionamento de tráfego reforça uma mensagem central: infraestrutura web não pode ser tratada como algo “estático” ou “configurado uma vez para sempre”. Em um ambiente de ameaças dinâmicas, no qual vulnerabilidades críticas como a CVE 2025 55182 são rapidamente incorporadas ao arsenal de cibercriminosos, somente uma postura contínua de vigilância, atualização e validação independente — incluindo pentests frequentes — é capaz de reduzir de forma consistente o risco de que sua própria infraestrutura se torne um canal invisível para ataques a usuários e parceiros.