ACTIVE DIRECTORY – Sécurité AD

Patrick CEREGHELLI – Consultant Sécurité – Ingénieur Systèmes – Chef de Projets

Patrick.cereghelli@digital.security
Patrick.cereghelli@laposte.net

Active Directory 1
 Active Directory : sécurité AD

✓ Protocoles d’authentification NTLM et Kerberos

✓ Gestion des accès
✓ Attaques en environnement AD
✓ TP Attaques sur l’AD
✓ Sécuriser l’AD et les environnements Microsoft
✓ Sécuriser les accès à privilèges

Active Directory 2
 Protocoles
d’authentification

❑ NTLM
❑ Kerberos V5

Active Directory
 NTLM et Kerberos
❑ Deux principaux mécanismes d'authentification existent sous Windows : NTLM et Kerberos.
❑ De par leur conception, ces deux mécanismes sont sensiblement différents et ne sont pas exposés aux
mêmes problématiques

NTLM
Protocole authentification basé sur un
challenge-réponse
Echange direct avec la ressource
Pas aussi sécurisé que Kerberos
Pas d’authentification mutuelle
Ne supporte que « l’impersonation »
KERBEROS
Protocole authentification basé sur l’utilisation
de tickets
Utilisation d’un tiers de confiance → le
contrôleur de domaine
Plus sécurisé que NTLM
Offre une authentification mutuelle
Supporte « l’impersonation » et la délégation

Impersonation: par exemple exécuter du code avec les droits d'un autre utilisateur.
Délégation: par exemple exécuter du code avec les droits d'un autre utilisateur à
travers le réseau
Active Directory 4
 Challenge d’authentification
❑ Microsoft a conçu différents protocoles d'authentification NTLM au travers des années. Ils permettent
d'authentifier les ressources à travers le réseau. Il s'agit de protocoles dits de type « défi/réponse »
(challenge/response)
✓ LM (alias LAN Manager ou LANMAN) : le protocole LM utilise le "Hashes" LM comme secret de l'algorithme de
chiffrement DES afin de calculer la réponse d'un client à un défi (challenge) transmis par un serveur. Déconseillé
aujourd’hui: faiblesse du "Hash" LM et de l'utilisation de l'algorithme DES
✓ NTLMv1 (alias NetNTLMv1) : le protocole NetNTLMv1 est similaire au protocole LM sauf que le secret utilisé est à
présent le "Hash" NTLM d'un utilisateur. Il est déconseillé d'utiliser ce protocole aujourd'hui, car il est facile de mener
des attaques afin de retrouver le mot de passe d'un utilisateur.
✓ NTLMv2 (alias NetNTLMv2) : il s'agit de la version la plus récente et la plus robuste du protocole NTLM. Il corrige
certaines faiblesses du protocole NTLMv1 et remplace notamment l'algorithme de chiffrement DES par un HMAC-DES.
❑ L'établissement des protocoles LM, NetNTLMv1 et NetNTLMv2 est réalisé grâce au protocole NTLMSSP (NTLM
Security Support Provider).
❑ L'authentification NTLM est supportée par de nombreux protocoles comme SMB, LDAP, HTTP(S), IMAP, SMTP,
ou encore MS-SQL. Pour cela, l'authentification NTLM est encapsulée au sein du protocole concerné.
❑ La capture d'un challenge (LM, NTLMv1, NTLMv2) sur un réseau peut permettre d'effectuer des attaques par
dictionnaire ou force brute afin de retrouver les mots de passe en clair, mais également d'effectuer du relai
NTLM

Active Directory 5
 Algorithme de stockage des mots de passe sous Windows
❑ LM Hash ("Hash" LM alias Lan Manager Hash): format de stockage des mots de passe utilisé sur les anciens
systèmes Windows (antérieurs à Windows NT 4). Il est également présent sur les nouveaux systèmes Windows
afin d'assurer la rétrocompatibilité, mais est désactivé par défaut depuis Windows Vista, car son niveau de
sécurité est considéré comme très faible. Il est préférable d'utiliser le format NT Hash.
❑ NT Hash (communément appelé NTLM) : format de stockage des mots de passe utilisé sur les systèmes
Windows modernes. Bien que vulnérable à certaines attaques, il est beaucoup plus robuste que LM.
❑ Ces « Hashes » peuvent être présents :
✓ dans la base SAM (Security Accounts Manager) pour le stockage des comptes locaux
✓ dans la base Ntds.dit de l'Active Directory pour le stockage des comptes de domaine
✓ dans la mémoire du processus « lsass.exe » (Local Security Authority Server Service) d'une machine
sur laquelle une ou plusieurs authentifications ont été réalisées.
❑ Une fois en possession de ces « Hashes », il est possible:
✓ de réaliser des attaques par dictionnaire ou force brute afin de tenter de retrouver les mots de passe en
clair
✓ d'effectuer des attaques de type pass-the-hash

Active Directory 6
 Algorithme de stockage des mots de passe sous Windows

Active Directory 7
 Les échanges NTLM
Trois étapes nécessaires au processus
processus d'authentification
d'authentification :
❑ NTLMSSP NEGOTIATE : la première
étape consiste à négocier le protocole
qui sera utilisé. Pour cela, le client
transmet au serveur une demande
d'authentification en précisant les
versions du protocole NTLM
acceptées.
❑ NTLMSSP CHALLENGE : le serveur
répond au client en précisant les
versions NTLM acceptées. Cette
réponse contient également un «
challenge » à résoudre.
❑ NTLMSSP AUTH : le client résout le
challenge et le transmet au serveur
(accompagné de diverses informations
telles que le login, le domaine associé
si applicable, etc.).
Gestion des Identités 8
 Fonctionnement NTLM avec un compte local au serveur
1. Authentification interactive de l’utilisateur sur le
client
Accès d’un utilisateur à un serveur avec un client ✓ Calcul d’un hash du mot de passe par le système
2. Le client envoie le nom d’utilisateur au serveur en clair
3. Le serveur génère un nombre aléatoire sur 16 octets
(challenge) et l’envoie au client
4. Le client chiffre le challenge avec le hash du mot de
passe de l’utilisateur et retourne le résultat au serveur
5
(response)
5. Le serveur utilise le nom d’utilisateur pour extraire le
hash du mot de passe de sa base « SAM » locale. Il
chiffre le challenge avec le hash du mot de passe, Il
compare la réponse fournit par le client et le challenge
généré. Si ils sont identiques → authentification
réussi

Active Directory 9
 Fonctionnement NTLM avec un compte de domaine
1. Authentification interactive de l’utilisateur sur le client
Accès d’un utilisateur à un serveur avec un client ✓ Calcul d’un hash du mot de passe par le système
2. Le client envoie le nom d’utilisateur au serveur en clair
3. Le serveur génère un nombre aléatoire sur 16 octets
(challenge) et l’envoie au client
4. Le client chiffre le challenge avec le hash du mot de
passe de l’utilisateur et retourne le résultat au serveur
(response)
5. Le serveur envoie au contrôleur de domaine (DC)
✓ Le nom d’utilisateur
✓ Le challenge
✓ La réponse
6. Le DC utilise le nom d’utilisateur pour extraire le hash du
mot de passe de sa base ntds.dit. Il chiffre le challenge
avec le hash du mot de passe
7. Le DC compare la réponse fournit par le client et le
challenge qu’il a généré. Si ils sont identiques
(authentification réussi), il notifie le serveur
Active Directory 10
 Kerberos
❑ Le protocole Kerberos est le protocole sécurisé
pour authentifier un utilisateur (ou un
ordinateur) qui souhaite accéder à une
ressource (partage de fichiers) sur un serveur
membre d’un domaine Active Directory.
❑ Dans un scénario type, il y a 3 acteurs :
✓ Le client C (l’utilisateur dans notre cas)
qui souhaite s’authentifier auprès d’un
serveur S.
✓ Le serveur S (le serveur de fichiers, soit
le compte ordinateur du serveur S) qui
doit s’assurer de l’authenticité de C.
✓ Le tiers de confiance, le KDC (le
contrôleur de domaine Active Directory).
Active Directory
❑ Développé initialement au MIT, dans le cadre
du projet Athena au début des années 80
❑ Version courante : Kerberos V5
✓ Améliorations par rapport à V4
✓ Standards IETF : RFCs 1510 et 1964
✓ V4 et V5 sont non-interopérables
❑ Principes
✓ Basé sur la notion de « Ticket »
✓ Cryptographie à Clefs secrètes
✓ Authentification mutuelle
✓ Tickets limités dans le temps
✓ Mécanismes anti-rejeux
11
 Architecture et terminologie Kerberos
L’architecture de Kerberos constitue une architecture 3 tiers :
✓ un client
✓ un serveur de ressources
✓ une autorité approuvée
Un « royaume » Kerberos :
✓ est une organisation logique dans laquelle s'exécute au moins une AA,
✓ est capable d’authentifier les « principaux » déclarés sur ce serveur.
Un « principal » Kerberos
✓ est un client Kerberos, identifiable par un nom unique (un utilisateur, un client, un serveur sont
des « principaux » Kerberos)
Une autorité approuvée (AA)
✓ stocke les informations de sécurité relatives aux principaux, serveur dit « de confiance » et dont
on présuppose qu’il est parfaitement sécurisé
✓ génère et gère les clefs de session, reconnu comme tel par le client et le serveur
✓ Un KDC (Key Distribution Center), nom donné dans Windows à l’autorité approuvée.

Active Directory 12
 Services Kerberos
❑ Deux types de services sont requis :
✓ un service d’authentification (AS ou Authentication Service) qui délivre des TGT (Ticket Granting Ticket)
✓ un service d’octroi de tickets (TGS ou Ticket Granting Service)
✓ La durée de vie du TGT (10 heures) et de Ticket de service (10 heures)
❑ Dans Kerberos, un KDC génère et stocke les clefs secrètes des principaux qui lui sont rattachés.
✓ Dans WinXX, La clé secrète est directement dérivée du mot de passe de l’utilisateur
✓ Pour des raisons de sécurité, ces clefs secrètes ne servent que lors de la phase initiale d’authentification
✓ Dans toutes les autres phases, on utilise des clefs de session « jetables »
❑ Un ticket est une structure de données constituée d’une partie chiffrée et d’une partie en clair.
✓ Les tickets servent à authentifier les requêtes des principaux (un utilisateur, un client, un serveur)
✓ Deux type de tickets :Ticket Granting Ticket (TGT) et Ticket de Service (TGS)

Active Directory 13
 Structure du ticket Kerberos et protocole PAC
❑ Le protocole d’authentification Kerberos standard permet l’authentification mais ne permet pas le contrôle
des accès.
❑ En effet, le modèle du contrôle d’accès de Windows est basé sur les SID (Security Identifier), Microsoft a
donc développé le protocole PAC qui est une extension du protocole Kerberos.
❑ Le protocole PAC permet de récupérer depuis l’annuaire le SID de l’utilisateur et des groupes auxquels il
appartient (dont SID History) et de les stocker dans le champ Authorization Data du TGT.
Champ Description
tkt-vno Version (5)
realm Royaume d'origine du ticket Clair
sname Nom de l'AA ayant délivré le ticket
flags Drapeaux d'états du ticket
key Clef de session pour l'échange futur
crealm Royaume d'origine du client
cname Nom du client
Liste des royaumes ayant pris part dans le schéma
transited
d'authentification
authtime Horodatage de l'authentification
starttime Indique à partir de quand le ticket est valide Chiffré
endtime Indique l'expiration du ticket
Pour ticket renouvelables ; indique jusqu'à quand le
renew-till
ticket peut être renouvelé
Contient 0 ou une liste d'adresses depuis lesquelles le
caddr
ticket est utilisable
Champ utilisé par les applications pour passer des
authorization-data
données spécifiques

Active Directory 14
 Les Algorithmes utilisés par Kerberos
Le paramètre Network Security – configure encryption types allowed for Kerberos permet de
définir les algorithmes de chiffrement que Kerberos peut utiliser.
Algorithme Sel Complément d’informations
des-cbc-md5 Oui Protocole moyennement sécurisé.
aes128-cts-hmac-sha1 Oui Protocole de chiffrement fortement sécurisé (nouveauté de Windows 7 /
Windows 2008 R2)
aes256-cts-hmac-sha1 Oui
rc4-hmac-MD5 Non Protocole historique. Faiblement sécurisé. A désactiver.

Gestion des Identités 15

 Authentifiant
➢ Un Authentifiant est un message contenant un nom et un timestamp, le tout chiffré avec la clé
de session de l’utilisateur
➢ L’authentifiant intègre l’heure et date du jour. Cela permet à Kerberos d’empêcher une attaque
par rejeu en autorisant par défaut que 5 minutes de décalage horaire entre le client C, le
serveur S et le contrôleur de domaine (le KDC).

Active Directory 16
 Données associés à une session d’authentification

Active Directory 17
 Accès à une ressource
La requête initiale contient (en clair) l’identité du
requérant et le serveur pour lequel on demande un
TGT.
Authentification Initiale Le serveur KDC émet un TGT pour le client
La partie chiffrée l’est avec la clef Kc du client =>
seul le bon client peut déchiffrer cette partie

On utilise le TGT obtenu précédemment pour

requérir un Ticket de Service
Demande d’un ticket de service Le serveur KDC émet un Ticket de Service pour
le client et pour le service considéré

On utilise le Ticket de Service obtenu

précédemment pour accéder au service
Le serveur de ressources valide alors (ou non)
Accès au service la requête

Active Directory 18
 Processus d’accès à un service

Source: https://beta.hackndo.com/kerberos/

Active Directory 19
 Génération et transmission d’un ticket Kerberos
➢ Génération du ticket par le KDC et transmission au client,
➢ Traitement du ticket par le client et préparation de la requête au serveur
➢ Traitement de la requête par le serveur et poursuite des échanges.

Génération d’un ticket Traitement par le client Traitement par le serveur de

par le KDC ressource

Active Directory 20
 Contrôle des Acquis
Quels sont les mécanismes d’authentification disponible pour Windows
Qu’est ce que un « hash » ?
Ou sont localisés les « Hashes » ?
Comment fonctionne NTLM ?
Qu’est ce qu’un KDC Windows ?
Qu’est ce qu’un ticket Kerberos ?
Citer deux types de tickets kerberos

Active Directory 21
 Gestion des accès

❑ Les SID (Security Identifier)

❑ Les permissions (permissions NTFS, permissions de
partages, permissions sur les entrées de registre,
permissions sur les objets Active Directory…).
❑ Les privilèges systèmes.
❑ Les processus.
❑ Les jetons d’accès.

Active Directory
 Le Security Identifier (SID): présentation
❑ Un identificateur de sécurité (SID) est une structure de données au
format binaire qui contient un nombre variable de valeurs. Les premières Comment Description
valeurs de la structure contiennent des informations sur la structure du Indique que la chaîne est un
SID. S
SID
❑ Un SID est un identifiant de sécurité unique. R Indique le niveau de révision
✓ Les comptes utilisateurs, groupes et les comptes ordinateurs de Indique la valeur de l’autorité
X
d’identificateur
l’annuaire AD disposent d’un SID.
Représente une série de
✓ Les comptes utilisateurs et les groupes de la base SAM (base de valeurs de sous-autorités, où n
Y
compte locale) disposent aussi d’un SID correspond au nombre de
valeurs.
❑ Notation Standard au format chaine: S-R-X-Y1-Y2-Yn-1-Yn
✓ Y1-Y2-Yn-1: identificateur de domaine.
✓ -Yn: est l’identificateur relatif. Il distingue un compte ou un groupe de tous les autres comptes et
groupes du domaine.
❑ S-1-5-21-1712426984-1618080182-1209977580-1109 :
✓ S-1-5- : indique que le SID a été généré par Windows Security_NT_Authority.
✓ 21-1712426984-1618080182-1209977580 : représente l’identifiant unique du domaine.
✓ 1109 : c’est l’identifiant unique de la ressource (un compte utilisateur dans notre cas).

Active Directory 23
 Le Security Identifier (SID): exemples
❑ SID du groupe intégré « administrateurs »
✓ S-1-5-32-544: Ce SID comporte quatre composants:
o Un niveau de révision (1)
o Valeur de l’autorité d’identificateur (5, AUTORITE)
o Un identificateur de domaine (32, Builtin)
o Un identificateur relatif (544, administrateurs)
❑ SID du groupe Domain Admins dans le domaine « contoso »
✓ S-1-5-21-1004336348-1177238915-682003330-512
o Un niveau de révision (1)
o Une autorité d’identificateur (5, AUTORITE)
o Un identificateur de domaine (21-1004336348-1177238915-682003330, contoso)
o Un identificateur relatif (512, administrateurs de domaine)

❑ Références
https://docs.microsoft.com/fr-fr/windows/security/identity-protection/access-control/security-identifiers
https://support.microsoft.com/fr-fr/help/243330/well-known-security-identifiers-in-windows-operating-systems

Active Directory 24
 Le Security Identifier (SID): quelques exemples
✓ Chaque ordinateur dispose d’un compte d’administrateur local et chaque domaine dispose d’un
compte d’administrateur de domaine
✓ Le compte d’administrateur est le premier compte créé lors de l’installation du système d’exploitation.
S-1-5-Domain-500 Administrateur
Le compte ne peut pas être supprimé, désactivé ou verrouillé, mais peut être renommé.
✓ Par défaut, le compte d’administrateur est membre du groupe administrateurs et ne peut pas être
supprimé du groupe.
✓ Compte d’utilisateur pour les personnes qui n’ont pas de compte individuel
S-1-5-Domain-501 Invité ✓ Contrairement à la connexion anonyme, Guest est un compte réel qui peut être utilisé pour la
connexion interactive. Le compte invité ne nécessite pas de mot de passe, mais il peut en avoir un.
✓ Un compte d’utilisateur utilisé par le service KDC (Key Distribution Center). Le compte existe
S-1-5-Domain-502 krbtgt
uniquement sur les contrôleurs de domaine.
✓ Un groupe global avec des membres autorisés à administrer le domaine. Par défaut, le groupe
administrateurs de domaine est membre du groupe Administrateurs sur tous les ordinateurs ayant
rejoint le domaine, y compris les contrôleurs de domaine.
Administrateurs de
S-1-5-Domain-512 ✓ Domain Admins est le propriétaire par défaut de tout objet créé dans l’annuaire Active Directory du
domaine
domaine par n’importe quel membre du groupe.
✓ Si des membres du groupe créent d’autres objets, tels que des fichiers, le propriétaire par défaut est le
groupe administrateurs.
Utilisateurs du ✓ Groupe global incluant tous les utilisateurs d’un domaine. Lorsque vous créez un objet utilisateur dans
S-1-5-Domain-513
domaine Active Directory, l’utilisateur est automatiquement ajouté au groupe.
Ordinateurs de ✓ Un groupe global incluant tous les ordinateurs ayant rejoint le domaine, à l’exception des contrôleurs
S-1-5-Domain-515
domaine de domaine.

Active Directory 25
 Le Security Identifier (SID): accès avec les SID

❑ Dans les environnements Microsoft, le contrôle des accès se fait à l’aide de jetons d’accès. Un jeton d’accès
contient entre autres le SID du compte de l’utilisateur et le SID de chaque groupe dont est membre
directement ou indirectement l’utilisateur (groupe membre d’un autre groupe).
❑ Le SID est stocké au niveau de l’attribut objectSid qui est géré par le système. Un administrateur ne peut pas
modifier la valeur de cet attribut ou affecter le SID d’un compte utilisateur qui a été supprimé à un autre compte
utilisateur

Active Directory 26
 Le Security Identifier: SID
❑ Quand on donne des permissions à un utilisateur sur un dossier appelé Partage (onglet Security), c’est
le SID de ce compte qui dispose des permissions dans le système de fichiers NTFS.
✓ Windows résout le SID en un nom dans l’onglet Security pour le confort des utilisateurs.
✓ Si on supprime le compte utilisateur et que l’on ferme / ouvre de nouveau la session (ou
redémarrage), l’ancien compte utilisateur apparaît sous forme d’un SID.
❑ Pour afficher le SID d’un utilisateur, utilisez la console ADSIEDIT.MSC, l’éditeur d’attribut dans des
consoles Active Directory Users and Computers ou l’outil PSGETSID
(http://technet.microsoft.com/en-us/sysinternals/bb897417.aspx).
❑ Certains SID s’affichent sous la forme suivante : S-1-5-32-544, S-1-5-32-545. Il s’agit du SID des
groupes par défaut de la base SAM ou d’entités de sécurités connues (Well-known Security Principal)
comme Authenticated Users.
❑ Le SID (attribut objectSid) est différent du GUID (objectGuid) qui est l’identifiant unique d’un objet dans
la forêt Active Directory.

Active Directory 27
 Les permissions
❑ Les permissions NTFS sont basées sur 13 permissions.
✓ (onglet Security dans les propriétés d’un dossier / fichier)
✓ La permission la plus importante est Take ownership. Elle permet de devenir propriétaire d’un
fichier / dossier. Hors le propriétaire d’un fichier / dossier peut modifier les permissions et se
donner un accès aux fichiers / dossiers.
❑ Les permissions sur les entrées de registre sont basées sur 11 permissions. La permission la plus
importante est Write owner. Elle permet de devenir le propriétaire de la clé ou de l’entrée de registre.
Le propriétaire dispose du droit de modifier les permissions.
❑ Les permissions sur les objets Active Directory sont beaucoup plus complexes.
❑ Les permissions NTFS, les permissions sur le registre et les permissions sur l’annuaire Active Directory
dispose d’un mécanisme appelé Héritage qui permet de propager les permissions d’un conteneur
parent (un dossier, une clé de registre ou une OU par exemple) à des objets enfants (fichiers, entrées
de registre, compte utilisateur / groupe).
✓ L’héritage peut être désactivé si besoin.

Active Directory 28
 Règles AGLP: groupes et permissions

Serveur de Ressources,
d’Application …

Partition
Domaine
Permission Permission
Ressource Ressource

(ACL sur SID GL)

Local
User1
Global Group
Group
Global
(SID GL) Local
User2 Group
(SID GG) Group
(SID User)
(SID GG)

Account  Global Group  Universal Group  Local Group  Permission

Active Directory 29
 Les permissions
Permissions au niveau de l’Active Directory Permissions au niveau du DNS

Active Directory 30
 Les permissions
Permissions au niveau du registre
Permissions au niveau du système Dossier/Fichier

Active Directory 31
 Les privilèges
❑ Les privilèges sont des droits donnés à un utilisateur ou un groupe d’utilisateurs
✓ Par exemple le fait de pouvoir contourner les permissions NTFS (Take ownership of files or other objects)
✓ accéder à la mémoire utilisée par tous les processus (Debug programs)
✓ ouvrir une session localement (Allow Log on locally).
✓ Les comptes administrateur et SYSTEM dispose de tous les droits sur une machine Windows car ils disposent
d’un accès presque complet au système de fichiers (permissions NTFS) et de tous privilèges.

❑ Les privilèges sont au nombre de 44 sur

une machine Windows Server 2012 R2 et
se configurent sous forme de paramètres
de GPO dans Computer Configuration |
Policies | Windows Settings | Security
Settings | Local Policies | User Rights
Assignment

✓ https://docs.microsoft.com/fr-fr/windows-server/identity/ad-
ds/plan/security-best-practices/appendix-b--privileged-accounts-
and-groups-in-active-directory

✓ https://docs.microsoft.com/fr-fr/windows/security/threat-
protection/security-policy-settings/user-rights-assignment

Active Directory 32
 Les privilèges
❑ Act as part of the operating system (SeTcbPrivilege) : ce privilège permet d’outrepasser certains contrôles lors de l’ouverture de session. Il est réservé aux
processus censés ouvrir les sessions des utilisateurs. Winlogon.exe et le service seclogon ont besoin de ce privilège. Il est recommandé de donner ce privilège à
personne. Par défaut, il n’est assigné à personne.
❑ Add workstations to domain (SeMachineAccountPrivilege) : permet d’ajouter une machine dans le domaine (jusqu’à 10 stations de travail par défaut). Par défaut ce
privilège est donné aux groupes Authenticated Users. Si vous ne souhaitez pas qu’un utilisateur standard puisse joindre une machine au domaine, ce privilège doit être
reconfiguré.
❑ Back up files and directories(SeBackupPrivilege) : permet de sauvegarder les données même sans avoir les permissions. Ce privilège est très critique et est donné
aux groupes Backup Operators et Server Operators. C’est pour cette raison que les administrateurs de contenus ne doivent pas être membre de ces 2 groupes.
❑ Create a token object (SeCreateTokenPrivilege) : ce privilège permet de créer un jeton d’accès. Il n’est donné à aucun compte utilisateur et cela doit rester ainsi.
❑ Debug programs (SeDebugPrivilege) : ce droit permet à un utilisateur d’ouvrir n’importe quel processus, d’accéder à son espace mémoire et de copier ses
ressources. Normalement, aucun service de production ne doit reposer sur ce privilège, il sert en général au développement d’applications et au troubleshooting
avancé. Par défaut, les Administrateurs ont ce privilège.
❑ Enable computer and user accounts to be trusted for delegation (SeEnableDelegationPrivilege) : permet de définir qui peut autoriser ou non un utilisateur /
ordinateur à faire de la délégation Kerberos.
❑ Generate security audits (SeAuditPrivilege) : détermine qui peut générer des événements dans le journal sécurité. Ce privilège est important car il existe une
stratégie de groupe qui permet de bloquer l’ouverture de session quand le journal Security est plein (sauf pour les administrateurs). Un attaquant pourrait générer des
milliers d’événements d’audit dans le seul but de bloquer l’ouverture de session pour les utilisateurs standards.
❑ Impersonate a client after authentication (SeImpersonatePrivilege) : permet à un processus de prendre l’identité d’un utilisateur qu’il aurait authentifié. Il faut étudier
la pertinence de laisser ce privilège à un Administrateur. Par défaut, les Administrateurs, SERVICE, LOCAL SERVICE et NETWORK SERVICE ont ce privilège.
❑ Manage auditing and security log (SeSecurityPrivilege) : détermine qui peut consulter et vider le journal Security. Par défaut les administrateurs disposent de ce
droit. Seules les personnes en charge du suivi des actions sur l’annuaire (audits et contrôles) devraient disposer du droit d’effacer le journal Security sur les contrôleurs
de domaine.
❑ Restore files and directories (SeRestorePrivilege) : permet de déterminer les comptes utilisateurs qui peuvent passer outre les permissions lors des opérations de
restauration. L’utilisateur dispose d’un équivalent des permissions NTFS Traverse Folder / Execute file et Write.
❑ Take ownership of files or other objects (SeTakeOwnershipPrivilege) : permet de devenir propriétaire d’un fichier, clé de registre (entre autres) et donc de redéfinir
les permissions NTFS sur ce fichier ou clé de registre.

Active Directory 33
 Les processus
❑ Un processus est généré pour chaque exécutable qui démarre sur le système Windows (un service ou une
application).
❑ On peut voir la liste des processus dans le « Task Manager »
❑ Il est possible de personnaliser l’affichage des colonnes pour visualiser entre autres l’exécutable qui a
généré le processus, sa consommation mémoire, …etc.

Active Directory 34
 Les services
❑ Pour visualiser et configurer les services, vous pouvez utiliser la console MMC « services.msc » ou éditer les entrées de
registre sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
❑ Les services sont des exécutables qui démarrent manuellement ou automatiquement dans le contexte d’un compte
utilisateur. Les services peuvent s’exécuter dans le contexte d’un compte utilisateur, d’une entité de sécurité (System,
Local System, Network Service…),
❑ Le service NETLOGON s’exécute avec le compte System (compte système local) et lance l’exécutable
« c:\windows\system32\lsass.exe »

Active Directory 35
 Les jeton d’accès
❑ Pendant l’ouverture de session interactive/non-interactive, un jeton de sécurité est crée pour
représenter l’utilisateur qui se connecte. Tous les programmes qu’exécute l’utilisateur héritent d’une
copie de ce jeton initial.
❑ Un jeton d’accès est généré par le processus Lsass.exe (service Netlogon) une fois que
l’utilisateur est authentifié avec le protocole Kerberos ou NTLM. Un jeton d’accès contient :
✓ Le SID et les SID History du compte de l’utilisateur
✓ Le SID et SID History de tous les groupes du domaine dont l’utilisateur est membre directement et
indirectement (groupe membre d’un autre groupe…).
✓ Le SID de tous les groupes de la base SAM locale auxquels l’utilisateur appartient (comme
Administrators)
✓ La liste des privilèges (comme SeDebugPrivilege) dont dispose l’utilisateur sur la machine locale.
❑ Un jeton d’accès permet d’accéder à une ressource (ex: validation des ACL sur les volumes en
NTFS)

Active Directory 36
 Les jeton d’accès
❑ Il existe deux types de jeton d’accès :
❑ Jeton primaire (Primary Token) : ce type de jeton est généré lors des ouvertures de session interactive
(locale) ou Batch et sont dit de type 2 dans les événements du journal de sécurité. Jeton qui identifie le
contexte de sécurité d’un processus. Ils ne sont pas exploitables.
❑ Impersonation jeton (Impersonation Token) : ce type de jeton est généré lors des ouvertures de session réseau
et sont dit de type 3 dans les événements du journal de sécurité. Jeton qui est utilisé pour prendre
temporairement une autre identité
✓ Les Impersonation Tokens, qui autorisent à utiliser un contexte de sécurité différent de celui du
processus courant. Ils implémentent quatre niveaux d'impersonation :
✓ Anonymous : non utilisé ;
✓ Identify : permet d'identifier l'utilisateur, mais pas d'effectuer des actions en son nom ;
✓ Impersonate : permet d'effectuer des actions locales dans le contexte de l'utilisateur ;
✓ Delegate : permet d'effectuer des actions distantes dans le contexte de l'utilisateur.

Active Directory 37
 Visualisation des jetons d’accès

SID : S-1-5-2
Nom : Réseau
Description : Un groupe qui inclut tous
les utilisateurs qui se sont connectés
par l’intermédiaire d’une connexion
réseau. L’appartenance est contrôlée
par le système d’exploitation.

SID : S-1-5-11
Nom : Utilisateurs authentifiés
Description : Un groupe qui inclut tous
les utilisateurs dont les identités ont été
authentifiées lorsqu’ils se sont
connectés. L’appartenance est
contrôlée par le système d’exploitation.

SID : S-1-5-21domaine-513
Nom : Utilisateurs du domaine
Description : Un groupe global qui, par défaut, inclut tous les comptes d’utilisateurs dans un domaine. Lorsque vous
créez un compte d’utilisateur dans un domaine, il est ajouté par défaut à ce groupe.
https://support.microsoft.com/fr-fr/help/243330/well-known-security-identifiers-in-windows-operating-systems

Active Directory 38
 Contrôle des Acquis
Qu’est ce qu’un SID Windows ?
Qu’est ce qu’une permission Windows ?
Qu’est ce qu’un privilège ?

Active Directory 39
 Attaques en
environement AD
❑ Attaques sur l’Active Directory
❑ Les « Hashes » (empreintes)
❑ Outils pour récupérer les hashes
❑ Mimikatz, outils powershell
❑ Panorama des attaques sur l’authentification
❑ TP

Active Directory
 Attaques sur Active Directory ?
L’annuaire Active Directory, un actif de plus en plus ciblé par les cybercriminels… et à risque
Les raisons sont multiples
✓ Microsoft est très répandu dans les entreprises
✓ AD a une position centrale au sein du système d’information
✓ L’annuaire porte le poids de l’historique et suit la vie de l’entreprise
o Ces mises à niveau, refontes, migrations sont souvent menées par l’infrastructure et la sécurité n’est pas embarquée
(nombreux problèmes de configuration et nombreux risques post migration)
o Quelques exemples de problèmes rencontrés : SID history, comptes AD krbgt à risque, récupération d’un grand nombre
de comptes inutiles et à privilège,…
✓ La démocratisation de la connaissance des failles kerberos l’outillage pour les exploiter fait qu’un « script
kiddy » est désormais capable en peu de temps de réaliser une attaque Golden ticket.
✓ les hackers vont chercher l’accès le plus rapide et efficace au système d’information de l’entreprise ou
l’organisation ciblée. L’AD est la porte d’entrée, ils n’ont plus qu’à trouver la clé pour pénétrer au sein du SI
o Le Pirate pourra avoir accès aux données, aux emails, aux appareils mobiles et poste du PDG et autres fonctions
décisionnaires qui détiennent les informations confidentielles de l’entreprise..
o Du fait de sa structure globale et centrale, l’AD donne accès au réseau de partenaires, clients, prestataires de
l’entreprise qui sont interconnectés au SI de l’entreprise
✓ Le maillon faible de l’AD : le manque de formation et d’investissement
Active Directory 41
 Attaques sur Active Directory ?
Plusieurs éléments permettent à un attaquant de
compromettre Active Directory.
On peut citer par exemple:
✓ Les vulnérabilités non patchées des systèmes Windows
✓ Les mauvaises configurations d’Active Directory
✓ Mauvaises habitudes d’administration (administrateurs
du domaine se connecte aux postes clients,
serveurs,…)
✓ Architecture non sécurisée (par définition, un annuaire
est ouvert, on peut lire des informations)
✓ Stratégie de mots de passe (mots de passe faible
notamment pour les administrateurs, fréquence de
Cinématique d’une attaque visant Active changement inexistante, comptes de services avec
privilèges ex: compte backup)
Directory
✓ La non compréhension des risques liés à Active
Directory de la part de certains managers

Active Directory 42
 Quelques outils: PsExec, Nessus, Enum4Linux
Psexec
• Exécution de programmes sur une machine distante
• Permet pour exemple de récupérer une invite de commande en mode interactif
• Utilisable avec un login/mot de passe ou hash (à vérifier)
Affichage d’une invite de commande du poste ayant l’adresse IP 192.168.1.1 en mode interactif
psexec.exe 192.168.1.1 -u domaine\utilisateur -p motdepasse -s -i cmd.exe
Nessus
• Scan de ports / services
• Identification de vulnérabilités et classement par criticité
• Tests de conformité (système d’exploitation, services, équipements, etc.)
• Création de politique spécifique
• Interface Web d’administration
• Gestion des utilisateurs

Enum4linux
• Extraire de nombreuses informations de services Windows et Samba (liste des utilisateurs et groupes d’un domaine,
politique de sécurité, liste des partages)
• Nécessite un compte sur le domaine sauf si les « null sessions » sont activées
Exemple liste des membres par groupe
enum4linux.pl -u admin -p mot_de_passe -G 192.168.1.1

Active Directory 43
 Quelques outils: Nmap
Nmap
• Scan de ports / services
• Identification de l’OS (plus ou moins fiable)
• Nombreux plugins disponibles (vulnérabilités, screenshots, récupération d’informations, smbpsexec, etc)

Scan de tous les ports TCP en SYN avec identification des services (65535)
nmap -sS -sV -PN -T4 -p- -O -vvvv -iL fichier_liste_ip_ou_ranges -oA output

Scan enum session avec la technique PTH

nmap -p445 --script=smb-enum-shares --script-args=smbuser=administrateur,smbhash=9c014340dd2bffb7aad3b435b51404ee
192.168.1.1

Scan enum session avec login et mdp

nmap -p445 --script=smb-enum-sessions --script-args=smbuser=digitaluser,smbpass=digitalpass 192.168.1.1

Screenshots des services Web (plugins disponibles sur Internet)

nmap -sV -p80,443,8443,8080,9090 --script /usr/share/nmap/scripts/http-screenshot 192.168.1.1

Active Directory 44
 Quelques outils: Mimikatz
❑ L’outil Mimikatz a été développé par Benjamin Delpy
❑ Rendu public en 2007. Mimikatz fonctionne sur les versions supérieures à Windows 2000 (les versions 32 et
64 bits sont supportées) : XP, 2003, Vista, Seven, 2008, 2008R2, 8, 2012.
❑ Mimikatz est organisé autour de différents modules (liste non exhaustive) :
✓ standard : intègre les commandes de base de l'outil.
✓ crypto : interagit avec les modules cryptographiques de Windows CryptoAPI [CAPI]et CNG [CNG], ainsi que l’extraction de certificats
et de clés.
✓ sekurlsa : extrait les hashes et mots de passe des sessions Windows en cours.
✓ system : intègre des commandes système de base telles que l’obtention de l’utilisateur et de l’ordinateur courant.
✓ nogpo : permet de contourner certaines GPO Windows triviales.
✓ samdump : permet d’extraire les hashes de la base SAM de l’équipement Windows, via la base de registre ou des fichiers plats.
✓ inject : injection de bibliothèques dans des processus Windows.
✓ ts : manipulation des sessions Terminal Server (autorise le dépassement du nombre maximal de connexions simultanées notamment).
✓ divers : contient diverses fonctions majoritairement expérimentales.
❑ Enfin, un pilote mimikatz.sys est également fourni et permet ainsi d’avoir un point d’entrée en mode utilisateur
dans le noyau.
Source https://connect.ed-diamond.com/MISC/MISC-066/Utilisation-avancee-de-Mimikatz

Active Directory 45
 Quelques outils: WCE
❑ Support la technique Pass-The-Hash (PTH)
❑ Vol de mots de passe en mémoire (sans et avec injection)
❑ Vol de tickets Kerberos
❑ Dump des mots de passe Windows en clair
❑ Usurpation via la création d'un token spécifique pour l'exécution de programmes

Exécution d’une invite de commande possédant un token spécifique au compte utilisateur1 du domaine domaine1
wce.exe -s utilisateur1:domaine1:aad3b435b51404eeaad3b435b51404ee:9c014340dd2bffb7aad3b435b51404ee
-c cmd.exe

Récupération des mots de passe Windows en mémoire

wce.exe -w

Dump des tickets Kerberos

wce.exe -K

Active Directory 46
 Quelques outils: ntdsutil
❑ Outil de ligne de commande qui fournit des fonctionnalités de gestion des services de domaine AD
❑ Utile dans un pentest pour sauvegarder la base contenant les informations des utilisateurs et groupes d’un AD

Copie du fichier ntds.dit, SYSTEM et SECURITY dans le répertoire C:\test

C:\>ntdsutil
ntdsutil: activate instance ntds
ntdsutil: ifm
ifm: create full c:\test
ifm: quit
ntdsutil: quit

Active Directory 47
 Quelques outils: Responder, Metasploit, John the ripper
Responder
❑ Outil « python » permettant d’effectuer du MITM et du spoofing sur de nombreux protocoles
❑ Permet d’émuler des services sur certains protocoles
❑ Les fonctionnalités sont à définir pour certaines dans le fichier de configuration prévu à cet effet

Metasploit
❑ Outil pour le développement et l'exécution d'exploits
❑ Création de binaires (.exe, .pdf, .apk, .java, etc.) comportant une charge malveillante visant à prendre le contrôle de
l’équipement cible
❑ Nombreux modules disponibles (SMBLogin, psexec, post-exploitation, etc.)
❑ Dispose de fonctionnalité permettant le rebond

John the ripper ou oclhashcat

❑ Cassage de mots de passe via dico, brute-force ou encore table arc-en-ciel
❑ Oclhashcat ajoute le cassage via la puissance du GPU

Active Directory 48
 Quelques outils: PowerShell
Dsinternals: modules de la communauté pour le Hacking
Active Directory
https://www.powershellgallery.com/packages/DSInternals/2.16.1
https://www.dsinternals.com/en/list-of-cmdlets-in-the-dsinternals-module/
✓ 2 modes de fonctionnement : en ligne et hors ligne.
✓ Permet de lire / modifier le LMHASH et le NTHASH d’un
compte, installation simplifiée (PowerShell V5) : Install-
Module DSInternals
PowerSploit : modules de la communauté
https://github.com/PowerShellMafia/PowerSploit
✓ Collection de scripts PowerShell pour la phase de
découverte et d’exploitation
✓ Principales fonctionnalités : injection de code, injection de
DLL, détection d’antivirus, scan de ports, Keylogger, copie
de fichiers verrouillé, intégration Mimikatz

Active Directory 49
 Les « Hashes » (empreintes)
❑ Lsass (Local Security Authority Process) est le
processus de Microsoft du Serveur local d'authentification
de sécurité responsable pour l'authentification de
l'identification de l'utilisateur et de l'application de la
politique de sécurité.
❑ Winlogon est un processus qui réalise la fonction de
gestion de connexion Windows, traitant la connexion de
l'utilisateur et sa fermeture de session dans Windows.
❑ Plusieurs bibliothèques intégrées à Windows, les
Authentication Packages, implémentent différents
mécanismes permettant de s'authentifier sur un système
ou une ressource distante (MSV1_0, Wdigest, Kerberos,
TsPkg, etc.).
❑ A priori, seul le package MSV1_0, introduit avec Windows
NT4, est basé sur un mécanisme défi/réponse impliquant Source: https://www.microsoftpressstore.com/articles/article.aspx?p=2228450&seqNum=8

les hashes LM et NTLM.

❑ Les packages Wdigest, Kerberos et TsPkg conservent ce
mot de passe sous une forme chiffrée mais réversible.

Gestion des Identités 50

 Outils pour récupérer les « hashes »

Programme Procédure Données récupérables

privilege::debug Hashes LM/NTLM de comptes locaux
sekurlsa::logonPasswords Full Hashes LM/NTLM en mémoire
Mimikatz
divers::secrets Full Mots de passe en mémoire
(voir note sur les tâches planifiées) Certificats et clés en mémoire
Hashdump Hashes LM/NTLM de comptes locaux
Meterpreter
cachedump Hashes MS-CACHE
wce.exe -w Hashes LM/NTLM en mémoire
WCE
wce.exe -l -v Mots de passe en mémoire

Source: https://connect.ed-diamond.com/MISC/MISC-068/Faiblesses-des-mecanismes-d-authentification-de-Windows-quelles-solutions

Active Directory 51
 Panorama des attaques sur l’authentification
❑ L'attaque Pass-the-Hash [PTH] est relativement connue. Elle vise à extraire le hash NTLM de l'utilisateur et
à injecter ce hash à la place de son mot de passe pour réaliser, à sa place, des authentifications réseau. Cette
attaque s'appuie sur le fournisseur de sécurité NTLM, déconseillé par rapport à Kerberos qui peut donc être
désactivé.
Des attaques similaires existent pour Kerberos (quelques exemples) :
✓ Over-Pass-the-Hash: l'attaque vise à passer le hash de l'utilisateur de la même façon que pour NTLM. En
effet, les demandes de tickets Kerberos sont signées par un dérivé du mot de passe de l'utilisateur.
✓ Pass-the-ticket: l'attaque vise à importer directement le ticket Kerberos d'un utilisateur (TGT, Ticket¬Granting
Ticket) pour demander des tickets d'accès (TGS, Ticket-Granting Service) à sa place. Le TGT est visible avec
la commande klist tgt et est valide habituellement 8 heures. Les TGS sont visibles avec le commande klist.
❑ Golden ticket: l'attaque vise à générer directement des tickets Kerberos (TGT) à la demande en connaissant
le secret qu'utilise les contrôleurs d'un domaine : un dérivé du mot de passe du compte krbtgt.
❑ Silver ticket: l'attaque permet, en connaissant un dérivé du mot de passe du service visé de générer
directement un ticket d'accès au service (TGS), la dernière étape de l'authentification Kerberos auprès d'un
tiers.

Active Directory 52
 Panorama des attaques sur l’authentification

Kerberos est un protocole

d'authentification, utilisé au sein d'Active
Directory et reposant sur un mécanisme
de tickets, émis par deux services de
distribution du KDC (Key Distribution
Center)

Les TGT sont chiffrés avec l'un des

secrets (clé RC4, dont la valeur est
identique au "Hashes" NTLM, ou clés
AES 128/256 bits) du compte « krbtgt »
du domaine et permettent l'obtention de
tickets de service.

Pass the hash

over pass the hash
pass the ticket
golden ticket
silver ticket.
Active Directory 53
 Attaque « Pass the Hash »

❑ L'attaque Pass the Hash est une attaque connue depuis longtemps et qui reste fonctionnelle sur les
versions de Windows récentes. Le concept est simple, lors d'une authentification Windows, les
« hashes » LM et NTLM sont utilisés afin d'identifier l'utilisateur.
❑ La récupération des "Hashes LM et NTLM suffit pour s'authentifier sur d'autres équipements ou services.
Il n'est donc pas nécessaire de les « casser » afin d'obtenir un accès sur d'autres services.
❑ Si nous disposons des droits SYSTEM ou d'administration sur le poste client ou le serreur, il est possible
d’extraire les hashes des comptes locaux qui sont dans la base SAM.
❑ Sur un réseau interne, on constate généralement que l'administrateur local est identique sur l'ensemble
des machines du réseau ou sur une grande partie, c'est-à-dire que le même mot de passe est réutilisé
pour ce compte et sur différentes machines.
❑ Les phases d'authentification reposent sur des défis/réponses possible à résoudre même si l'on ne
dispose que du hash, qui est stocké en mémoire par Windows. En conséquence, tous les hashes
LM/NTLM obtenus sur un système Windows peuvent alors être chargés dans la session en cours afin de
les « passer » lors des phases d'authentification réseau et ainsi usurper l'identité d'un autre utilisateur
dont le hash a été dérobé

Active Directory 54
 Attaque par Golden Ticket avec Mimikatz
Golden ticket: l'attaque vise à
générer directement des tickets
Kerberos (TGT) à la demande
en connaissant le secret
qu'utilise les contrôleurs d'un
domaine : un dérivé du mot de
passe du compte krbtgt.

✓ Pour pouvoir modifier le TGT, ou en forger un nouveau, il faudrait connaitre la clé qui l’a chiffré, c’est à dire
celle du KDC. Cette clé, c’est en fait le hash NTLM du compte krbtgt. Ce compte est un simple compte, sans
droits particuliers (au niveau système ou Active Directory) et même désactivé.
✓ Si jamais un attaquant parvient à trouver le hash NTLM de ce compte, il est alors en mesure de forger des
TGT avec des PAC arbitraires.
✓ Il suffit de forger un TGT avec comme information que l’utilisateur de ce ticket fait partie du groupe
“Administrateurs du Domaine”, et le tour est joué.
Source: https://beta.hackndo.com/kerberos-silver-golden-tickets/

Active Directory 55
 Attaque par Golden Ticket avec Mimikatz

Active Directory 56
 Attaque avec un Silver Ticket

Silver ticket : l'attaque

permet, en connaissant un
dérivé du mot de passe du
service visé de générer
directement un ticket d'accès
au service (TGS), la dernière
étape de l'authentification
Kerberos auprès d'un tiers.

❑ Si un attaquant parvient à extraire le mot de passe ou le hash NTLM d’un compte de service, il peut alors forger
un ticket de service (TGS) en choisissant les informations qu’il veut mettre dedans afin d’accéder à ce service,
sans passer par le KDC.
❑ L’attaquant construit ce ticket forgé qui est appelé Silver Ticket.
Source: https://beta.hackndo.com/kerberos-silver-golden-tickets/

Active Directory 57
 Attaque avec un Silver Ticket

Active Directory 58
 TP

Objectifs du TP : Evaluer et expérimenter des attaques sur l’environnement Microsoft

(postes clients Windows et annuaire Active Directory)
Vous disposez de :
➢ 1 serveur Windows 2016 server en tant que contrôleur de domaine
« ActiveDirectory » sur le domaine « ADTESTX.NET »
➢ 1 Windows Seven intégré au domaine AdtestX.net : W7-X
➢ 1 Windows 10 intégré au domaine AdtestX.net : W10-X

Active Directory 59
 Sécuriser AD et les
environnements
Microsoft
❑ Problèmes courants sur les environnements
Windows
❑ Comment sécuriser les environnements Windows
❑ Sécuriser AD et Azure AD
❑ Sécuriser le poste de travail
❑ Architecture sécurisée Active Directory

Active Directory
 Problèmes courants sur les environnements Windows
✓ Systèmes déployés avec les réglages par défaut
✓ Nombre important d’administrateurs !
✓ Les comptes « administrateur » et les comptes de service ont beaucoup trop de privilèges d’accès
✓ Mauvaise utilisation des comptes administrateurs de domaine (on se connecte sur les postes, les
serveurs)
✓ Mots de passe trop courts pour les administrateurs et les comptes de service
✓ Les comptes administrateurs locaux ne sont pas gérés correctement (fréquence de changement des
mots de passe ?)
✓ Mots de passe trop courts pour les comptes de service
✓ Les comptes administrateurs locaux ne sont pas gérés correctement
✓ Les contrôleurs de domaine n’ont pas les tout derniers correctifs
✓ Les serveurs n’ont pas les tout derniers correctifs
✓ Trop de programmes/services sont exécutés sur les contrôleurs de domaine (séparation des fonctions ?)

Active Directory 61
 Comment se protéger des attaques sur l’authentification
Actions de protection
✓ Une des premières actions entreprises par les équipes de défense en cas de suspicion de compromission du domaine est
de renouveller deux fois consécutif le mot de passe du compte « krbtgt »
✓ Auditer le compte « krbtgt » régulièrement
✓ Les solutions du marché permettent la détection de l'usage de golden tickets, notamment la solution Microsoft Advanced
Threat Analytics (ATA)
✓ Limiter les accès au contrôleurs de domaine
✓ Appliquez le principe de moindre privilège
• Limitez l’accès des utilisateurs à ce dont ils sont réellement besoin
• Limitez les accès Admin et Administrateur de domaine
• Utilisez avec modération les comptes Admin et seulement pour des modifications approuvées
✓ Installez sur les postes des protections pour empêcher les cyber attaquants de charger des modules comme « mimikatz »
✓ Utiliser un bastion pour sécuriser vos comptes à privilèges !
✓ Surveillez les activités sur les fichiers et le comportement des utilisateurs
✓ Créez des alertes relatives à un comportement connu indiquant des attaques par Golden ou Silver Ticket

Active Directory 62
 Comment sécuriser les environnements Windows
Les comptes à privilèges Stratégies de mots de passe
✓ Ne pas autoriser la connexion avec des comptes privilégiés sur des ✓ Ne pas réutiliser les mots de passe.
machines considérées comme « à-risque ». ✓ Utiliser NTLMv2 uniquement, ou encore
✓ Restreindre le nombre de comptes à hauts privilèges sur l’AD mieux, Kerberos (sic).
✓ Ne pas autoriser les comptes locaux à ouvrir des sessions à distance et ✓ Limiter le nombre de données d'entrées
désactiver les comptes d'administration locaux. MS-CACHE stockées localement.
✓ Utiliser des postes et des comptes dédiés à l'administration du domaine. ✓ Vérifier les mots de passe par rapport à des
✓ Créer les tâches planifiées avec des comptes dédiés, disposant de listes noires
privilèges limités. ✓ Vérifier la réutilisation de mots de passe
✓ Ne pas intégrer les utilisateurs aux groupes d'administration locaux.
✓ Vérifier les autorisations et l’utilisation des comptes administrateurs
✓ Ne pas se connecter avec des comptes sensibles sur un poste « à
risque ».
✓ Créer des groupes d’accès à granularité plus fine
✓ Retirer les privilèges non requis
✓ Mettre en œuvre l’authentification multi facteur
✓ Mettre en œuvre une solution PIM/PAM

Active Directory 63
 Comment sécuriser les environnements Windows

Gouvernance AD
✓ Mettre en place une gouvernance (Active Directory ?)
✓ Revues sur les droits d’accès, audit
✓ Processus efficaces et opérationnels (ISO 27001 ?)
✓ Impliquer le personnel technique
✓ Impliquer les managers

Active Directory 64
 Sécuriser AD et Azure AD

Détection des attaques

(ATA / ATP)

Tests d’intrusions

Durcissement protocoles authentification Audit des changements liés aux

(Kerberos, NTLM) infrastructures et objets

PRA/PCA Sécurisation des postes Automatisation du cycle Gestion des comptes

Active Directory d’administration de vie des objets administrateurs locaux

Durcissement du système Délégation de Réduction des privilèges des Mise en place de politique de
d’exploitation l’administration comptes de services mots de passe / MFA

Définition de l’architecture cible - gouvernance des annuaires Active Directory / Azure Active Directory

Source Metsys

Active Directory 65
 Sécuriser le poste de travail

Windows Defender
Advanced Threat
Protection (ATP)

Credential Guard Device Guard

Windows Hello Enterprise Data Protection

BitLocker Secure Boot

Délégation d’administration
LAPS Utilisateur standard (administrateur)
(Tier 0 / Tier 1 / Tier 2)

Un OS supporté (APPV – UE/V) Un OS à jour Un antivirus à jour

Source Metsys

Active Directory 66
 Architecture sécurisée Active Directory
VXXX est un groupe français regroupant plusieurs sociétés membres présentes en France et à l’International. Il conçoit
des solutions de sécurisation des accès physiques pour les sites d’importance vitale dans les deux domaines « Détection
périmétrique d’intrusion » et « Contrôle et sécurisation des accès ». Il est issu du rapprochement en 2014 de SORHEA
(détection d’intrusions) et de TIL Technologies (contrôle d’accès).
Le groupe VXXX emploie environ 150 personnes réparties sur cinq sites dont deux en France. Chaque société possède
son historique et savoir-faire. Le groupe est dans une phase d’acquisition et de rachat de sociétés. Les objectifs de la
direction sont de faciliter le travail collaboratif avec des projets structurants tels que la migration vers office 365, définir un
cadre d’interconnexion efficace pour les sociétés existantes et futures et renforcer la sécurité globale du SI

Sociétés Active Directory Commentaires

TXXX TXXX.fr
AXXX AXXX.local 80 personnes + TST
ARXXX Domaine DNS « arX.fr » SAMBA. 1 machine ARX à son propre tenant O365
« fait tout ou presque » + pfsense.
PXXXX-USA corp.local (A RENOMMER) Géré par IQ (infogérant)

VXXX Pas d’AD Utilisateurs 0365

EXXX Eurocloture.local
TXXX TDSI à son propre tenant O365

Source Metsys

Active Directory 67
 Architecture sécurisée Active Directory
Foret Administration Active Directory Eléments ayant influencé le choix de l’architecture
➢ Conserver l’indépendance des structures. On évite la
TXXX.fr
solution un seul « tenant » office 365 au niveau de la forêt AD
commune « VXXX » pour éviter les problématiques de
Cloud, Office 365
Azure
migration dans le cloud en cas de départ d’une des sociétés.
Administrateurs AXXX.local
Fédération +
Active Directory ➢ Possibilité d’accéder à des applications en mode SaaS
synchronisation cloud communes impliquent de fédérer et synchroniser les identités
des comptes dans
le cloud dans le cloud.
Corp.local ➢ Administration centralisée et sécurisée. L’orientation prise
favorise la sécurité avec la mise en place d’une forêt AD
EXXX.local
AD
connnect
d’administration. Ce type d’architecture en général réservé
aux grandes entreprises,
XXX
Service PKI ➢ Partage au travers d’une forêt Active Directory de
Service données AD FS
Relation approbation AD
commun services communs. Cette structure servira de socle pour la
unidirectionnelle création de services commun à l’ensemble du groupe (service
Relation approbation AD Foret Active Directory
bidirectionnelle « VXXX » pour les de certificats, service de données partagée, applications
Services commun à toutes les communes). Ce domaine « commun » sera lui aussi géré par
entités
la forêt d’administration.

Active Directory 68
 Architecture sécurisée Active Directory

❑ Pour les comptes administration, une architecture en tiers de confiance empêchera l’élévation de
privilège pour un attaquant ayant volé des identifiants.
❑ Chaque compte est « cantonné » à son périmètre. Cela évitera que le « hash » d’un compte
administrateur du domaine AD ne se retrouve sur un nombre important d’ordinateurs. Cela prépare le
contrôle et la séparation des tâches.

Source Metsys

Active Directory 69
 Sécuriser les accès à
privilèges
❑ Qu’est-ce qu’un compte à privilèges ?
❑ Les comptes à privilèges dans l’entreprise
❑ Pourquoi la sécurisation des accès à privilèges
est-elle importante ?
❑ Mettre en place une solution PAM (Privileged
Access Management)

Active Directory
 Qu’est-ce qu’un compte à privilèges ?
❑ Un accès à privilèges signifie que l’utilisateur dispose de droits d’accès de type administrateur à un
système.
✓ Par exemple, un droit d’accès à privilèges sur Microsoft Exchange Server permet à l’utilisateur qui en
dispose de créer, modifier et/ou supprimer des comptes e-mail sur ce serveur
✓ Un utilisateur privilégié est une personne avec un accès administratif à des systèmes critiques pour
modifier les configurations du système, installer des logiciels, modifier des comptes utilisateurs, accédez
à des données sécurisées
❑ Plus généralement, un compte à privilèges, ou accès « root », permet de modifier les
configurations d’un système, d’installer et désinstaller des programmes, de créer ou supprimer des
comptes d’utilisateurs, ou encore d'accéder à des données sensibles.
✓ C’est la raison pour laquelle les accès à privilèges doivent être contrôlés et supervisés. Tout comme il
doit être possible de révoquer ces droits à tout moment.
❑ Il existe des solutions de gestion des accès à privilèges: PAM pour Privileged Access
Management (Wallix et Cyberark) et de gestion des identités privilégiées: PIM pour Privileged
Identity Management
❑ Les comptes à privilèges, tels que les administrateurs de Active Directory disposent d’un accès
direct ou indirect à la plupart ou à la totalité des ressources d’une organisation informatique.
Cela rend la compromission de ces comptes un risque important pour l’entreprise.
Active Directory 71
 Les comptes à privilèges dans l’entreprise
❑ Principe de privilège minimal
A D M I N I S T R AT E U R S
DE DOMAINE
A D M I N I S T R AT E U R S ❑ Groupes imbriqués
BASES DE DONNEES
❑ Ségrégation des rôles
✓ Administrateurs de domaine
✓ Administrateurs de serveurs
✓ Administrateurs de poste de travail
A D M I N I S T R AT E U R S
DE SERVEURS ✓ Administrateurs de bases de données

A D M I N I S T R AT E U R S D E
P O S T E S D E T R AVA I L

IoT
IoT
A D M I N I S T R AT E U R S
RESEAUX

Domaine AD.ENT1.FR
Active Directory 72
 Pourquoi la sécurisation des accès à privilèges est-elle importante ?
❑ Les cybercriminels se concentrent sur l’accès à privilèges des systèmes Windows et des annuaires comme
Active Directory (AD) pour accéder rapidement à toutes les données ciblées des organisations.
❑ Les approches de sécurité traditionnelles se sont concentrées sur le réseau et les pare-feu comme
périmètre de sécurité principal, mais l’efficacité de la sécurité réseau a été considérablement réduite par
deux tendances :
✓ Les organisations hébergent des données et des ressources en dehors de la limite réseau
traditionnelle sur les ordinateurs portables, les appareils tels que les téléphones mobiles et les
tablettes, les services Cloud et les appareils mobiles (BYOD)
✓ Les pirates ont une capacité et des outils permettant des suivre et d’obtenir des accès sur des stations
de travail situées dans les limites du réseau par le biais de techniques (hameçonnage, attaques web
et e-mail)
❑ Ces facteurs nécessitent la création d’un périmètre de sécurité moderne à partir des contrôles d’identité et
d’autorisation, en plus de la stratégie de périmètre de réseau classique.
❑ Un périmètre de sécurité est défini comme un ensemble de contrôles cohérents entre les ressources et leurs
menaces. Les comptes à privilèges sont effectivement en mesure de contrôler ce nouveau périmètre de
sécurité. il est donc essentiel de protéger l’accès à privilèges

Active Directory 73
 Mettre en place une solution PAM (Privileged Access Management)

Une solution de PAM que l’on appelle aussi bastion va permettre :

✓ Des mots de passe sécurisés dans un coffre-fort dédié.
✓ Accordez des privilèges aux utilisateurs uniquement pour les systèmes sur lesquels ils sont
autorisés.
✓ Évitez que les utilisateurs privilégiés aient ou aient besoin de mots de passe système locaux
✓ Gérez l'accès de manière centralisée et rapide sur un ensemble disparate de systèmes
hétérogènes.
✓ Créez un audit inaltérable pour toute opération privilégiée.

Active Directory 74
 Séparer le réseau d’Administration du réseau Bureautique
❑ Un chemin « bleu » dans lequel un compte d’utilisateur standard est utilisé pour l’accès non privilégié
aux ressources, telles que la messagerie électronique et la navigation Web, ainsi que le travail
quotidien.
❑ Chemin « rouge » dans lequel l’accès privilégié se produit sur un appareil renforcé pour réduire le
risque de hameçonnage et d’autres attaques par le Web et par courrier électronique.

Active Directory 75
 Privileged Access Management: Architecture Wallix
❑ L'intégration à Active Directory
permet de gérer les informations
Accès Externe
d'identification AD avec MFA
WAN
❑ Les comptes cibles locaux (root,. \
Administrateur) peuvent être utilisés
pour se connecter à la cible
VIP
❑ Authentification auprès d'une
WAB-AM
application distante (RDS) à l'aide de WAB
scripts Auto IT WAB-AM 1 WAB-AM 1
DR
✓ Client lourd Accès Interne
✓ Client Web.
Desaster
VIP Recovery
❑ Authentification sur les actifs
WAB
télécoms (ssh par ex) WAB
WAB Master WAB Slave
❑ L'authentification à l'aide de comptes DR
génériques est possible, la
responsabilité est conservée. RDS Router
TARGETS Windows Servers Linux Servers
Applications /Switch

Active Directory 76
 Privileged Access Management: connexion

❑ 3 types de connexion possibles:

✓ Comptes: utilisez un compte
principal différent du compte
secondaire
✓ Mappages de comptes: le
même utilisateur est utilisé
comme compte principal et
compte secondaire.
✓ Ouverture de session
interactive: l'utilisateur doit
spécifier la connexion
secondaire (manuel)
❑ Les droits sont définis à l'aide
de groupes.
❑ L'autorisation donne accès à un
groupe d'utilisateurs pour un
groupe d'appareils

Active Directory 77