Pirater les serveurs web NGINX pour ensuite router le trafic des visiteurs vers des serveurs qu’ils contrôlent, voici la campagne menée par un groupe de cybercriminels. Faisons le point sur cette menace potentielle.

Un nouveau rapport publié par les chercheurs en sécurité de chez DataDog Security Labs révèle une campagne d’attaques ciblant NGINX, le célèbre serveur web open source, capable de fonctionner aussi en tant que reverse proxy.

“Datadog Security Research a identifié des acteurs malveillants associés à la récente exploitation React2Shell menant une campagne visant à détourner le trafic web à l’aide de configurations NGINX malveillantes.“, précise le rapport. Pour autant, ce même document ne précise pas comment sont compromis les serveurs NGINX impactés par cette campagne.

À ce jour, l’Europe ne semble pas directement ciblée par ces attaques. Les attaquants cibleraient plutôt des services web avec des domaines de premier niveau asiatiques (.th, .in. id, etc.) et gouvernementaux (.edu, .gov) où les outils NGINX et Baota (interface de gestion de l’espace web) sont utilisés.

Grâce à un ensemble de scripts Bash, les pirates modifient la configuration du serveur compromis. Ces scripts modifient notamment les blocs de la configuration NGINX pour capturer le trafic entrant et le rediriger vers les domaines contrôlés par les attaquants. Pour cela, les attaquants s’appuient sur la fonction de reverse proxy de NGINX configurable via la directive .

Comme le montre l’image ci-dessous, les pirates parviennent à afficher du contenu malveillant auprès des visiteurs des sites web compromis.

Analyse de la chaîne d’infection Nginx

Une fois un serveur web compromis, l’attaque se déroule en 5 étapes où un script Bash spécifique est exécuté à chacune d’elles. Ce qui nous donne :

• Etape 1 – zx.sh

Ce script agit comme le dropper et l’orchestrateur initial de l’attaque. Une fois l’accès initial obtenu, est exécuté pour récupérer et lancer les étapes suivantes. Ce qui est intéressant avec ce script, c’est sa résilience : il tente d’abord d’utiliser des outils standards comme ou . Si ces outils sont absents ou bloqués sur le serveur compromis, il se tourne alors vers une fonction Bash capable d’ouvrir une connexion TCP brute (raw TCP) pour télécharger les charges utiles.

• Etape 2 – bt.sh

Ce script cible le panneau de gestion Baota. Il énumère les configurations dans , dans le but d’injecter une configuration. L’injection est dynamique : elle analyse la variable pour identifier le TLD (Top-Level Domain) et injecte un template de proxy malveillant sans tout casser.

• Etape 3 – 4zdh.sh

Il s’agit d’une variante plus robuste et avancée de la fonction d’injection. Contrairement à , il scanne l’ensemble des répertoires standards Nginx () en plus de Baota. Pour garantir la disponibilité du serveur, il utilise et pour insérer la configuration malveillante proprement sans casser les blocs de configuration existants. Avant de relancer le service Nginx, il prend également soin de valider la syntaxe avec la commande .

• Etape 4 – zdh.sh

Cette étape se concentre sur les environnements Linux où Nginx serait exécuté dans un conteneur, ce qui correspond aussi à un scénario où le serveur n’est pas équipé de Baota. Il se focalise sur le contenu du répertoire . Il injecte ensuite la configuration dans Nginx, sur le même principe qu’à l’étape précédente.

• Etape 5 – ok.sh

La dernière étape : assurer la reconnaissance et l’exfiltration. Il génère un rapport ( dans ou ) cartographiant l’ensemble des actions réalisées précédemment : domaines détournés, templates utilisés et serveurs de destination. Ces données sont ensuite exfiltrées vers le serveur C2 de l’attaquant.

Il est à noter que le serveur C2 des attaquants est associé à l’adresse IP suivante : .

Au final, nous pouvons constater qu’aucun service supplémentaire n’est exécuté sur le serveur compromis : les pirates ne font que modifier la configuration de Nginx. Cela peut donc s’avérer difficile à détecter si les fichiers de configuration ne sont pas surveillés.

Source