Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour construire et **automatiser des flux de travail** alimentés par les outils communautaires les plus avancés au monde.\
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? Ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Tout d'abord, il est recommandé d'avoir une **clé USB** avec des **binaires et des bibliothèques bien connus** (vous pouvez simplement obtenir Ubuntu et copier les dossiers _/bin_, _/sbin_, _/lib_ et _/lib64_), puis monter la clé USB et modifier les variables d'environnement pour utiliser ces binaires :
Une fois que vous avez configuré le système pour utiliser des binaires fiables et connus, vous pouvez commencer à **extraire quelques informations de base** :
* Les **processus root** s'exécutent généralement avec de petits PIDs, donc si vous trouvez un processus root avec un grand PID, vous pouvez suspecter.
* Vérifiez les **connexions enregistrées** des utilisateurs sans shell dans `/etc/passwd`.
* Vérifiez les **hachages de mots de passe** dans `/etc/shadow` pour les utilisateurs sans shell.
Dans d'autres cas, vous devez télécharger [**LiME**](https://github.com/504ensicsLabs/LiME) depuis github et le compiler avec les bons en-têtes de noyau. Pour **obtenir les en-têtes de noyau exacts** de la machine victime, vous pouvez simplement **copier le répertoire**`/lib/modules/<version du noyau>` sur votre machine, puis **compiler** LiME en les utilisant :
LiME peut également être utilisé pour **envoyer la capture via le réseau** au lieu de la stocker sur le système en utilisant quelque chose comme : `path=tcp:4444`
Tout d'abord, vous devrez **arrêter le système**. Ce n'est pas toujours une option car parfois le système sera un serveur de production que l'entreprise ne peut pas se permettre d'arrêter.\
Il existe **2 façons** d'arrêter le système, un **arrêt normal** et un **arrêt "débrancher la prise"**. Le premier permettra aux **processus de se terminer normalement** et au **système de fichiers** d'être **synchronisé**, mais il permettra également au **logiciel malveillant éventuel** de **détruire les preuves**. L'approche "débrancher la prise" peut entraîner **une perte d'informations** (peu d'informations seront perdues car nous avons déjà pris une image de la mémoire) et le **logiciel malveillant n'aura aucune opportunité** d'y remédier. Par conséquent, si vous **soupçonnez** la présence d'un **logiciel malveillant**, exécutez simplement la commande **`sync`** sur le système et débranchez la prise.
Il est important de noter que **avant de connecter votre ordinateur à quoi que ce soit lié à l'affaire**, vous devez vous assurer qu'il sera **monté en lecture seule** pour éviter de modifier les informations.
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour construire et automatiser facilement des flux de travail alimentés par les outils communautaires les plus avancés au monde.\
Certains systèmes Linux disposent d'une fonctionnalité permettant de vérifier l'intégrité de nombreux composants installés, offrant ainsi un moyen efficace d'identifier des fichiers inhabituels ou hors de leur emplacement habituel. Par exemple, `rpm -Va` sur Linux est conçu pour vérifier tous les packages qui ont été installés à l'aide du gestionnaire de paquets RedHat.
Sur les systèmes basés sur Debian, le fichier _**/var/lib/dpkg/status**_ contient des détails sur les paquets installés et le fichier _**/var/log/dpkg.log**_ enregistre des informations lorsqu'un paquet est installé.\
Sur RedHat et les distributions Linux connexes, la commande **`rpm -qa --root=/mntpath/var/lib/rpm`** répertorie le contenu d'une base de données RPM sur un système.
**Tous les programmes installés ne seront pas répertoriés par les commandes ci-dessus** car certaines applications ne sont pas disponibles sous forme de packages pour certains systèmes et doivent être installées à partir de la source. Par conséquent, une vérification des emplacements tels que _**/usr/local**_ et _**/opt**_ peut révéler d'autres applications qui ont été compilées et installées à partir du code source.
Une autre bonne idée est de **vérifier** les **dossiers courants** à l'intérieur de **$PATH** pour les **binaires non liés** aux **paquets installés** :
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour construire et automatiser facilement des flux de travail alimentés par les outils communautaires les plus avancés au monde.\
Il est extrêmement courant que les logiciels malveillants s'implantent en tant que nouveaux services non autorisés. Linux dispose de plusieurs scripts utilisés pour démarrer les services au démarrage de l'ordinateur. Le script d'initialisation de démarrage _**/etc/inittab**_ appelle d'autres scripts tels que rc.sysinit et divers scripts de démarrage dans le répertoire _**/etc/rc.d/**_, ou _**/etc/rc.boot/**_ dans certaines anciennes versions. Dans d'autres versions de Linux, comme Debian, les scripts de démarrage sont stockés dans le répertoire _**/etc/init.d/**_. De plus, certains services courants sont activés dans _**/etc/inetd.conf**_ ou _**/etc/xinetd/**_ en fonction de la version de Linux. Les enquêteurs numériques doivent inspecter chacun de ces scripts de démarrage à la recherche d'entrées anormales.
Sur les systèmes Linux, les modules du noyau sont couramment utilisés comme composants de rootkit pour les packages de logiciels malveillants. Les modules du noyau sont chargés lorsque le système démarre en fonction des informations de configuration dans les répertoires `/lib/modules/'uname -r'` et `/etc/modprobe.d`, ainsi que du fichier `/etc/modprobe` ou `/etc/modprobe.conf`. Ces zones doivent être inspectées pour repérer les éléments liés aux logiciels malveillants.
Il existe plusieurs fichiers de configuration que Linux utilise pour lancer automatiquement un exécutable lorsqu'un utilisateur se connecte au système et qui peuvent contenir des traces de logiciels malveillants.
* _**/etc/profile.d/\***_, _**/etc/profile**_, _**/etc/bash.bashrc**_ sont exécutés lorsque n'importe quel compte utilisateur se connecte.
* _**∼/.bashrc**_, _**∼/.bash\_profile**_, _**\~/.profile**_, _**∼/.config/autostart**_ sont exécutés lorsque l'utilisateur spécifique se connecte.
* _**/etc/rc.local**_ est traditionnellement exécuté après le démarrage de tous les services système normaux, à la fin du processus de passage à un niveau d'exécution multi-utilisateurs.
Consultez tous les fichiers journaux disponibles sur le système compromis à la recherche de traces d'exécution malveillante et d'activités associées telles que la création d'un nouveau service.
Les événements de **connexion** enregistrés dans les journaux système et de sécurité, y compris les connexions via le réseau, peuvent révéler que des **logiciels malveillants** ou un **intrus ont accédé** à un système compromis via un compte donné à un moment précis. D'autres événements autour du moment d'une infection par des logiciels malveillants peuvent être capturés dans les journaux système, y compris la **création** d'un **nouveau****service** ou de nouveaux comptes autour de l'incident.\
* Affiche des messages généraux et des informations concernant le système. Il s'agit d'un journal de données de toutes les activités dans l'ensemble du système global.
* Conserve les journaux d'authentification pour les connexions réussies ou échouées, ainsi que les processus d'authentification. Le stockage dépend du type de système.
*`cat /var/log/auth.log | grep -iE "session opened for|accepted password|new session|not in sudoers"`
* **/var/log/boot.log** : messages de démarrage et informations de démarrage.
* **/var/log/maillog** ou **var/log/mail.log** : est destiné aux journaux du serveur de messagerie, pratique pour les informations sur postfix, smtpd ou les services liés aux e-mails exécutés sur votre serveur.
* **/var/log/kern.log** : conserve les journaux du noyau et les informations d'avertissement. Les journaux d'activité du noyau (par exemple, dmesg, kern.log, klog) peuvent montrer qu'un service particulier a planté à plusieurs reprises, ce qui peut indiquer l'installation d'une version trojanisée instable.
* **/var/log/dmesg** : un référentiel pour les messages du pilote de périphérique. Utilisez **dmesg** pour voir les messages dans ce fichier.
* **/var/log/faillog** : enregistre des informations sur les connexions échouées. Utile pour examiner les violations de sécurité potentielles telles que les piratages de mots de passe de connexion et les attaques par force brute.
* **/var/log/cron** : enregistre les messages liés à Crond (tâches cron). Par exemple, lorsque le démon cron a démarré une tâche.
* **/var/log/daemon.log** : suit les services d'arrière-plan en cours d'exécution, mais ne les représente pas graphiquement.
* **/var/log/btmp** : enregistre toutes les tentatives de connexion échouées.
* **/var/log/httpd/** : un répertoire contenant les fichiers error\_log et access\_log du démon Apache httpd. Toutes les erreurs rencontrées par httpd sont conservées dans le fichier **error\_log**. Pensez aux problèmes de mémoire et aux autres erreurs liées au système. **access\_log** enregistre toutes les demandes reçues via HTTP.
* **/var/log/mysqld.log** ou **/var/log/mysql.log** : fichier journal MySQL qui enregistre chaque message de débogage, d'échec et de réussite, y compris le démarrage, l'arrêt et le redémarrage du démon MySQL mysqld. Le système décide du répertoire. Les systèmes RedHat, CentOS, Fedora et autres systèmes basés sur RedHat utilisent /var/log/mariadb/mariadb.log. Cependant, Debian/Ubuntu utilise le répertoire /var/log/mysql/error.log.
* **/var/log/xferlog** : conserve les sessions de transfert de fichiers FTP. Comprend des informations telles que les noms de fichiers et les transferts FTP initiés par l'utilisateur.
Les journaux système Linux et les sous-systèmes d'audit peuvent être désactivés ou supprimés lors d'une intrusion ou d'un incident de logiciel malveillant. Étant donné que les journaux sur les systèmes Linux contiennent généralement certaines des informations les plus utiles sur les activités malveillantes, les intrus les suppriment régulièrement. Par conséquent, lors de l'examen des fichiers journaux disponibles, il est important de rechercher des lacunes ou des entrées désordonnées qui pourraient indiquer une suppression ou une manipulation.
Cela est important car les **attaquants** peuvent parfois copier `/bin/bash` à l'intérieur de `/bin/false`, de sorte que des utilisateurs comme **lightdm** peuvent être **capables de se connecter**.
* **SSH**: Les connexions aux systèmes effectuées à l'aide de SSH depuis un système compromis entraînent la création d'entrées dans les fichiers de chaque compte utilisateur (_**∼/.ssh/authorized\_keys**_ et _**∼/.ssh/known\_keys**_). Ces entrées peuvent révéler le nom d'hôte ou l'adresse IP des hôtes distants.
* **Bureau Gnome**: Les comptes utilisateur peuvent avoir un fichier _**∼/.recently-used.xbel**_ qui contient des informations sur les fichiers récemment consultés à l'aide des applications exécutées sur le bureau Gnome.
* **VIM**: Les comptes utilisateur peuvent avoir un fichier _**∼/.viminfo**_ qui contient des détails sur l'utilisation de VIM, y compris l'historique des chaînes de recherche et les chemins des fichiers ouverts avec vim.
* **Open Office**: Fichiers récents.
* **MySQL**: Les comptes utilisateur peuvent avoir un fichier _**∼/.mysql\_history**_ qui contient les requêtes exécutées avec MySQL.
* **Less**: Les comptes utilisateur peuvent avoir un fichier _**∼/.lesshst**_ qui contient des détails sur l'utilisation de less, y compris l'historique des chaînes de recherche et les commandes shell exécutées via less.
### Journaux USB
[**usbrip**](https://github.com/snovvcrash/usbrip) est un petit logiciel écrit en Python 3 pur qui analyse les fichiers journaux Linux (`/var/log/syslog*` ou `/var/log/messages*` selon la distribution) pour construire des tables d'historique des événements USB.
Il est intéressant de **connaître tous les périphériques USB qui ont été utilisés** et cela sera encore plus utile si vous disposez d'une liste autorisée de périphériques USB pour détecter les "événements de violation" (l'utilisation de périphériques USB qui ne figurent pas dans cette liste).
By collecting volatile data from the target Linux system, we can gain insights into the running processes, network connections, open files, and system logs. This information can be useful for identifying any suspicious activities or potential security breaches.
3. Analyze the output to gather information such as file size, permissions, owner, and modification timestamps.
##### Analysis
Analyzing file metadata can provide valuable information about a file, including its size, permissions, owner, and timestamps. This information can help in understanding the file's purpose, its origin, and any potential modifications or tampering.
Replace `<device>` with the device or partition where the deleted files were located, and `<output_directory>` with the directory where the recovered files should be saved.
Recovering deleted files can be crucial in forensic investigations as it can provide valuable evidence or information that was intentionally or accidentally deleted. By using forensic tools like Scalpel, we can search for and recover deleted files from a Linux system.
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour créer facilement et automatiser des flux de travail avec les outils communautaires les plus avancés au monde.\
Examinez les fichiers _**/etc/passwd**_, _**/etc/shadow**_ et les **journaux de sécurité** à la recherche de noms ou de comptes inhabituels créés et/ou utilisés à proximité d'événements non autorisés connus. Vérifiez également les éventuelles attaques de force brute sudo.\
Les structures de données du système de fichiers peuvent fournir des quantités importantes d'**informations** liées à un incident de **logiciel malveillant**, y compris le **moment** des événements et le **contenu** réel du **logiciel malveillant**.\
Les logiciels malveillants sont de plus en plus conçus pour **contourner l'analyse du système de fichiers**. Certains logiciels malveillants modifient les horodatages des fichiers malveillants pour les rendre plus difficiles à trouver avec une analyse chronologique. D'autres codes malveillants sont conçus pour stocker uniquement certaines informations en mémoire afin de réduire la quantité de données stockées dans le système de fichiers.\
Pour faire face à de telles techniques anti-forensiques, il est nécessaire de porter une **attention particulière à l'analyse chronologique** des horodatages du système de fichiers et aux fichiers stockés dans des emplacements courants où des logiciels malveillants pourraient être trouvés.
* Avec **autopsy**, vous pouvez voir la chronologie des événements qui peut être utile pour découvrir une activité suspecte. Vous pouvez également utiliser la fonction `mactime` de **Sleuth Kit** directement.
* Vérifiez la présence de **scripts inattendus** dans **$PATH** (peut-être des scripts sh ou php ?)
* Les fichiers dans `/dev` étaient autrefois des fichiers spéciaux, vous pouvez trouver ici des fichiers non spéciaux liés à des logiciels malveillants.
* Examinez les horodatages des **inodes supprimés pour un grand nombre de fichiers supprimés à la même heure**, ce qui pourrait indiquer une activité malveillante telle que l'installation d'un rootkit ou d'un service trojanisé.
* Étant donné que les inodes sont alloués sur la base du prochain disponible, **des fichiers malveillants placés sur le système à peu près au même moment peuvent se voir attribuer des inodes consécutifs**. Par conséquent, après avoir localisé un composant de logiciel malveillant, il peut être productif d'inspecter les inodes voisins.
* Vérifiez également les répertoires tels que _/bin_ ou _/sbin_ car l'heure de **modification et/ou de changement** des nouveaux fichiers ou des fichiers modifiés peut être intéressante.
* Il est intéressant de voir les fichiers et les dossiers d'un répertoire **triés par date de création** plutôt que par ordre alphabétique pour voir quels fichiers ou dossiers sont plus récents (les derniers en général).
Notez qu'un **attaquant** peut **modifier l'heure** pour faire **apparaître des fichiers** comme **légitimes**, mais il ne peut pas modifier l'**inode**. Si vous constatez qu'un **fichier** indique qu'il a été créé et modifié en même temps que le reste des fichiers du même dossier, mais que l'**inode** est **plus grand que prévu**, alors les **horodatages de ce fichier ont été modifiés**.
Lors de l'analyse forensique d'un système Linux, il est important de rechercher tout contenu modifié qui pourrait être pertinent pour l'enquête. Voici quelques étapes pour trouver ce contenu :
1. Examiner les journaux système : Les journaux système, tels que `/var/log/syslog` et `/var/log/auth.log`, peuvent contenir des informations sur les activités suspectes ou les modifications apportées au système.
2. Vérifier les fichiers de configuration : Les fichiers de configuration, tels que `/etc/passwd` et `/etc/shadow`, peuvent être modifiés pour accorder des privilèges supplémentaires à un utilisateur ou pour masquer des activités malveillantes.
3. Analyser les fichiers de log d'application : Les applications spécifiques peuvent enregistrer des activités dans leurs propres fichiers de log. Il est important de vérifier ces fichiers pour détecter toute modification suspecte.
4. Examiner les fichiers de journalisation du noyau : Le noyau Linux peut enregistrer des informations sur les activités du système dans des fichiers de journalisation spécifiques. Ces fichiers, tels que `/var/log/kern.log`, peuvent contenir des indices sur les modifications apportées au système.
5. Vérifier les fichiers de configuration réseau : Les fichiers de configuration réseau, tels que `/etc/network/interfaces` et `/etc/resolv.conf`, peuvent être modifiés pour rediriger le trafic ou masquer des activités malveillantes.
6. Analyser les fichiers de log des services : Les services exécutés sur le système peuvent enregistrer des activités dans leurs propres fichiers de log. Il est important de vérifier ces fichiers pour détecter toute modification suspecte.
7. Utiliser des outils de comparaison de fichiers : Les outils tels que `diff` ou `md5sum` peuvent être utilisés pour comparer les versions actuelles des fichiers avec des sauvegardes précédentes afin de détecter toute modification.
En suivant cette méthodologie de base, vous pouvez identifier les fichiers et les activités modifiés sur un système Linux, ce qui peut être essentiel pour comprendre une intrusion ou une activité malveillante.
Lors de l'analyse d'un système Linux dans le cadre d'une enquête forensique, il est important de rechercher des fichiers supprimés qui pourraient contenir des informations cruciales. Voici une méthodologie de base pour trouver des fichiers supprimés :
1.**Analyser l'espace libre** : Utilisez des outils tels que `fls` pour rechercher des fragments de fichiers supprimés dans l'espace libre du disque.
2.**Rechercher dans les journaux du système** : Consultez les journaux du système, tels que `/var/log/syslog`, pour trouver des traces de fichiers supprimés.
3.**Utiliser des outils de récupération de fichiers** : Des outils tels que `photorec` ou `scalpel` peuvent être utilisés pour récupérer des fichiers supprimés à partir de partitions ou de systèmes de fichiers spécifiques.
4.**Analyser les métadonnées** : Examinez les métadonnées des fichiers existants pour trouver des références à des fichiers supprimés. Les outils tels que `exiftool` peuvent être utiles pour cette tâche.
5.**Analyser les fichiers temporaires** : Les fichiers temporaires peuvent contenir des informations sur des fichiers supprimés. Recherchez des fichiers avec des extensions telles que `.tmp` ou `.bak`.
6.**Utiliser des outils de recherche de mots clés** : Utilisez des outils tels que `grep` pour rechercher des mots clés spécifiques dans les fichiers du système, y compris les fichiers supprimés.
7.**Analyser les fichiers de configuration** : Les fichiers de configuration peuvent contenir des références à des fichiers supprimés. Examinez les fichiers tels que `/etc/fstab` ou `/etc/passwd` pour trouver des informations utiles.
En suivant cette méthodologie de base, vous pouvez augmenter vos chances de trouver des fichiers supprimés et d'obtenir des informations précieuses dans le cadre d'une enquête forensique Linux.
Sélectionne uniquement les fichiers qui ont été ajoutés (`A`), copiés (`C`), supprimés (`D`), modifiés (`M`), renommés (`R`), dont le type (c'est-à-dire fichier régulier, lien symbolique, sous-module, etc.) a été modifié (`T`), qui sont non fusionnés (`U`), inconnus (`X`), ou dont la correspondance a été rompue (`B`). Toute combinaison des caractères de filtre (y compris aucun) peut être utilisée. Lorsque `*` (tout ou rien) est ajouté à la combinaison, tous les chemins sont sélectionnés s'il y a un fichier qui correspond à d'autres critères dans la comparaison ; s'il n'y a aucun fichier qui correspond à d'autres critères, rien n'est sélectionné.
Notez que toutes les différences ne peuvent pas comporter tous les types. Par exemple, les différences de l'index vers l'arborescence de travail ne peuvent jamais comporter d'entrées ajoutées (car l'ensemble des chemins inclus dans la différence est limité à ce qui se trouve dans l'index). De même, les entrées copiées et renommées ne peuvent pas apparaître si la détection de ces types est désactivée.
Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
**Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour créer et **automatiser facilement des flux de travail** alimentés par les outils communautaires les plus avancés au monde.\
