Analyse d'Artefact : Journaux d'Authentification Linux (auth.log & secure)

Note

Résumé exécutif : bien que les journaux binaires comme wtmp fournissent un registre de base des connexions et déconnexions des utilisateurs, les fichiers texte auth.log (sur Debian/Ubuntu) et secure (sur RHEL/CentOS) agissent comme les caméras de sécurité haute définition du système d’exploitation. Ils enregistrent les détails techniques de chaque tentative d’authentification, les mécanismes spécifiques utilisés (mots de passe vs clés publiques), les élévations de privilèges (sudo, su) et les événements du cycle de vie des comptes. Pour les analystes DFIR, la maîtrise de ces journaux est essentielle pour reconstituer l’accès initial et le mouvement latéral.

1. Emplacement de l’artefact et rotation des journaux

Les journaux d’authentification sont stockés en texte brut, permettant aux analystes de les examiner à l’aide d’utilitaires Unix standards (grep, awk, sed) directement depuis une image forensique montée (ex: /mnt/analyse/).

• Systèmes Debian / Ubuntu / Kali : /var/log/auth.log
• Systèmes RHEL / CentOS / Fedora : /var/log/secure

Maîtriser la rotation des journaux (Log Rotation)

Les distributions Linux utilisent le démon logrotate pour archiver les anciens journaux et prévenir la saturation des disques. Lors de l’investigation d’un incident, les analystes ne doivent jamais limiter leur périmètre au seul fichier actif.

Journaux actifs

auth.log ou secure - contient les événements d’authentification les plus récents en texte brut.

Journaux archivés

auth.log.1 (texte brut récemment archivé), auth.log.2.gz (plus ancien, compressé). Les analystes doivent utiliser zgrep ou zcat pour effectuer des recherches à travers les archives compressées sans altérer la preuve par une extraction manuelle.

2. Analyse des connexions SSH (le vecteur principal)

Le protocole Secure Shell (SSH) demeure le principal vecteur d’accès initial et de mouvement latéral pour les acteurs malveillants ciblant les infrastructures Linux. L’identification de schémas (pattern matching) au sein de ces journaux révèle la méthodologie de l’attaquant.

A. Authentifications réussies

Identifier la méthode d’authentification d’un attaquant fournit une indication immédiate sur la gravité de la compromission.

• Authentification par mot de passe :

  ssh_password_success.sh

  grep "Accepted password" /mnt/analyse/var/log/auth.log

  Valeur forensique : indique que l’acteur malveillant possédait un identifiant valide ou a réussi une attaque par force brute.
• Authentification par clé publique :

  ssh_pubkey_success.sh

  grep "Accepted publickey" /mnt/analyse/var/log/auth.log

  Valeur forensique : indique que l’attaquant possède la clé privée correspondante. L’entrée du journal révèle souvent l’empreinte (fingerprint) de la clé, permettant aux analystes de relier l’authentification à une ligne spécifique du fichier ~/.ssh/authorized_keys de l’utilisateur.

B. Échecs d’authentification (Brute Force et Spraying)

• Mots de passe incorrects : grep "Failed password" révèle les tentatives classiques de force brute.
• Utilisateurs inconnus : grep "Invalid user" signale un balayage automatisé. Un volume élevé de ces journaux ciblant des comptes administratifs communs (ex: admin, root, oracle) suggère fortement des tentatives d’exploitation de masse non ciblées.

3. Élévation de privilèges et exécution Sudo

Retracer ce qu’un utilisateur standard compromis a accompli avec des droits administratifs est une mine d’or comportementale. Sauf désactivation explicite dans la configuration, l’utilitaire sudo consigne la commande exacte exécutée.

sudo_execution_tracking.sh

grep "COMMAND=" /mnt/analyse/var/log/auth.log

Décortiquer une entrée de journal Sudo

Une entrée de journal sudo standard suit un format strict : Feb 6 10:00:00 server sudo: nico : TTY=pts/0 ; PWD=/home/nico ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow

• Qui : nico (le compte compromis)
• Où : PWD=/home/nico (le répertoire de travail au moment de l’exécution)
• Contexte cible : USER=root (les privilèges assumés)
• Action : COMMAND=/usr/bin/cat /etc/shadow (le binaire exécuté et ses arguments)

Indicateurs d’attaque via Sudo

Les analystes doivent rechercher activement :

1. Shells Root Interactifs : des commandes comme sudo su - ou sudo -i. Une fois qu’un attaquant obtient un shell root interactif, les commandes individuelles ne sont plus consignées dans auth.log. L’investigation doit immédiatement pivoter vers l’historique Shell Linux (.bash_history) de l’utilisateur root.
2. Évasion GTFOBins : l’exécution de binaires permettant de s’échapper vers un shell, tels que sudo awk, sudo find ou sudo nmap.
3. Modification de fichiers : l’exécution de sudo edit ou sudo vi ciblant des fichiers système critiques.

4. Persistance et manipulation des comptes

Les acteurs malveillants établissent fréquemment leur persistance en créant des comptes portes dérobées (backdoors) ou en modifiant les appartenances aux groupes. Le journal d’authentification trace méticuleusement ces altérations.

• Création de compte : grep "new user" aide à identifier les comptes backdoors déguisés en services système (ex: sysadmin, backup_svc).
• Manipulation de mot de passe : grep "password changed" suit les réinitialisations d’identifiants non autorisées.
• Octroi de privilèges : grep "add group" révèle si un attaquant a ajouté un compte standard compromis à des groupes hautement privilégiés tels que sudo, wheel ou root.

5. Stratégie de triage DFIR et corrélation

Afin de maximiser l’efficacité de l’analyse des journaux durant un incident, les équipes DFIR emploient des stratégies de corrélation spécifiques.

1. Identifier les “Top Talkers” : extraire rapidement les 10 adresses IP principales menant des attaques par force brute afin d’alimenter les listes de blocage du pare-feu.

   extract_top_attackers.sh

   cat /mnt/analyse/var/log/auth.log | grep "Failed password" | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head

2. Tracer le mouvement latéral : filtrer les connexions SSH réussies pour isoler les adresses IP internes (ex: 192.168.x.x ou 10.x.x.x). Une connexion réussie depuis un autre serveur interne cartographie le chemin de mouvement latéral de l’attaquant.
3. Détecter l’effacement de traces (Anti-Forensique) : les acteurs malveillants tentent souvent de couvrir leurs traces en effaçant les journaux. Si le démon de journalisation (rsyslog ou systemd-journald) présente des redémarrages suspects durant la fenêtre de l’incident, ou si des “trous” chronologiques inexplicables apparaissent dans le fichier texte, il s’agit d’un indicateur de haute fidélité de falsification des journaux.

---

Références et lectures complémentaires

• SANS Institute : Advanced Incident Response and Threat Hunting
• GTFOBins : Privilege Escalation via Sudo
• Artefact lié : Analyse de l’historique Shell Linux (.bash_history)