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

I. Présentation

Le 13 novembre 2023, la plateforme Hack The Box a mis à disposition de ses utilisateurs plusieurs challenges d'investigation/forensic nommés "Sherlocks". Le but de ces challenges est de proposer des traces d'attaques afin de s'entraîner à l'investigation et la compréhension d'une cyberattaque.

Dans cet article, nous allons détailler la démarche qui permet de résoudre le Sherlocks Bumblebee, de difficulté "Facile".

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é.

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	SQLite, web, Apache
Outils utilisés	Sublime text, dbeaver, grep

II. Découverte de l'archive

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

Il semble donc qu'un contractant externe ait dérobé les identifiants d'un utilisateur de l'entreprise après s'être connecté au WiFi Guest, à nous de comprendre comment il s'y est pris. Nous avons à notre disposition une archive ZIP :

Cette archive ZIP contient un fichier .log (simple fichier texte) et un fichier .sqlite3, j'utilise l'outil dbeaver pour ouvrir et parcourir ce deuxième fichier et Sublime text pour le premier :

La base de données est bien celle d'un forum (phpBB) et les journaux d'évènements viennent certainement d'un service web Apache.

III. Investigation numérique : le cas Bumblebee

A. Tâche n°1: Isoler le compte de l'attaquant

• Énoncé - Task 1 : What was the username of the external contractor?

Notre première opération consiste à identifier quel compte utilisateur du forum phpBB a été utilisé pour réaliser les opérations malveillantes. Je commence par isoler les adresses IP du fichier access.log afin d'avoir un premier aperçu des clients du service web :

$ cat access.log |cut -d " " -f 1 |sort |uniq -c
     31 ::1
    210 10.10.0.78
    456 10.255.254.2

Astuce : La commande cut est ici très pratique pour découper un texte à partir d'un délimiteur choisi (ici l'espace). Je ne garde que le premier ensemble (par exemple le "1" dans la ligne "1 2 3"). Dans l'exemple ci dessus, l'adresse IP cliente et le premier élément de chaque ligne de log du fichier access.log.

Deux adresses IP clientes sont concernées. Je fais une seconde commande pour voir quels types de points d'entrées ont été requêtés :

cat access.log | grep -v "\.js\|\.css\|\.png\|.jpg\|\.gif\|\.ico"|cut -d " " -f 1,7

Astuce : A nouveau la commande cut est intéressante pour sélectionner les ensembles à afficher. Si je souhaite garder uniquement le prénom et l'âge dans la ligne "Jules César 43", j'utilise cut -d " " -f 1,3

J'exclus notamment de la sortie les fichiers inutiles (images, css, js) pour n'avoir que les points d'entrée intéressants. Voici un aperçu du résultat obtenu:

On peut notamment voir que l'adresse IP 10.10.0.78 accède à /adm/ et des fonctionnalités de backup, ce qui va plus dans le sens d'une compromission d'un panel d'administration. Après corrélation avec les informations de la base de données, nous pouvons voir que le dernier utilisateur créé était lié à l'adresse IP 10.10.0.78 :

L'utilisateur concerné est donc apoole1.

B. Tâche n°2: Identifier l'IP de l'attaquant

• Énoncé - Task 2 : What IP address did the contractor use to create their account?

Il s'agit maintenant de repérer l'adresse IP utilisée pour la connexion suspecte. Nous avons déjà la réponse grâce à notre investigation précédente : 10.10.0.78

C. Tâche n°3 : Trouver le post malveillant

• Énoncé - Task 3 : What is the post_id of the malicious post that the contractor made?

Il semble que l'attaquant ait créé un post sur le forum lors de son attaque. Je commence par étudier les différents points d'entrée pour voir lesquels peuvent être liés à la création d'un message sur un forum. Le point d'entrée posting parait cohérent :

En faisant le lien avec la table phpbb_post, nous pouvons confirmer le timestamp du post_id n°9 et l'adresse IP correspondante :

D. Tâche n°4 : Payload de l'attaquant

• Énoncé - Task 4 : What is the full URI that the credential stealer sends its data to?

La question nous oriente de fait sur un credential stealer (vol d'identifiant). L'attaquant aurait utilisé le forum pour dérober des identifiants. On peut commencer par s'intéresser au post n°9 pour voir son contenu. Je le récupère dans le fichier .sqlite3 :

Il s'agit d'un format HTML minifié (compressé), on peut utiliser un beautifier HTML en ligne pour plus de lisibilité, il va organiser le code HTML pour qu'il soit visuellement plus agréable à parcourir an gérant les sauts de lignes et indentations :

Dans le cadre d'une investigation numérique réelle, tout n'est pas bon à envoyer sur Internet. Les opérations de forensic sont généralement faites depuis des systèmes déconnectés d'Internet afin d'éviter d'envoyer, par erreur, des informations à l'attaquant. Il faut donc disposer de tout l'outillage nécessaire sans avoir besoin d'Internet. Également, les analystes ont généralement deux postes de travail, un pour la recherche sur Internet, l'autre (déconnecté) pour l'investigation sur les traces de la cyberattaque.

Il est notamment important de repérer que les autres messages du forum ne contiennent presque pas de balises HTML :

Il semble que l'attaquant ai voulu injecter dans son message un code HTML faisant apparaître une page d'authentification. Il s'agit d'une exploitation assez classique d’injection de code HTML/Javascript qui vise à faire croire à l'utilisateur qu'il a été déconnecté. Un utilisateur non sensibilisé, pressé ou distrait entrera alors ses identifiants :

À droite, la supercherie nous apparait comme difficile à louper, mais dans le contexte de l'attaque, le message est chargé au sein du forum et profite donc de la mise en forme CSS de ce dernier. On peut voir en analysant le code source de son message que le formulaire injecté enverra les identifiants de l'utilisateur sur http://10.10.0.78/update.php une fois celui-ci validé.

E. Tâche n°5 : Compromission du compte administrator

• Énoncé - Task 5 : When did the contractor log into the forum as the administrator? (UTC)

L'attaquant semble avoir réussi à piéger l'administrateur du forum avec son attaque. Dans un premier temps, on peut aller voir la table des utilisateurs et s'intéresser au compte compromis :

En toute logique, les informations ici nous renseignent sur la date de dernière authentification avec le compte administrateur. Cependant il ne s'agit pas de la bonne réponse. Nous pouvons nous intéresser à la table phpbb_log qui nous donne des informations plus claires :

On comprend clairement que l'adresse IP suspecte (10.0.0.78) s'est authentifiée avec un compte privilégié au timestamp donné. Cependant, en fonction de l'outil en ligne utilisé pour convertir le timestamp en une date classique, il peut y avoir des décalages (d’où "UTC" dans l'énoncé) 🙂 :

L'attaquant s'est donc authentifié avec le compte compromis le 26/04/2023 à 10:53:12.

F. Tâche n°6 : Identifiant LDAP

• Énoncé - Task 6 : In the forum there are plaintext credentials for the LDAP connection, what is the password?

Ici aussi, nous pouvons facilement trouver la réponse dans la base de données :

En ayant compromis l'application, on peut imaginer que l'attaquant a lui aussi eu accès à cette information. Dans un contexte réel, ce compte et serveur LDAP seront peut être la prochaine étape de l'investigation.

G. Tâche n°7 : User-Agent de l'administrateur

• Énoncé - Task 7 : What is the user agent of the Administrator user?

Ici, je décide de retourner sur les journaux d'évènement Apache. Il s'agit de trouver le user-agent de l'administrateur légitime. Nous disposons déjà de l'adresse IP de l'attaquant, nous pouvons donc l’exclure de notre recherche grâce à l'option -v de grep :

cat access.log |grep -v ".js|.css|.png|.jpg|.gif|.ico"|cut -d " " -f 1,7,12-25 |grep -v 10.10.0.78 |grep adm

J'ai également ajouté un filtre sur adm, point d'entrée auquel seul l'administrateur légitime et l'attaquant peuvent avoir accès :

L'user-agent de l'administrateur légitime est donc "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36".

H. Tâche n°8 : Modification d'un groupe privilégié

• Énoncé - Task 8 : What time did the contractor add themselves to the Administrator group? (UTC)

Il semble que l'attaquant ait ajouté son utilisateur dans le groupe administrator après compromission de l'utilisateur administrateur. La table phpbb_log peut également nous aider puisque ce type d'action sensible y est journalisée :

Là encore il faut être vigilant sur l'utilisation de l'UTC et non du GMT. L'attaquant s'est ajouté dans le groupe administrators le 26/04/2023 à 10:53:51.

I. Tâche n°9 : Exfiltration de la base de données

• Énoncé - Task 9 : What time did the contractor download the database backup? (UTC)

J'utilise la commande grep suivante pour filtrer les requêtes provenant de l'IP de notre attaquant :

cat access.log |grep -v ".js|.css|.png|.jpg|.gif|.ico" |grep 10.10.0.78

On peut voir que l'une de ses dernières requête était effectivement le téléchargement d'une archive .sql.gz :

Encore une fois, il faut faire attention à la question qui demande le temps en UTC, il faut enlever une heure à la date de journaux d'évènements (pas très évident à deviner).

J. Tâche n°10 : Taille de la fuite de donnée

• Énoncé - Task 10 : What was the size in bytes of the database backup as stated by access.log?

Nous pouvons nous renseigner sur le format des logs Apache par défaut dans la documentation officielle : https://httpd.apache.org/docs/2.4/logs.html#accesslog. On y apprend notamment que dans le format par défaut, le dernier élément d'une ligne de log est la taille de la réponse :

Ce qui nous indique donc que l'archive téléchargée fait 34707 octets :

Et voila, nous sommes arrivé au bout de l'exercice !

IV. Résumé de l'attaque

Au cours de cette investigation, nous avons découvert qu'un contractant (utilisateur externe) a utilisé un forum phpBB vulnérable à de l'injection de code HTML pour injecter un faux formulaire d'authentification dans un message. L'administrateur du forum s'est fait piéger et l'attaquant a volé ses identifiants, s'est connecté et a ajouté son compte utilisateur dans les groupes privilégiés du forum. Suite à cela, il a utilisé ses privilèges pour télécharger une archive de la base de données du forum.

Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés, pas forcément adapté aux attaques uniquement web, mais on peut toujours essayer 🙂 :

TTP (MITRE ATT&CK)	Détails
T1078.003 - Valid Accounts: Local Accounts	Création d'un compte via la fonction de création de compte et authentification avec le compte apoole1.
T1189 - Drive-by Compromise	Injection d'une fausse page d'authentification dans un post du forum phpBB.
T1078.003 - Valid Accounts: Local Accounts	Authentification sur le compte administrateur avec les identifiants volés.
T1098 - Account Manipulation	Ajout du compte attaquant dans le groupe administrators via les droits de l'utilisateur administrateur.
T1048.002 - Exfiltration Over Alternative Protocol: Exfiltration Over Asymmetric Encrypted Non-C2 Protocol	Exfiltration de la base de données en HTTPS (présumé).

V. Notions abordées

A. Côté analyste

L'utilisation de cat et de grep sur des fichiers de logs d'une certaine taille commence ici à atteindre ses limites. Je pense qu'un bon analyste devrait s'armer d'outils spécifiques pour se faciliter la tâche sur ce type de fichier (n'hésitez pas à en proposer dans les commentaires 🙂 ).

Connaître le format des journaux d'évènement des solutions analysées est un plus pour gagner en rapidité et en précision lors de nos recherches. Notamment pour savoir précisément quelles informations sont journalisées et où (log, base de données, etc.).

B. Côté défense

On met le doigt sur les dangers des applications vulnérables pour tout un système d'information. Une fois les applications compromises, les secrets révélés permettent à l'attaquant de continuer son attaque (compte de base de données, comptes LDAP, réutilisation des mots de passe découverts sur d'autres actifs, etc.). Même les applications qui paraissent inoffensives ou sans intérêt peuvent donner des informations ou accès très utiles à un attaquant.

Pour retracer le déroulé exact d'une cyberattaque, le timing est très important. Il faut savoir retracer avec précision chaque opération de l'attaquant, et ce sur de multiples systèmes, n'ayant pas tous le même format de date, voire la même source de temps. Il faut évidemment aussi manier à la perfection ces histoires d'UTC, GMT, etc. (ce qui n'est pas mon cas :)). Pour faciliter le travail de vos analystes, pensez donc à bien configurer la même source de temps sur tous les systèmes de votre SI (les fameux serveurs NTP).

Nous pouvons recommander à l’entité attaquée de revoir sa politique de filtrage réseau, il n'est sans doute pas normal ou prévu qu'un utilisateur puisse accéder à un forum interne depuis le réseau WiFi de l'entreprise, qui généralement ne donne accès qu'à internet.

Enfin, il peut être recommandé de sensibiliser les utilisateurs et les administrateurs pour améliorer la vigilance des ces populations face au phishing. Cela va dans le sens des directives n°1 : Former les équipes opérationnelles à la sécurité des systèmes d’information et n°2 : Sensibiliser les utilisateurs aux bonnes pratiques élémentaires de sécurité informatique du guide d'hygiène de l'ANSSI.

C. Côté attaquant

L'attaquant aurait pu supprimer un grand nombre de traces, ce qui aurait considérablement compliqué la tâche de l'analyste. Le fait de disposer de la base de données, plutôt précise, du forum après compromission nous a bien aidé à comprendre l'attaque. Une phase supplémentaire de son attaque aurait donc pu être de supprimer ses traces : le post de phishing, ses droits privilégiés et son appartenance au groupe administrators, pourquoi pas modifier/supprimer les journaux de l'application ou les entrées de la base de données.

Si l'attaquant avait été en mesure d'ajouter du code JavaScript à son formulaire malveillant (j'ignore si c'est le cas), il aurait pu faire en sorte que le formulaire d'authentification malveillant ne s'affiche que pour un utilisateur précis (administrateur). Cela en parcourant à l'aide du JavaScript la page actuelle de l'utilisateur en isolant son nom d'utilisateur (qui est généralement écrit dans le bandeau supérieur). Son message malveillant serait alors passé inaperçu pour les autres utilisateurs, rendant son attaque plus discrète encore.

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

Retrouvez tout nos articles relatifs à Hack The Box sur cette page :

• IT-Connect - Articles Hack The Box