Analyse d'Artefact : Journaux de Connexion Linux (wtmp, btmp, lastlog)

Note

Résumé exécutif : bien que les journaux textuels comme auth.log ou secure fournissent des détails de haute précision sur le processus d’authentification, les systèmes Linux maintiennent également un ensemble parallèle de fichiers binaires structurés (wtmp, btmp, lastlog). Pour les analystes DFIR menant une investigation post-mortem sur une image disque, ces artefacts binaires sont essentiels pour établir rapidement une chronologie indiquant qui s’est connecté, depuis où et quand, ainsi que pour détecter les attaques automatisées ou les falsifications anti-forensiques.

1. Le trio des journaux binaires

Contrairement aux journaux en texte brut, ces fichiers ne peuvent pas être lus de manière fiable avec des outils standards comme cat ou grep sans risquer de corrompre ou de mal interpréter les données. Ils sont généralement situés dans /var/log/ et nécessitent des utilitaires en ligne de commande spécifiques pour décoder leurs structures C.

wtmp (Connexions réussies)

Enregistre l’historique de toutes les connexions utilisateurs réussies, des déconnexions, ainsi que des démarrages et arrêts du système. Il s’analyse avec la commande last.

btmp (Échecs de connexion)

Enregistre toutes les tentatives d’authentification échouées. Critique pour identifier les attaques par force brute (brute-force) ou par pulvérisation de mots de passe (password spraying). Il s’analyse avec la commande lastb.

lastlog (Dernière activité)

Une base de données à fichiers dispersés (sparse file) qui n’enregistre que la date et l’heure de la toute dernière connexion pour chaque UID du système. Il s’analyse avec la commande lastlog.

(Note : le fichier utmp enregistre l’état actuel en direct des utilisateurs connectés. Il est hautement volatil et généralement vidé au redémarrage, ce qui le rend moins pertinent pour une analyse post-mortem hors ligne.)

2. Traque des authentifications réussies (wtmp)

Le fichier wtmp sert de chronologie d’accès principale. Lors d’une analyse hors ligne sur une image forensique montée (ex: dans /mnt/analyse/), les analystes doivent forcer les outils à lire le fichier de preuve plutôt que les journaux en direct de la machine hôte.

parse_wtmp.sh

# -f cible l'artefact forensique spécifique
# -F affiche les dates complètes (incluant l'année) pour éviter toute confusion chronologique
last -F -f /mnt/analyse/var/log/wtmp

Focus d’investigation

• Adresses IP sources anormales : une connexion réussie depuis une adresse IP externe sur un serveur qui ne devrait être accessible que via un VPN d’administration est une alerte rouge absolue.
• Détournement de compte de service : observer une session shell interactive pour des comptes comme www-data, apache ou postgres est un indicateur quasi certain de la présence d’un Web Shell ou de l’exécution d’un reverse shell.
• Redémarrages système : les attaquants redémarrent fréquemment les systèmes (entrées shutdown ou reboot dans wtmp) pour charger des modules noyau malveillants ou effacer des artefacts en mémoire.

3. Traque des attaques par force brute (btmp)

Le fichier btmp est l’artefact principal pour quantifier les attaques sur les identifiants.

parse_btmp.sh

lastb -f /mnt/analyse/var/log/btmp

Interprétation DFIR

• Force brute vs erreur humaine : quelques tentatives échouées suivies d’un succès dans wtmp indiquent généralement une faute de frappe. Des milliers d’échecs provenant d’une seule IP en quelques minutes signent une attaque automatisée.
• Ciblé vs opportuniste : si le fichier btmp montre des tentatives ciblant des comptes inexistants ou génériques (admin, test, oracle), l’attaque est probablement un scan automatisé opportuniste. Des tentatives ciblant spécifiquement des noms d’utilisateurs d’employés valides et non privilégiés suggèrent une campagne de pulvérisation de mots de passe ciblée.

4. Profilage des comptes dormants (lastlog)

Le fichier lastlog est structuré de manière unique ; c’est une table associant les UIDs à leur dernier horodatage de connexion.

parse_lastlog.sh

# -R spécifie le répertoire racine, permettant à l'outil d'associer les UIDs aux noms d'utilisateurs
# en utilisant le fichier /etc/passwd du système compromis plutôt que celui de la station d'analyse.
lastlog -R /mnt/analyse/

Interprétation DFIR

Les analystes doivent rechercher le “réveil” de comptes dormants. Si le compte d’un ancien employé ou un compte de service (bin, daemon, adm) passe de l’état “Jamais connecté” (Never logged in) à une date récente correspondant à la fenêtre de l’incident, l’attaquant a très probablement ressuscité ou détourné ce compte pour assurer sa persistance.

5. Analyse avancée et anti-forensique (utmpdump)

Les acteurs de la menace connaissent ces journaux et tentent fréquemment de les effacer à l’aide de commandes comme echo > /var/log/wtmp ou d’outils de nettoyage (wipers) personnalisés.

Lorsque les commandes natives comme last échouent en raison d’une corruption de fichier, ou lorsque les analystes doivent exporter les données vers un SIEM, utmpdump est l’outil chirurgical de choix. Il traduit les structures binaires brutes en texte lisible par l’homme.

utmpdump_export.sh

utmpdump /mnt/analyse/var/log/wtmp > wtmp_export_forensic.txt

Détection de l’effacement de journaux (Log Wiping)

Si un attaquant utilise un nettoyeur de journaux rudimentaire qui écrase les entrées avec des octets nuls (\x00), la commande last pourrait ignorer silencieusement la corruption et sauter ces entrées. Cependant, utmpdump révélera ces anomalies, affichant des enregistrements malformés ou vides qui prouvent de manière définitive une falsification anti-forensique intentionnelle.

6. Pièges critiques en DFIR

1. Le piège du fuseau horaire (Timezone) : les commandes last et lastb formatent les horodatages en fonction du fuseau horaire local de la station de travail de l’analyste, et non du fuseau horaire du système compromis. Les analystes doivent méticuleusement tenir compte de ce décalage ou utiliser utmpdump pour visualiser les horodatages bruts et non ajustés afin d’éviter des erreurs catastrophiques dans la reconstitution de la chronologie.
2. Rotation des journaux : Linux effectue une rotation agressive des journaux. Les analystes doivent s’assurer d’analyser également les fichiers archivés (wtmp.1, btmp.1) pour capturer l’étendue complète d’intrusions plus anciennes.
3. Artefacts vides : si wtmp ou btmp ont une taille de 0 octet sur un serveur opérationnel, il est hautement probable que l’acteur malveillant ait exécuté un effacement destructif. Les analystes doivent immédiatement pivoter pour rechercher les actions de l’attaquant dans l’historique du shell Linux.

---

Références et lectures complémentaires

• SANS Institute : Advanced Incident Response and Threat Hunting
• Artefact lié : Journaux d’authentification Linux (auth.log & secure)
• Artefact lié : Analyse de l’historique shell Linux (.bash_history)