El secuestro silencioso de tráfico: así NGINX, Baota y proxy_pass se vuelven herramientas de atacantes

Investigadores en ciberseguridad han sacado a la luz una campaña activa que manipula las instalaciones de NGINX y paneles de gestión como Baota (BT) para desviar tráfico web legítimo hacia infraestructuras controladas por atacantes. La técnica no se centra en romper la criptografía ni en explotar un fallo en el navegador del usuario: en su lugar, modifica la propia configuración del servidor web para que, de forma silenciosa, actúe como un proxy hacia destinos maliciosos.

El equipo de Datadog Security Labs ha sido uno de los primeros en documentar esta actividad, vinculándola a la oleada de explotación del fallo conocido como React2Shell (referido en su informe como CVE-2025-55182). Según su análisis, los atacantes inyectan bloques de configuración de NGINX que capturan solicitudes entrantes en rutas específicas y las reenvían mediante la directiva proxy_pass hacia servidores bajo su control, con lo que pueden inspeccionar, modificar o aprovechar las comunicaciones de los visitantes. Más detalles técnicos y ejemplos están disponibles en el informe de Datadog aquí y la explicación de la directiva proxy_pass en la documentación oficial de NGINX puede consultarse en este enlace.

Lo que hace particularmente peligrosa a esta campaña es su carácter automatizado y su persistencia: los atacantes han desplegado un conjunto de scripts que orquestan la búsqueda de objetivos, la modificación de archivos y la supervivencia en sistemas comprometidos. Entre los nombres identificados por los investigadores figuran zx.sh, que lanza las etapas siguientes y utiliza utilidades comunes como curl o wget —o incluso conexiones TCP crudas si esas herramientas están bloqueadas—; bt.sh, que apunta específicamente a entornos con el panel Baota para sobrescribir configuraciones; 4zdh.sh y zdh.sh, que buscan ubicaciones habituales de NGINX y afinan el alcance de la intrusión; y ok.sh, que genera un informe de las reglas maliciosas activas. Estas piezas forman lo que los analistas describen como un toolkit multinivel diseñado tanto para descubrir objetivos como para implantar y mantener las reglas de redirección maliciosas.

Los operadores detrás de esta campaña no parecen uniformes en sus objetivos finales. GreyNoise, que monitoriza actividad de red hostil a gran escala, identificó que unas pocas direcciones IP han protagonizado la mayor parte de los intentos de explotación tras la divulgación de React2Shell, y que los post-exploit payloads varían: algunos recuperan ejecutables para criptominería, mientras que otros abren shells reversos, lo que sugiere interés tanto por el uso automatizado de recursos como por el acceso interactivo. El análisis de GreyNoise puede revisarse aquí.

Otro dato relevante es el foco geográfico y sectorial de los atacantes. Los patrones observados muestran preferencia por dominios de nivel superior de determinados países en Asia (.in, .id, .pe, .bd, .th), infraestructuras de hosting chinas y espacios institucionales como dominios .edu y .gov. Además, esta actividad llega en un contexto de campañas de reconocimiento a gran escala que han buscado paneles de acceso de productos como Citrix ADC y Netscaler Gateway mediante rotación masiva de proxies residenciales y uso de IPs en la nube pública, un esfuerzo coordinado que GreyNoise ha documentado en su análisis de reconocimiento aquí.

¿Qué riesgos supone que un NGINX comprometido reenvíe peticiones a infraestructura atacante? Las consecuencias van desde el robo de credenciales y la recolección de datos sensibles hasta la posibilidad de insertar contenido malicioso (por ejemplo, scripts que afecten a los navegadores de los usuarios) o de encaminar tráfico a servidores intermediarios para operaciones de espionaje. También existe la opción de desplegar cargas posteriores para minería o puertas traseras que faciliten movimientos laterales dentro de una red corporativa.

Para quienes administran servidores web, las señales de compromisos de este tipo son claras si se sabe dónde mirar: configuraciones "location" inesperadas que apuntan a upstreams externos, includes de ficheros recientes en /etc/nginx o rutas equivalentes, recargas repetidas de NGINX fuera de los horarios habituales, y procesos que inician conexiones salientes persistentes hacia direcciones desconocidas. Es recomendable revisar la integridad de los ficheros de configuración con las copias de seguridad, auditar cambios en tiempo real donde sea posible y limitar el acceso a paneles de gestión como Baota mediante listas de control de acceso y autenticación fuerte.

Además de la detección y remediación inmediata, la defensa requiere acciones preventivas: mantener servidores y paneles de administración actualizados, parchear vulnerabilidades explotadas públicamente (como las asociadas a React2Shell), restringir el tráfico saliente mediante reglas de egress en la red para impedir comunicaciones no autorizadas, y vigilar indicadores de compromiso relacionados con cargas típicas post-explotación (mineros o shells reversos). También conviene controlar las herramientas y utilidades de descarga en los sistemas, puesto que los atacantes recurren a curl, wget o a conexiones TCP directas para traer sus componentes.

Este incidente recuerda que la superficie de ataque no se limita al código de las aplicaciones web, sino que incluye la propia capa de infraestructura que las sirve. Un cambio sutil en la configuración de NGINX puede convertir un servidor legítimo en un intermediario malicioso sin que el propietario lo note de inmediato. La recomendación para responsables de operaciones y equipos de seguridad es actuar con rapidez: auditar configuraciones, verificar la procedencia de cambios y asegurarse de que las interfaces de gestión estén protegidas y monitorizadas.

Para profundizar en los hallazgos técnicos y las tácticas usadas por los atacantes, pueden consultarse los informes de Datadog Security Labs sobre el secuestro de tráfico en NGINX aquí y el seguimiento de GreyNoise sobre la consolidación de explotaciones y las campañas de reconocimiento aquí y aquí. También es útil repasar la documentación oficial de NGINX sobre reverse proxy para entender mejor cómo se usa la directiva proxy_pass en contextos legítimos en este enlace.

En resumen, la combinación de vulnerabilidades previamente conocidas, paneles de gestión accesibles y un toolkit automatizado ha permitido a los atacantes escalar una campaña capaz de redirigir tráfico a gran escala. La buena noticia es que con controles básicos de acceso, monitorización enfocada a cambios de configuración y políticas estrictas de egress se pueden reducir significativamente las ventanas de explotación y detectar intrusiones con rapidez.