Linux CatScale : comment collecter les traces de compromission d’un système Linux ?

I. Présentation

Dans cet article, nous allons faire un tour d’horizon de l’outil Linux CatScale, un script de collecte des traces de compromission pour système Linux fournis par WithSecureLabs. Nous verrons notamment en quoi consiste une collecte des traces dans le cadre d’une analyse forensic, quels sont les éléments récupérés par Linux CatScale sur un système et comment analyser et étudier ces éléments.

Cet article peut notamment être utile dans le cas où vous constatez une activité anormale sur votre serveur et que vous souhaitez réaliser une collecte rapide des éléments avant une potentiellement extinction de celui-ci. Cela vous permettra d’avoir quelques éléments à présenter à une équipe de réponse à incident. Le premier (mauvais) réflexe est en général de tout éteindre, ce qui efface une bonne partie des traces de compromission.

II. Qu’est-ce que Linux CatScale ?

Linux CatScale est avant tout un script bash, celui-ci vise à collecter au sein d’une archive tous les éléments qui pourront intéresser un analyste dans le cadre d’une investigation numérique, aussi connu sous l’acronyme DFIR (Digital Forensic Incident Response). Ces éléments sont par exemple :

• Les processus en cours d’exécution ;
• Les utilisateurs actuellement connectés ;
• la liste des fichiers modifiés récemment ;
• les journaux d’évènements ;
• les connexions actives ;
• etc.

Toutes ces informations seront archivées dans un fichier au format “.tar.gz” qui pourra ensuite être copié sur le poste d’un analyste pour une étude approfondie de son contenu. Pour rappel, le processus d’investigation numérique se décompose en 5 grandes phases :

Également, il faut rappeler qu’en forensic (investigation numérique), on ne travaille jamais directement sur le système compromis. L’une des grandes étapes de toute investigation est donc la phase d’acquisition/collecte, qui consiste à collecter tout ce dont on aura besoin pour l’analyse qui sera réalisée « à froid », c’est à dire sans interaction directe avec le système étudié.

Ainsi, cet outil peut être utilisé aussi bien par des équipes d’investigation numérique, de réponse à incident, ou même en premier lieu par les administrateurs systèmes eux-mêmes qui suspectent une compromission de leur serveur.

L’intérêt fondamental de cet outil est la possibilité d’avoir rapidement une collecte d’information et que celle-ci soit standardisée. C’est-à-dire que les mêmes éléments seront collectés quel que soit le contexte, et organisés de la même manière pour une analyse plus efficace. On évite ainsi d’avoir des opérations manuelles, réalisées pas tout à fait de la même manière, avec une option en moins ou en plus en fonction de la personne qui saisit les commandes.

Ce type d’outil peut donc être utilisé :

• Dans le cadre de l’analyse d’un serveur compromis
• Pour réaliser du threat hunting (détection proactive de compromission)
• pour une collecte automatisée, standardisée et rapide

Ce script est open-source et proposé par l’entreprise de cybersécurité Finlandaise WithSecure.

III. Collecter les traces de compromission avec Linux CatScale

À présent, nous allons voir comment réaliser une collecte grâce à Linux CatScale. Nous sommes ici, par exemple, dans la position d’un administrateur système qui suspecte une compromission de son serveur et souhaite réaliser au plus tôt une collecte d’information. Cela peut aussi être le cas d’une équipe de réponse à incident qui arrive dans un système d’information et qui réalise ses premiers prélèvements.

Les prérequis pour accéder à Linux CatScale sont :

• avoir un accès terminal ou SSH à la cible ;
• avoir les droits « root » sur le serveur concerné ;
• avoir le script de collecte à disposition.

Nous pouvons commencer par récupérer le contenu du dépôt Github sur notre poste d’analyse :

# Récupération des scripts Linux CatScale depuis Github
git clone https://github.com/WithSecureLabs/LinuxCatScale

Le contenu du script d’extraction (« Cat-Scale.sh« ) à exécuter sur les serveurs à analyser est en Bash, plutôt bien écrit et entièrement commenté. Je vous recommande sa lecture afin de l’exécuter sur des serveurs en production.

Avant de réaliser notre collecte, il est important d’être au fait de certains détails afin de ne pas réaliser d’actions qui pourraient effacer des traces importantes :

• Il est recommandé d’exécuter le script de collecte depuis une clé USB, cela dans le but d’impacter le moins possible l’activité en cours sur le système analysé (c’est-à-dire ne pas altérer les preuves potentielles ou les traces de l’attaquant). À noter que ce n’est pas toujours possible (cas d’une machine virtuelle).
• L’outil ne va pas faire une copie pure et parfaite du système analysé comme le font certains outils d’acquisition au sens propre de la DFIR, c’est-à-dire sans altération de contenu (FTK Imager, EnCase, ou même la commande « dd« ), et ne s’y substitut pas. Également, vous n’aurez pas exemple par le contenu de la mémoire vive. Il ne s’agit que de copie de fichiers (logs, configurations) ou du résultat de certaines commandes (par exemple les commandes « « ps » ou « ss« ).
• S’il est encore sur le système, l’attaquant verra l’activité de collecte et l’exécution de l’outil figurera également dans les collectes qu’il génère (dans la liste des processus, par exemple).

Maintenant que tout est clair, procédons à notre collecte d’information.

Le script de collecte “Cat-Scale.sh” utilise exclusivement des binaires natifs Linux. Il n’est pas à proprement parler « POSIX compatible », mais est censé utiliser des binaires qui sont présents sur la grande majorité des systèmes Linux, cela afin d’avoir une collecte sans erreurs et uniformisée entre tous les types de systèmes. Par conséquent, il n’a en principe pas de dépendances.

Je commence par copier le script « Cat-Scale.sh » dans le répertoire « /tmp » du système cible via la commande « scp » :

# Dépôt du script de collecte
cd /opt/LinuxCatScale
scp Cat-Scale.sh [email protected]:/tmp/

Puis, j’ajoute les permissions d’exécution et j’exécute le script via « sudo » :

# Connexion SSH au serveur à prélever
ssh [email protected]
cd /tmp

# Exécution du script de collecte
chmod +x Cat-Scale.sh
sudo ./Cat-Scale.sh

Lors de son exécution, le script va afficher sa progression, ce qui donnera une première idée des informations extraites :

En fonction de l’activité, de l’âge et de la taille du système, l’extraction peut-être plus ou moins longue et volumineuse (~200 Mo dans mon exemple). Voici l’affichage obtenu en fin d’exécution :

[…]
Creating 2million-20240615-0916.tar.gz 
 
Cleaning up!...
Clean-up Successful!

************************************************************
Collection of triage data complete! 
Please submit the following file and SHA1 hash for analysis.
*************************************************************
 
dd6620a7cef22512aca58a61192743b4bb51ac8c  ./catscale_2million-20240615-0916.tar.gz

Nous étudierons plus en détail ces informations dans la prochaine section de cet article. Nous nous retrouvons à la fin de la collecte avec un fichier « 2million-20240615-0916.tar.gz« , formaté de la façon suivant :

--.tar.gz

Linux CatScale supprime tous les autres artefacts qu’il a dû créer durant son exécution (fichiers temporaires par exemple). Nous pouvons alors récupérer cette archive sur notre poste d’analyse.

# Récupération de l’archive depuis le poste de l’analyste
scp [email protected]:/tmp/catscale_2million-20240615-0916.tar.gz .

La toute dernière étape de cette phase de collecte est la suppression de l’archive ainsi que du script de collecte. Il est très important de ne pas laisser trainer cette archive sur le système (même s’il est déjà compromis). Ayant exécuté le script en tant que « root« , il peut contenir des informations sensibles concernant votre système ou ses vulnérabilités.

# Suppression de l’archive et du script de collecte sur le système à analyser
rm /tmp/Extract-Cat-Scale.sh
rm /tmp/*.tar.gz

Enfin, il faut être vigilant quant à la manipulation, le transite et le stockage de l’archive récupérée et considérer qu’elle contient des informations sensibles.

Vous pouvez noter que ce processus est très simple, et qu’il peut même être scripté afin de collecter des données sur plusieurs serveurs. À présent, nous pouvons nous déconnecter du système compromis et passer du côté “analyste”.

IV. Analyse des traces de compromission

Maintenant que nous possédons cette archive, nous n’avons en principe plus besoin d’intervenir sur le système compromis, celle-ci devrait nous suffire pour nos recherches. Il est préconisé par l’éditeur du script de décompresser l’archive « .tar.gz » obtenue grâce au script fournit (« Extract-Cat-Scale.sh« ). Il faut alors s’assurer que l’archive « .tar.gz » est dans le même répertoire que le script utilisé :

Aucun argument n’est alors à passer au script d’extraction, il faut cependant l’exécuter en tant que « root » ou via « sudo » :

# Exécution du script d'extraction de l'archive
$ sudo ./Extract-Cat-Scale.sh 

[sudo] password for mickael: 
Let's do this
2million-20240615-0916 Completed

B. Structure de l’archive Linux CatScale

Nous allons à présent faire un tour d’horizon des différentes données qui sont collectées par Linux CatScale. Comme je l’ai rappelé, l’avantage est que toutes les archives collectées auront le même format :

On trouve à la racine plusieurs répertoires dans lesquels sont organisés les fichiers et données :

Ce répertoire contiendra la liste des fichiers cachés dans les répertoires « /home » des utilisateurs ainsi que le répertoire « /root« . Cela inclus des fichiers très importants comme les historiques de commandes Bash (« .bash_history« ), SQL (« .mysql_history« ), python, l’utilisation de sudo, etc.

Ce répertoire contiendra une copie complète du répertoire « /var/log« . Lorsqu’ils sont correctement configurés, les logs sont la source d’information principale d’une analyse forensic, notamment parce qu’ils sont le seul élément réellement persistant. Certains fichiers additionnels sont présents comme la « version texte » des journaux « btmp« , « utmp« , « wtmp« , etc. Ainsi que les résultats de différentes commandes comme  « passwd-check » ou « who« .

Ce répertoire contiendra toutes les éventuelles traces de persistance réalisées par l’attaquant. Le script de collecte va notamment chercher les artefacts classiques dans la méthodologie des attaquants comme les tâches planifiées (T1053.004) ou les services (T1569).

Sont ici stockés des fichiers supplémentaires contenant le résultat de diverses commandes qui sont le fruit des retours d’expérience des éditeurs. Le fichier  « pot-webshell-first-1000.txt » contiendra par exemple les 1000 premières lignes de tous les fichiers web du serveur (« .php« , « .jsp« , « .asp« , etc.). Cela peut être utile pour une analyse rapide avec des règles Yara (recherche de signature de malware). Un autre exemple est le fichier « exec-perm-files.txt » qui contient la liste de tous les fichiers ayant la permission d’exécution sur le système.

C’est ici que l’on trouvera toutes les informations à propos du système sur lequel a été fait la collecte (timezone, version de l’OS, système de fichiers). Il contiendra également la liste et copie des fichiers qui ont été modifiés dans les 90 derniers jours, pouvant ainsi être le fruit de l’action d’un attaquant ayant modifié le système (ajout d’un backdoor, désactivation d’une fonction de sécurité, etc.).

Ce répertoire contiendra toutes les données relatives aux processus en cours d’exécution et connexions actives au moment de la collecte. Il s’agit de données généralement d’une grande importance pour un analyste, car elles permettent d’identifier des processus inhabituels ou de repérer le serveur C2 (Command & Control) de l’attaquant.

On y trouvera, par exemple, le résultat de commande « ps » avec différentes options, mais aussi « ss« , pour les connexions réseaux, les hashs des processus afin de facilement effectuer des recherches basées sur les signatures, etc. Voici un exemple de processus étrange identifié grâce à la collecte des processus en cours d’exécution :

On voit ici qu’un processus fils d’Apache2 exécute des commandes de prise d’informations. Ce n’est pas tout à fait le genre de commandes qu’exécutent les applications web en temps normal.

Ces répertoires contiendront les éléments de configurations et d’activité des conteneurs et machines virtuelles présentes sur l’hôte. Par exemple la liste des volumes, conteneurs, images, etc. Ces éléments permettent d’identifier les cas d’utilisation de ces technologies pour inclure des portes dérobées sur le système compromis. Les TTP suivants sont notamment concernés :

Pour aller plus loin, sachez qu’il existe une version du MITRE ATT&CK dédiée aux attaques sur les conteneurs : MITRE ATT&CK – Containers Matrix

V. Pour aller plus loin

A. Analyser plusieurs systèmes

Dans le cas où vous menez une analyse sur plusieurs systèmes en simultanés, le script d’extraction peut gérer cela de la même façon qu’avec une seule archive. Il suffit de toutes les positionner dans le répertoire de Linux CatScale et d’exécuter le script d’extraction :

Cela nous donnera notamment la possibilité d’étudier différents systèmes en même temps, et de manière uniforme. La commande suivante va, par exemple, relever les échecs d’authentification dans le fichier « auth.log » de toutes les archives à disposition :

# Recherche du terme “authentication failure” via la commande "grepp"
$ grep "authentication failure;" extracted/*/Logs/varlogs/auth.log -ri

Voici un résultat possible :

B. Utiliser des règles Yara sur les traces collectées

Avec toutes ces données à disposition, nous pouvons à présent utiliser des outils d’analyse et de recherche d’artefacts afin d’accélérer notre recherche. Je vais, par exemple, créer une règle Yara très simple qui va rechercher quelques chaines de caractères classiques des backdoors PHP du créateur Pentest Monkey.

YARA est un outil utilisé afin d’identifier et de classifier des fichiers malveillants. Il fonctionne à partir de règles basées sur des patterns, des chaînes de caractères ou des propriétés de fichiers. Ces règles peuvent ensuite être appliquées sur toute une arborescence de fichier pour analyser et détecter des scripts, extrait de code ou binaires malveillants, ce qui aide à identifier des menaces ou effectuer des analyses de forensic. YARA est largement utilisé par les analystes pour automatiser la détection de menaces et faciliter les investigations.

Voici donc ma règle Yara, qui n’est pas très complexe à comprendre :

rule phpmonkey_reverseshell {
   meta:
      description = "php - pentestmonkey reverse-shell"
      author = "Mickael"
      reference = ""
      date = ""
      hash1 = ""
   strings:
      $s1 = "[email protected]"
      $s2 = "https://raw.githubusercontent.com/pentestmonkey"
      $s3 = "uname -a; w; id; /bin/bash -i" 
      $s4 = "// Open reverse connection"
      $s5 = "Successfully opened reverse shell to"
   condition:
      2 of them
}

Je déclare plusieurs chaines de caractères, si plus de 2 d’entre elles se situent au sein d’un fichier, alors la règle Yara lèvera une alerte. J’utilise ensuite Yara en spécifiant ma règle ainsi que le fichier « pot-webshell-first-1000.txt« , celui qui contient les 1000 premières lignes de tous les fichiers web du serveur collectés (PHP, JSP, ASP, etc). Il pèse plus de 40 Mo dans mon cas et serait difficile à étudier manuellement. Je passe par une petite boucle Bash pour scanner plusieurs dossiers de collecte en même temps :

# Boucle sur tous les répertoires de collecte Linux CatScale extraits 
for directory in $(find /opt/LinuxCatScale/ -type d -name "Misc") ; do 
    echo -e "\n[+] Yara scan on $directory"; 

    # Utilisation de Yara avec la règle personnalisée
    yara /tmp/php-monkey.yar $directory ;
done

Voici le résultat :

Bingo ! Yara a découvert les traces d’une backdoor PHP dans la collecte effectuée sur le système nommé « Ultimatum », si l’on recherche la chaine de caractère dans le fichier, il est effectivement présent :

# Recherche d’une chaine de caractère de la règle Yara 
$ grep "[email protected]" /opt/LinuxCatScale/extracted/Ultimatum/Misc/ip-172-31-11-131-20230808-0937-pot-webshell-first-1000.txt

// Copyright (C) 2007 [email protected]

C. Envoi des données collectées sur un SIEM ELK

WithSecure a également mis à disposition des patterns Grok afin de faciliter l’intégration des données collectées dans le SIEM ELK :

# Affichage d'une partie du fichier "patterns" de Linux CatScale
$ head -n 10 patterns 

USERNAME [a-zA-Z0-9._-]+
USER %{USERNAME}
EMAILLOCALPART [a-zA-Z][a-zA-Z0-9_.+-=:]+
EMAILADDRESS %{EMAILLOCALPART}@%{HOSTNAME}
INT (?:[+-]?(?:[0-9]+))
BASE10NUM (?<![0-9.+-])(?>[+-]?(?:(?:[0-9]+(?:\.[0-9]+)?)|(?:\.[0-9]+)))
NUMBER (?:%{BASE10NUM})
BASE16NUM (?<![0-9A-Fa-f])(?:[+-]?(?:0x)?(?:[0-9A-Fa-f]+))
BASE16FLOAT \b(?<![0-9A-Fa-f.])(?:[+-]?(?:0x)?(?:(?:[0-9A-Fa-f]+(?:\.[0-9A-Fa-f]*)?)|(?:\.[0-9A-Fa-f]+)))\b

Les patterns Grok sont des expressions régulières prédéfinies qui permettent de parser et de structurer les données. Dans le contexte d’un SIEM (Security Information and Event Management), comme ELK, ils sont utilisés pour extraire des informations spécifiques des logs bruts (ici, les données provenant de la collecte Linux CatScale), les rendant ainsi exploitables pour des analyses et des visualisations.

L’intérêt est donc de pouvoir facilement intégrer ces données dans un SIEM et de profiter des fonctions de représentation graphique, mais surtout des recherches KQL. Le tout afin de faciliter l’investigation sur un grand nombre de données et gagner du temps.

VI. Conclusion

Dans cet article, nous avons fait le tour de la solution Linux CatScale proposée par WithSecure afin de réaliser une collecte de données sur un système Linux en vue de réaliser une investigation numérique.

Connaitre ce type d’outil est important pour savoir réagir en cas de cyberattaque ou de suspicion d’intrusion, cela afin d’être en capacité de fournir rapidement des données exploitables à une équipe d’investigation numérique ou de garder des preuves avant l’extinction d’un système compromis.