L'enlèvement silencieux de la circulation: donc NGINX, Baota et proxy _ passer deviennent des outils d'agresseurs

Les chercheurs en cybersécurité ont mis en lumière une campagne active qui manipule les installations NGINX et les panneaux de gestion tels que Baota (BT) pour détourner le trafic Web légitime vers des infrastructures contrôlées par les attaquants. La technique ne se concentre pas sur la rupture de la cryptographie ou l'exploitation d'une défaillance dans le navigateur de l'utilisateur: au lieu de cela, elle modifie la configuration propre du serveur Web de sorte qu'il agit tranquillement comme un mandataire vers des destinations malveillantes.

La sécurité de Datadog L'équipe de Labs a été l'une des premières à documenter cette activité, la liant à la vague d'exploitation de l'échec connu sous le nom de React2Shell (appelé CVE-2025-55182). Selon leur analyse, les attaquants injectent des blocs de configuration NGINX qui capturent les applications entrantes sur des routes spécifiques et les retransmettent à travers la directive. _ passer par proxy aux serveurs sous votre contrôle, afin que vous puissiez inspecter, modifier ou profiter des communications des visiteurs. Plus de détails techniques et des exemples sont disponibles dans le rapport Datadog Voilà. et l'explication de la directive proxy _ pass dans la documentation officielle NGINX peut être trouvée dans ce lien.

Ce qui rend cette campagne particulièrement dangereuse est son caractère automatisé et sa persistance : les attaquants ont déployé un ensemble de scripts qui orchestrent la recherche de cibles, la modification de fichiers et la survie de systèmes compromis. Les noms identifiés par les chercheurs comprennent zx.sh, qui lance les étapes suivantes et utilise des utilitaires communs tels que curl ou wget - ou même des connexions TCP brutes si ces outils sont bloqués -; bt.sh, qui pointe spécifiquement vers des environnements avec le panneau Baota pour écraser les configurations; 4zdh.sh et zdh.sh, qui cherchent des emplacements NGINX réguliers et affiner la portée de l'intrusion; et ok.sh, qui génère un rapport de règles malveillantes actives. Ces pièces forment ce que les analystes décrivent comme une boîte à outils à plusieurs niveaux conçue à la fois pour découvrir les objectifs et pour mettre en œuvre et maintenir des règles de redirection malveillantes.

Les opérateurs derrière cette campagne ne semblent pas uniformes dans leurs objectifs finaux. GreyBoise, qui surveille les activités de réseau hostiles à grande échelle, a identifié que quelques adresses IP ont mené la plupart des tentatives d'exploitation après la divulgation de React2Shell, et que les charges utiles après l'exploitation varient : certaines récupèrent l'exécutable pour cryptominery, tandis que d'autres ouvrent des coquilles inversées, suggérant un intérêt à la fois pour l'utilisation automatisée des ressources et l'accès interactif. L'analyse de GreyBruit peut être revue Voilà..

Une autre donnée pertinente est l'orientation géographique et sectorielle des attaquants. Les tendances observées montrent une préférence pour les domaines de plus haut niveau de certains pays d'Asie (.in, .id, .pe, .bd, .th), l'infrastructure d'hébergement chinoise et les espaces institutionnels tels que .edu et .gov.domaines. En outre, cette activité s'inscrit dans le cadre de campagnes de reconnaissance à grande échelle qui ont cherché des panneaux d'accès pour des produits tels que Citrix ADC et Netscaler Gateway grâce à la rotation massive des procurations résidentielles et à l'utilisation des IP dans le cloud public, un effort coordonné que GreyNoise a documenté dans son analyse de reconnaissance Voilà..

Quels sont les risques d'envoi de demandes de NGINX pour attaquer une infrastructure? Les conséquences vont du vol d'identités et de la collecte de données sensibles à la possibilité d'insérer du contenu malveillant (p. ex. des scripts qui affectent les navigateurs des utilisateurs) ou d'orienter le trafic vers des serveurs intermédiaires pour des opérations d'espionnage. Il est également possible de déployer des charges ultérieures pour l'exploitation minière ou les portes arrière qui facilitent les mouvements latéraux au sein d'un réseau d'entreprise.

Pour ceux qui gèrent des serveurs web, les signes de ces engagements sont clairs si vous savez où regarder : des configurations inattendues de "localisation" qui pointent vers des amonts externes, y compris des fichiers récents dans / etc / nginx ou des itinéraires équivalents, des recharges répétées NGINX en dehors des temps habituels, et des processus qui commencent des connexions sortantes persistantes vers des directions inconnues. Il est recommandé d'examiner l'intégrité des fichiers de configuration avec sauvegarde, de vérifier les changements en temps réel lorsque c'est possible et de limiter l'accès aux panneaux de gestion tels que Baota au moyen de listes de contrôle d'accès et d'une forte authentification.

Outre la détection et la médiation immédiates, la défense doit prendre des mesures préventives : tenir à jour les serveurs et les panneaux d'administration, corriger les vulnérabilités exploitées par le public (comme celles associées à React2Shell), restreindre le trafic sortant au moyen de règles de libération du réseau pour empêcher les communications non autorisées, et surveiller les indicateurs d'engagement liés aux charges normales après exploitation (mineurs ou shells inversés). Il est également approprié de contrôler les outils de téléchargement et les utilitaires dans les systèmes, car les attaquants utilisent les connexions curl, wget ou direct TCP pour apporter leurs composants.

Cet incident rappelle que la surface d'attaque n'est pas limitée au code des applications web, mais inclut la couche même de l'infrastructure qui les dessert. Un changement subtil dans les paramètres NGINX peut transformer un serveur légitime en intermédiaire malveillant sans que le propriétaire le remarque immédiatement. La recommandation à l'intention des opérateurs et de l'équipement de sécurité consiste à agir rapidement : vérifier les configurations, vérifier la source des changements et s'assurer que les interfaces de gestion sont protégées et surveillées.

Pour approfondir les découvertes techniques et les tactiques utilisées par les attaquants, veuillez consulter les rapports de Datadog Security Labs sur le détournement de trafic dans NGINX. Voilà. et le suivi de GreyBoise sur les campagnes de consolidation et de reconnaissance agricole Voilà. et Voilà.. Il est également utile d'examiner la documentation officielle de NGINX sur le changement de proxy pour mieux comprendre comment la directive proxy _ pass est utilisée dans des contextes légitimes dans ce lien.

Bref, la combinaison de vulnérabilités connues, de panneaux de gestion accessibles et d'une boîte à outils automatisée a permis aux attaquants d'intensifier une campagne capable de réorienter le trafic à grande échelle. La bonne nouvelle est qu'avec les contrôles d'accès de base, la surveillance axée sur les changements de configuration et les politiques d'évacuation strictes peut réduire considérablement les fenêtres d'exploitation et détecter les intrusions rapidement.