Analyse d'Artefact : Comptes et Privilèges Linux

1. L’annuaire des utilisateurs (`/etc/passwd`)

Ce fichier définit tous les comptes humains et de service, leurs identifiants uniques (UID) et leurs environnements d’exécution. Parce qu’il est lisible par tous (rw-r--r--), il est massivement ciblé lors de la phase de reconnaissance de l’attaquant.

Format : nom_utilisateur:mot_de_passe_placeholder:UID:GID:Commentaire:Repertoire_Personnel:Shell

Lors de l’analyse d’une image forensique montée (ex: dans /mnt/analyse/), les analystes doivent rechercher trois anomalies spécifiques :

A. Le Root caché (UID 0)

Seul le compte root devrait posséder un identifiant utilisateur (UID) de 0. Les acteurs de la menace créent souvent un compte d’apparence inoffensive (ex: support ou sysupdate) et lui assignent l’UID 0. Le noyau Linux évalue les privilèges en fonction de l’UID, et non du nom d’utilisateur. Par conséquent, ce compte devient une backdoor furtive disposant de privilèges absolus.

# Recherche de tout compte possédant l'UID 0
awk -F: '($3 == "0") {print}' /mnt/analyse/etc/passwd

B. Shells suspects pour les comptes de service

Les comptes de service conçus pour exécuter des démons en arrière-plan (www-data, apache, mysql, postgres) ne devraient jamais posséder de shell de connexion interactif. Leur champ shell devrait être explicitement défini sur /usr/sbin/nologin ou /bin/false. Si un analyste découvre que /bin/bash ou /bin/sh a été assigné à www-data, c’est un indicateur quasi certain que l’attaquant a modifié le compte pour générer un reverse shell interactif (souvent suite à l’exploitation d’une application web).

C. Ajouts récents

Les nouveaux utilisateurs sont ajoutés à la fin du fichier /etc/passwd. L’examen des 5 à 10 dernières lignes expose rapidement les comptes backdoors nouvellement créés.

2. Le coffre-fort des secrets (`/etc/shadow`)

Ce fichier contient les véritables hashs de mots de passe et les politiques d’expiration des comptes. Pour protéger les identifiants, il n’est strictement lisible que par root.

Format : nom_utilisateur:hash:dernier_changement:min:max:avertissement:inactif:expiration

A. Mots de passe vides

Si le champ hash est entièrement vide ou contient des chaînes d’authentification invalides permettant le contournement (selon la configuration PAM), le compte peut être accédé via SSH ou un TTY local sans mot de passe. Il s’agit d’une erreur de configuration critique ou d’une backdoor intentionnelle.

B. Comptes de service avec des hashs

Les comptes de service légitimes (comme bin ou daemon) ont typiquement un astérisque (*) ou un point d’exclamation (!) dans le champ hash, les verrouillant contre l’authentification par mot de passe. Si un compte de service possède un long hash cryptographique (ex: commençant par $6$ pour SHA-512), un attaquant a explicitement défini un mot de passe pour détourner le compte et s’en servir comme persistance.

C. Réutilisation de hash (Hash Reuse)

Les acteurs de la menace peuvent copier le hash d’un utilisateur compromis connu et le coller dans l’entrée shadow d’un compte backdoor nouvellement créé. Si deux noms d’utilisateurs distincts partagent exactement la même chaîne de hachage, cela indique une manipulation manuelle et non autorisée du fichier shadow.

3. Élévation de privilèges (`/etc/group`)

Ce fichier définit les appartenances aux groupes. Son analyse révèle l’élévation de privilèges “horizontale” ou “verticale”.

Les analystes DFIR doivent identifier quels utilisateurs sont membres des “Groupes Dieu” — des groupes qui accordent la capacité d’exécuter des commandes en tant que root (généralement via sudo).

wheel : le groupe administratif par défaut sur les systèmes RHEL/CentOS.
sudo : le groupe administratif par défaut sur les systèmes Debian/Ubuntu.
root : GID 0.
docker : vecteur de menace critique. Tout utilisateur ajouté au groupe docker possède essentiellement les privilèges root. Un acteur malveillant dans ce groupe peut générer un conteneur privilégié, monter le système de fichiers racine de l’hôte (/) et effectuer un chroot à l’intérieur, contournant ainsi toutes les limites de sécurité standards de l’OS.

# Recherche de membres non autorisés dans les groupes privilégiés
grep -E "^(wheel|sudo|root|docker|admin):" /mnt/analyse/etc/group

4. Métadonnées et corrélation temporelle

Avant d’analyser le contenu de ces fichiers, les analystes doivent évaluer leurs métadonnées, spécifiquement l’heure de modification (mtime).

ls -lart /mnt/analyse/etc/passwd /mnt/analyse/etc/shadow /mnt/analyse/etc/group

Pivot forensique : si l’incident s’est produit le 12 février et que le mtime du fichier /etc/shadow indique le 12 février à 03h00 (alors que le reste du répertoire /etc/ n’a pas été modifié depuis des mois), cela fournit la preuve définitive qu’un compte a été créé ou qu’un mot de passe a été altéré durant la fenêtre de l’intrusion.

5. Triage DFIR et automatisation

Afin d’accélérer le triage sur une image forensique montée, les équipes DFIR utilisent des scripts bash automatisés pour identifier rapidement les anomalies structurelles à travers les fichiers de configuration des comptes.

Bash (Script d'audit des comptes)

#!/bin/bash
TARGET_DIR="/mnt/analyse"

echo "[+] Vérification des comptes avec UID 0 cachés..."
awk -F: '($3 == "0" && $1 != "root") {print "ALERTE : " $1 " a lUID 0"}' $TARGET_DIR/etc/passwd

echo "[+] Vérification des comptes de service avec shells interactifs..."
awk -F: '($3 < 1000 && $7 ~ /(bash|sh|zsh)$/ && $1 != "root") {print "ATTENTION : " $1 " a le shell " $7}' $TARGET_DIR/etc/passwd

echo "[+] Vérification des comptes sans mot de passe dans shadow..."
awk -F: '($2 == "" || $2 == "::") {print "CRITIQUE : " $1 " n a pas de mot de passe"}' $TARGET_DIR/etc/shadow

echo "[+] Vérification des utilisateurs non autorisés dans les groupes privilégiés..."
grep -E "^(wheel|sudo|root|docker|admin):" $TARGET_DIR/etc/group

Prochaines étapes de corrélation

Si un compte backdoor suspect est identifié, pivotez immédiatement vers les journaux d’authentification Linux (auth.log / secure) pour déterminer exactement quand la commande useradd ou usermod a été exécutée et par quel compte administratif compromis.

Références et lectures complémentaires

SANS Institute : Advanced Incident Response and Threat Hunting
GTFOBins : Élévation de privilèges via Docker
Artefact lié : Journaux d’authentification Linux (auth.log)
Artefact lié : Historique Shell Linux (.bash_history)