Environnement : Machine virtuelle de simulation d'intrusion
Identifiants : defend
Objectifs : Identifier 3 flags cachés et retrouver l'adresse IP de l'attaquant

Identification de l'attaquant

Premièrement, analyser les connexions récentes au système :

last -a | head -20
who -a

Identifier l'IP source associée au compte root. Cette adresse est potentiellement celle de l'intrus. La confirmation se fera via les logs des services exploités.

Audit des comptes utilisateurs

Recherche de comptes à privilèges élevés

# Extraire les comptes possédant UID 0 (privilèges root)
awk -F: '$3==0 {print $1}' /etc/passwd

# Lister les comptes normaux avec leurs attributs
awk -F: '$3>=1000 {printf "%s (UID:%s Home:%s)\n",$1,$3,$6}' /etc/passwd

Points de vigilance : comptes sans description, répertoire personnel anormal (ex : /tmp), interpréteur /bin/bash sans propriétaire identifiable, noms suspects (miner, hack, redis créé manuellement).

Traces de modification des fichiers d'authentification

# Vérifier les dates de modification des fichiers critiques
stat /etc/passwd /etc/shadow 2>/dev/null

# Rechercher les commandes de création de comptes dans les logs
grep -iE "useradd|adduser|new user" /var/log/auth.log /var/log/secure* 2>/dev/null

# Interroger l'historique des commandes shell
grep -iE "useradd|usermod|passwd" /root/.bash_history /home/*/.bash_history 2>/dev/null

Détection d'utilisateurs masqués ou anormaux

# Comptes sans mot de passe (connexion directe possible)
awk -F: '($2=="" || $2=="!") {print $1}' /etc/shadow

# Vérifier les règles sudo existantes
grep -vE "^#|^$" /etc/sudoers 2>/dev/null
ls -la /etc/sudoers.d/ 2>/dev/null

# Détecter les noms contenant des caractères inhabituels
grep -P "[\s\x24\x2a]" /etc/passwd 2>/dev/null

Examen des processus suspects

Critères de détection :

• Ligne de commande vague ou tronquée (./run, sh -c ...)
• Exécutable situé dans des répertoires temproaires (/tmp, /var/tmp, /dev/shm)
• Processus en arrière-plan sans terminal attribué (STAT Ss ou S<)
• Noms usurpés imitant des services légitimes (sshd avec orthographe modifiée)

# Affichage détaillé des processus
ps auxf

# Pour chaque PID suspect, inspecter :
EXE_PATH="/proc/$SUSPECT_PID/exe"
CMD_LINE="/proc/$SUSPECT_PID/cmdline"
ls -la $EXE_PATH 2>/dev/null
cat $CMD_LINE 2>/dev/null | tr '\0' ' '

# Vérifier les connexions réseau actives du processus
ss -tnp | grep "pid=$SUSPECT_PID"

# Arborescence des processus pour retrouver le lanceur
pstree -pAla | grep -A2 -B2 "nom_suspect"

# Comparer les résultats ps avec /proc pour détecter les dissimulations
ls /proc | grep -E "^[0-9]+$" | while read pid; do
    ps -p "$pid" > /dev/null 2>&1 || echo "PID $pid masqué !"
done

Récupération du Flag 1

Basculer vers l'utilisateur root puis consulter l'historique des commandes :

su - root
history | less

Le flag est directement visible dans les commandes exécutées par l'intrus.

Récupération du Flag 2

L'historique révèle une modification du fichier /etc/rc.d/rc.local. Ce fichier constitue un vecteur classique de persistance : il permet l'exécution automatique de scripts au démarrage du système.

cat /etc/rc.d/rc.local

Le contenu de ce fichier contient le deuxième flag.

Récupération du Flag 3

L'existence d'un compte redis nouvellement créé suggère un service Redis installé. Vérifier l'état du port 6379 :

ss -tlnp | grep 6379

Si le service n'est pas actif, le démarrer :

systemctl start redis
# ou
redis-server --daemonize yes

Depuis un second terminal, tester l'accès sans authentification :

redis-cli -h 127.0.0.1 -p 6379 INFO server

Si la connexion réussit sans mot de passe, l'attaquant a pu exploiter cette vulnérabilité pour écrire des fichiers sensibles. Vérifier :

ls -la /root/.ssh/
cat /root/.ssh/authorized_keys

La présence d'une clé publique étrangère confirme la méthode d'intrusion : l'attaquant a utilisé Redis pour injecter sa clé SSH et obtenir un accès root distant.

Pour retrouver le fichier de configuration Redis modifié :

rpm -Vf /usr/bin/redis-server 2>/dev/null
find /etc/redis -type f -exec ls -la {} \;
cat /etc/redis/redis.conf | grep -vE "^#|^$"

Le troisième flag se trouve dans la configuration Redis.

Pour confirmer l'IP de l'attaquant via les logs Redis :

grep -i "connect" /var/log/redis/redis.log 2>/dev/null

L'adresse 192.168.75.129 apparaît dans les tentatives de connexion, confirmant qu'il s'agit bien de l'IP de l'intrus.

Synthèse méthodologique

Phase 1 : Identification de la source de l'attaque

Analyser les logs de connexion système pour extraire les IP associées au compte root. Corréler ces informations avec les journaux des services réseau (Redis) pour valider le comportement malveillant.

Phase 2 : Audit de la sécurité des comptes

L'audit couvre trois axes :

• Privilèges : Détecter tout compte avec UID 0 hors root
• Création : Examiner les modifications des fichiers passwd/shadow et les logs d'authentification
• Anomalies : Identifier les comptes sans mot de passe, les configurations sudo inhabituelles et les noms déguisés

Phase 3 : Extraction des indicateurs de compromission

• Flag 1 : Extrait de l'historique des commandes shell
• Flag 2 : Localisé dans le script de démarrage (rc.local)
• Flag 3 : Trouvé dans la configuration Redis après vérification de l'exploitation du service

Phase 4 : Reconstitution de la chaîne d'attaque

L'attaquant a :

1. Exploité une instance Redis exposée sans authentification
2. Utilisé la commande CONFIG SET pour écrire sa clé publique SSH dans /root/.ssh/authorized_keys
3. Obtenu un accès SSH root permanent vers la machine compromise