Audit et sécurisation d’un domaine Active Directory

Projet en bref

Contexte

Ce projet consistait à évaluer la sécurité d’un système d’information Windows dans un environnement de laboratoire représentant une organisation manipulant des données sensibles. Le périmètre comprenait un contrôleur de domaine, un serveur membre et un poste de travail.

La mission couvrait l’ensemble du cycle d’un audit technique : cartographie du réseau, recherche de vulnérabilités, validation contrôlée de leur impact, constitution d’une chaîne d’attaque et transformation des constats en mesures correctives compréhensibles et priorisées.

Les éléments propres au scénario pédagogique, les identifiants, les adresses et les preuves brutes ont été volontairement exclus de cette présentation.

Objectifs techniques

• Cartographier les hôtes, services et protocoles liés au domaine ;
• identifier les faiblesses de configuration et de gestion des accès ;
• évaluer les possibilités de mouvement latéral et d’élévation de privilèges ;
• conserver des preuves techniques traçables, y compris pour les tests négatifs ;
• construire un plan de remédiation à court et à long terme.

Architecture auditée

Le schéma suivant représente uniquement les rôles et les principaux flux du laboratoire :

flowchart LR
    Kali["Poste d’audit<br/>Kali Linux"]

    subgraph AD["Laboratoire Active Directory"]
        DC["Contrôleur de domaine<br/>AD DS · DNS · LDAP · Kerberos"]
        File["Serveur membre<br/>SMB · WinRM · RDP · Web"]
        Workstation["Poste Windows<br/>SMB · WinRM · RDP"]
    end

    Kali -->|"Nmap · DNS · LDAP · Kerberos"| DC
    Kali -->|"SMB · WinRM · RDP · HTTP"| File
    Kali -->|"SMB · WinRM · RDP"| Workstation
    DC <-->|"Authentification et annuaire"| File
    DC <-->|"Authentification et annuaire"| Workstation

    style Kali fill:#e8f4ff,stroke:#2563eb
    style DC fill:#fff7ed,stroke:#ea580c
    style File fill:#f8fafc,stroke:#475569
    style Workstation fill:#f8fafc,stroke:#475569

Méthodologie

L’audit a suivi une progression par paliers afin de limiter les suppositions et de relier chaque action à une preuve :

1. Découverte du réseau et identification des services exposés ;
2. énumération DNS, LDAP et SMB sans identifiants ;
3. identification de comptes valides et recherche d’un premier accès ;
4. réénumération authentifiée des comptes, groupes, partages et relations AD ;
5. analyse des droits locaux, sessions et chemins de mouvement latéral ;
6. validation de l’impact sur le domaine ;
7. classement des vulnérabilités et rédaction des remédiations.

Cette démarche s’est appuyée sur Nmap, NetExec, enum4linux-ng, ldapsearch, Kerbrute, SprayHound, Impacket, ldapdomaindump, BloodHound, FreeRDP et des scripts Bash dédiés.

Travaux réalisés

Automatisation et traçabilité

• Développement d’une chaîne de 16 scripts Bash spécialisés ;
• centralisation des paramètres du laboratoire et séparation des secrets locaux ;
• journalisation des commandes, sorties, erreurs et codes de retour ;
• conservation explicite des tests non concluants ;
• génération d’un manifeste SHA-256 et d’une archive des preuves.

Énumération et cartographie

• Découverte des hôtes et des ports exposés ;
• identification des rôles Windows et des services Active Directory ;
• analyse des informations DNS, LDAP, SMB et des partages réseau ;
• collecte des objets et relations AD avec ldapdomaindump et BloodHound ;
• comparaison des résultats anonymes et authentifiés.

Validation des vulnérabilités

• Contrôle de la robustesse des comptes et de la politique de mot de passe ;
• recherche de secrets exposés dans des attributs, scripts ou partages ;
• vérification des droits d’administration locale et des accès distants ;
• analyse des sessions privilégiées présentes sur les machines membres ;
• validation encadrée d’une chaîne de mouvement latéral jusqu’au domaine.

Analyse et remédiation

• Description de chaque vulnérabilité avec preuve, impact et criticité ;
• distinction entre cause racine, facteur aggravant et conséquence ;
• rédaction de mesures immédiates de confinement et de correction ;
• proposition d’améliorations structurelles pour les comptes, postes d’administration, protocoles et mécanismes de supervision.

Difficultés et choix techniques

Interpréter correctement les résultats négatifs

Problème — Un échec d’outil ne prouve pas l’absence de vulnérabilité

Un délai dépassé sur RDP ou un contrôle limité à une liste de comptes pouvait facilement conduire à une conclusion trop générale.

Analyse : chaque résultat a été replacé dans les limites exactes du test : service accessible, authentification refusée, délai dépassé ou cible non couverte.

Solution et résultat : les scripts enregistrent la commande, la sortie et le code de retour. Le rapport différencie désormais clairement les constats confirmés des tests non concluants.

Uniformiser les formats d’authentification

Problème — Les outils n’attendent pas tous le même identifiant

LDAP, SMB, Kerberos et BloodHound utilisent, selon les cas, un nom court, un UPN,un identifiant de type DOMAINE\utilisateur ou un nom DNS complet.

Analyse : plusieurs erreurs provenaient du format d’identité ou de la résolution DNS, et non d’un mot de passe incorrect.

Solution et résultat : des fonctions communes construisent les formats attendus et imposent le FQDN lorsque l’outil le nécessite. Les exécutions sont devenues plus reproductibles.

Prioriser une chaîne de faiblesses

Problème — Aucun constat isolé n’expliquait à lui seul l’impact final

Des comptes faibles, des secrets exposés, des droits locaux excessifs et une session privilégiée formaient ensemble un chemin de compromission.

Analyse : les preuves ont été ordonnées chronologiquement puis reliées aux relations observées dans Active Directory.

Solution et résultat : le rapport distingue les vulnérabilités individuelles de la chaîne d’attaque globale, ce qui permet de prioriser les mesures capables de rompre plusieurs étapes à la fois.

Résultats

L’audit a montré que plusieurs faiblesses de sécurité pouvaient être combinées : gestion insuffisante de comptes techniques, secrets en clair, droits locaux excessifs, exposition de services d’administration et présence d’une session privilégiée sur un serveur membre.

Les recommandations prioritaires portent sur la rotation des secrets, la suppression des identifiants en clair, la réduction des privilèges locaux, le cloisonnement des comptes d’administration, le durcissement de l’authentification et la supervision des comportements sensibles dans Active Directory.

Compétences démontrées

• Conduite d’un audit de sécurité Active Directory ;
• administration et diagnostic d’environnements Windows ;
• énumération réseau, DNS, LDAP, Kerberos et SMB ;
• analyse de chemins d’attaque avec BloodHound ;
• automatisation et gestion des erreurs en Bash ;
• collecte, intégrité et classement de preuves techniques ;
• évaluation de la criticité et analyse d’impact ;
• rédaction d’un rapport de pentest et d’un plan d’action ;
• restitution de constats techniques à un public non spécialiste.

Retour d’expérience

Ce projet m’a appris qu’une compromission de domaine résulte souvent moins d’une vulnérabilité unique que de l’enchaînement de faiblesses ordinaires. Une politique de mot de passe insuffisante, un secret oublié dans un script et un droit local trop large peuvent devenir critiques lorsqu’une identité privilégiée est exposée sur la même machine.

Il m’a également permis d’améliorer ma manière de documenter un audit : conserver les résultats négatifs, expliciter les limites d’un test et relier chaque conclusion à une preuve rend l’analyse plus fiable et les mesures correctives plus directement applicables.

Avec davantage de temps, j’ajouterais des tests automatisés des scripts, une exécution continue dans un laboratoire jetable et un contrôle systématique des artefacts avant archivage.