SEC560 | TESTS DE PÉNÉTRATION RÉSEAU ET PIRATAGE ÉTHIQUE

560.5 Domination de domaine et Azure Annihilation :

Bienvenue à la session SANS Security 560.5. Dans cette session, nous allons examiner les
mécanismes d'authentification utilisés sous Windows, tels que NTLM et Kerberos, et comment nous
pouvons attaquer ces mécanismes. De plus, nous verrons comment nous pouvons escalader nos
privilèges et contourner les contrôles UAC. En outre, nous nous concentrerons également sur la
manière d'obtenir le contrôle des domaines Windows à l'aide de Domain Dominants.

La deuxième partie de cette session se concentrera sur Azure AD et son intégration avec les
domaines Windows sur site. Nous passerons en revue les bases d'Azure AD et examinerons les
attaques fondamentales, suivies de quelques attaques spécifiques ciblant le cloud et les domaines
sur site. Nous aborderons ensuite les applications et l'authentification, puis les attaques spécifiques
et nous terminerons par quelques défenses Azure spécifiques.

Sans plus attendre, commençons.

 TABLE DES MATIÈRES

I. KERBEROS
1. LAB 5.1: Kerberos
II. ATTAQUES DE DOMINATION DE DOMAINE (GOLDEN TICKETS, DCSYNC, DCSHADOW)
1. LAB 5.2: Domination de domaine
2. TP 5.3: Domination de domaine - Chemin alternatif
3. LAB 5.4: SilverTicket pour la persistance
III. INTRODUCTION A AZURE
IV. STRATEGIES D'ATTAQUE D'AZURE
V. INTEGRATION AD SUR SITE
VI. STRATEGIES D'ATTAQUE AVEC INTEGRATION AD
VII. APPLICATIONS ET AUTHENTIFICATION
VIII. STRATEGIES D'ATTAQUE DES APPLICATIONS
IX. REPONDEUR
1. Lab 5.5 : Répondeur
X. BLOODHOUND : LIMIER CHIEN DE CHASSE
1. Labo 5.6 : Bloodhound
XI. ESCALADE DES PRIVILEGES ET UAC
1. Labo 5.7 : escalade des privilèges
XII. MESURES DEFENSIVES
FEUILLE DE ROUTE DES COURS :
 Planification des tests d'intrusion
 Reconnaissance
 Analyse et accès initial
 Exploitation
 Post-exploitation,
 Analyse des données et rapports
 Domination de domaine Annihilation de l'azur
Avec Active Directory, Microsoft a introduit un nouveau système d'authentification appelé
Kerberos. Kerberos est un protocole d'authentification réseau basé sur des tickets, développé par le
MIT. Le protocole permet à deux parties (un client et un serveur, par exemple) de s'authentifier l'une
l'autre sur un canal réseau non sécurisé, à condition que les deux parties fassent confiance à la
troisième partie : le serveur Kerberos. Compte tenu de ces trois éléments, Kerberos tire son nom du
chien mythologique à trois têtes.

Chaque partie dans un environnement Kerberos s'authentifie auprès du serveur Kerberos et reçoit
un ticket. Plus précisément, il s'agit d'un ticket-granting-ticket : un ticket qui peut être utilisé pour
demander des tickets. Lorsqu'une partie (client) souhaite utiliser un service d'une seconde partie
(serveur), la première partie utilise son ticket d'octroi de ticket pour obtenir un ticket pour la seconde
partie auprès du serveur Kerberos, puis le présente à la seconde partie, ce qui s'authentifiant auprès
du tiers. Étant donné que les deux parties font confiance au serveur Kerberos, un ticket fourni par le
serveur Kerberos est approuvé par les deux parties, ce qui conduit à l'authentification et à
l'autorisation.

Avant l'introduction de Kerberos, les domaines Windows antérieurs à Active Directory (Windows
NT) reposaient sur l'authentification par défi/réponse NTLM. NTLM assure l'authentification entre
deux parties sans tiers de confiance.

Si Kerberos ne peut pas être utilisé (pour diverses raisons), Windows se retournera vers
l'authentification NTLM.
 I. KERBEROS :
FLUX D'AUTHENTIFICATION :

Dans Active Directory, lorsqu'un client s'authentifie avec succès auprès d'un contrôleur de
domaine, il reçoit un ticket granting-ticket.

Pour s'authentifier, le poste de travail de l'utilisateur envoie une demande au serveur

d'authentification (AS) du contrôleur de domaine. Cette demande comprend un horodatage crypté
avec le hachage du mot de passe NT de l'utilisateur, qui est aussi communément appelé hachage
NTLM. Le contrôleur de domaine (AS) possède le hachage du mot de passe de l'utilisateur dans sa
base de données et tentera de décrypter le message. En cas de succès et si l'horodatage est toujours
valide, le client recevra un ticket d'attribution de ticket (TGT) par le service d'attribution de ticket
(TGS), un rôle logique du KDC qui fait partie du contrôleur de domaine.

Kerberos fonctionne avec des tickets : des données sécurisées par cryptographie qui donnent
accès à un service pour un utilisateur particulier et pendant une période bien définie. Par exemple,
vous pouvez recevoir un ticket pour accéder à un partage sur un serveur de fichiers.

Un ticket-granting-ticket est le ticket qu'un client reçoit en premier, et c'est un ticket spécial. C'est
un ticket pour le service krbtgt et peut donc être utilisé pour demander d'autres tickets. Par défaut,
un TGT est valable pendant 10 heures. Lorsqu'il expire, Windows en demandera un nouveau
automatiquement et de manière transparente.

Une fois qu'un client a obtenu le TGT, il peut demander l'accès à d'autres services, par exemple un
partage de fichiers. Pour obtenir cet accès, le client envoie son TGT au TGS avec les détails du service
auquel il veut accéder.

Pour accéder au service (par exemple, un partage de fichiers), le client envoie le ticket au service
(le serveur de fichiers). Comme le serveur de fichiers fait également confiance à Kerberos (le TGS), il
acceptera les tickets et accordera l'accès au service une fois qu'il aura validé par des moyens
cryptographiques qu'il s'agit d'un ticket authentique émis par le TGS auquel le service fait confiance.
Le service décidera alors si l'utilisateur doit avoir accès et à quel niveau.
 Lors d'une transaction Kerberos, trois clés de sécurité à long terme sont utilisées. Il est essentiel
pour nos stratégies d'attaque de comprendre leur fonctionnement, c'est pourquoi nous allons les
décrire :

 La clé secrète à long terme du KDC, souvent appelée "clé de domaine", est dérivée du
compte de service krbtgt. Elle est utilisée dans Kerberos pour chiffrer le TGT et signer le certificat
d'attributs privilégiés (PAC).
 La clé secrète à long terme du client est basée sur le mot de passe du compte client. Elle est
utilisée dans Kerberos pour vérifier l'horodatage chiffré (AS-REQ) et chiffrer la clé de session.
 La clé secrète à long terme de la cible est basée sur le mot de passe du service cible. Elle est
utilisée dans Kerberos pour chiffrer le TGS et signer le PAC.

La compromission de l'une de ces clés représente un risque pour la sécurité. Il en existe

cependant un "GROS" : lorsque nous compromettons la clé secrète à long terme du KDC, nous
pouvons recréer des TGT et signer des PAC, ce qui nous permet d'obtenir tous les privilèges au sein
du domaine.

Le certificat d'attributs privilégiés (PAC) contient des informations sur l'autorisation et les
privilèges de l'utilisateur, par exemple l'appartenance à un groupe. Avec la clé KDC, il est possible de
falsifier le PAC pour qu'il contienne tous les privilèges souhaités dans le domaine.

TYPES DE CHIFFREMENT KERBEROS :

Quel type de cryptage Kerberos utilise-t-il ? Par défaut, le système utilise la méthode de cryptage
la plus élevée supportée par le client ! Pour les systèmes basés sur Microsoft, à partir de Windows
Vista, toutes les machines Microsoft prennent en charge les types de cryptage AES ! Il est assez
simple de configurer les systèmes Windows pour qu'ils ne prennent en charge que des types de
chiffrement spécifiques pour Kerberos. Par défaut, un Windows Server 2016 prend en charge les
types de chiffrement suivants :

 DESCBCCRC
 DES_CBC_MD5
 RC4 HMACMD5
 AES128_HMAC_SHA1
 AES256_HMAC_SHA1

Comme indiqué, à partir de Windows Vista, tous les systèmes Windows prennent en charge la
méthode de cryptage AES, plutôt sûre (qui utilise 4 096 itérations de BPKDF2). Les types de
chiffrement Kerberos pris en charge peuvent être configurés dans le paramètre suivant :

Configuration de l'ordinateur -> Stratégies -> Paramètres Windows -> Paramètres de sécurité ->
Stratégies locales -> Options de sécurité -> Sécurité du réseau : Configurer les types de chiffrement
autorisés pour Kerberos.

ZOOM SUR L'AS-REQ (AVEC PRE-AUTHENTIFICATION)  :

Jetons un coup d'œil à l'étape initiale, AS-REQ !:

1. AS-REQ : dans un premier temps, le client effectue une préauthentification en envoyant un

AS-REQ au KDC (dans ce cas, la composante AS du KDC). Cet AS-REQ comprend une version cryptée
de l'horodatage (cryptée à l'aide du hachage du mot de passe du compte client), qui est validée par le
KDC. Cet "horodatage crypté" est appelé "pré-authentification" et est activé (obligatoire) par défaut
dans les environnements Microsoft Kerberos.
2. AS-REP : si la pré authentification réussit (l'horodatage peut être décrypté), le KDC envoie
deux éléments au client :
  Le Ticket Granting Ticket (TGT), qui comprend la clé de session Client/TGS et est chiffré à
l'aide de la clé à long terme du KDC (dans le cas de rc4_hmac_md5, le hachage du mot de passe NT
de krbtgt). Cette clé à long terme du KDC est également utilisée pour signer le PAC (qui fait
également partie du TGT et comprend des informations sur l'identité de l'utilisateur et les groupes
dont il est membre).
 La clé de session Client/TGS, chiffrée à l'aide de la clé à long terme du client (dans le cas de
rc4_hmac_md5, le hachage du mot de passe de l'utilisateur).

Il est intéressant de noter que lorsque la pré authentification n'est pas activée, le KDC fournit une
réponse AS-REP sans valider l'horodatage crypté. Bien qu'il ne s'agisse pas d'un problème "critique"
qui compromettrait la sécurité du protocole Kerberos (les deux messages de réponse seraient
toujours chiffrés avec une clé qui ne nous est pas accessible), cela nous permet de lancer des
attaques par force brute contre la partie de la réponse qui est chiffrée, en utilisant la clé à long terme
du client (dans le cas de rc4_hmac_md5, le hachage du mot de passe de l'utilisateur).

ZOOM SUR LE TGT (TICKET GRANTING TICKET) ET LE PAC :

Le TGT est le premier ticket reçu par le client. À quoi ressemble-t-il ? Le TGT contient les
informations suivantes :

 Nom : Le nom de l'utilisateur auquel le ticket est associé.

 Heure de début et heure de fin : elles indiquent la période de validité du ticket. Par défaut,
dans les environnements Windows AD, cette durée est de 10 heures.
 Données d'autorisation : Les données d'autorisation détaillent les privilèges et les droits
d'accès de l'utilisateur. Dans Windows, les données d'autorisation prennent la forme d'un objet PAC
(Privilege Attribute Certificate).
 La clé de session Client/TGS qui peut être utilisée pour les communications futures entre le
client et le TGS.

Il doit être clair que le PAC est extrêmement sensible et qu'il ne doit en aucun cas être altéré. Afin
de protéger son intégrité, il est signé à l'aide de deux clés :

 Il est signé à l'aide de la clé cible à long terme. Comme il s'agit d'une TGT, la cible est le
compte krbtgt (donc dans rc4_hmac_md5, ce serait le hachage NT krbtgt).
 Il est également signé à l'aide de la clé LT du KDC. Comme indiqué à plusieurs reprises, dans
rc4_hmac_md5, il s'agirait du hachage NT de krbtgt.

Enfin, pour éviter que l'ensemble du TGT ne soit falsifié, il est chiffré à l'aide de la clé à long terme
du KDC (qui est le hachage NT de krbtgt lorsque rc4_hmac_md5 est utilisé). Le TGT ne peut pas être
lu par le client, mais ce n'est pas grave, car il n'a besoin de le renvoyer au KDC que pour une
validation ultérieure (par exemple, lorsqu'un ticket de service est demandé). Dans le TGS-REQ,
l'utilisateur souhaite s'authentifier auprès d'un certain service et envoie donc ce qui suit au KDC
(dans ce cas, la composante TGS du KDC):

 Un message d'authentification (chiffré à l'aide de la clé de session Client/TGS) ;

 Le TGT crypté et une demande de ticket (faisant référence à un certain Service Principal
Name, SPN).

ZOOM SUR LE ST (SERVICE TICKET):

Si le KDC reçoit un TGS-REQ avec un TGT valide, il renverra une réponse, TGS-REP. Le KDC validera
si le service auquel le client demande l'accès existe et créera ensuite un ticket de service (ST) qui sera
renvoyé. Il est important de noter que le KDC n'effectue aucune validation des privilèges (le service
cible peut le faire lui-même en examinant le PAC inclus dans le ticket de service, voir ci-dessous).

Le ticket de service comporte deux parties :

 Une partie client, qui est chiffrée à l'aide de la clé de session Client/TGS (afin qu'elle puisse
être déchiffrée par le client).
 Une partie serveur, qui est chiffrée à l'aide de la clé à long terme cible (dans le cas de
rc4_hmac_md5, le hachage du mot de passe du service cible). Cette partie serveur comprend
également le PAC de l'utilisateur. C'est ce ticket de service que l'utilisateur soumettra par la suite au
service auquel il tente d'accéder.

UN MOT SUR LA VALIDATION PAC :

Chaque fois que le service cible reçoit la partie serveur d'un ticket de service (qu'il peut déchiffrer
à l'aide de sa "clé à long terme cible"), il peut lire le contenu du PAC. Le service cible validera la
signature créée à l'aide de la clé à long terme cible mais ne validera pas toujours la signature créée à
l'aide de la clé à long terme KDC !

Ceci provient de la spécification des extensions Microsoft Kerberos Network Authentication

Service V5 (KILE ou MS-KILE):

"Kerberos V5 ne fournit pas de vérification de révocation de compte pour les demandes TGS, ce
qui permet d'émettre des renouvellements de TGT et des tickets de service tant que le TGT est valide
même si le compte a été révoqué. KILE fournit une politique de compte de contrôle (section 3.3.5.7.
1) qui limite l'exposition à un temps plus court. Les KDC KILE dans le domaine du compte sont tenus
de vérifier les comptes lorsque le TGT est antérieur à 20 minutes. Cela limite la période pendant
laquelle un client peut obtenir un ticket avec un compte révoqué tout en limitant les performances
coût pour les requêtes AD ".

Qu'est-ce que cela signifie concrètement pour nous ?

 Pour un TGT : Si le TGT date de plus de 20 minutes, le contenu du PAC est validé. Cela ouvre
ainsi une fenêtre de 20 minutes où le contenu n'est pas validé. Cela signifie que, si vous avez le
hachage à long terme KDC (hachage NT du compte krbtgt lors de l'utilisation de rc4_hmac_md5),
vous pouvez même créer des tickets avec de fausses informations de compte (par exemple,
l'utilisateur "Invisible" en tant que membre du "Domain Admins" groupe), qui sera valable 20
minutes. Au cours de ces 20 minutes, vous pouvez demander plusieurs tickets de service valables 10
heures.
 Pour un ticket de service : Les systèmes Windows modem (à partir de Windows Vista) ne
valident pas le PAC par défaut pour les services. Windows valide toujours le PAC pour les processus
qui ne s'exécutent pas en tant que services. La validation PAC peut être activée lorsque le serveur
d'applications ne fonctionne pas dans le contexte du système local, du service réseau ou du service
local.

Nous discuterons bientôt de certains vecteurs d'attaque possibles !

ATTAQUE KERBEROS I : COMPTES DE SERVICE KERBEROSING :

Kerberoasting est une technique d'attaque initialement décrite par l'instructeur SANS Tim Medin
en 2014. C'est une technique d'attaque intéressante contre Kerberos qui peut être utilisée après un
compromis initial pour obtenir des privilèges et des informations d'identification supplémentaires
dans un domaine Windows interne ! Les diapositives de son discours original ont été publiées ici :
https://redsiege.com/kerberoast-slides.

Comment ça marche?

Passons en revue les quatre premières étapes de l'authentification Kerberos :

1. Dans un premier temps, l'utilisateur demande un Ticket Granting Ticket (TGT) au contrôleur
de domaine (qui agit en tant que centre de distribution de clés). Lorsque rc4_hmac_md5 est utilisé, la
demande est chiffrée à l'aide du hachage NT de l'utilisateur.
2. Dans un deuxième temps, l'utilisateur reçoit un Ticket Granting Ticket et une clé de session
qui sont chiffrés à l'aide du hachage NT de krbtgt.
3. Troisièmement, l'utilisateur souhaite s'authentifier auprès d'un certain service et envoie ainsi
une demande de ticket au KDC (DC).
4. Le KDC ne fait aucune validation de privilèges (il laisse cela au service cible) et renvoie un
ticket de service, dont la partie serveur est chiffrée à l'aide du hachage NT du service cible. C'est ce
ticket de service que l'utilisateur soumettra par la suite au service auquel il tente d'accéder. Le
service pourra lire le contenu du Ticket de Service en le déchiffrant avec son hachage.

Compte tenu de ce qui précède, nous pouvons tenter de déchiffrer le hachage NT du service cible,
car le hachage est utilisé pour chiffrer la partie serveur du "ticket de service".

Alors, comment pouvons-nous lancer une telle attaque ? Plusieurs outils sont disponibles pour
mettre en œuvre cette stratégie d'attaque. La plupart d'entre eux fonctionnent en suivant les étapes
suivantes :

1. Interrogez Active Directory pour les comptes avec un nom principal de service (SPN)
2. Demander des tickets de service RC4 au DC en utilisant ces valeurs SPN
3. Extraire les tickets de services reçus et les vider dans un fichier
4. Lancez des attaques par force brute hors ligne contre les tickets pour récupérer les
informations d'identification utilisées pour chiffrer le ticket de service

Il y a quelques éléments intéressants à noter sur l'attaque que nous avons décrite :
  Pendant toute la durée de notre attaque, nous n'interagissons pas avec le service cible. Cela
signifie qu'au moment de notre attaque, le service cible peut même être indisponible... En tant que
défenseur, cela signifie que les capacités de détection sont limitées (nous y reviendrons bientôt !)
 L'attaque se concentre sur les "comptes de service", et non sur les "comptes d'ordinateur",
car ces mots de passe seraient impossibles à déchiffrer !

Alors, jetons un coup d'œil à certains des outils utilisés pour cela.

KERBEROASTING QUELS COMPTES DE SERVICE SONT UNE CIBLE ?

Comme déjà indiqué, il faut privilégier les comptes de services qui sont intéressants ! Quels
comptes de service pourraient être intéressants ? Il peut y en avoir plusieurs ! Voici quelques critères
à prendre en compte :

 Le compte doit évidemment avoir des privilèges élevés qui pourraient être intéressants.
 Le compte ne doit pas être un compte d'ordinateur, car il est généralement impossible de les
pirater.

Voici quelques exemples de comptes potentiellement intéressants (issus d’AD security.org) :

 AGPMServer: Microsoft Advanced Group Policy Management:

=> A souvent des droits de contrôle complets sur tous les objets de stratégie de groupe.
 MSSQL/MSSQLSvc:
=> Droits d'administration sur le(s) serveur(s) SQL, qui contient souvent des données
intéressantes.
 FIMService - Forefront Identity Manager Service :
=> A souvent des droits d'administrateur sur plusieurs forêts AD.
 STS - Security Token Service (VMware):
=> Service VMware SSO qui pourrait fournir un accès VMware par porte dérobée.

Ce ne sont là que quelques exemples de comptes de service intéressants. Au cours d'un test
d'intrusion typique, vous en verrez de nombreux autres qui sont habituels à l'organisation. Une
bonne énumération des comptes et des membres de groupe vous aidera à cibler les comptes
intéressants !

ATTAQUE KERBEROS I : KERBEROASTING—OUTILS :

Sur la base de ce qui a précédé, il semble qu'il reste encore beaucoup de travail à faire pour
monter une attaque Kerberoasting réussie... Comme pour la plupart des stratégies d'attaque
courantes, il existe cependant plusieurs outils qui automatisent une grande partie du travail :

 Lorsqu'il a initialement présenté la technique d'attaque Kerberoasting, Tim Medin a

développé une boîte à outils qui pourrait être utilisée en conjonction avec Mimikatz pour effectuer
toutes les étapes décrites ci-dessus ! Tim a présenté ses diapositives au Pentest Hackfest et Derbycon
en 2014 !
 La boîte à outils de post-exploitation bien connue Empire a un module intégré pour effectuer
Kerberoasting, "Invoke-Kerberoast". Les techniques utilisées par "Invoke-Kerberoast" ne reposent
pas sur l'utilisation de Mimikatz ; ainsi, ils sont plus furtifs !

Nous tirerons parti de la boîte à outils originale développée par Tim Medin dans notre prochain
laboratoire, qui nous permettra de parcourir les différentes étapes d'attaque une par une.

ATTAQUE KERBEROS 2: SILVER TICKET:

 Parlons d'une autre stratégie d'attaque disponible dans notre arsenal ! Les Silver Ticket sont des
tickets de Service falsifié. Alors que le "golden ticket" est un peu plus tristement célèbre, les Silver
Tickets représentent un risque sérieux : ils ne nous obligent pas à compromettre le compte krbtgt ET
peuvent être plus subtils !

Dans une attaque Silver Ticket, nous forgeons un ticket de service avec un PAC personnalisé (par
exemple, pour augmenter les privilèges). Mimikatz permet aux attaquants de falsifier des Silver
tickets, en utilisant l'appartenance au groupe par défaut suivante :

 Utilisateurs du domaine
 Administrateurs de domaine
 Administrateurs de schéma
 Administrateurs d'entreprise
 Propriétaires créateurs de stratégie de groupe

Ce ticket de service est falsifié à l'aide de la clé LT cible (par exemple, le hachage NT du service).
Comme nous n'avons pas la clé KDC LT, nous ne pouvons pas créer une signature PAC valide et
complète. Cependant, comme discuté précédemment, la validation PAC n'est pas toujours activée, ce
qui signifie qu'il y a toujours un risque d'être abusé ! Alors qu'un Golden Ticket est un faux TGT qui
donne accès à n'importe quel service Kerberos, le Silver Ticket est un faux ticket de service ou TGS.
Cela signifie pour un ticket argent :

 La portée est limitée à tout service ciblé sur un serveur spécifique ;

 Le DC n'est pas contacté car il n'y a pas de TGT associé.

ATTAQUE KERBEROS 3: PASS-THE-TICKET :

Étant donné que les tickets peuvent être utilisés pour obtenir l'accès à un service ou demander
d'autres tickets, il n'est pas surprenant que les attaquants aient trouvé des moyens de voler et de
réutiliser les tickets. Une telle attaque s'appelle une attaque passe-le-ticket. Nous pouvons obtenir
des tickets existants (de préférence des tickets d'octroi de tickets à partir de comptes administratifs)
en les extrayant de la mémoire des machines compromises, puis les utiliser pour accéder à d'autres
machines. Il existe des outils d'attaque open source disponibles pour extraire les tickets et exécuter
des attaques pass-the-ticket, comme l'outil WCE dont nous avons déjà parlé.

Abuser d'un ticket implique que nous abusons de l'authentification et de l'autorisation Kerberos :
L'avantage pour un attaquant d'utiliser une attaque avec un ticket est que nous n'avons pas besoin
du mot de passe ou du hachage du compte compromis. Juste un ticket.
 Avec Mimikatz, nous pouvons afficher le TGT en utilisant la commande kerberos::tgt. Comme vous
pouvez le voir dans la sortie, le nom du service est krbtgt pour le domaine sec560.private (il s'agit
donc d'un TGT) et le nom du client est l'administrateur du domaine sec560.private. C'est donc un
ticket très précieux à voler : c'est le TGT de l'administrateur du domaine. Ce ticket donnera accès à
toutes les ressources du domaine. À partir de l'heure de début et de fin, nous pouvons voir que ce
billet est valable 10 heures. Pour obtenir ce ticket, nous devons disposer d'un accès administrateur
(local) à une machine sur laquelle l'administrateur du domaine est connecté. Ce ticket peut être
exporté vers un fichier, par exemple. Pour cela, nous lançons la commande "kerberos::list /export":
Cela exportera tous les tickets vers un fichier (un pour chaque ticket) dans le répertoire courant.

Nous ne pouvons pas sélectionner le nom des billets ; c'est Mimikatz qui décide du nom en
fonction de métadonnées comme le nom d'utilisateur. Les tickets générés par Mimikatz utilisent
l’extension. kirbi, mais n'importe quelle extension peut être utilisée pour une attaque pass-the ticket.

Sur n'importe lequel des systèmes du domaine, nous pouvons transmettre ce TGT pour recevoir
l'accès aux ressources restreintes. Dans la capture d'écran ci-dessus, nous voyons qu'il n'y a pas de
tickets Kerberos mis en cache. Après avoir passé le ticket avec la commande "Kerberos:ptt", on voit
que le TGT est mis en cache. Nous pouvons maintenant utiliser PsExec pour nous connecter, par
exemple, au contrôleur de domaine DC01 et ouvrir une invite de commande. Avec la commande
"whoami“, nous pouvons vérifier que nous sommes élevés au compte administrateur.

ATTAQUE KERBEROS 4: OVERPASS-THE-HASH:

Lorsque vous lisez ceci, il est bon de se souvenir de l'attaque Pass-the-Hash initiale. N'oubliez pas
que Pass-the-Hash repose sur l'authentification NTLM, donc une défense possible pourrait être de
simplement désactiver NTLM. Bien qu'il ne s'agisse pas d'un contrôle simple à mettre en œuvre, il ne
nous protège pas non plus complètement contre Pass-The-Hash :

Nous pourrions utiliser le hachage NT volé pour "lancer" le processus Kerberos et demander des
tickets pour un certain service : le schéma de cette diapositive donne un aperçu de la façon dont
Pass-the-Hash (PtH) peut toujours être un problème même si NTLM est entièrement désactivé dans
un environnement ! Dans ce cas, nous nous appuyons sur rc4_hmac_md5 comme type de
chiffrement Kerberos et utilisons immédiatement le hachage NT (qui est la clé LT du client) au lieu
d'entrer le mot de passe ! Notez que cette attaque fonctionnerait également avec AES (au lieu
d'utiliser le hachage NT, nous utiliserions la clé AES) !

Cette technique est communément appelée "Overpass-the-Hash".

ATTAQUES KERBEROS : COMPRENDRE LES DEFENSES (I):

 Alors, comment une entreprise peut-elle se défendre contre les attaques Kerberos  ? Il y a
quelques choses qu'il pourrait envisager de faire :

 Tout d'abord, comme nous avons besoin des clés à long terme cibles (par exemple, le
hachage NT du compte de service), une entreprise peut s'assurer que les comptes de service ont des
mots de passe longs (plus de 25 caractères) qui sont complexes et ne peut pas facilement être
décrypté. Depuis Windows Server 2012, Microsoft prend en charge les "comptes de service gérés de
groupe", qui appliquent des mots de passe aléatoires et complexes et peuvent être gérés de manière
centralisée à partir de l'environnement Active Directory !
 Si possible, dans l'environnement (tous les systèmes au moins Windows Vista), le type de
cryptage RC4 peut être désactivé au niveau de la stratégie de groupe. Les anciens systèmes sont donc
toujours très intéressants !
 Une entreprise peut obliger les systèmes Windows à effectuer la validation PAC (ce n'est pas
le cas par défaut dans Windows). Cela aura cependant un impact sur les performances, car une étape
supplémentaire est ajoutée dans toutes les authentifications qui se produisent. Pour vérifier si la
validation PAC est appliquée, nous devons vérifier la clé de registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\ValidateK
dcPacSignature (valeur=l)
 Lorsque CredentialGuard est déployé dans tout l'environnement, les hachages ou les clés
Kerberos ne peuvent pas être volés de la mémoire ! CredentialGuard est une défense très efficace,
mais elle n'est malheureusement disponible que pour les versions Enterprise de Windows à partir de
Windows 10.
 Les utilisateurs sensibles peuvent être configurés comme "utilisateurs protégés", ainsi leurs
clés Kerberos ne sont plus stockées dans la mémoire LSASS ! Les utilisateurs protégés sont configurés
de manière centralisée sur le contrôleur de domaine (à partir de Windows Server 2012 R2) et
appliquent un certain nombre de contrôles de sécurité :

• La délégation des informations d'identification est désactivée

• Windows Digest ne mettra pas en cache les informations d'identification en clair de l'utilisateur
même lorsque Windows Digest est activé

• NTLM ne mettra pas en cache les informations d'identification en clair de l'utilisateur ou la

fonction NT à sens unique (NTOWF)

• Kerberos ne créera plus de clés DES ou RC4. De plus, il ne mettra pas en cache les informations
d'identification en clair ou les clés à long terme de l'utilisateur après l'acquisition du TGT initial.

• Un vérificateur en cache n'est pas créé lors de la connexion ou du déverrouillage. La connexion

hors connexion n'est donc plus prise en charge.

Source:

https://docs.microsoft.com/en-us/windows-server/securitv/credentials-protection-and-
management/protected-users-securitv-group

Shortlink: https://redsiege.com/560/cred-protection.
Faisons un lab sur Kerberoasting ! Tous les détails sur le lab sont décrits dans le manuel.

Veuillez travailler sur l'exercice de LAB : Atelier 5.1 : Kerberos dans le manuel SEC560.

 II. ATTAQUES DE DOMINATION DE DOMAINE (GOLDEN TICKETS, DCSYNC, DCSHADOW)  :

DOMINANCE DE DOMAINE (PERSISTANCE AD) :

Tout au long du cours, nous avons discuté de diverses techniques que nous pouvons utiliser pour
nous déplacer latéralement dans un environnement Windows et obtenir un accès administrateur.
Bien sûr, nous aimerions également conserver l'accès que nous obtenons !

Alors, quelle est la prochaine étape de notre boîte à outils ? En règle générale, nous pouvons
essayer l'une des astuces suivantes pour consolider/préserver l'accès administrateur à l'AD :

 Vidage du fichier NTDS.dit à partir duquel toutes les informations d'identification peuvent
être extraites
 Créer simplement un compte d'administrateur de domaine (de préférence avec des
informations d'identification solides)
 Création d'un golden ticket Kerberos qui permettra un accès à long terme à l'environnement
 Création d'une clé squelette, qui nous permettra de nous authentifier comme n'importe quel
utilisateur dans l'environnement
 Utilisation de l'attaque DCSync

Discutons de ces techniques plus en détail.

OBTENTION DE L'ACCES AU FICHIER DE SAUVEGARDE NTDS.DIT  :

Les attaquants avancés attaqueront souvent l'infrastructure Active Directory de leurs cibles car
elles contiennent les "clés du royaume". Si nous obtenons des droits d'administrateur de domaine,
nous aurons un accès illimité aux ressources de ce domaine. Une fois à l'intérieur, nous voulons
également atteindre la persistance : obtenir un accès inconditionnel aux fonctions d'administration
d'Active Directory, même lorsque les informations d'identification sont modifiées.

De nombreuses attaques sont possibles avec Active Directory. Ici, nous voulons nous concentrer
sur les attaques pour obtenir des informations d'identification et/ou un accès. Comme nous l'avons
vu, la base de données Active Directory est stockée dans un fichier appelé ntds.dit. Et les hachages
sont protégés par une clé de cryptage stockée dans le registre système.

Lorsque nous obtenons une copie de ces fichiers, nous pouvons extraire des hachages et
récupérer des mots de passe, entre autres.

Ces fichiers sont présents sur un contrôleur de domaine, mais lorsque le contrôleur de domaine
est opérationnel, ces fichiers sont en cours d'utilisation et ne peuvent pas être copiés. Il existe
cependant une solution de contournement appelée clichés instantanés. Les clichés instantanés (alias
VSS, Volume Snapshot Service) sont une technologie Microsoft permettant de créer des sauvegardes
locales de fichiers. Cette technologie peut être utilisée pour récupérer des copies de sauvegarde des
fichiers ntds.dit et SYSTEM.

Nous n'avons pas toujours besoin d'accéder à un contrôleur de domaine pour obtenir ces fichiers.
Lorsque des sauvegardes centralisées sont effectuées sur les contrôleurs de domaine, ces fichiers se
retrouveront également sur les serveurs de sauvegarde.
 CREATION D'UN COMPTE D'ADMINISTRATEUR DE DOMAINE  :

Une attaque simple pour obtenir la persistance dans Active Directory consiste à créer un nouvel
utilisateur administrateur de domaine avec un mot de passe qui n'expire jamais.

Une fois que nous avons des droits d'administration sur le domaine, nous pouvons créer un
nouvel administrateur de domaine. Cela n'implique pas nécessairement que nous devions obtenir les
droits d'administrateur de domaine, mais simplement obtenir le droit de créer de nouveaux
utilisateurs et de les affecter à des groupes. Un administrateur de domaine dispose de ces droits,
mais dans Active Directory, ces droits peuvent également être délégués à des utilisateurs
administrateurs qui ne disposent pas de droits d'administrateur de domaine. Étant donné que
l'administrateur de domaine est un compte très puissant, de nombreuses organisations ne fourniront
ce compte qu'à un groupe restreint de membres du personnel de sécurité.

Les autres utilisateurs qui doivent effectuer des tâches administratives courantes, telles que la
gestion des utilisateurs, ne disposent que des droits nécessaires pour le faire. Mais une fois qu'un
utilisateur a le droit de créer un nouvel utilisateur et de l'affecter à des groupes arbitraires, il peut
créer un administrateur de domaine.

Ce compte créé nous donnera un accès administrateur de domaine au domaine tant que le
compte n'est pas découvert et supprimé. Les entreprises surveillent souvent leur infrastructure
Active Directory pour la création de nouveaux comptes avec des droits d'administration.

PRESENTATION DU GOLDEN TICKET :

Une autre méthode pour obtenir un ticket pour les attaques passe-le-ticket consiste à utiliser
Mimikatz pour générer un Golden Ticket. Un Golden Ticket est un Ticket donnant droit à un accès
maximal pendant une durée maximale. C'est la mère de tous les Tickets; il n'y a pas de Ticket qui
offre plus d'accès.

Nous avons discuté des attaques Kerberos plus tôt ! L'un des vecteurs d'attaque possibles que
nous avons examinés était la création d'un "Golden Ticket" ! Un Golden Ticket n'est "rien de plus"
qu'un TGT "spécial" créé par un attaquant.

Afin de créer un TGT valide (avec un PAC valide), nous aurions besoin :

 La clé LT cible
 La clé KDC LT
 Dans le cas d'un TGT, les clés cible et KDC LT sont identiques (krbtgt). Il faudrait donc obtenir le
hash NT du compte krbtgt (RC4) ou la clé AES (AES) !

Lorsqu'Active Directory est compromis, le hachage NT ou la clé AES du compte krbtgt peut être
extrait de la mémoire. Toutes les autres informations nécessaires pour créer un Golden Ticket ne
sont pas des informations secrètes mais peuvent être obtenues facilement. Par exemple, le nom du
domaine sera nécessaire. Bien que le nom de domaine d'une organisation ne soit pas rendu public, il
n'est pas si difficile pour nous d'obtenir le nom d'un domaine. Notez que le hachage NT ou la clé AES
du compte krbtgt peuvent également être extraits de la base de données Active Directory et de ses
sauvegardes.

Le nom Golden Ticket fait référence au film de Willy Wonka. Dans ce film, les enfants peuvent
gagner un Golden Ticket qui leur donne un accès complet à une fabuleuse chocolaterie.

KERBEROS FLOW AVEC GOLDEN TICKET:

Jetons un coup d'œil au flux Kerberos lorsqu'un Golden Ticket est en jeu. Lorsque nous utiliserions
un Golden Ticket, la première interaction est un TGS-REQ (demande de Service Ticket) utilisant le
faux TGT (le Golden Ticket). Il n'y a pas de soumission d'informations d'identification préalable ni
d'AS-REQ/AS-REP !

On pourrait supposer que l'absence d'AS-REQ/AS-REP peut être un déclencheur de détection.

Heureusement, Kerberos est un protocole sans état, c'est pourquoi l'AD ne conserve pas la trace des
AS-REQ/AS-REP précédents avant qu'une TGS-REQ ne soit exécutée. Si l'on devait implémenter une
règle comme celle-ci, une avalanche de faux positifs apparaîtrait (par exemple, des TGT générés par
DC01 et ensuite utilisés pour demander un ticket de service sur DC02).

PROPRIETES GOLDEN TICKET:

Alors, quelles sont les propriétés d'un Golden Ticket ? Qu'est-ce qui le rend si spécial? Un Golden
Ticket n'est, comme indiqué précédemment, rien de plus qu'un faux TGT. Cependant, il possède des
fonctionnalités très intéressantes :

 Il est créé *SANS* aucune interaction avec le DC (c'est "fait maison"). Ceci est possible car
Kerberos est un protocole "sans état"
 Comme indiqué dans la diapositive précédente, cependant, cela nous obligerait à obtenir la
clé KDC à long terme (ce qui ne devrait pas être facile à obtenir !)
 Il s'agit généralement d'un TGT pour un compte administratif (par exemple, RID 500 dans le
domaine ou un administrateur de domaine)
 Il est généralement valide pendant une longue période (10 ans par défaut)

Les billets d'or ont été initialement décrits dans la présentation BlackHat USA 2014 de Benjamin
Delpy "Abusing Microsoft Kerberos— Sorry you guys don't get it ". Cette présentation est souvent
appelée "le discours Golden Ticket". Vous pouvez retrouver les slides ici :

https://www.blackhat.com/docs/us-14/materials/us-14-Duckwall-Abusing-Microsoft-Kerberos-
Sorrv-You-Guvs-Don't-Get-It.ndf

Shortlink: redsiege.com/560/golden
 CRÉATION D'UN GOLDEN TICKET AVEC MIMIKATZ : ÉTAPE I:

Dans cet exemple, nous expliquons ce qui est nécessaire pour créer un Golden Ticket avec
Mimikatz. La commande Kerberos::golden de Mimikatz peut être utilisée pour générer un Golden
Ticket. Il s'agit d'une commande "informatique" pure : elle ne nécessite pas de droits
d'administrateur, et elle ne nécessite pas d'accès au domaine. La génération d'un Golden Ticket peut
être effectuée sur n'importe quel ordinateur Windows dans le monde avec des droits d'accès
normaux, à condition que les valeurs d'entrée nécessaires soient connues.

 La première entrée, la valeur la plus difficile à obtenir, est le hash NT du compte Kerberos
(krbtgt). Comme indiqué précédemment, ce hachage peut être obtenu à partir de contrôleurs de
domaine compromis ou de bases de données Active Directory.
 La deuxième valeur est le nom du compte administratif. Dans notre exemple, c'est root.
 La troisième valeur est le nom de domaine : sec560.private dans notre exemple.
 Et la quatrième et dernière valeur est le SID du compte admin.

C'est la seule entrée nécessaire pour créer un Golden Ticket. Notez que Mimikatz a beaucoup plus
d'options pour cette commande kerberos::golden. La seule option supplémentaire que nous avons
utilisée ici est l'option /ticket: pour écrire le Golden Ticket sur le disque.

Dès la durée de vie, vous pouvez constater que ce Golden Ticket est valable 10 ans ! Cela signifie
que tant que vous ne changez pas le mot de passe du compte krbtgt, le ticket vous donnera accès à
votre infrastructure Active Directory complète pour les 10 prochaines années !

À partir de la sortie, vous pouvez clairement voir que le compte administratif (ID utilisateur 500)
est un administrateur de domaine (ID de groupe 512) et un administrateur d'entreprise (ID de groupe
519).
 CREER UN GOLDEN TICKET AVEC MIMIKATZ : ÉTAPE 2

Pour utiliser le ticket généré précédemment, nous émettons la commande Mimikatz Kerberos::ptt
golden.ticket.bin. Cela injecte le ticket dans la mémoire de Windows, prêt à être utilisé lorsque nous
tentons de nous connecter à un service.

La commande Kerberos::list peut être utilisée pour lister tous les tickets que nous avons. Nous
pouvons voir que le nom du serveur est krbtgt/sec560.private : cela nous indique qu'il s'agit d'un
ticket d'octroi de tickets pour le domaine sec560.private. L'utilisateur est la racine du domaine
sec560.private. Si nous regardons les dates de début et de fin, nous voyons 2017-2027. C'est une
période extrêmement longue pour un ticket : 10 ans (rappelez-vous, la durée de vie par défaut d'un
TGT est de 10 heures). C'est parce qu'ici nous avons utilisé un Golden Ticket. Maintenant, lorsque
nous essayons de nous connecter à un partage, par exemple, ce ticket injecté sera utilisé pour
obtenir un ticket pour le partage auquel nous voulons accéder (cela nécessite Kerberos, nous devons
donc utiliser le nom du serveur de fichiers pour y accéder, et non son IP adresse, car cela entraînerait
une authentification NTLM, qui ne fonctionne pas avec les tickets).

Une fois qu'un golden ticket est généré, la seule façon pour une entreprise d'atténuer l'attaque
est de changer deux fois le mot de passe du compte krbtgt. Les deux derniers mots de passe sont
acceptés comme cryptage, donc le mot de passe doit être changé (mais pas trop vite ou vous
casserez le domaine !)

PRESENTATION DE SKELETON KEY : CLE SQUELETTE

Une autre attaque de persistance AD que nous souhaitons illustrer est une attaque visant à
obtenir la persistance à l'intérieur d'un domaine. Bien sûr, le Golden Ticket est le mécanisme de
persistance ultime, mais cette attaque squelette mérite également notre attention.

Une clé passe-partout est une clé spéciale qui ouvre toutes les serrures à l'intérieur d'un
bâtiment. Chaque serrure de porte à l'intérieur du bâtiment nécessite sa propre clé pour être
ouverte, mais toutes les serrures peuvent également être ouvertes avec une seule clé spéciale : la clé
passe-partout. Mimikatz fournit une attaque par clé squelette pour Active Directory.

Lorsque l'attaque squelette Mimikatz est exécutée sur un contrôleur de domaine, un morceau de
code est corrigé en mémoire afin que tous les comptes puissent être connectés avec un mot de passe
spécial (mimikatz). Cela ne supprime pas les mots de passe existants. Il est désormais possible de se
connecter à un compte en utilisant deux mots de passe différents : On peut se connecter avec le mot
de passe de compte normal, ou on peut se connecter avec le mot de passe de la clé squelette.
 Techniquement, la clé squelette le fait en manipulant la façon dont l'horodatage chiffré (AS-REQ)
est validé. Pour rappel, dans RC4, l'horodatage est chiffré à l'aide du hash NT de l'utilisateur par le
client, après quoi le contrôleur de domaine tente de déchiffrer l'horodatage. Lorsque la clé squelette
est installée, le contrôleur de domaine tente de déchiffrer l'horodatage à l'aide du hachage NT de
l'utilisateur ET du hachage NT de la clé squelette (mimikatz par défaut :
60BA4FCADC466C7A033C178194C03DF6, mot de passe "mimikatz").

Cela doit être fait sur un contrôleur de domaine ; cela ne fonctionne pas sur les contrôleurs non-
domaine. Mais cela ne signifie pas que nous ne pouvons pas nous connecter qu'avec le mot de passe
squelette sur un contrôleur de domaine : le mot de passe fonctionne sur tous les membres du
domaine qui utilisent ce contrôleur de domaine compromis pour l'authentification.

S'il y a plus d'un contrôleur de domaine, l'attaque doit être exécutée sur tous les contrôleurs de
domaine pour être sûr que le mot de passe squelette fonctionnera dans tous les cas.

SKELETON KEY EN ACTION :

Dans l'exemple ci-dessus, nous pouvons voir l'attaque par clé squelette. Comme cela corrigera le
code du processus LSA en mémoire, des droits d'administrateur sont requis et le privilège de
débogage doit être activé. Il suffit de lancer la commande "misc::skeleton" et le tour est joué, la clé
squelette est installée sur le contrôleur de domaine.

Lorsqu'il existe plusieurs contrôleurs de domaine dans un domaine, les membres du domaine se
connectent à un contrôleur de domaine pour s'authentifier via une sorte de schéma d'équilibrage de
charge.

Cela signifie que pour être fiable à 100 %, l'attaque par clé squelette doit être effectuée sur tous
les contrôleurs de domaine. Sinon, un membre de domaine peut s'authentifier auprès d'un
contrôleur de domaine auquel le correctif de clé squelette n'est pas appliqué en mémoire.

Comme il s'agit d'un correctif en mémoire, le simple redémarrage du contrôleur de domaine

supprime la clé squelette. Mais, bien sûr, nous pouvons installer une entrée d'exécution automatique
pour que Mimikatz s'exécute automatiquement au démarrage du contrôleur de domaine.

REPLICATION DU DOMAINE : DCSYNC

 Benjamin Delpy, l'auteur de Mimikatz, a été le pionnier de nombreuses attaques contre la sécurité
de Windows, ce qui a conduit à des améliorations de la sécurité dans Windows. En collaboration avec
Vincent Le Toux, Benjamin a élaboré une autre attaque contre Active Directory : l'usurpation
d'identité d'un contrôleur de domaine.

Pour des raisons de disponibilité, les administrateurs déploient plusieurs contrôleurs de domaine
dans une infrastructure Active Directory. Chaque contrôleur de domaine possède une copie de la
base de données Active Directory, et les mises à jour de cette base de données sur un contrôleur de
domaine (par exemple la création d'un nouvel utilisateur) doivent être propagées aux autres
contrôleurs de domaine en temps voulu. C'est ce qu'on appelle la réplication Active Directory : un
ensemble de méthodes et de protocoles pour synchroniser la base de données des contrôleurs de
domaine Active Directory.

Vincent et Benjamin ont élaboré ces méthodes et protocoles à utiliser par Mimikatz : Mimikatz a
une commande (dcsync) qui fera en sorte que tout ordinateur exécutant Mimikatz se fera passer
pour un contrôleur de domaine auprès d'un contrôleur de domaine cible afin d'obtenir les
informations d'identification stockées dans ce contrôleur de domaine.

Bien sûr, les utilisateurs normaux ne peuvent pas accéder à ces informations. Il faut des droits
d'administrateur de domaine pour pouvoir participer à la réplication des données. Un Golden Ticket
peut fournir ces droits d'administration.

dcsync peut vider les hachages de tous les utilisateurs ou d'un utilisateur sélectionné.

REPLICATION DU DOMAINE : DCSYNC EXEMPLE :

Cet exemple montre la commande dcsync. En exécutant la commande "kerberos::dcsync

/user:administrator", nous demandons les informations d'identification de l'administrateur de
l'utilisateur à un contrôleur de domaine. La commande "kerberos :: dcsync" répertorie les
informations d'identification de tous les utilisateurs.

Lorsque cette commande est émise sans options supplémentaires, Mimikatz sélectionne
automatiquement le domaine et le contrôleur de domaine, et extrait les informations d'identification
de ce contrôleur de domaine via la réplication ; le protocole DRSR (Directory Replication Service
Remote).

Il s'agit d'une attaque très puissante : une fois que nous avons obtenu les informations
d'identification de l'administrateur du domaine, nous pouvons utiliser dcsync pour nous connecter à
un contrôleur de domaine et extraire les informations d'identification du compte krbtgt. Ces données
peuvent ensuite être utilisées pour créer un Golden Ticket, puis la partie est terminée : le seul
recours dont dispose une entreprise est de changer le mot de passe du compte krbtgt. Ce mot de
passe n'expire jamais et n'est jamais modifié, sauf si cela est fait manuellement.

Il est possible de détecter une attaque dcsync. Le trafic réseau DRSR ne doit se produire qu'entre
les contrôleurs de domaine. Si une entreprise détecte un trafic réseau DRSR entre un contrôleur de
domaine et un poste de travail, elle sait qu'une attaque dcsync a eu lieu.

DEVENIR UN CONTROLEUR DE DOMAINE : DCSHADOW

"Ils m'ont dit que je pouvais être tout ce que je voulais, alors je suis devenu contrôleur de
domaine". Avec ce slogan, Benjamin Delpy et Vincent Le Toux ont présenté début 2018 leur nouvelle
stratégie d'attaque AD appelée "DCShadow". Bien qu'il semble très similaire à DCSync, il est plus
intrusif et définitivement différent !

DCShadow a pris de l'importance après BlackHat USA 2018, où Vincent Le Toux et Benjamin Delpy
ont présenté leurs recherches. Les diapositives peuvent être trouvées ici :
https://www.dcshadow.com/us-18-Delpv LeToux-So-I Became-A-Domain-Controller.pdf. Il dispose
d'un site Web public contenant également des informations sur https://www.dcshadow.com.

Comment fonctionne l'attaque "DCShadow" ? Il y a quatre étapes principales dans une attaque
DCShadow :

 Comme condition préalable, nous devons obtenir les droits d'administrateur de domaine ;
 À l'aide de Mimikatz, nous enregistrons temporairement le poste de travail que nous
utilisons en tant que DC ;
 Nous créons un changement dans le schéma qui nous profite (par exemple, changer le
hachage du mot de passe d'un compte sensible) ;
 En utilisant Mimikatz, nous pouvons maintenant déclencher une réplication, ce qui force un
contrôleur de domaine légitime à valider le changement !

Les modifications effectuées par DCShadow sont effectuées à l'aide de la réplication, ce qui les
rend presque "invisibles" pour les journaux d'événements Windows normaux. Windows s'appuie
normalement sur les journaux d'événements générés sur le contrôleur de domaine source qui crée
les modifications. Comme dans ce cas, ce DC n'existe pas ; aucun journal des événements Windows
n'est généré !
 DEVENIR UN CONTROLEUR DE DOMAINE : DCSHADOW EN ACTION (I)

La capture d'écran ci-dessus est l'étape 1 d'une attaque DCShadow ; nous élaborons un
changement que nous pousserons par la suite. Il est important de noter que DCShadow ne s'appuie
que sur des fonctionnalités qui existaient par conception (c'est-à-dire le service de réplication
d'annuaire) ! Il n'abuse d'aucun exploit ou vulnérabilité (similaire à DCSync).

Dans la capture d'écran à gauche, nous avons préparé un petit changement et modifions le
compte administrateur par défaut pour avoir une description de "DCShadow was here!" Nous devons
maintenant laisser cette fenêtre ouverte et lancer une deuxième fenêtre Mimikatz qui peut être
utilisée pour initier le push (nous verrons cela sur la diapositive suivante). Cette première étape doit
être exécutée dans le contexte de "NT AUTHORITY\SYSTEM", nous devons donc d'abord effectuer un
"token ::elevate" !

DEVENIR UN CONTROLEUR DE DOMAINE : DCSHADOW EN ACTION (2)

Une fois que nous avons préparé le changement (étape précédente), nous devons laisser l'invite
de commande s'exécuter sur l'invite "RPC Server is wait". Nous allons maintenant lancer une
deuxième fenêtre Mimikatz (en utilisant le contexte Administrateur de domaine cette fois).
 Dans la deuxième fenêtre Mimikatz, nous déclenchons maintenant une réplication en exécutant la
commande "lsadump::dcshadow /push" ! La modification que nous avons élaborée et préparée à
l'étape précédente sera désormais conservée. Il est intéressant de noter comment le poste de travail
"promu" est ensuite à nouveau désenregistré (il ne devient pas un contrôleur de domaine
permanent).

ATTAQUES PAR DOMINANCE DE DOMAINE : COMPRENDRE LES DEFENSES

Les attaques par dominance de domaine nécessitent que l'attaquant ait déjà des privilèges très
élevés dans le domaine. La prévention n'est donc pas simple, mais il existe quelques contrôles de
détection :

 Comme indiqué précédemment, les Golden Tickets ne peuvent pas être détectés lors de leur
création (car cela se produit hors ligne sans interaction avec l'AD).
 Une recherche périodique sur les systèmes des utilisateurs finaux pourrait être effectuée
pour détecter les TGT en mémoire avec une durée de validité déraisonnablement longue (par
exemple, en utilisant klist). Cette technique n'est cependant pas adaptée à la détection en temps réel
et nécessiterait de vastes capacités de collecte de données !
 DCSync et DCShadow sont facilement repérables sur la couche réseau : la réplication entre
deux systèmes qui ne sont pas tous les deux des contrôleurs de domaine devrait le rendre apparent !
 DCShadow peut être détecté en consultant le journal des événements Windows pour l'ajout
temporaire d'un contrôleur de domaine (création et suppression immédiate). Recherchez 5137 (un
objet de service d'annuaire a été créé) et 5141 (un objet de service d'annuaire a été supprimé) !
Veuillez travailler sur les exercices de laboratoire

Atelier 5.2 : Dominance du domaine

Atelier 5.3 : Atelier 5.2 Chemin alternatif

Laboratoire supplémentaire ! En cas de temps libre, n'hésitez pas à faire de l'exercice

Laboratoire 5.4 : Persistance SilverTicket
III. INTRODUCTION A AZURE

QU'EST-CE QU'AZURE ACTIVE DIRECTORY ?

Azure Active Directory ou Azure AD est un service cloud fourni par Microsoft pour prendre en
charge la gestion des identités et des accès intégrée dans plusieurs services cloud tels que les
applications Azure et Office 365. Azure AD est comparable à votre Active Directory sur site, qui est
utilisé comme serveur d'identité pour vos composants sur site.

Azure AD est basé sur IaaS et fournit un service d'identité hautement évolutif et toujours
disponible pour vos applications cloud. Plusieurs fonctionnalités existent dans Azure AD en
fournissant l'identité en tant que service basé sur plusieurs protocoles standard ouverts. Ceux-ci
seront décrits dans les sections suivantes.

Azure AD est largement utilisé par de nombreuses organisations. Microsoft a publié les chiffres
suivants en 2018 (issus de la conférence Ignite) :

 17,5 millions d'organisations utilisent Azure AD comme service d'identité pour leur
environnement cloud
 90 % des entreprises du Fortune 500 ont implémenté Azure AD
 Au total, Microsoft compte 1,1 milliard d'identités au sein de son service Azure AD
 450 milliards de demandes d'authentification sont traitées chaque mois

Nous pouvons conclure qu'AZURE AD devient l'une des normes de facto pour l'identité en tant
que service dans les environnements cloud. Cela est également dû à l'intégration facile dans d'autres
plates-formes telles qu'Office 365.

Avant de configurer Azure AD, vous devez disposer d'un abonnement Azure, qui peut être créé
gratuitement via https://azure.microsoft.com/free/. Vous pouvez créer un locataire de base pour
votre organisation via le portail Azure à l'aide d'un compte d'administrateur général. Après vous être
connecté au portail Azure, vous pouvez créer un nouveau locataire pour votre organisation. Votre
nouveau locataire représente votre organisation et vous aide à gérer une instance spécifique des
services cloud Microsoft pour vos utilisateurs internes et externes.

1. Créer un nouveau locataire :

 Sélectionnez Créer une ressource, sélectionnez Identité, puis sélectionnez Azure Active
Directory

2. Créez un nouveau répertoire :

  Saisissez le nom de votre organisation dans la zone Nom de l'organisation.
 Tapez <nom de domaine initial> dans la zone Nom de domaine initial.
 Sélectionnez la région/le pays requis dans la case Pays ou région.
 Sélectionnez Créer.

Votre nouveau locataire est créé avec le domaine <nom de domaine initial>. onmicrosoft.com.
Vous avez maintenant créé avec succès votre premier locataire Azure AD.

Référence: https://docs.microsoft.com/en-us/azure/active directory/fundamentals/active-

directory-access-create new-tenant.

Plusieurs modèles de licence existent dans Azure AD, par défaut le niveau gratuit est activé, ce qui
vous offre des fonctionnalités de base de gestion des identités et des accès. Si vous souhaitez utiliser
des fonctionnalités plus avancées, une mise à niveau vers une licence premium est requise. Les
options de licence suivantes existent dans Azure AD :

1- Azure Active Directory Gratuit :

Fournit la gestion des utilisateurs et des groupes, la synchronisation d'annuaires sur site, des
rapports de base, le changement de mot de passe en libre-service pour les utilisateurs du cloud et
l'authentification unique sur Azure, Office 365 et de nombreuses applications SaaS populaires.

2- Azure Active Directory Premium PI:

En plus des fonctionnalités gratuites, PI permet également à vos utilisateurs hybrides d'accéder à
la fois aux ressources sur site et dans le cloud. Il prend également en charge l'administration
avancée, telle que les groupes dynamiques, la gestion des groupes en libre-service, Microsoft Identity
Manager (une suite de gestion des identités et des accès sur site) et les capacités de réécriture dans
le cloud, qui permettent la réinitialisation de mot de passe en libre-service pour vos utilisateurs sur
site.

3- Azure Active Directory Premium P2

En plus des fonctionnalités Free et PI, P2 offre également Azure Active Directory Identity
Protection pour vous aider à fournir un accès conditionnel basé sur les risques à vos applications et
données critiques de l'entreprise et Privileged Identity Management pour aider à découvrir,
restreindre et surveiller les administrateurs et leur accès aux ressources. et de fournir un accès juste
à temps en cas de besoin.

Licences de fonctionnalités "Pay as you go"

Vous pouvez également obtenir des licences de fonctionnalités supplémentaires, telles qu’Azure
Active Directory Business-to-Customer (B2C). B2C peut vous aider à fournir des solutions de gestion
des identités et des accès pour vos applications destinées aux clients.
 Référence : https://azure.microsoft.com/en-us/pricing/details/active-directory/

AZURE AD CONTRE ACTIVE DIRECTORY :

Il est important de noter que, bien qu'ils partagent un nom, Azure Active Directory et un Active
Directory traditionnel sur site ont très peu en commun. Azure Active Directory n'est pas «  juste un
contrôleur de domaine dans le cloud » : il utilise différents protocoles, structures, approbations et
structures de domaine/répertoire. Examinons donc les différences entre un Active Directory standard
et Azure AD :

Demander des informations sur l'annuaire  :

 L'annuaire actif de Windows est essentiellement une base de données / un répertoire qui
vous aide à organiser les utilisateurs, les groupes, les politiques de votre entreprise, etc. Pour
demander des informations à partir de votre annuaire actif, le protocole LDAP (Lightweight Directory
Access Protocol) est utilisé.
 Microsoft a conçu Azure AD pour prendre en charge les services basés sur Internet (Web) :
les interfaces API REST (Representational State Transfer) sont utilisées pour récupérer des
informations spécifiques à partir d'Azure AD. Une autre option pour demander des informations
spécifiques consiste à exécuter des requêtes d'annuaire via PowerShell.

Protocoles d'authentification :

 L'authentification déléguée est prise en charge par votre contrôleur de domaine sur site via
des protocoles d'authentification tels que NTLM et Kerberos. Les protocoles ont été initialement
conçus pour fonctionner sur un réseau local et ne conviennent pas à l'authentification basée sur
Internet.
 Dans Azure AD, plusieurs protocoles Web sont pris en charge pour activer l'authentification
déléguée : Certains des protocoles d'authentification les plus couramment pris en charge sont OAuth,
SAML et OpenID Connect. Cela permet aux organisations d'intégrer l'authentification Azure AD avec
des applications externes ou d'autres solutions SaaS.

Structure du répertoire :

 Dans Active Directory, vous pouvez utiliser des unités d'organisation pour organiser des
objets en groupes administratifs logiques. Une unité organisationnelle ou une unité d'organisation
peut contenir des objets tels que des comptes, des ordinateurs, des imprimantes, des applications et
bien d'autres.
 Dans Azure Active Directory, la structure est plate : aucune structure logique ne peut être
implémentée, telle que des unités d'organisation. Azure AD n'a que 3 types d'objets : les utilisateurs,
les groupes et les applications. Il a été conçu comme un fournisseur d'identité pour les mécanismes
d'authentification par modem.

Gestion de la configuration :
  La fonctionnalité de stratégie de groupe est utilisée pour contrôler l'environnement de travail
via Windows Active Directory. Ceux-ci fournissent des options de gestion et de configuration
centralisées pour les paramètres des systèmes, des applications et des utilisateurs au sein du
domaine.
 La gestion de la configuration dans Azure AD est très limitée ; le seul type d'outil de
configuration centralisée est appelé accès conditionnel. Cette politique vous permet uniquement
d'appliquer des conditions spécifiques dans le cas où vous souhaitez accorder l'accès aux
applications, et il convient de noter que Microsoft fntune peut être utilisé pour adapter les
configurations à l'échelle de l'entreprise.

Structure du domaine :

 Au niveau supérieur, vous pouvez définir une forêt et une arborescence de domaines qui
incluent plusieurs domaines. Dans la plupart des cas, ces concepts sont utilisés pour plus d'isolement
et d'autonomie lorsque cela est nécessaire. Les scénarios les plus courants pour avoir une forêt et
plusieurs domaines sont basés sur plusieurs sous-organisations au sein d'une forêt, plusieurs
départements au sein d'une grande forêt ou basés sur la géolocalisation.
 Azure AD utilise le concept de locataire : un locataire est une ressource entièrement
indépendante et il n'existe aucune relation parent-enfant possible entre les locataires.

Domaines externes :

 Les communications de domaine à domaine Active Directory se font via des approbations.
Une approbation AD est un canal d'authentification et de communication sécurisé entre différentes
entités. Les approbations vous permettent d'accorder l'accès à des utilisateurs, des groupes et des
ordinateurs spécifiques sur différents domaines.
 Un cas typique dans Azure lors de l'utilisation de domaines externes est qu'un utilisateur
externe souhaite avoir accès à des ressources spécifiques au sein de votre locataire. Le concept
d'approbations n'existe pas dans Azure AD. Dans le cas où une collaboration interentreprises est
requise, vous pouvez inviter des utilisateurs invités à accéder à une ressource spécifique au sein de
votre locataire.

FONDAMENTAUX - STRUCTURE DE REPERTOIRE AZURE :

Azure Active Directory est un service d'identité avec une structure plate. Dans cette structure,
trois objets communs sont configurés liés aux identités dans Azure AD. Une identité est un objet qui
peut être authentifié via des mots de passe, des clés secrètes ou des certificats. Au sein de chaque
locataire, un annuaire Azure AD est une structure approuvée et isolée. Dans ce répertoire, vous
pouvez créer les identités suivantes :

 Comptes utilisateurs : Il s'agit d'une identité avec les données qui lui sont associées ; un
compte ne peut exister sans identité. Un compte d'utilisateur est créé via Azure AD ou un autre
service cloud Microsoft et ceux-ci sont stockés dans votre Azure AD et accessibles à l'abonnement au
service cloud de votre organisation. Les comptes d'utilisateurs sont associés à des comptes
professionnels ou scolaires dans le Microsoft Cloud.
 Groupes : des groupes sont créés pour gérer les autorisations à une échelle supérieure. Les
ressources, telles que les comptes d'utilisateurs, peuvent faire partie d'un groupe en tant que
propriétaire ou membre du groupe. Un ensemble d'autorisations d'accès peut être attribué à un
groupe au lieu d'avoir à fournir les droits un par un. Le propriétaire du groupe a le contrôle et peut
accorder des droits de gestion à d'autres utilisateurs selon les besoins. Il existe quatre manières
courantes d'attribuer des droits d'accès :
o Attribution directe : le propriétaire de la ressource attribue l'accès directement à l'utilisateur
 o Attributions de groupe : le propriétaire de la ressource attribue l'accès à tous les membres de
ce groupe.
o Affectation basée sur des règles : le propriétaire de la ressource utilise une règle pour définir
les utilisateurs affectés à cette ressource. La règle est basée sur des attributs attribués à des
utilisateurs individuels.
o Attribution d'autorité externe : l'accès provient d'une ressource externe, par exemple, un
répertoire actif sur site.
 Applications : Azure AD fournit un accès sécurisé aux applications cloud et sur site. Dans
Azure AD, il existe quatre principaux types d'applications qui peuvent utiliser Azure AD en tant que
fournisseur de services d'identité :
o Application de galerie Azure AD : il s'agit d'une liste pré-générée de plus de 1000 applications
pour l'authentification unique avec Azure AD (par exemple, Office 365)
o Application sur site avec proxy d'application : les applications sur site peuvent utiliser le proxy
d'application pour prendre en charge l'authentification unique.
o Applications développées sur mesure : les applications personnalisées peuvent être
enregistrées dans Azure AD pour prendre en charge l'authentification unique
o Applications non-Gallery : d'autres applications peuvent être ajoutées à Azure AD, si elles
prennent en charge les protocoles nom d'utilisateur/mot de passe, SAML ou OpenID Connect.

Vous trouverez plus d'informations sur la structure et la terminologie d'Azure AD sur

https://docs.microsoft.com/en us/azure/active directory/fundamentals/active-directory-whatis.

FONDAMENTAUX - INTERFACES DE GESTION :

La gestion d'Azure AD peut être effectuée de plusieurs manières. La méthode la plus courante
pour configurer Azure AD consiste à utiliser le portail Web. Si vous êtes un compte privilégié (Global
Administrator), vous pouvez configurer toutes les fonctionnalités d'Azure AD et utiliser cette
interface pour les opérations quotidiennes telles que :

1. Gestion des comptes utilisateurs

2. Gestion des groupes d'utilisateurs

3. Surveiller la gestion des identités et des accès

Une manière plus avancée de gérer votre Azure AD est via PowerShell, Microsoft dispose d'un
guide de référence complet listant toutes les Cmdlets auxquelles vous pouvez accéder via le module
PowerShell. Ceci est très utile si vous souhaitez automatiser certaines tâches ou si vous devez
exécuter quelque chose en masse sur plusieurs objets. Le modèle Azure PowerShell peut être installé
en exécutant la commande suivante Install-Module AzureAD. Les applets de commande du module
Azure AD vous permettent de récupérer des données à partir de l'annuaire, de créer de nouveaux
objets dans l'annuaire, de mettre à jour des objets existants, de supprimer des objets, ainsi que de
configurer l'annuaire et ses fonctionnalités.

Une référence complète à toutes les applets de commande peut être trouvée sur le site Web de
Microsoft via le lien suivant : https://docs.microsoft.com/nl-nl/powershell/azure/active-directory/
overview?view=azureadps-2.0 ou utilisez le Get-Help <nom de l'applet de commande>.

FONDAMENTAUX - REINITIALISATION DE MOT DE PASSE EN LIBRE-SERVICE  :

La fonctionnalité de réinitialisation de mot de passe en libre-service dans Azure AD active le

portail de réinitialisation de mot de passe. L'utilisateur pourra réinitialiser son propre mot de passe
en utilisant plusieurs méthodes d'authentification pour prouver son identité. Lorsqu'un utilisateur
accède au portail de réinitialisation de mot de passe, un workflow est lancé pour déterminer :
  Comment la page doit-elle être localisée ?
 Le compte utilisateur est-il valide ?
 À quelle organisation appartient l'utilisateur ?
 Où est géré le mot de passe de l'utilisateur ?
 L'utilisateur dispose-t-il d'une licence pour utiliser la fonction ?

Lorsque SSPR est activé, vous devez sélectionner au moins l'une des options suivantes pour les
méthodes d'authentification. C'est une bonne pratique de l'industrie et également recommandée par
Microsoft que vous choisissiez deux ou plusieurs méthodes d'authentification afin que vos
utilisateurs aient plus de flexibilité au cas où ils ne pourraient pas accéder à leur compte quand ils en
ont besoin. Les méthodes d'authentification suivantes sont disponibles :

 Notification d'application mobile

 Code d'application mobile
 E-mail
 Téléphone mobile
 Téléphone de bureau
 Questions de sécurité

Les utilisateurs ne peuvent réinitialiser leur mot de passe que s'ils disposent de données
présentes dans les méthodes d'authentification que l'administrateur a activées. Plus d'informations
sont disponibles sur https://docs.microsoft.com/en-us/azure/active-directory/authentication/
concept-sspr-howitwork.

FONDAMENTAUX - ROLES ADMINISTRATIFS :

Dans votre Active Directory sur site, vous pouvez définir des rôles administratifs très précis ; dans
Azure AD, vous disposez d'une liste prédéfinie de rôles. Les rôles sont mis à jour régulièrement par
Microsoft pour fournir des autorisations granulaires. Il est donc difficile de gérer les rôles
d'administrateur. Il est recommandé de consulter régulièrement cette liste et de vous assurer que
vous utilisez les bons rôles pour vos besoins. Chaque locataire a besoin d'un administrateur global. Ce
rôle est comparable à un administrateur de domaine (ou d'entreprise) sur site. Le rôle vous donne
des autorisations complètes sur Azure et Office 365. Il est recommandé d'utiliser ce rôle uniquement
dans des situations très spécifiques et jamais pour les opérations quotidiennes normales. Une autre
bonne pratique consiste à créer un compte d'urgence avec le rôle d'administrateur global et à définir
un mot de passe très fort qui est stocké hors ligne et ne peut être utilisé que si tous les autres
utilisateurs sont verrouillés de votre environnement.

Nous avons répertorié ci-dessous certains des rôles clés décrits par Microsoft :

 Administrateur général : les utilisateurs qui sont affectés au rôle d'administrateur général
peuvent lire et modifier tous les paramètres administratifs de votre organisation Azure AD. Par
défaut, la personne qui souscrit à un abonnement Azure se voit attribuer le rôle d'administrateur
général pour l'organisation Azure AD. Seuls les administrateurs généraux et les administrateurs de
rôles privilégiés peuvent déléguer des rôles d'administrateur.
 Administrateur d'application : les utilisateurs de ce rôle peuvent créer et gérer tous les
aspects des applications d'entreprise, des enregistrements d'application et des paramètres de proxy
d'application. Ce rôle accorde également la possibilité de consentir aux autorisations déléguées et
aux autorisations d'application à l'exception de Microsoft Graph et Azure AD Graph.
 Administrateur d'authentification : les utilisateurs dotés de ce rôle peuvent définir ou
réinitialiser des informations d'identification sans mot de passe et peuvent mettre à jour les mots de
passe de tous les utilisateurs. Les administrateurs d'authentification peuvent demander aux
utilisateurs de se réinscrire avec des informations d'identification existantes sans mot de passe (par
exemple, MFA ou FIDO) et de révoquer l'authentification MFA sur l'appareil.
 Lecteur global : les utilisateurs de ce rôle peuvent lire les paramètres et les informations
administratives sur les services Microsoft 365, mais ne peuvent pas effectuer d'actions de gestion. Le
lecteur global est l'équivalent en lecture seule de l'administrateur global. Attribuez un lecteur global
au lieu d'un administrateur global pour la planification, les audits ou les enquêtes
 Administrateur du service d'assistance : les utilisateurs dotés de ce rôle peuvent modifier les
mots de passe, invalider les jetons d'actualisation, gérer les demandes de service et surveiller l'état
du service. L'invalidation d'un jeton d'actualisation force l'utilisateur à se reconnecter. Les
administrateurs du Helpdesk peuvent réinitialiser les mots de passe et invalider les jetons
d'actualisation des autres utilisateurs qui ne sont pas administrateurs.
 Administrateur de la sécurité : les utilisateurs dotés de ce rôle ont des autorisations pour
gérer les fonctionnalités liées à la sécurité dans le centre de sécurité Microsoft 365, Azure Active
Directory Identity Protection, Azure Information Protection et Office 365 Security & Compliance
Center.
 Opérateur de sécurité : les utilisateurs dotés de ce rôle peuvent gérer les alertes et bénéficier
d'un accès global en lecture seule aux fonctionnalités liées à la sécurité, y compris toutes les
informations du centre de sécurité Microsoft 365, Azure Active Directory, Identity Protection,
Privileged Identity Management et Office 365 Security & Compliance Center.
 Lecteur de sécurité : les utilisateurs dotés de ce rôle ont un accès global en lecture seule aux
fonctionnalités liées à la sécurité, y compris toutes les informations du centre de sécurité
Microsoft 365, Azure Active Directory, Identity Protection, Privileged Identity Management, ainsi que
la possibilité de lire Azure Active Directory. Rapports de connexion et journaux d'audit, et dans le
Centre de sécurité et de conformité Office 365.

De nombreux autres rôles administratifs sont décrits sur le site Web de Microsoft Azure, vous
pouvez trouver toutes les descriptions sur https://docs.microsoft.com/en-us/azure/active-
directory/users groups-roles/directory-assign-admin-roles.

IV. STRATEGIES D'ATTAQUE D'AZURE :

RECONNAISSANCE :

L'utilisation d'Azure AD permet à un adversaire d'effectuer une reconnaissance de manière assez

simple : la création d'un locataire 0365 ou Azure AD crée automatiquement un domaine <nom du
locataire>.onmicrosoft.com. Des domaines personnalisés peuvent également être ajoutés à votre
locataire ; la validation du propriétaire se fait via des enregistrements DNS dédiés.

Les adversaires demanderont ces enregistrements DNS et essaieront d'identifier les informations
contenues dans les enregistrements TXT ou MX. Microsoft propose deux options pour effectuer la
validation de domaine, où vous, en tant qu'organisation, devez modifier vos paramètres DNS avec
votre bureau d'enregistrement :

1. Un enregistrement TXT qui a la valeur MS=<nombre aléatoire> avec un TTL de 3600 secondes

2. Un enregistrement MX avec une priorité très élevée, destination de l'enregistrement MX

ms<random number>.msvl.invalid avec un TTL de 3600 secondes

De plus, dans le cas où l'organisation exécute Azure AD avec des applications SaaS (Software-as-a-
Service), l'adversaire peut consulter les enregistrements DNS MX, les enregistrements DNS TXT ou les
enregistrements de fédération tels que adfs.targetdomain.com, sso.targetdomain .com,
sts.targetdomain.com et bien d'autres.
 Notre société victime pour cette section sera "NVISO QA". Examinons leurs enregistrements DNS à
l'aide d'un outil de reconnaissance appelé DNS Dumpster. Dans la section Enregistrements MX, deux
éléments révèlent la présence d'Azure AD :

1. Les enregistrements *.mail.protection.outlook.com

2. L'enregistrement MS=ms76736040

Ainsi, nous pouvons supposer que « NVISO QA » utilise Azure AD.

Vous pouvez tester DNS Dumpster par vous-même ici : https://dnsdumpster.com/.

Il existe un autre moyen simple de déterminer si une entreprise utilise Azure. Nous pouvons
simplement demander à Microsoft en utilisant l'URL ci-dessous :

https://login.microsoftonline.com/getuserrealm.srf login=user@<domaine>&xml=l

Remplacez le domaine par le domaine de l'entreprise que vous souhaitez valider. Le nom
d'utilisateur peut être n'importe quoi, même des utilisateurs inexistants. Le XML résultant indiquera
si Azure AD et 0365 sont utilisés via le paramètre NameSpaceType. Une valeur « Managed » indique
qu'Azure AD est en cours d'utilisation. Nous pourrions également effectuer la demande et obtenir le
même résultat en utilisant qanviso.onmicrosoft.com comme domaine.

D'autres valeurs pour l'arc NameSpaceType "Federated" dans le cas où ADFS est utilisé (plus sur
cela plus tard) ou "Inconnu" si aucun enregistrement ne peut être trouvé. C'est ce que vous
obtiendrez si, par exemple, vous supprimez le trait d'union dans qa-nviso. Aucun enregistrement
n'existe pour ce domaine.

ÉNUMERATION DES UTILISATEURS :

Entre savoir qu'une entreprise utilise Azure AD et cibler ses utilisateurs (par exemple, avec une
attaque par pulvérisation de mot de passe), il y a une autre étape : déterminer qui sont les
utilisateurs et quelles adresses e-mail existent réellement. Ceci peut être réalisé en utilisant le flux de
travail suivant :

1. L'obtention d'une liste d'employés peut être effectuée à l'aide de techniques OSINT classiques,
par exemple, en utilisant Linkedln.

2. Appliquer plus de techniques OSINT et déterminer la structure de messagerie de l'entreprise,

par exemple, first.last@corp.com
 3. À l'aide de votre liste d'employés et de la structure du courrier, énumérez les comptes/adresses
valides grâce à l'un des nombreux outils d'énumération disponibles.

Voici quelques exemples d'outils d'énumération d'utilisateurs :

 0365 Creeper : https://github.com/LMGsec/o365creeper

 0365Enum : https://github.com/gremwell/o365enum
 MSMailProbe : https://github.com/busterb/msmailprobe
 Office365UserEnum : https://bitbucket.org/grimhacker/office365userenum

Après que Microsoft a changé la façon dont ActiveSync répond aux requêtes, un certain nombre
de ces outils ne parviennent pas à énumérer les utilisateurs valides. Cependant, d'autres méthodes
sont toujours disponibles, comme en témoigne la sortie de 0365Enum de Gremwell. Étant donné que
NVISO QA n'a pas de déploiement Exchange sur site ou hybride, l'énumération office.com de l'outil
l'option fonctionne particulièrement bien.

En plus de ces outils, certains des outils expliqués dans la diapositive de pulvérisation de mot de
passe permettent également l'énumération des utilisateurs.

PULVERISATION DE MOT DE PASSE :

En raison de leurs portails de connexion publics, les environnements cloud sont d'excellentes
cibles pour les attaques par pulvérisation de mots de passe. Ces types d'attaques utilisent un
ensemble limité de mots de passe communs contre de nombreux utilisateurs au sein du locataire
Azure AD. Généralement, ceux-ci couvrent de nombreuses organisations et fournisseurs d'identité
différents.

Qu'est-ce que la pulvérisation de mot de passe ?

Les attaques par force brute traditionnelles tentent d'obtenir un accès non autorisé à un seul
compte en devinant le mot de passe. Cela peut rapidement entraîner le verrouillage du compte ciblé,
car les politiques de verrouillage de compte couramment utilisées autorisent un nombre limité de
tentatives infructueuses (généralement trois à cinq) pendant une période de temps définie. Lors
d'une attaque par pulvérisation de mot de passe, l'acteur malveillant va essayer un ensemble limité
de mots de passe couramment utilisés contre de nombreux comptes avant de passer à la tentative
d'un deuxième mot de passe, et ainsi de suite. Cette technique permet à l'acteur de ne pas être
détecté en évitant les verrouillages de compte rapides ou fréquents.

Dans notre exemple, l'attaquant a obtenu une liste de tous les utilisateurs et va cibler ces
utilisateurs avec un mot de passe commun. Pour ne pas être détecté, l'acteur mettra le script en
pause pendant plusieurs secondes, puis passera à un deuxième mot de passe commun. Ciblant à
nouveau tous les utilisateurs de notre périmètre : Bob, Jim et Alice.

Les campagnes de pulvérisation de mots de passe ciblent généralement les applications à

authentification unique (SSO) et basées sur le cloud utilisant des protocoles d'authentification
fédérés.

https://www.helpnetsecurity.com/2019/03/20/imap-based-password-spraying/

OUTILS DE PULVERISATION DE MOT DE PASSE :

Plusieurs outils existent pour vous aider dans les attaques par pulvérisation de mots de passe et
l'énumération des utilisateurs. Une fois que vous avez obtenu une liste des mots de passe et des
utilisateurs couramment utilisés pour cette organisation, vous pouvez utiliser certains des outils
suivants pour attaquer des services cloud spécifiques. Notez que dans la plupart des cas, les attaques
par pulvérisation de mot de passe ciblent les protocoles hérités, car les mécanismes
d'authentification par modem ont souvent des contrôles contre la pulvérisation de mots de passe
(par exemple, authentification à deux facteurs, accès conditionnel, ...)

Dans le monde de l'entreprise, nous rencontrons souvent encore la prise en charge des protocoles
d'authentification hérités pour prendre en charge les anciens clients Office Outlook, les outils de
messagerie, Azure AD est souvent utilisé avec d'autres services 0365 ; cela signifie que nous
pourrions abuser du service de messagerie pour attaquer les comptes Azure AD !

La liste suivante est un ensemble limité d'outils pouvant être utilisés pour la pulvérisation de mots
de passe ou les attaques par énumération d'utilisateurs :

 Ruler (par Sensepost) : Ruler a été développé par Sensepost. Il vous permet d'interagir à
distance avec les serveurs Exchange, via le protocole MAPI/HTTP ou RPC/HTTP. L'objectif principal
est d'abuser des fonctionnalités Outlook côté client et d'obtenir un shell à distance. Ruler a plusieurs
fonctionnalités, mais certaines fonctions intéressantes de notre point de vue sont l'énumération des
utilisateurs, la création de nouvelles règles de messagerie malveillantes et le vidage de la liste
d'adresses globale (GAL). Le code source de la règle peut être trouvé sur :
https://github.com/sensepost/mler.
 Spraying Toolkit (par byt3bl33d3r) : un ensemble de scripts/utilitaires Python qui tentent de
rendre les attaques par pulvérisation de mot de passe contre Lync/S4B et OWA beaucoup plus
rapides, moins pénibles et plus efficaces. Atomizer est l'un des scripts de base de la boîte à outils de
pulvérisation de mot de passe. Il peut exécuter la pulvérisation de mot de passe via lync, OWA ou
IMAP et différents types de fichiers peuvent être utilisés comme mot de passe et liste d'utilisateurs. Il
vous permet de gratter Google et Bing pour les profils Linkedln, génère automatiquement des e-mails
à partir des noms de profil en utilisant le modèle spécifié et effectue des pulvérisations de mot de
passe en temps réel. La source de la boîte à outils de pulvérisation peut être trouvée sur :
https://github.com/byt3bl33d3r/SprayingToolkit.
 MailSniper : MailSniper est un outil de test d'intrusion pour effectuer des recherches dans les
e-mails dans un environnement Microsoft Exchange. Cet outil, basé sur PowerShell, comprend des
modules supplémentaires pour la pulvérisation de mots de passe, l'énumération des
utilisateurs/domaines, la collecte de la liste d'adresses globale à partir d'OWA et d'EWS et la
vérification des autorisations de boîte aux lettres pour chaque utilisateur Exchange d'une
organisation. La source MailSniper peut être trouvée sur https://github.com/dafthack/MailSniper.

Dans le cas où l'authentification par modem est activée, les adversaires devront s'appuyer sur
d'autres outils, qui seront abordés dans une section ultérieure.

ATTAQUES DE REUTILISATION DE MOT DE PASSE :

Les attaques par réutilisation ou relecture de mot de passe sont très efficaces contre les
environnements publics si MFA (Multi-Factor Authentication) n'est pas activé. Les employés utilisent
encore souvent le même mot de passe sur les comptes personnels et d'entreprise. Des sites tels que
"1 been pwned" et "ghostproject" peuvent vous aider à rassembler une liste de mots de passe qui
sont éventuellement utilisé pour les comptes professionnels.

Une fois les comptes compromis identifiés pour une organisation cible, ils peuvent être réutilisés
avec 0365 et leur compte Azure AD correspondant. Il est utile de noter que Microsoft dispose d'un
contrôle de sécurité intégré qui vise à empêcher de telles attaques : Microsoft surveille les
informations d'identification divulguées et dans le cas où les hachages d'un mot de passe compromis
sont stockés dans Azure AD, Microsoft générera un rapport mettant en évidence ces utilisateurs
compromis.

RECONNAISSANCE AUTHENTIFIEE :
 Après une attaque de pulvérisation/réutilisation de mot de passe réussie, vous avez obtenu un
nom d'utilisateur et un mot de passe. Avec ce nouvel accès, un monde d'informations s'ouvre. Un
certain nombre d'outils peuvent vous aider à faciliter vos efforts de reconnaissance
d'authentification :

 0365Recon : un script PowerShell unique qui peut saisir les utilisateurs, les informations
utilisateur, les groupes, l'appartenance à un groupe et les informations sur l'entreprise. 0365Recon
dépend des modules MSOnline et/ou AzureAD PowerShell, qui ont été introduits précédemment.
 ROADtools : ROADtools est un framework pour interagir avec Azure AD développé par Dirk-
Jan Mollema. Il comporte 2 composants principaux :
o ROADlib : bibliothèque pour s'authentifier auprès d'Azure AD ou s'intégrer à une base de
données ROADrecon.
o ROADrecon : utilisé pour explorer les informations Azure AD, y compris une interface.
ROADrecon a même un plugin BloodHound qui fonctionne avec un fork personnalisé de
BloodHound : https://github.com/dirkjanm/BloodHound-AzureAD

En plus de cela, certains des outils de pulvérisation de mot de passe dont nous venons de parler
ont également des capacités de reconnaissance d'authentification.

Les références:

 https://github.com/nyxgeek/o365recon.
 https://github.com/dirkjanm/ROADtools.
 https://dirkjanm.io/introducing-roadtools-and-roadrecon-azure-ad-exploration-framework/

RECONNAISSANCE AUTHENTIFIEE - 0365RECON :

Pour utiliser le script 0365recon PowerShell, nous avons besoin de certains modules installés en
premier : Pour la plupart des gens, vous n'aurez qu'à installer le module MsOnline

 Module d'installation MSOnline

 Install-Module -Name AzureAD

Le module AzureAD est nécessaire si vous souhaitez également utiliser la fonctionnalité

commentée.

Lors de l'exécution du script, des informations d'identification doivent être fournies pour
s'authentifier auprès d'Azure AD.

Par défaut, il énumère une liste d'utilisateurs, de groupes, d'appartenances à des groupes, de
domaines et d'informations sur l'entreprise.

RECONNAISSANCE AUTHENTIFIEE - ROADTOOLS :

 L'utilisation de roadrecon est très simple et se compose de 3 étapes/commandes :

1. Authentifiez-vous

2. Rassemblez

3. Interface graphique

Avec la première commande, "roadrecon auth", vous vous connectez à Azure AD avec un
utilisateur que vous avez compromis. Il existe différentes options pour se connecter, y compris le mot
de passe, le code de l'appareil ou les jetons JWT. Dans notre cas, nous avons accès à un nom
d'utilisateur et à un mot de passe, nous pouvons donc simplement nous connecter en utilisant le mot
de passe. Roadrecon récupérera et stockera les jetons d'authentification à utiliser à l'étape suivante.
Avec "roadrecon gather", la collecte de données est lancée et toutes les informations collectées sont
stockées dans roadrecon.db.

Enfin, à l'aide de "roadrecon gui", l'interface Web est lancée et toutes les informations peuvent
être consultées en visitant http://127.0.0.1:5000.

POST-EXPLOITATION :

Une fois authentifié auprès d'Azure AD, plusieurs chemins d'attaque sont plausibles, en fonction
de la présence de mauvaises configurations ou des privilèges du compte compromis. Pour faciliter
l'enquête sur l'escalade potentielle des privilèges et d'autres tâches offensives, PowerZure a été créé
par les gars de SpecterOps.

PowerZure dispose d'un certain nombre de fonctions disponibles qui peuvent être classées
comme suit :

 Obligatoire - Choses que vous devez faire avant toute autre chose
 Fonctions opérationnelles qui provoqueront une opération dans Azure
 Collecte d'informations -Fonctions qui collectent des informations sur les ressources dans
Azure
 Secret Gathering -Fonctions qui se concentrent sur la collecte de secrets, en particulier
 Exfiltration de données -Fonctions qui exfiltreront les données

PowerZure utilise le module az, qui est un autre module en plus des deux dont nous avons parlé
précédemment. Il s'agit de la manière recommandée et actuelle d'interagir avec Azure via CLI  :
https://docs.microsoft.com/en-us/powershell/azure/new-azureps-module-az?view=azps-4.2.0

Suivez ces étapes pour démarrer avec PowerZure :

 1. Importez le module PowerZure dans PowerShell, qui téléchargera le module az s'il n'est pas
déjà présent.

2. Connectez-vous via l'un des trois modes suivants :

 Interactif - Via une page de connexion. Obligatoire si MFA est utilisé.

 Jeton - Via un jeton Azure mis en cache.
 Paramètres-Par le nom d'utilisateur et le mot de passe passés en tant que paramètres (si
aucun MFA n'est utilisé).

3. Définissez un abonnement pour que PowerZure fonctionne. Cela fait partie des fonctions
obligatoires.

4. Exécutez la fonction souhaitée, selon le rôle attribué à votre compte.

Vous trouverez plus d'informations sur l'architecture et les principes d'Azure, des détails
supplémentaires sur PowerZure et les moyens d'abuser des rôles Azure dans le billet de blog
SpecterOps : https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-
ca70b330511a.

De plus, pour une vue sur les fonctions PowerZure et le rôle nécessaire pour les exécuter, voir le
PowerZure : Github : https://github.com/hausec/PowerZure.

V. INTEGRATION AD SUR SITE :

INTRODUCTION - MODELES D'IDENTITE AZURE AD :

Au sein du service d'identité d'Azure AD, il existe trois types différents de modèles d'identité :

Identité cloud uniquement  : Cela signifie que l'identité n'existe que dans Azure AD, il n'y a pas de
lien entre Azure AD et d'autres annuaires pour importer des identités. Il s'agit du paramètre par
défaut, lorsqu'un compte Office 365 est créé, ce compte est stocké dans Azure AD en tant qu'identité
cloud uniquement. Dans cette section, nous nous concentrerons sur les autres modèles d'identité.

Identité synchronisée : Pour les grandes organisations en mode hybride, il s'agit de la

configuration la plus courante, car les identités sont gérées sur site et synchronisées régulièrement
vers l'environnement cloud. En règle générale, le processus de synchronisation est un agent exécuté
sur un contrôleur de domaine qui remplit Azure AD.

Identité fédérée : Une identité fédérée est un autre modèle d'identité hybride, similaire au
modèle d'identité synchronisé, sauf que dans le cas d'une identité fédérée, le fournisseur d'identité
sur site est responsable de l'authentification proprement dite. Si les utilisateurs demandent l'accès
au cloud, ils seront redirigés vers le fournisseur d'identité sur site et, après une authentification
réussie, ils seront redirigés vers le service cloud.

PRESENTATION D'AZURE AD CONNECT POUR L'IDENTITE HYBRIDE  :

 Azure AD Connect est un outil conçu par Microsoft pour synchroniser les identités locales avec les
identités cloud. Ce logiciel vous permet de connecter votre annuaire actif local à Azure AD. Il a
plusieurs fonctionnalités, mais l'objectif principal est de synchroniser les utilisateurs et les groupes de
votre domaine local vers Azure AD. L'avantage est que les utilisateurs finaux peuvent utiliser une
seule identité pour accéder aux services sur site et dans le cloud. L'intervalle de synchronisation par
défaut est défini sur 30 minutes, mais ce paramètre peut être modifié pour répondre à vos besoins.

Notez qu'Azure AD Connect est une cible courante pour les attaquants car il doit s'exécuter à la
fois avec des privilèges élevés sur votre annuaire actif local et avec des privilèges élevés dans votre
environnement Azure AD. Généralement, l'utilisateur Azure AD Connect est configuré lors de
l'installation de la connexion Azure AD et a le format suivant : « MSOLXXXXXX ».

METHODES D'AUTHENTIFICATION AZURE AD CONNECT  :

Les méthodes d'authentification suivantes sont prises en charge et répertoriées dans la

documentation Azure AD Connect :

 Synchronisation du hachage du mot de passe : méthode de connexion qui synchronise un

hachage du mot de passe AD local d'un utilisateur avec Azure AD. En fait, un nouveau hachage salé
est généré à partir du hachage sur site.
 Authentification directe : permet aux utilisateurs d'utiliser le même mot de passe sur site et
dans le cloud sans nécessiter le stockage des hachages dans Azure AD ou l'infrastructure
supplémentaire d'un environnement fédéré. L'authentification s'effectue sur l'AD local via un agent
Azure AD Connect.
 Intégration de la fédération : la fédération est une partie facultative d'Azure AD Connect et
peut être utilisée pour configurer un environnement hybride à l'aide d'une infrastructure ADFS
locale. Il fournit également des fonctionnalités de gestion ADFS telles que le renouvellement des
certificats et des déploiements de serveurs ADFS supplémentaires.

Nous examinerons plus en détail ces méthodes d'authentification dans les diapositives suivantes.

Les fonctionnalités supplémentaires qui doivent être disponibles via Azure AD Connect sont :

 Synchronisation : responsable de la création d'utilisateurs, de groupes et d'autres objets,

ainsi que de la vérification des informations d'identité de vos utilisateurs et groupes sur site
correspondent au cloud. Cette synchronisation inclut également les hachages de mot de passe.
 Surveillance de l'intégrité : Azure AD Connect Health peut fournir une surveillance robuste.

Des références à ces modèles et plus d'informations peuvent être trouvées via la documentation
officielle de Microsoft : https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-
azure-ad-connect
 SYNCHRONISATION DU HACHAGE DU MOT DE PASSE (PHS) :

La synchronisation Password Hash ne se contente pas de synchroniser les mots de passe de votre
annuaire actif local vers votre locataire Azure AD. Microsoft implémente plusieurs étapes pour
protéger vos mots de passe sur site. Dans le cas où Azure AD serait piraté et que des hachages
seraient récupérés, il serait toujours impossible pour un adversaire de les utiliser et de cibler vos
comptes Active Directory sur site.

Les étapes suivantes sont décrites par Microsoft (source :

https://docs.microsoft.com/en-us/azure/active directory/hybrid/how-to-connect-password-hash-
synchronization) et expliquent comment les hachages sont synchronisés dans un modèle hybride via
Azure AD connect :

1. Toutes les deux minutes, l'agent de synchronisation de hachage de mot de passe sur le
serveur AD Connect demande les hachages de mot de passe stockés (l'attribut unicodePwd) à un
contrôleur de domaine. Cette requête s'effectue via le protocole de réplication MS-DRSR standard
utilisé pour synchroniser les données entre les contrôleurs de domaine. Le compte de service doit
disposer des autorisations Répliquer les modifications de répertoire et Répliquer toutes les
modifications de répertoire AD (accordées par défaut lors de l'installation) pour obtenir les hachages
de mot de passe.
2. Avant l'envoi, le contrôleur de domaine chiffre le hachage du mot de passe MD4 à l'aide
d'une clé qui est un hachage MD5 de la clé de session RPC et d'un sel. Il envoie ensuite le résultat à
l'agent de synchronisation de hachage de mot de passe via RPC. Le DC transmet également le sel à
l'agent de synchronisation en utilisant le protocole de réplication DC, afin que l'agent puisse
déchiffrer l'enveloppe.
3. Une fois que l'agent de synchronisation de hachage de mot de passe a l'enveloppe chiffrée, il
utilise MD5CryptoServiceProvider et le sel pour générer une clé pour déchiffrer les données reçues
dans leur format MD4 d'origine. L'agent de synchronisation de hachage de mot de passe n'a jamais
accès au mot de passe en clair. L'agent de synchronisation de hachage de mot de passe étend le
hachage de mot de passe binaire de 16 octets à 64 octets en convertissant d'abord le hachage en une
chaîne hexadécimale de 32 octets, puis en reconvertissant cette chaîne en binaire avec le codage UTF
16. L'agent ajoute un sel par utilisateur, composé d'un sel de 10 octets, au binaire de 64 octets pour
mieux protéger le hachage d'origine. Enfin, l'agent de synchronisation de hachage de mot de passe
combine ensuite le hachage MD4 plus le sel par utilisateur, et l'entre dans la fonction PBKDF2. 1000
itérations de l'algorithme de hachage à clé HMAC-SHA256 sont utilisées.
4. L'agent de synchronisation de hachage de mot de passe prend le hachage de 32 octets
résultant, concatène à la fois le sel par utilisateur et le nombre d'itérations SHA256 (pour une
utilisation par Azure AD), puis transmet la chaîne d'Azure AD Connect à Azure AD via SSL.
 Lorsqu'un utilisateur tente de se connecter à Azure AD et entre son mot de passe, le mot de passe
est exécuté via le même processus MD4+salt+PBKDF2+HMAC-SHA256. Si le hachage résultant
correspond au hachage stocké dans Azure AD, l'utilisateur a saisi le mot de passe correct et il est
authentifié.

AUTHENTIFICATION DIRECTE (PTA) :

L'authentification directe est une alternative à la synchronisation de hachage de mot de passe

Azure AD. Il offre le même avantage que l'authentification cloud. Si vous souhaitez appliquer des
stratégies de sécurité et de mot de passe Active Directory sur site, vous devez choisir cette option.

Alors, comment ça marche? Lorsqu'un utilisateur tente de se connecter à une application

sécurisée par Azure AD, et si l'authentification directe est activée sur le locataire, les étapes suivantes
se produisent (source : https://docs.microsoft.com/en us/azure/ active-directory/hybride/comment-
connecter-pta-comment-ça-fonctionne) :

1. L'utilisateur essaie d'accéder à une application, par exemple Outlook Web App.
2. Si l'utilisateur n'est pas déjà connecté, il est redirigé vers la page de connexion des
utilisateurs Azure AD.
3. L'utilisateur entre son nom d'utilisateur dans la page de connexion Azure AD, puis
sélectionne le bouton Suivant. L'utilisateur entre son mot de passe dans la page de connexion Azure
AD, puis sélectionne le bouton Se connecter.
4. Azure AD, à la réception de la demande de connexion, place le nom d'utilisateur et le mot de
passe (chiffrés à l'aide de la clé publique des agents d'authentification) dans une file d'attente.
5. Un agent d'authentification sur site récupère le nom d'utilisateur et le mot de passe chiffré
de la file d'attente. Notez que l'agent n'interroge pas fréquemment les demandes de la file d'attente,
mais récupère les demandes via une connexion persistante préétablie.
6. L'agent déchiffre le mot de passe à l'aide de sa clé privée.
7. L'agent valide le nom d'utilisateur et le mot de passe par rapport à Active Directory à l'aide
d'API Windows standard, qui est un mécanisme similaire à celui utilisé par Active Directory
Federation Services (ADFS). Le nom d'utilisateur peut être soit le nom d'utilisateur local par défaut,
généralement userPrincipalName, soit un autre attribut configuré dans Azure AD Connect (appelé
autre ID).
8. Le contrôleur de domaine Active Directory (DC) sur site évalue la demande et renvoie la
réponse appropriée (succès, échec, mot de passe expiré ou utilisateur verrouillé) à l'agent.
9. L'agent d'authentification, à son tour, renvoie cette réponse à Azure AD.
10. Azure AD évalue la réponse et répond à l'utilisateur de manière appropriée. Par exemple,
Azure AD connecte l'utilisateur immédiatement ou demande l'authentification multifacteur Azure.
11. Si la connexion de l'utilisateur réussit, l'utilisateur peut accéder à l'application.

SERVICES DE FEDERATION ACTIVE DIRECTORY (ADFS) :

 Active Directory Federation Services (ADFS) offre aux administrateurs un moyen simplifié de
permettre aux utilisateurs de tirer parti des identités locales (informations d'identification) pour
accéder aux applications cloud.

Afin de tirer parti d'ADFS, une approbation fédérée entre Azure AD et l'environnement sur site
doit être configurée.

L'authentification fédérée au sein d'ADFS est une authentification basée sur les revendications. Il
s'agit d'une autre approche de l'authentification qui supprime la gestion de l'authentification de
l'application et facilite la gestion des comptes en centralisant l'authentification. Dans une
revendication, vous pouvez trouver des informations spécifiques qui décrivent l'identité donnée.
Plusieurs réclamations peuvent être demandées. Celles-ci sont conservées dans un jeton qui a
également une signature, vous savez donc que le jeton n'est pas falsifié en transit. Lorsqu'un
utilisateur essaie de se connecter avec la méthode d'authentification de fédération, l'utilisateur sera
redirigé vers l'ADFS pour effectuer une connexion.

Les approbations ADFS sont basées sur des paires de clés publiques privées (infrastructure PKI),
vous ne pouvez donc pas faire confiance/configurer une fédération si vous n'avez pas de domaine
vérifié connu. L'authentification fédérée ne fonctionnera jamais avec le domaine Microsoft par
défaut.onmicrosoft.com. Azure AD Connect peut également créer une approbation pour autoriser
l'authentification fédérée.

La documentation complète de Microsoft est disponible sur :

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed.

AUTHENTIFICATION UNIQUE TRANSPARENTE S.S.O :

L'authentification unique transparente Azure Active Directory (Azure AD Seamless SSO) connecte
automatiquement les utilisateurs lorsqu'ils se trouvent sur leurs appareils d'entreprise connectés à
votre réseau d'entreprise. Authentification unique Azure AD utilise Kerberos pour identifier
l'utilisateur sur cet appareil d'entreprise. Nous expliquerons plus en détail le flux à enseigne unique.
Notez que l'authentification unique n'est pas compatible avec les services de fédération Active
Directory (ADFS) car l'authentification est redirigée vers votre fournisseur d'identité sur site
(contrôleur de domaine).

Principaux points forts de l'authentification unique :

 L'authentification unique transparente peut être combinée avec les méthodes de connexion
Synchronisation du hachage du mot de passe ou Authentification directe. L'authentification unique
transparente ne s'applique pas aux services de fédération Active Directory (ADFS).
  Pour utiliser Seamless SSO, l'appareil de l'utilisateur doit être joint au domaine, mais
l'appareil n'a pas besoin d'être joint à Azure AD.
 À l'aide de votre domaine local, la clé de déchiffrement Kerberos du compte d'ordinateur
(AZUREADDSSO$) est partagée en toute sécurité avec Azure AD. Ceci est nécessaire pour déchiffrer le
ticket Kerberos qui a été demandé par Azure AD.

Vous trouverez plus d'informations sur ce concept sur

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso.

AUTHENTIFICATION UNIQUE TRANSPARENTE - FLUX DETAILLE :

Alors, comment l'authentification unique transparente fonctionne-t-elle avec Windows Active

Directory ? Comme d'habitude, Microsoft a fourni des instructions détaillées sur le fonctionnement
de l'authentification unique transparente dans sa documentation en ligne. Les étapes suivantes ont
été prises à partir de https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-
connect-sso-how-it-works

Les étapes suivantes décrivent ce processus en détail. Notez également qu'Azure AD demande
des tickets au cas où vous pourriez générer vos propres tickets Kerberos. Cela permettrait également
à un acteur malveillant d'accorder l'accès aux applications exposées via Azure AD.

1. L'utilisateur essaie d'accéder à une application native (par exemple, le client Outlook) à partir
d'un appareil d'entreprise joint à un domaine à l'intérieur de votre réseau d'entreprise.
2. Si l'utilisateur n'est pas déjà connecté, l'application native récupère le nom d'utilisateur de
l'utilisateur depuis la session Windows de l'appareil.
3. L'application envoie le nom d'utilisateur à Azure AD et récupère le point de terminaison WS-
Trust MEX de votre locataire. Ce point de terminaison WS-Trust est utilisé exclusivement par la
fonctionnalité Seamless SSO et n'est pas une implémentation générale du protocole WS-Trust sur
Azure AD.
4. L'application interroge ensuite le point de terminaison WS-Trust MEX pour voir si le point de
terminaison d'authentification intégré est disponible. Le point de terminaison d'authentification
intégré est utilisé exclusivement par la fonction Seamless SSO.
5. Si l'étape 4 réussit, un challenge Kerberos est émis.
6. Si l'application parvient à récupérer le ticket Kerberos, elle le transmet au point de
terminaison d'authentification intégré d'Azure AD.
7. Azure AD décrypte le ticket Kerberos et le valide.
8. Azure AD connecte l'utilisateur et envoie un jeton SAML à l'application.
9. L'application soumet ensuite le jeton SAML au point de terminaison de jeton 0Auth2 d'Azure
AD
10. Azure AD valide le jeton SAML et envoie à l'application un jeton d'accès et un jeton
d'actualisation pour la ressource spécifiée, ainsi qu'un jeton d'ID.
11. L'utilisateur a accès à la ressource de l'application.
 L'authentification unique transparente est opportuniste, ce qui signifie qu'en cas d'échec,
l'expérience de connexion revient à son comportement habituel, ce qui signifie que l'utilisateur doit
saisir son mot de passe pour se connecter.

VI. STRATEGIES D'ATTAQUE AVEC INTEGRATION AD :

DCSYNC - PHS ATTAQUANT :

PHS était auparavant présenté comme le compte de synchronisation utilisé par Azure AD Connect
pour synchroniser les hachages de mot de passe sur site avec Azure AD. Le compte de
synchronisation a donc besoin de droits de réplication, ce qui a été expliqué plus tôt dans la journée.
Si nous pouvons mettre la main sur ce compte, nous pouvons effectuer une attaque dcsync !

Étape 1 : Déterminez sur quel serveur Azure AD Connect est installé. Microsoft a facilité cette
recherche en générant automatiquement le compte de synchronisation nommé comme suit :
"MSOLnnnnnnnnnn" avec "n" étant des caractères aléatoires. De plus, sa description commence par
"Compte créé par Microsoft Azure Active Directory Connect". La description mentionne l'ordinateur
sur lequel Azure AD Connect s'exécute.

Il existe différentes manières d'interroger le domaine sur site et d'identifier le compte MSOL. Avec
un accès authentifié au domaine sur site, vous pouvez utiliser ldapsearch sur Linux ou la plate-forme
Jxplorer (http://jxplorer.org/). Un moyen simple de rechercher le domaine à partir d'une machine
jointe à un domaine Windows consiste à utiliser le module AD PowerShell. Après l'avoir importé dans
une session PowerShell, récupérez la description de l'utilisateur en fonction de son nom :

Get-ADUser -filter 'name -like "Msol*"' -Propriétés Description

Le module est, par défaut, disponible sur les contrôleurs de domaine, mais vous pouvez le
récupérer et l'importer sur un poste de travail Windows via ici :
https://github.com/samratashok/ADModule.

Plus d'informations sur le module AD sont disponibles dans la documentation de Microsoft :

https://docs.microsoft.com/en-us/powershell/module/addsadministration/?view=winlO-ps .

L'étape 2 : Consiste à récupérer le mot de passe du compte de synchronisation auprès du

Credential Manager et à le déchiffrer avec des clés DPAPI. Après un changement en avril 2020, le mot
de passe ne pouvait plus être obtenu avec uniquement les droits d'administrateur local. Il est
maintenant stocké dans Credential Manager et accessible uniquement pour le service ADSync.
Cependant, il existe plusieurs façons de contourner cette limitation.

 Option 1 : Sur le serveur lui-même, il est possible d'utiliser un script PowerShell créé par
Adam Chester. Ce script exécutera une commande via xp cmdshell sur la base de données locale
ADSync. Par conséquent, la commande s'exécute dans le contexte de l'utilisateur ADSync et peut
utiliser ses clés DPAPI pour déchiffrer le mot de passe.
 Option 2 : il est également possible de récupérer le mot de passe sur le réseau à l'aide de
l'outil adconnectdump de Fox-IT et Dirk-Jan Mollema. Cet outil récupérera la base de données locale
ADSync et les DPAPI nécessaires clés du serveur pour tout déchiffrer localement.

Des informations détaillées sur l'option 1 sont disponibles sur le blog d'Adam Chester :

 https://blog.xpnsec.com/azuread-connect-for-redteam/
 https://gist.github.com/xpn/fl2bl45dbal6c2eebddlc6829267b90c
 Les détails sur l'option 2 peuvent être trouvés sur le blog de Dirk-Jan Mollema :

 https://dirkjanm.io/updating-adconnectdump-a-joumey-into-dpapi/
 https://github.com/fox-it/adconnectdump

Maintenant que nous avons accès au mot de passe du compte MSOL, nous pouvons l'utiliser pour
effectuer une attaque DCSync.

Voici un petit retour sur la description de DCSync d'avant :

Pour des raisons de disponibilité, les administrateurs déploient plusieurs contrôleurs de domaine
dans une infrastructure Active Directory. Chaque contrôleur de domaine possède une copie de la
base de données Active Directory, et les mises à jour de cette base de données sur un contrôleur de
domaine (par exemple la création d'un nouvel utilisateur) doivent être propagées aux autres
contrôleurs de domaine en temps voulu. C'est ce qu'on appelle la réplication Active Directory : un
ensemble de méthodes et de protocoles pour synchroniser la base de données des contrôleurs de
domaine Active Directory.

Vincent et Benjamin ont élaboré ces méthodes et protocoles à utiliser par Mimikatz : Mimikatz a
une commande (dcsync) qui fera en sorte que tout ordinateur exécutant Mimikatz se fera passer
pour un contrôleur de domaine auprès d'un contrôleur de domaine cible afin d'obtenir les
informations d'identification stockées dans ce contrôleur de domaine.

Bien sûr, les utilisateurs normaux ne peuvent pas accéder à ces informations. Il faut des droits
d'administrateur de domaine pour pouvoir participer à la réplication des données. Ou le compte de
synchronisation Azure AD Connect, bien sûr.

CLE SQUELETTE - PTA ATTAQUANT :

Pour rappel, avec PTA, l'authentification de l'utilisateur est validée sur site. Plus précisément, il est
validé sur le serveur Azure AD Connector. Cela fournit des options d'attaque supplémentaires.

 Étape 1 : Similaire avec PHS, déterminez sur quel serveur Azure AD Connect est installé.
Quelques diapositives plus tôt, dans la section PHS DCSync, nous avons expliqué comment procéder.

Au préalable, nous aurons à nouveau besoin des droits d'administrateur local, car nous allons
injecter une DLL et accrocher une fonction API Windows.

 Étape 2 : Créez une DLL qui accroche la fonction LogonUserW, qui est responsable de la
validation de l'authentification. Cela vous permet d'exécuter votre propre logique «
d'authentification ». Dans la diapositive suivante, nous verrons quelques options intéressantes pour
cette logique d'authentification.

Un bel outil pour faciliter le hooking est EasyHook : https://easyhook.github.io/

 Dans une troisième et dernière étape, injectez la DLL dans

AzureADConnectAuthenticationAgentService. Un outil qui peut nous aider ici est
"injectAIIITheThings", qui contient plusieurs techniques d'injection de DLL :
https://github.com/fdiskyou/injectAHTheThings.

Selon la façon dont on code notre DLL, différentes attaques sont possibles :

 Regarder en silence -Imprimez le nom d'utilisateur et le mot de passe et transférez les

informations d'identification à la fonction LogonUserW d'origine.
 Clé squelette - Si le mot de passe fourni correspond à la clé squelette (c'est-à-dire, notre mot
de passe codé en dur), continuez le flux d'authentification réussi. Si ce n'est pas le cas, transmettez
les informations d'identification à la fonction LogonUserW d'origine pour décider du sort de
l'utilisateur.

Il est également possible de combiner les deux approches. Avoir une clé squelette pour pouvoir se
connecter en tant qu'utilisateur et combiner cela avec le stockage de toutes les informations
d'identification fournies. Cela nous donnera également toutes les informations d'identification claires
de l'utilisateur.

Des informations supplémentaires peuvent être trouvées dans les ressources ci-dessous :

 https://www.varonis.com/blog/azure-skeleton-key/
 https://blog.xpnsec.com/azuread-connect-for-redteam/

SILVERTICKET-ATTAQUANT SSO TRANSPARENT :

L'authentification unique transparente utilise la clé de déchiffrement Kerberos du compte

AZUREADDSSOS pour déchiffrer le ticket Kerberos qui a été demandé par Azure AD et le traduit en
jetons SAML ou JWT.

Une technique d'attaque intéressante contre Seamless SSO a été décrite par Michael Grafnetter
en janvier 2017. Dans son article de blog "Impersonating Office 365 Users With Mimikatz"
(https://www.dsintemals.com/en/impersonating office-365-users-mimikatz/ ), il parle d'abuser des
tickets Silver d'un compte spécifique lié à Azure AD pour obtenir un accès non autorisé aux services
Office 365. Comme SSO utilise Kerberos, les stratégies d'attaque typiques de Kerberos sont
également utiles ici.

Dans son article de blog, Michael a expliqué que nous pouvons diviser l'attaque en 2 parties
principales. Dans la première partie, nous devons obtenir les informations suivantes qui nécessitent
des droits DA (pour DCSync le hachage du compte)

1. Hachage du mot de passe NT du compte AZUREADSSOACC

2. Nom du domaine AD
3. Nom de connexion AAD de l'utilisateur que nous voulons emprunter, par exemple,
elrond@contoso.com. Il s'agit généralement de son userPrincipalName ou de l'attribut mail de l'AD
sur site.
4. SID de l'utilisateur que nous voulons usurper, par exemple, S-l-5-21-2121516926-
2695913149-3163778339-1234

Dans le cas où nous avons collecté ces informations, nous pouvons passer à l'étape 2 et générer
nos tickets argent !

La deuxième partie de l'attaque se déroule comme suit :

  Générez un ticket argent en utilisant mimikatz et en fournissant les informations que nous
avons recueillies précédemment. Il vous faudra remplacer les valeurs /user, /sid /id/domain et /rc4
par les valeurs précédemment obtenues :

mimikatz.exe "kerberos::golden /user:sans699 /sid:S-1-5-21-2121516926-26222-3163778339

/id:1234/domaine:sans699.local/rc4:f9969e088b2c!3d93833d0ce436c76dd/
target.aadg.windows.net.nsatc.net/service.HTTP /ptt" exit

 Une fois le ticket chargé en mémoire, nous pouvons valider son bon fonctionnement en
suivant les étapes suivantes :
 Lancez Mozilla Firefox.
 Accédez à aboutxonfig et définissez la préférence network.negotiate-auth.trusted-uris sur la
valeur https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com .
 Accédez à n'importe quelle application Web intégrée à notre domaine AAD (par exemple,
Office365).
 Une fois à l'écran de connexion, renseignez le nom d'utilisateur en laissant le champ du mot
de passe vide. Ensuite, appuyez sur TAB ou ENTER.

PASS-THE-HASH - ATTAQUER ADFS:

Au 4ième jour, le pass-the-hash a été longuement discuté. Cependant, il ne peut pas être utilisé
uniquement pour accéder aux systèmes avec un hachage d'administrateur. Une application Web
basée sur NTLM peut également être ciblée à l'aide d'une attaque PtH avec le hachage d'un
utilisateur normal ! Ceci est particulièrement utile en combinaison avec ADFS et WIA.

WIA est l'authentification intégrée de Windows et est activé dans les services de fédération Active
Directory (ADFS) pour les demandes d'authentification qui se produisent au sein du réseau interne de
l'organisation (intranet) pour toute application qui utilise un navigateur pour son authentification.
Plus d'informations sur ce concept sont disponibles ici :

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-
browser-wia

Étape 1 -Ajoutez le domaine cible à la zone Intranet local d'Internet Explorer. Ceci est nécessaire
pour déclencher l'authentification automatique via NTLM avec le hachage que nous avons fourni.

Les captures d'écran ci-dessus montrent les options Internet dans l'onglet Sécurité, qui abrite les
paramètres Intranet.

Lorsque vous cliquez sur « Sites », puis sur le bouton « Avancé » qui est visible dans la fenêtre qui
s'affiche, la liste des sites intranet s'affiche. Là, nous pouvons ajouter de nouveaux sites, ce que nous
voulons faire avec notre site Web cible pour nous assurer que l'authentification automatique est
déclenchée.

Sur la droite, les paramètres de connexion de l'utilisateur sont affichés, accessibles via le bouton
"Niveau personnalisé" dans les paramètres de l'intranet local.

Nous pouvons maintenant passer le hachage en utilisant Mimikatz dans une nouvelle invite de
commande. À partir de là, nous ouvrons Internet Explorer et naviguons jusqu'au site cible,
déclenchant une authentification automatique à l'aide de NTLM.

 Ouvrez Mimikatz, passez le hachage et ouvrez une nouvelle fenêtre CMD :

privilège :: débogage

sekurlsa::pth /user:<victime> /ntlm:<NThash> /domain:<domain> /run:cmd.exe

 Dans l'invite CMD, ouvrez Internet Explorer : "C:\Program Files\internet explorer\

iexplore.exe"
 Accédez à l'application que vous avez ajoutée à la zone Intranet, qui utilise ADFS pour
l'authentification.

Vous devriez maintenant avoir accès à l'application en tant qu'utilisateur victime, c'est-à-dire si
aucun 2FA n'est utilisé.

Des conseils supplémentaires sur PtH vers les applications Web authentifiées par NTLM sont
disponibles ici : https://labs.f-secure.com/blog/pth-attacks-against-ntlm-authenticated-web-
applications/

TOKEN FORGING-ATTAQUANT ADFS :

ADFS utilise l'authentification basée sur les revendications (qui contient des déclarations sur
l'identité d'un utilisateur), qui supprime la gestion de l'authentification de l'application. Les
revendications sont utilisées pour générer des jetons SAML, qui sont signés par le certificat de
signature de jetons ADFS.

Prérequis : La première étape doit être exécutée sur le serveur ADFS, sous le contexte du compte
de service ADFS ! Les droits d'administrateur de domaine ne suffisent pas dans ce cas, car la base de
données interne Windows (WID) utilisée pour stocker les données de configuration ADFS n'est
accessible qu'au compte de service ADFS.

L'étape 1 de l'attaque consiste à collecter toutes les informations nécessaires pour forger des
tokens :

 PFX crypté, qui contient le certificat de signature de jeton crypté sur la base du gestionnaire
de clés distribuées (DKM) de Microsoft.
 La clé DKM, qui peut être lue depuis l'AD et qui sert à déduire la clé AES pour le
déchiffrement du PFX.
 Une vue d'ensemble des applications fédérées configurées (parties utilisatrices) et de leurs
informations de configuration, telles que l'identifiant RP, l'algorithme de signature, le certificat de
chiffrement de jeton, les mles d'émission et les mles de contrôle d'accès.

Avec l'accès nécessaire au serveur ADFS et au compte de service, cette étape peut être exécutée à
l'aide de l'outil ADFSDump de Mandiant FireEye (écrit en C#) : https://github.com/fireeye/ADFSDump

Des informations supplémentaires sur l'utilisation de DKM pour ADFS sont disponibles ici :
https://msresource.wordpress.com/2016/05/04/the-use-of-distributed-key-manager-dkm-in-active-
directory fédération-services-ad-fs/
 Avec les informations collectées à l'étape 1, nous pouvons désormais générer des jetons signés
pour des utilisateurs arbitraires hors ligne, c'est-à-dire sans avoir besoin d'accéder au serveur ADFS.
L'outil ADFSSpoof Python (encore une fois par Mandiant FireEye) peut aider dans ce cas. Il a deux
caractéristiques principales :

 Déchiffrer PFX - Prend le PFX crypté de la base de données ADFS et la clé de déchiffrement
DKM d'AD (toutes deux récupérées à l'étape 1) pour produire une paire clé/certificat utilisable pour
la signature/falsification de jetons.
 Token Forging - Prend la clé de signature et le certificat pour produire un jeton de sécurité
signé qui peut être utilisé pour accéder à une application fédérée.

ADFSSpoof dispose de trois modules pour générer des jetons : 0365, DropBox et SAML. Les deux
premiers sont à utiliser avec 0365 et DropBox. Cependant, le module SAML peut générer un jeton de
sécurité SAML 2.0 générique pour s'authentifier auprès d'applications fédérées arbitraires qui
utilisent SAML 2.0.

Nous discuterons également des jetons SAML plus en détail dans la section suivante ! L'outil
ADFSSpoof peut être trouvé ici : https://github.com/fireeye/adfspoof

De plus, pour avoir un aperçu complet des techniques utilisées dans cette attaque, la présentation
ci-dessous devrait vous éclairer :

https://www.slideshare.net/DouglasBienstock/troopers-19-i-am-ad-fs-and-so-can-you

VII. APPLICATIONS ET AUTHENTIFICATION :

AZURE AD : APPLICATIONS D'ENTREPRISE :

L'un des principaux avantages d'Azure AD est son utilisation en tant que plate-forme
d'authentification centrale par diverses applications d'entreprise. Les types d'applications suivants
sont pris en charge avec Azure Active Directory :

 Applications Azure AD Gallery : Azure AD possède une galerie qui contient des milliers
d'applications qui ont été pré-intégrées pour l'authentification unique avec Azure AD. Certaines des
applications utilisées par votre organisation se trouvent probablement dans la galerie.
 Applications locales avec proxy d'application : avec le proxy d'application Azure AD, vous
pouvez intégrer vos applications Web locales à Azure AD pour prendre en charge l'authentification
unique. Dans une telle configuration, les utilisateurs finaux peuvent accéder à vos applications Web
sur site de la même manière qu'ils accèdent à Office 365 et à d'autres applications SaaS.
 Applications développées sur mesure : lors de la création de vos propres applications métier,
vous pouvez les intégrer à Azure AD pour prendre en charge l'authentification unique. En inscrivant
votre application auprès d'Azure AD, vous contrôlez la politique d'authentification de l'application.
  Applications hors galerie - Apportez vos propres applications ! Prenez en charge
l'authentification unique pour d'autres applications en les ajoutant à Azure AD. Vous pouvez intégrer
n'importe quel lien Web de votre choix, ou toute application qui affiche un champ de nom
d'utilisateur et de mot de passe, prend en charge les protocoles SAML ou OpenID Connect, ou prend
en charge SCIM.

Vous pouvez trouver des didacticiels, de la documentation et des concepts sur la page de
documentation officielle de Microsoft :
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/

AZURE AD : APPLICATIONS D'ENTREPRISE - PROTOCOLES D'AUTHENTIFICATION  :

Azure Active Directory pour les développeurs (vl.O) est un service d'identité basé sur le cloud
utilisant des protocoles standard pour l'authentification sans mot de passe. Ces protocoles peuvent
être utilisés pour fournir un accès délégué sécurisé à des applications tierces (Web). La plate-forme
d'identité Microsoft (v2.0) prend en charge les comptes Microsoft personnels ou personnels. La v2.0
est une évolution de la plateforme de développement Azure Active Directory (Azure AD) (vl.0). Dans
les plates-formes vl.O et v2.0, les protocoles d'authentification suivants sont couramment utilisés
pour fournir un accès délégué :

Fédération WS

• Utilisé pour les fonctionnalités d'authentification unique

• WS Federation est également utilisé par Microsoft ADFS

• L'authentification utilise un jeton de sécurité

• Limité à la plate-forme MS Identity vl.O

SAML2.0

• Utilisé pour les fonctionnalités d'authentification unique

• L'application Office 365 utilise SAML 2.0

• L'authentification utilise des jetons SAML pour valider l'accès

• Limité à la plate-forme MS Identity vl.O

Oauth 2.0

• Accès délégué aux applications tierces

• Axé sur l'autorisation (et non sur l'authentification)

• Utilise un jeton d'accès et des jetons d'actualisation pour valider l'accès

• Disponible dans la plate-forme MS Identity 1.0 et 2.0

Connexion OpenID

• Accès délégué aux applications tierces

• Extension sur OAuth 2.0

• Axé sur l'authentification (et non sur l'autorisation)

 • Utilise des jetons d'identification et des points de terminaison d'identité pour obtenir des
informations sur l'utilisation

• Disponible dans la plate-forme MS Identity 1.0 et 2.0

Dans les prochaines diapositives, nous allons approfondir et voir comment ces protocoles
fonctionnent.

AUTHENTIFICATION AZURE AD : PROTOCOLES D'AUTHENTIFICATION -WS-FEDERATION  :

WS-federation fournit un protocole transfrontalier qui permet l'authentification basée sur les
jetons. Il est basé sur la norme WS-trust OSASIS.

Le fournisseur de services, dans notre cas, est Azure AD, et le service de jeton de sécurité (ADFS
ou service de fédération Active Directory) doit avoir une relation d'approbation fédérée configurée
avant que les jetons de sécurité puissent être échangés et validés. WS-Trust et WS-Federation
fournissent un protocole pour créer un modèle de sécurité basé sur des jetons (revendications) ; il
n'applique pas le format du jeton, mais définit les mécanismes de requête/réponse du protocole :

1. Quel jeton envoyer

2. Ce qu'il faut inclure dans le jeton

3. Comment établir une confiance interfédérale

Toutes les spécifications techniques relatives à WS-Federation se trouvent dans la version 1.2 du
langage de fédération de services Web (WS-Federation).

Norme OASIS : http://docs.oasis-open.org/wsfed/federation/vl.2/os/ws-federation-l.2-spec-

os.html

AUTHENTIFICATION AZURE AD : PROTOCOLES D'AUTHENTIFICATION - SAML 2.0  :

 Le diagramme de protocole fourni par Microsoft décrit la séquence d'authentification unique dans
SAML 2.0.

Le service cloud (le fournisseur de services) utilise une liaison de redirection HTTP pour
transmettre un élément AuthnRequest (demande d'authentification) à Azure AD (le fournisseur
d'identité). Azure AD utilise ensuite une liaison de publication HTTP pour publier un élément
Response sur le service cloud. C'est l'étape 3 du schéma ci-dessus. AuthnRequest comprend les
champs obligatoires suivants :

 ID : Azure AD utilise cet attribut pour renseigner l'attribut InResponseTo de la réponse
renvoyée.
 Version : la version SAML utilisée
 Issuelnstant : il s'agit d'une chaîne DateTime avec une valeur UTC et un format aller-retour
(« o »). Azure AD attend une valeur DateTime de ce type, mais n'évalue ni n'utilise la valeur.
 L'élément Issuer dans un AuthnRequest doit correspondre exactement à l'un des
ServicePrincipalNames du service cloud dans Azure AD. En règle générale, il s'agit de l'URI de l'ID
d'application spécifié lors de l'enregistrement de l'application.
 L'élément RequestedAuthnContext spécifie les méthodes d'authentification souhaitées. Il est
facultatif dans les éléments AuthnRequest envoyés à Azure AD. Azure AD prend en charge les valeurs
AuthnContextClassRef telles que comme urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

Si l'utilisateur n'est pas connecté, Azure AD authentifie l'utilisateur et génère un jeton SAML
(étape 4 dans le schéma ci-dessus). Cela inclut la réponse Azure qui est fournie à l'application pour
valider les autorisations et l'identité de cet utilisateur. L'élément Response inclut le résultat de la
demande d'autorisation. Azure AD définit les valeurs ID, Version et Issuelnstant dans l'élément
Response. Il définit également les attributs suivants :

 Issuer (Emetteur) : Azure AD définit l'élément Issuer sur

https://login.microsoftonline.com/<TenantIDGUID>/ où <TenantIDGUID> est l'ID de locataire du
locataire Azure AD
 Status : l'élément Status indique le succès ou l'échec de la connexion. Il inclut l'élément
StatusCode, qui contient un code ou un ensemble de codes imbriqués qui représente l'état de la
demande
 Assertion : Ceci inclut l'Émetteur, la signature, le sujet et les conditions liées à la demande.
 Audience : contient un URI qui identifie une audience visée. Azure AD définit la valeur de cet
élément sur la valeur de l'élément Issuer de l'AuthnRequest qui a initié la connexion.
 AttributeStatement : contient des revendications sur le sujet ou l'utilisateur.
 AuthnStatement : cet élément affirme que le sujet de l'assertion a été authentifié par un
moyen particulier à un moment particulier. L'attribut Authnlnstant spécifie l'heure à laquelle
l'utilisateur s'est authentifié auprès d'Azure AD. L'élément AuthnContext spécifie le contexte
d'authentification utilisé pour authentifier l'utilisateur

Toute la documentation relative à l'utilisation de SAML2.0 pour l'authentification unique dans

Azure AD est disponible sur https://docs.microsoft.com/en-us/azure/active-directory/develop/single-
sign-on-saml-protocol.

Semblable à Single-Sign-On, Azure Active Directory (Azure AD) prend en charge le profil de
déconnexion unique du navigateur Web SAML 2.0. Pour que la déconnexion unique fonctionne
correctement, l'URL de déconnexion de l'application doit être explicitement enregistré auprès
d'Azure AD lors de l'enregistrement de l'application. Azure AD utilise LogoutURL pour rediriger les
utilisateurs une fois qu'ils sont déconnectés.

Le diagramme ci-dessus montre le flux de déconnexion dans Azure AD à l'aide de SAML 2.0.

Toute la documentation relative à l'utilisation de SAML2.0 pour Single-Sign-Out dans Azure AD est
disponible sur https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-out-
saml-protocol.

AZURE AD : PROTOCOLES D'AUTHENTIFICATION - OAUTH 2.0 :

OAuth 2.0 est une norme ouverte pour la délégation d'accès. Il est utilisé pour permettre à des
sites Web ou à des applications d'accéder à leurs informations sur d'autres sites Web, mais sans
échanger de mots de passe. En bref, OAuth 2.0 fournit un accès délégué sécurisé. OAuth 2.0 n'est pas
rétrocompatible avec OAuth 1.0. OAuth 2.0 fournit des flux d'autorisation spécifiques pour les
applications Web, les applications de bureau, les téléphones mobiles et les appareils intelligents.

Microsoft Azure AD prend en charge Oauth2.0 afin qu'Azure AD puisse être utilisé comme service
d'identité pour les applications Web, de bureau et mobiles. Sur la plupart des plateformes sociales ou
des organisations professionnelles, ce protocole est pris en charge pour fournir une authentification
et une autorisation transfrontalières.

La spécification OAuth 2.0 complète est disponible sur https://oauth.net/2/.

 Pour des raisons de sécurité, le flux OAuth 2.0 est généralement implémenté en tant que flux
d'autorisation, ce qui signifie que les canaux de communication sont divisés en un canal avant et un
canal arrière.

Dans une telle configuration, le jeton d'accès réel n'est jamais transféré via le canal frontal (pour
empêcher les attaques telles que l'homme dans le navigateur ou le reniflage de trafic). Le canal de
retour est en fait un canal protégé entre les serveurs d'autorisation et l'application elle-même. Le flux
global est organisé comme suit :

1. Un utilisateur demande l'accès à une application spécifique. Cela se fait en fournissant un URI
de redirection pour les communications par canal de retour, un type de réponse, un code et une
portée (informations nécessaires pour valider l’identité);
2. Le serveur d'autorisation demandera les autorisations nécessaires et, en fonction des
privilèges accordés, la demande sera acceptée ou refusée.
3. En cas d'autorisation d'accès, un code d'autorisation est transmis à l'application ;
4. Le code d'autorisation est ensuite échangé contre un jeton d'accès, généralement d'une
durée de vie de 1 heure. Dans le cadre de cette demande, nous pourrions également émettre un
jeton d'actualisation qui dure généralement plus longtemps (30 jours) ou même a une fenêtre
glissante (dans azur, il s'agit d'un maximum de 90 jours) ;
5. Une fois que l'application dispose d'un jeton d'accès valide, les informations requises et
définies dans le paramètre scope peuvent être demandées au serveur de ressources.

Si la durée de vie du jeton d'accès est expirée, l'application utilisera le jeton d'actualisation pour
obtenir un nouveau jeton d'accès. Si un attaquant peut obtenir le jeton d'accès valide, il aura les
mêmes privilèges que cette application, il est donc crucial de protéger les jetons d'accès et
d'actualisation.

Azure Active Directory (Azure AD) utilise OAuth 2.0 pour vous permettre d'autoriser l'accès aux
applications Web et aux API Web dans votre locataire Azure AD. Dans ce flux, les rôles suivants sont
présents :

 Azure Active Directory est le serveur d'autorisation et émet le code d'autorisation. Le client
utilisera ce code d'autorisation pour obtenir les access_token et refresh_token d'Azure AD.
 Les codes d'accès sont validés et l'accès aux données est accordé en fonction du jeton
d'accès.

La description complète d'OAuth2.0 de Microsoft est disponible sur :

https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow.

AZURE AD: PROTOCOLES D'AUTHENTIFICATION - OPENID CONNECT:

OpenID Connect est une couche d'identité utilisée par Azure Active Directory. Cette méthode est
une extension sur OAuth 2.0 et utilise des jetons d'accès pour accéder aux ressources protégées.
OpenID Connect est recommandé par Microsoft lors de la mise en œuvre de l'authentification dans
les applications Web accessibles via le navigateur.

Les aspects les plus importants pour nous liés à OpenID Connect sont les suivants :

 OpenID Connect est pour l'authentification, Oauth 2.0 est pour l'autorisation.
 OpenID Connect ajoute des points de terminaison Userlnfo et un ensemble standard
d'étendues à Oauth 2.0
 Génère un jeton d'identification (JWT) en combinaison avec un jeton d'accès. Le jeton JWT
encodé (JSON Web Tokens) contient des informations sur l'utilisateur.
 Implémentation standardisée avec Azure AD

Plus d'informations et de détails techniques peuvent être trouvés sur

https://openid.net/specs/openid-connect-core-l_0.html.

AZURE AD: PROTOCOLES D’AUTHENTIFICATION: OPENID CONNECT -JWT IDTOKEN:

OpenID Connect fonctionne avec des jetons d'identification. Ces jetons sont également appelés
jetons JWT et comprennent les sections suivantes :

 Token Header : Métadonnées pour le jeton et il contient au minimum le type de signature et

l'algorithme de chiffrement.
 Charge utile (réclamations) : dans le contexte de JWT, une réclamation peut être définie
comme une déclaration concernant une entité (généralement, l'utilisateur). La réclamation contient
les informations que nous souhaitons transmettre.
 Signature : la norme JWT suit la spécification JSON Web Signature (JWS) pour générer le
jeton signé final.

Comme vous pouvez le voir ci-dessus, le jeton est encodé en Base64 et les sections sont divisées
par un caractère.

Lorsque nous décodons la section de charge utile, nous pouvons voir que les informations sur
l'utilisateur sont incluses dans le jeton d'identification.

Ces informations peuvent être utilisées par l'application pour valider l'identité et permettre
l'accès à l'application. D'autres informations sur l'utilisateur peuvent être ajoutées, mais ce n'est
qu'un exemple par défaut.
 Alors, comment ce jeton est-il utilisé dans Azure AD ? Comme indiqué précédemment, Azure AD
utilise OpenID Connect pour vous permettre d'authentifier les applications d'entreprise. De plus,
Microsoft recommande l'utilisation d'OpenID lors du développement d'applications Web qui
utiliseront Azure AD pour l'authentification. Vous pouvez trouver le flux standard utilisé dans Azure
AD sur la diapositive ci-dessus :

Le flux est assez similaire au flux OAuth 2.0, sauf que ce flux est spécifique à l'authentification.
Comme OpenID connect est basé sur OAuth, le point de terminaison utilisé dans Azure AD est
/OAuth2/v2.0/authorize. Le flux est le suivant :

1. L'utilisateur accède à une application Web à laquelle il souhaite accéder et est dirigé vers le
point de terminaison « /authorize », où l'utilisateur est invité à entrer ses informations
d'identification ;
2. Si l'authentification réussit, l'utilisateur reçoit un jeton JWT ;
3. L'utilisateur est redirigé vers le serveur Web et transmet le jeton JWT ;
4. Le jeton JWT est validé par le serveur Web (clé publique-privée) et un cookie de session est
défini.

Pour certaines applications, le flux se termine ici. Cependant, de nombreuses applications doivent
non seulement connecter les utilisateurs, mais également accéder aux services Web au nom de ces
utilisateurs. Ce sont les prochaines étapes décrites dans le diagramme ci-dessus. Une documentation
complète est disponible sur https://docs.microsoft.com/en-us/azure/active-directory/develop/vl-
protocols-openid-connect-code.

VIII. STRATEGIES D'ATTAQUE DES APPLICATIONS :

ATTAQUE DE CONSENTEMENT ILLICITE – ABUS DES AUTORISATIONS DE L'APPLICATION  :

 Alors, comment pourrions-nous attaquer ces protocoles d'authentification par modem ? Tout
d'abord, il est important de noter que bon nombre de ces protocoles ont été conçus dans un souci de
sécurité et sont donc techniquement plutôt solides.

Ceci étant dit, ces protocoles d'authentification par modem exposent une surface d'attaque
entièrement nouvelle et intéressante ! Un bon aperçu des stratégies d'attaque d'Azure AD peut être
trouvé dans une présentation donnée par Sean Metcalf et Mark Morowczynski chez Blackhat : «
Attacking & Defending the Microsoft Cloud (Azure AD & Office 365) ».

Il est important de noter que l'utilisation (et l'abus) du cloud Microsoft n'est pas purement
théorique : APT-28 (Fancy Bear) a été observé en utilisant l’hameçonnage de jetons OAuth dans la
nature.

Un excellent outil qui facilite plusieurs de ces stratégies d'attaque est le "Office365 Attack
Toolkit", qui a été développé par MDSec !

Qu'est-ce que la boîte à outils d'attaque Office365  ?

La boîte à outils MDSec 0365 permet aux testeurs d'intrusion / Red Teamers d'effectuer un
hameçonnage par jeton d'authentification afin d'employer une variété de techniques d'attaque.
Certains des scénarios d'exploitation pris en charge par l'outil incluent :

 Extraction de mots-clés Outlook

 Extraction de mots-clés OneDrive/SharePoint
 Création de règles Outlook
 Porte dérobée de macro de document Word

Un autre outil intéressant développé dans cet espace est PwnAuth (FireEye) qui a été présenté
dans leur rapport d'abus OAuth intitulé "Shining a Light on OAuth Abuse".

Les références :

https://www.mdsec.co.uk/2019/07/introducing-the-office-365-attack-toolkit/

https://adsecurity.org/wp-content/uploads/2019/08/2019-blackhat-us-metcalf-morowczynski
attackinganddefendingthemicrosoftcloud.pdf

https://www.fireeye.com/blog/threat-research/2018/05/shining-a-light-on-oauth-abuse-with-
pwnauth.html

EWS CRACKER - CONTOURNEMENT MFA:

EWS signifie Exchange Web Services. Il s'agit d'un protocole basé sur SOAP utilisé pour la
planification des heures d'inactivité/occupation, qui est souvent exploité par des clients de
messagerie tiers. Il permet à un utilisateur de lire des e-mails, d'en envoyer et de tester des
informations d'identification.

Malheureusement, EWS ne prend en charge que l'authentification de base. Si vous disposez d'une
authentification multifacteur via un fournisseur tiers, tel que Ping, Duo ou Okta, EWS peut être utilisé
pour contourner MFA. Il peut également être utilisé pour contourner les solutions MDM.

EWS Crack est un script Python qui peut être utilisé pour attaquer EWS. Le code source complet
est disponible sur : https://github.com/mikesiegel/ews-crack.

De plus, un article intéressant sur son utilisation typique peut être trouvé sur
https://www.reddit.eom/r/netsec/comments/7qs6gb/ewscrack_byp_ss_2fa_and_mdm_in_office365
_using_ews/

SERVICE PRINCIPAL POUR L'ACCES PAR PORTE DEROBEE  :

Un principal de service est comme une identité de sécurité utilisée par des applications ou des
services pour accéder à des ressources Azure spécifiques. Vous pouvez le considérer comme une
identité d'utilisateur (nom d'utilisateur et mot de passe ou certificat) pour une application, qui peut
également avoir des privilèges dans Azure AD.

Prérequis : bien que n'importe quel utilisateur puisse créer et enregistrer des applications,
l'attribution de privilèges élevés nécessite des droits d'administrateur d'application.

La création d'un accès par porte dérobée à l'aide d'un principal de service est un processus assez
simple :

PowerZure a une fonction appelée "get-sps" pour récupérer les principaux de service.

De plus, les modules PowerShell permettent également de récupérer le SPN à l'aide de « Get-
AzureADServicePrincipal ».

https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/

https://www.synacktiv.com/posts/pentest/azure-ad-introduction-for-red-teamers.html

SERVICE PRINCIPAL HUNTING WITH ROADRECON :

Vous vous souvenez de Roadtools ? Cet outil que nous avons présenté précédemment fournit
également un aperçu simple des principaux de service et des rôles d'applications. Parfait pour
identifier rapidement les cibles potentielles.

DEMO - PORTE DEROBEE D'UN SERVICE PRINCIPAL :

 Passons en revue un petit enregistrement montrant une attaque utilisant un principal de service.
Voici les étapes exécutées dans la démo :

1. L'attaquant a compromis le compte de Carl Hooper et se connecte à l'aide de Connect-

AzureAD dans PowerShell
2. Récupérez le SPN SANSDemo699 en utilisant :

Get-AzureADServicePrincipal -fdter "DisplayName équiv. 'SANSDemo699"'

$SPN = Get-AzureADServicePrincipal -fdter "DisplayName équiv. 'SANSDemo699'"

La première commande affichera la sortie, tandis que la seconde stocke l'objet pour un traitement
ultérieur.

3. Récupérez les informations d'identification SPN pour voir si elles ont déjà été définies.

Get-AzureADServicePrincipalPasswordCredential -Objectld SSPN.Objectld

4. Lorsque nous essayons de le définir avec la commande ci-dessous, nous obtenons un accès
refusé :

New-AzureADServicePrincipalPasswordCredential -Objectld SSPN.Objectld -EndDate "01- 01-2022

12:00:00" -StartDate "13-08-2020 12:00:00" -Value

5. C'est parce que Carl ne dispose pas de droits suffisants. Notre initié malveillant est assez
amical pour ajouter Carl aux administrateurs d'application
6. Exécutez à nouveau l'étape 4, qui devrait fonctionner cette fois, et validez les informations
d'identification (comme à l'étape 3).
7. Même après avoir supprimé Carl des administrateurs de l'application, le mot de passe
attribué au SPN fonctionne comme une porte dérobée et nous pouvons l'utiliser pour nous
authentifier auprès de ROADtools.
8. Malheureusement, l'application que nous avons ciblée n'a pas non plus les droits nécessaires
pour interroger le domaine. Dommage !

Notez que l'application n'a même pas besoin d'être active pour que cette attaque fonctionne,
similaire à une attaque Kerberoast.
IX. REPONDEUR :
KERBEROS ET NTLMV2 :
Nous avons expliqué précédemment que Kerberos est le principal protocole
d'authentification dans un environnement de domaine Windows.

Cela signifie-t-il que NTLMv2 peut être désactivé ?

Tout d'abord, il est important de noter que Kerberos s'appuie sur les SPN (Service Principals
Names) pour l'authentification. Les noms de principal de service sont construits à l'aide de noms
d'hôte. Par défaut, cela signifie que chaque fois que des adresses IP sont utilisées (par exemple,
W192.168.10.10), Kerberos ne fonctionnera pas et le système reviendra à l'authentification NTLM. Il
s'agit d'un paramètre de stratégie de groupe qui peut être configuré, mais, par défaut, Kerberos ne
fonctionnera pas avec les adresses IP.
Certains logiciels plus anciens ne prennent pas en charge Kerberos et s'appuient (au mieux)
sur l'authentification NTLMv2. Cela inclut, par exemple, les systèmes non Windows qui interagissent
avec les domaines Windows AD.
En raison des problèmes mentionnés ci-dessus, NTLMv2 est rarement totalement désactivé
dans les environnements d'entreprise, et il reste une surface d'attaque très intéressante !

STRATEGIES D'ATTAQUE NTLMV2 :

Comment pourrions-nous attaquer NTLMv2 ? La conception du protocole défi-réponse

NTLMv2 nous fournit deux stratégies d'attaque principales :
 Reniflage d'un défi-réponse NTLMv2, après quoi nous pouvons lancer des attaques par force
brute hors ligne pour récupérer le mot de passe/hachage NT de l'utilisateur. Nous avons expliqué
comment les défis et les réponses NTLMv2 sont construits hier ; n'hésitez pas à jeter un autre coup
d'œil pour un rafraîchissement rapide.
 Relais d'une connexion SMB à l'aide de NTLMv2, obtenant ainsi l'accès à un système cible
**sans** connaître le mot de passe/hachage NT de l'utilisateur.
Nous discuterons en profondeur des deux stratégies d'attaque ! Notez que pour les deux
stratégies d'attaque, il serait utile pour l'attaquant d'inciter les victimes à se connecter à leurs
machines (car cela leur permettrait à la fois de renifler les connexions défi-réponse NTLMv2 ET relais
SMB). Comment pourrions-nous y parvenir...

COMMENT OBTENIR LE CHALLENGE/REPONSE NETNTLMV2  ?

Alors, comment puis-je faire en sorte qu'un système victime se connecte à ma machine ?
Entrez "Répondeur" ! Responder est le "meilleur ami du testeur d'intrusion" ! Il existe depuis
quelques années et s'est avéré être un outil très efficace.

Responder est un outil initialement développé par SpiderLabs (Laurent Gaffie). Il se

concentre principalement sur l'attaque de l'authentification NTLM. Le répondeur tente d'inciter les
victimes à s'authentifier, après quoi il collecte les réponses au défi NTLM(v2) qui peuvent être
réutilisées dans diverses attaques.

Alors comment atteint-il son objectif ? Responder s'appuie sur deux protocoles principaux
pour inciter les victimes à se connecter (et à s'authentifier) :

 NBT-NS (NetBIOS Name Server)

 LLMNR (Link-Local Multicast Name Resolution) est le successeur de NBT-NS (depuis Windows
Vista).

Les deux protocoles permettent aux hôtes d'un même sous-réseau de résoudre les noms
d'hôtes en envoyant des requêtes à l'adresse de multidiffusion (pensez à une fonctionnalité de type
ARP pour la résolution des noms d'hôtes). Qu'est ce qui pourrait aller mal ? Vous l'avez deviné  : tout
comme l'usurpation d'identité ARP, quelqu'un d'inattendu répondra aux demandes de résolution de
noms.

La dernière version de Responder est disponible ici : https://github.com/lgandx/Responder.

Dans la capture d'écran, nous pouvons voir Responder remplir ses enchères : il capture un
hachage défi/réponse NTLM(v2) à partir d'un système. Nous pouvons en déduire ce qui suit :

 L'adresse IP de la victime est 192.168.18.128

 Le nom d'utilisateur de la victime est SEC560STUDENT\clark
 Le répondeur a trompé la victime pour qu'elle se connecte en "empoisonnant" la résolution
du nom d'hôte "WINDOWSO1"

Une autre opportunité d'attaque intéressante à l'aide de Responder consiste à tirer parti des
"Paramètres de proxy de détection automatique". La détection automatique de proxy est une
fonctionnalité par laquelle un proxy Web est automatiquement identifié par le système ; cette
fonctionnalité est également appelée Web Proxy Auto-Discovery (WPAD). Lorsque la détection
automatique du proxy est activée, la classe WebProxy du système tente de localiser le script de
configuration du proxy en procédant comme suit :

1. La fonction Winlnet InternetQueryOption est utilisée pour localiser le script de configuration

proxy le plus récemment détecté par Internet Explorer ;
2. Si aucun script n'est trouvé, la classe WebProxy utilise DHCP pour localiser le script. Le
serveur DHCP peut être configuré pour répondre avec l'emplacement du script ou l'URL qui pointe
vers le script ;
 3. Au cas où DHCP ne fournirait pas l'emplacement du script, une requête DNS est envoyée
pour localiser un hôte avec « WPAD » comme nom d'hôte ou alias ;
4. Si tout ce qui précède ne renvoie pas de résultat, les paramètres configurés dans les
paramètres LAN d'Internet Explorer sont utilisés. Comme nous l'avons vu précédemment, Responder
fournira la réponse que l'hôte recherche ; il répondra à la demande de résolution "WPAD"
NBT-NS/LLMNR. Comme prévu, les hôtes qui récupèrent la résolution de nom vont maintenant
commencer à utiliser l'hôte du répondeur comme proxy Web. Il s'agit d'une attaque Man-in-the-
Middle assez efficace. Désormais, Responder peut aller plus loin. il peut être configuré pour forcer
l'authentification NTLM. Une fois appliqué, les hôtes utilisant Responder comme serveur proxy
incluront désormais leur authentification NTLM dans leurs demandes.

Au fil des ans, de nombreux autres moyens "créatifs" d'obtenir des défis/réponses NetNTLMv2
ont été décrits par divers chercheurs en sécurité. Tant de techniques existent, car il suffit de forcer
un système cible à charger une ressource externe avec Windows Single Sign-On (SSO).

Quelques favoris des fans incluent (mais ne sont pas limités à):

 Scanners de vulnérabilité exécutant des scans authentifiés (classiques). Lorsqu'ils sont

configurés pour analyser une plage IP entière, ces analyseurs tentent de s'authentifier auprès de tout
système de cette plage IP qui écoute sur le port 445.
 Incorporation d'une image distante (hébergée sur un partage SMB) dans un document Word.
Si la victime ouvre le document Word, les informations d'identification NetNTLMv2 nous sont
envoyées.
 Intégration d'une icône distante (hébergée sur un partage SMB) dans un partage de dossier
(fichier SCF). Si la victime ouvre le dossier, les informations d'identification NetNTLMv2 nous sont
envoyées.
 Intégration d'un partage SMB à une image dans le code source de l'application Web. Si la
victime visite le site Web, les informations d'identification NetNTLMv2 nous sont envoyées.

Référence :

https://osandamalith.com/2017/03/24/r)laces-of-interest-in-stealing-netntlm-hashes/

Lien court : redsiege.com/560/netntlm

NTLM ATTACK STRATEGY # I:OFFLINE BRUTE FORCE:

Alors, comment pouvons-nous maintenant utiliser ces défis et réponses NTLMv2 ? Comme
nous le verrons dans les prochaines slides, les relayer est un vecteur d'attaque intéressant ! Il y a
d'autres options, cependant. On pourrait également essayer de déduire le mot de passe en lançant
des attaques par dictionnaire ou par force brute contre la réponse au défi. Dans ce cas, nous
relèverions le défi et tenterions tous les mots de passe/hachages possibles pour calculer une réponse
identique à celle qui a été capturée. Lorsqu'il est trouvé, nous avons les informations d'identification
valides qui ont été saisies. Hashcat (un outil de craquage de hachage bien connu) a un support
intégré pour exécuter des attaques par dictionnaire et par force brute contre les réponses au défi
NTLMv2. La syntaxe de la ligne de commande ressemblerait à ceci : hashcat -m 5600 hash.txt
liste_mots de passe.txt -o fissuré.txt

 5600 est le type de hachage pour NetNTLMv2

 hash.txt contient le hachage à craquer
 password_list.txt est le fichier de dictionnaire contenant tous les mots de passe que nous
voulons essayer
 cracked.txt est l'endroit où nous voulons écrire notre sortie

STRATEGIE D'ATTAQUE NTLM # 2 : RELAIS SMB :

Le relais SMB est une attaque où nous relayons une tentative d'authentification NTLMv2 contre
notre machine vers un autre système afin d'obtenir un accès non autorisé à cette machine. Les cas
d'utilisation typiques incluent les scanners de vulnérabilité automatisés, les scripts créés par les
administrateurs... Alors, comment ça marche réellement ?

1. Dans un premier temps, nous devons leurrer une victime pour qu'elle tente de s'authentifier
contre notre machine "maléfique". Cela peut sembler difficile, mais il existe plusieurs façons d'y
parvenir. Nous examinerons quelques exemples dans les prochaines diapositives ;
2. La demande d'authentification reçue est transmise par nos soins à la cible réelle (par
exemple, un serveur Windows) ;
3. Le serveur Windows (cible) nous répond par un challenge d'authentification ;
4. Nous transmettons la demande d'authentification à la victime ;
5. La victime calcule une réponse à partir de ses identifiants qui nous sont transmis ;
6. Nous transmettons la réponse au serveur Windows ;
7. Si autorisé, le serveur Windows cible nous accorde l'authentification ;
8. Afin de "boucler la boucle", nous transmettons un message "échec d'authentification" à la
victime.

Pour des raisons de simplicité, nous avons omis un éventuel environnement "basé sur un
domaine" dans le schéma ci-dessus (le serveur Windows effectue une authentification locale). Dans
un environnement basé sur un domaine, le serveur Windows transfère le défi et la réponse à un
contrôleur de domaine.

STRATEGIE D'ATTAQUE NTLM N° 2 : RELAIS SMB AVEC RESPONDER  :

 Pour un effet maximal, nous pourrions combiner Responder avec l'attaque de relais SMB ! La
demande d'authentification initiale requise par l'attaque de relais SMB pourrait être obtenue par les
capacités de résolution multidiffusion de Responder (en utilisant NBT-NS ou LLMNR) ! Considérez le
flux d'attaque suivant :

1. Le poste de travail victime tente de résoudre un nom de domaine via NBT-NS ou LLMNR, car
le nom de domaine demandé n'a pas d'entrée DNS (par exemple, parce qu'il a fait une faute de
frappe : "FILESEERVER" au lieu de "FILESERVER ») ;
2. Nous utilisons Responder pour répondre à la demande de résolution multicast ;
3. La victime tente de s'authentifier auprès de nous ;
4. La demande d'authentification reçue est transmise par nos soins à la cible réelle (par
exemple, un serveur Windows) ;
5. Le serveur Windows (cible) nous répond par un challenge d'authentification ;
6. Nous transmettons la demande d'authentification à la victime ;
7. La victime calcule une réponse à partir de ses identifiants qui nous sont transmis ;
8. Nous transmettons la réponse au serveur Windows ;
9. Si autorisé, le serveur Windows cible nous accorde l'authentification ;
10. Afin de "boucler la boucle", nous transmettons un message "échec d'authentification" à la
victime.

ATTAQUES DE REPONDEUR : COMPRENDRE LES DEFENSES :

Les stratégies d'attaque décrites ci-dessus peuvent être défendues, mais les contrôles de
sécurité requis ne sont pas des "gains rapides" et ne sont donc généralement pas correctement
configurés :

 NBT-NS et LLMNR peuvent être désactivés via des stratégies de groupe. Lorsque cette option
est désactivée, les attaques de type répondeur qui visent à inciter les victimes à s'authentifier
échouent.
 La signature SMB empêchera les attaques de relais NTLM à l'aide de SMB. La signature SMB
est activée par défaut uniquement sur les contrôleurs de domaine Windows, mais peut également
être activée sur d'autres systèmes. En tant que petite mise en garde/avertissement : plusieurs
rapports indiquent que la signature SMB entraînera une réduction des performances (transfert de
fichiers) pouvant atteindre 15 %. De plus, cela pourrait rompre la compatibilité avec des logiciels
tiers : McAfee indique dans sa base de connaissances interne que la signature SMB doit être
désactivée si l'authentification NTLM doit être utilisée.
 Lorsqu'il existe une entrée DNS WPAD qui pointe réellement vers le serveur proxy
d'entreprise. Alternativement, une entreprise peut également désactiver les "Paramètres de proxy
de détection automatique" dans le navigateur.
 D'un point de vue architectural, l'isolation des clients à l'aide, par exemple, de VLAN privés
serait également un moyen efficace de gêner Responder. Dans un tel scénario, si nous nous
connectons au réseau, nous ne pourrions pas communiquer avec d'autres postes de travail (cela nous
évite de solliciter des hachages).
Please work on the lab exercise Lab 5.5: Responder

X. BLOODHOUND : LIMIER CHIEN DE CHASSE :

COMMENT SAVOIR OU VOLER DES INFORMATIONS D'IDENTIFICATION  ?

En raison de sa taille et de sa complexité, il est souvent difficile pour les administrateurs de

conserver une bonne vue d'ensemble de la manière dont les privilèges sont attribués dans
l'environnement. Nous pouvons en tirer parti pour repérer les privilèges excessifs, qui peuvent être
utilisés dans les mouvements latéraux...

Une fois que les privilèges d'administrateur (limités) sont obtenus (par exemple, sur tous les
postes de travail mais pas sur les serveurs), nous pouvons commencer à sauter d'un système à l'autre
pour tenter de voler les informations d'identification de différents sauts, augmentant ainsi les
privilèges au fur et à mesure. Un exemple serait un administrateur de domaine qui est authentifié
auprès de l'un des postes de travail sous notre contrôle. Nous pourrions aller sur ce poste de travail
et vider les informations d'identification de la mémoire à l'aide de Mimikatz.

Un outil qui facilite cette attaque est BloodHoundAD, qui génère un diagramme des sessions
actives et des relations dans l'annuaire actif. Sur la diapositive ci-dessus, nous pouvons voir un
exemple d'un tel diagramme. En quelques étapes, Erik pourrait facilement voler les hachages de Tim,
obtenant ainsi les privilèges d'administrateur de domaine.
 BLOODHOUND EN ACTION: INGESTION VIA SHARPHOUND

BloodHound a deux options principales pour collecter ses données, toutes deux via l'ingestor
officiel appelé SharpHound. Ce programme C # se présente sous la forme d'un binaire pré-compilé ou
d'un script PowerShell. Selon vos besoins, plusieurs paramètres et méthodes de collecte de données
sont disponibles. Certaines méthodes de collecte courantes incluent :

 Par défaut : inclut l'appartenance au groupe de sécurité Active Directory, les approbations de
domaine, les autorisations abusives sur les objets AD, l'arborescence OU, les liens de stratégie de
groupe, les propriétés d'objet AD les plus pertinentes, les groupes locaux des systèmes Windows
joints au domaine et les sessions utilisateur.
 Tout : exécute toutes les méthodes de collecte à l'exception de GPOLocalGroup.
 DCOnly : collecte uniquement les données liées à AD à partir des contrôleurs de domaine
 ComputerOnly : collecte uniquement les sessions utilisateur et les groupes locaux à partir de
systèmes joints à un domaine (non-DC).

Plus d'informations peuvent être trouvées ici : https://github.com/BloodHoundAD/SharpHormd3

BLOODHOUND EN ACTION : REQUETES :

Une fois que BloodHound a ingéré des données (qui peuvent être collectées à l'aide de
différents outils), il peut commencer à créer des graphiques pour une analyse plus approfondie.
BloodHound fournit plusieurs outils de collecte de données (appelés ingestors). Un bon exemple est
Sharphound, qui est un ingestor C#, le principal ingestor à exécuter sur les systèmes Windows.

Vous pouvez développer vos propres requêtes ou utiliser l'une des nombreuses requêtes intégrées
facilement disponibles. Voici quelques exemples de requêtes disponibles :

 Trouver tous les administrateurs de domaine

 Trouver les chemins les plus courts vers les administrateurs de domaine
  Trouver des mandants avec des droits DCSync

L'un des plus intéressants (et des plus connus) est le "Trouver les chemins les plus courts vers les
administrateurs de domaine" !

BLOODHOUND EN ACTION : INTERFACE GRAPHIQUE :

Dans le graphique sur la diapositive, nous pouvons voir le résultat de l'une des requêtes.
BloodHound utilise une base de données neo4j pour stocker toutes les informations et les fournir
dans une interface Web visuelle pour analyse. Dans ce cas précis, un utilisateur a tenté de trouver le
chemin le plus court pour accéder à l'administrateur de domaine. Il semble qu'il y ait deux chemins
disponibles, qui peuvent être clairement vus dans le diagramme.

Dans une prochaine étape, nous allons maintenant nous authentifier sur l'une des premières
machines du graphique et tenter de voler les informations d'identification de l'utilisateur suivant
dans le chemin d'attaque. Notez que, dans ce cas précis, il n'y a que deux sauts d'ordinateur ; un
graphique réel d'un environnement d'entreprise semblera probablement plus complexe !

Please work on the lab exercise Lab 5.6: BloodHound

XI. ESCALADE DES PRIVILEGES ET UAC :

 DEFAUTS COURANTS D'ESCALADE DE PRIVILEGES WINDOWS  :

Même lorsque les environnements Windows sont configurés selon un principe de « moindre
privilège » et que le nombre de comptes administratifs est limité, un certain nombre de failles
courantes d'élévation des privilèges Windows pourraient éventuellement permettre à un utilisateur
non privilégié d'obtenir des privilèges administratifs. Les problèmes locaux d'élévation des privilèges
peuvent être causés par des logiciels obsolètes/non corrigés qui exposent le système d'exploitation
principal à des vulnérabilités. Le plus souvent, cependant, ils sont le résultat d'un certain nombre de
mauvaises configurations ou d'erreurs dont les adversaires peuvent abuser. Vous trouverez ci-
dessous une liste non exhaustive de certaines stratégies d'attaque couramment utilisées :

 Piratage de l'ordre de recherche de DLL

 Chemins sans guillemets avec espaces
 Exécutables de service Windows inscriptibles
 Clé de registre "AlwaysInstallElevated"
 Fichiers d'installation sans assistance
 Préférences de stratégie de groupe (environnements de domaine Windows 2008)

CHEMINS SANS GUILLEMETS AVEC ESPACES :

Les chemins sans guillemets avec des espaces peuvent être un problème sérieux dans les
configurations des services Windows. Analysons un exemple :

 L'image de gauche est une capture d'écran d'un service VMware Tools récent installé sur un
hôte Windows 10. Notez le chemin vers l'exécutable, qui est défini sur :

"C:\Program Files\Vmware\Vmware Tools\vmtoolsd.exe"

 L'image de droite est une capture d'écran d'un OpenVPN récent installé sur un hôte Windows
10. Notez le chemin vers l'exécutable, qui est défini sur :

C:\Program Files\OpenVPN\bin\openvpnserv.exe

Le service VMware Tools n'est clairement pas vulnérable au problème, car le chemin de
l'exécutable est correctement délimité à l'aide de guillemets. Le service OpenVPN, cependant,
soulève quelques questions... Pouvez-vous penser à comment nous pourrions en abuser ?

Si le chemin du service contient des espaces et n'est pas entouré de guillemets, alors
Windows doit deviner où trouver l'exécutable du service... Les espaces sur le CMD peuvent soit faire
partie du chemin du fichier, soit indiquer des arguments de ligne de commande !
 Alors regardons ce service OpenVPN... Windows essaie de démarrer ce service
"automatiquement" (donc au démarrage). Mais comment Windows essaie-t-il de démarrer le
service ? Il essaie bien sûr de charger le "chemin de l'exécutable". Mais comment est-il interprété ?
Étant donné l'espace dans le nom du chemin, il y a une ambiguïté ici :

OPTION 1 :

Logique : Windows considère l'espace à la fin du nom de fichier et suppose que tout ce qui
suit sont des arguments passés à cet exécutable.

Chemin du fichier : C:\Programme

Arguments : Fichiers\OpenVPN\bin\openvpnserv.exe

OPTION 2 :

Logique : La logique exceptée, Windows considère l'espace comme faisant partie du chemin
du fichier et trouve le bon exécutable.

Chemin du fichier : C:\Program Files\OpenVPN\bin\openvpnserv.exe

Arguments : <AUCUN>

Windows tentera d'abord l'option 1. Si nous pouvions ainsi écrire dans "C:\", nous pourrions
créer un programme appelé "Program.exe" qui serait ensuite exécuté avec les privilèges du service
Windows OpenVPN. Dans ce cas précis, il n'y a pas d'élévation de privilèges, car un utilisateur non
privilégié ne peut pas non plus écrire sur "C:\".

Une excellente ligne de commande pour trouver ces types de services sur notre propre
machine est ci-dessous (publié à l'origine par Danial Compton):

wmic service get name,displayname,pathname,startmode |findstr /I "Auto" | findstr /i /v "C:\

Windows\\" | findstr /i /v """

FICHIERS D'INSTALLATION SANS ASSISTANCE:

Les installations sans surveillance sont souvent utilisées dans les entreprises où il serait trop
long d'effectuer manuellement des déploiements à grande échelle. Si les administrateurs Windows
ne parviennent pas à nettoyer correctement après ce processus, un fichier XML appelé
"Unattend.xml" est laissé sur le système local. Un exemple d'un tel fichier est inclus à gauche !

Comme vous pouvez le voir, il inclut le mot de passe dans un format codé en base64, ce qui
signifie qu'il peut être très facilement décodé. Maintenant, où pouvez-vous trouver ces fichiers xml  ?
Cela dépend... Certains bons candidats à vérifier incluent :

 C:\Windows\Panthère\
 C:\Windows\Panther\Unattend\
  C:\Windows\System32
 C:\Windows\System32\sysprep\

PREFERENCES DE STRATEGIE DE GROUPE (GPP) :

Les GPP ont été utilisés pour permettre aux administrateurs de créer des stratégies de
domaine avec des informations d'identification intégrées. Ces stratégies permettaient aux
administrateurs, par exemple, de modifier des comptes locaux ou d'intégrer des informations
d'identification à des fins de mappage de lecteurs.

Bien que très utile, le mécanisme de stockage utilisé pour ces informations d'identification
n'est pas sécurisé : les GPP sont stockés dans des fichiers XML sur le partage SYSVOL (partage de
domaine Windows accessible à tous les utilisateurs du domaine) et le mot de passe est stocké chiffré
avec une clé AES connue de 32 octets ( il a été publié par Microsoft dans un article MSDN :

https://msdn.microsoft.com/en-us/librarv/cc422924.aspxl.

Bien que cette vulnérabilité ait été corrigée par Microsoft dans MS14-025, les GPP existants
avec des mots de passe n'ont pas été supprimés (cela doit être effectué manuellement...). Voyons
comment nous pouvons les trouver !

Afin de trouver ces mots de passe dans un environnement, vous pouvez exécuter ce qui suit
à partir de n'importe quelle session utilisateur authentifiée par domaine : C:\> findstr /S cpassword
%LOGONSERVER%\sysvol\*.xml

Cette commande d'une ligne recherchera la chaîne "cpassword" dans n'importe quel
fichier .xml sous le partage réseau sysvol accessible au public du contrôleur de domaine.

Les captures d'écran sur la diapositive fournissent un contexte supplémentaire :

 La première capture d'écran montre un fichier XML identifié avec une valeur cpassword
lorsqu'il serait ouvert à l'aide d'un éditeur de texte normal. Notez la valeur du "cpassword" ;
 En bas à gauche, on peut voir la clé de chiffrement utilisée par Microsoft, qui est publiée dans
un article MSDN ;
 Enfin, en bas à droite, on voit le module GPP Metasploit extraire et décrypter
automatiquement le mot de passe...
 A côté des modules Metasploit, plusieurs scripts PowerShell existent qui feront la même chose, ce
qui bien sûr réduit le taux de détection de tels outils.

OUTILS D'ESCALADE DE PRIVILEGES :

Afin de trouver des vulnérabilités dans un environnement, il existe trois outils très simples à
exécuter et à utiliser :

 BeRoot est un outil de post-exploitation pour vérifier les erreurs de configuration courantes
afin de trouver un moyen d'augmenter nos privilèges. Il fonctionne sous Windows, Linux et MacOS.
Le référentiel GitHub est disponible sur https://github.com/AlessandroZ/BeRoot
 Watson a été développé par le chercheur en sécurité RastaMouse ; c'est un outil .NET conçu
pour énumérer les bases de connaissances manquantes et suggérer des exploits pour les
vulnérabilités utiles d'escalade de privilèges. Watson est disponible à https://github.com/rasta-
mouse/Watson
 PowerUp est un script purement PowerShell qui utilisera les techniques mentionnées ci-
dessus (et bien plus encore) pour essayer d'élever les privilèges. PowerUp était auparavant un script
PowerShell autonome, mais il a maintenant été inclus dans le cadre de post-exploitation Empire
PowerShell.

UN MOT SUR LE CONTROLE DE COMPTE D'UTILISATEUR (UAC)  :

Microsoft a continué d'améliorer la sécurité de chaque version de Windows et, par

conséquent, a réduit la surface d'attaque du système d'exploitation. L'une des failles de sécurité les
plus courantes et les plus répandues a été l'octroi de privilèges d'administrateur à des utilisateurs par
ailleurs standard, souvent pour résoudre des problèmes d'application et de configuration.

Le contrôle de compte d'utilisateur (UAC) est un composant de sécurité qui permet aux
utilisateurs d'effectuer des tâches courantes en tant que non-administrateurs ou en tant
qu'administrateurs sans avoir à changer d'utilisateur, à se déconnecter ou à utiliser Exécuter en tant
que. Les comptes d'utilisateurs membres du groupe Administrateurs local exécutent la plupart des
applications en tant qu'utilisateur standard. En séparant les fonctions d'utilisateur et
d'administrateur, l'UAC aide les utilisateurs à évoluer vers l'utilisation des droits d'utilisateur
standard par défaut. Ainsi, si un utilisateur est connecté en tant qu'administrateur local, l'UAC
désactive les droits d'administrateur d'un utilisateur et invite l'utilisateur lorsque ses droits
d'administrateur sont requis. Si un utilisateur se connecte en tant qu'utilisateur standard, il est invité
à fournir les informations d'identification d'un compte administrateur s'il tente d'effectuer une tâche
nécessitant des droits d'administrateur.

En fin de compte, l'utilisateur a le contrôle sur le moment d'utiliser les privilèges

d'administrateur, car l'UAC n'a pas la possibilité d'être contrôlé via une politique centralisée.
 Par défaut, les utilisateurs standard et les administrateurs accèdent aux ressources et
exécutent les applications dans le contexte de sécurité des utilisateurs standard. Lorsqu'un utilisateur
se connecte à un ordinateur, le système crée un jeton d'accès pour cet utilisateur. Le jeton d'accès
contient des informations sur le niveau d'accès accordé à l'utilisateur, y compris des identificateurs
de sécurité spécifiques (SID) et des privilèges Windows. Avec le composant d'élévation UAC intégré,
les utilisateurs standard peuvent facilement effectuer une tâche administrative en saisissant des
informations d'identification valides pour un compte d'administrateur local. Le composant
d'élévation UAC intégré par défaut pour les utilisateurs standard est l'invite d'identification.

Lorsqu'un administrateur se connecte, deux jetons d'accès distincts sont créés pour
l'utilisateur : un jeton d'accès utilisateur standard et un jeton d'accès administrateur. Le jeton d'accès
utilisateur standard contient les mêmes informations spécifiques à l'utilisateur que le jeton d'accès
administrateur, mais les privilèges administratifs Windows et les SID sont supprimés. Le jeton d'accès
utilisateur standard est utilisé pour démarrer des applications qui n'effectuent pas de tâches
administratives (applications utilisateur standard). Le jeton d'accès utilisateur standard est ensuite
utilisé pour afficher le bureau (explorer.exe). Explorer.exe est le processus parent dont tous les
autres processus initiés par l'utilisateur héritent de leur jeton d'accès. Par conséquent, toutes les
applications s'exécutent en tant qu'utilisateur standard, sauf si un utilisateur fournit son
consentement ou ses informations d'identification pour approuver une application afin d'utiliser un
jeton d'accès administratif complet.

NIVEAUX UAC :

Contrairement à Windows Vista, où vous n'aviez que deux options - UAC activé ou désactivé -
dans Windows 7, 8 et 10, vous avez le choix entre quatre niveaux. Les différences entre eux sont les
suivantes :

• Élevé : toujours notifier. À ce niveau, vous êtes averti avant que les applications et les
utilisateurs n'apportent des modifications nécessitant des autorisations administratives. Lorsqu'une
invite UAC s'affiche, le bureau est grisé. Vous devez choisir Oui ou Non avant de pouvoir faire quoi
que ce soit d'autre sur l'ordinateur. Impact sur la sécurité : il s'agit du paramètre le plus sécurisé et le
plus intrusif également.

• Moyen : M'avertir uniquement lorsque des programmes/applications tentent d'apporter des

modifications à mon ordinateur. Il s'agit du niveau par défaut et l'UAC vous avertit uniquement avant
que les programmes n'effectuent des modifications nécessitant des autorisations administratives. Si
vous apportez manuellement des modifications à Windows, aucune invite UAC ne s'affiche. Ce niveau
est moins intrusif, car il n'empêche pas l'utilisateur d'apporter des modifications au système ; il
n'affiche des invites que si un l'application veut apporter des modifications. Lorsqu'une invite UAC
s'affiche, le bureau est grisé et vous devez choisir Oui ou Non avant de pouvoir faire quoi que ce soit
d'autre sur votre ordinateur. Impact sur la sécurité : ce paramètre est moins sécurisé que le premier
paramètre, car des programmes malveillants peuvent être créés pour simuler les frappes au clavier
ou les mouvements de la souris effectués par un utilisateur et modifier les paramètres de Windows.

• Faible : M'avertir uniquement lorsque des programmes/applications tentent d'apporter des

modifications à mon ordinateur (ne pas assombrir mon bureau) : ce niveau est identique à celui ci-
dessus, sauf que lorsqu'une invite UAC s'affiche, le bureau n'est pas estompé, et d'autres les
programmes sont capables d'interférer avec elle. Impact sur la sécurité : ce niveau est encore moins
sécurisé, car il permet aux programmes malveillants de simuler facilement des frappes au clavier ou
des mouvements de souris qui interfèrent avec l'invite UAC.

• Ne jamais notifier : à ce niveau, l'UAC est désactivé et n'offre aucune protection contre les
modifications non autorisées du système. Impact sur la sécurité : si vous ne disposez pas d'une bonne
solution de sécurité, vous risquez fort de rencontrer des problèmes de sécurité avec votre PC. Avec
UAC désactivé, il est beaucoup plus facile pour les programmes malveillants d'infecter votre
ordinateur et de prendre le contrôle.

TECHNIQUES DE CONTOURNEMENT UAC :

A côté de ces configurations "de haut niveau", les stratégies de groupe permettent une
configuration très fine de l'UAC. Il est important de noter que l'UAC peut généralement être
contourné :

 Sous Windows 7, sysprep.exe (utilisé pour configurer une installation Windows lors de
l'installation) est vulnérable à une vulnérabilité de détournement d'ordre de recherche DLL, qui est
exploitée par le module "bypassuac" du framework Metasploit (pour Windows 7)
 PowerShell Empire utilise plusieurs techniques UAC de contournement. Dans les
environnements Windows 10 renforcés (sans vulnérabilités), il générera une fenêtre UAC demandant
à l'utilisateur de "Permettre" une recherche légitime composant système d'obtenir des informations
d'identification d'administrateur (le taux de réussite dépend des paramètres UAC)
 Un outil intéressant qui essaie plus de 30 techniques de contournement UAC peut être
trouvé à https://github.com/hfirefOx/UACME

Please work on the lab exercise Lab 5.7: Privilege Escalation

XII. MESURES DEFENSIVES

FONDAMENTAUX - VERROUILLAGE INTELLIGENT:
 Le verrouillage intelligent est une fonctionnalité de protection d'Azure AD pour verrouiller les
adversaires qui tentent de forcer brutalement les mots de passe. Cette fonctionnalité peut
reconnaître les connexions provenant d'utilisateurs valides et les traiter différemment de celles
provenant de sources inconnues. Cette fonctionnalité est activée par défaut et propose les fonctions
intéressantes suivantes :
 Par défaut, le verrouillage intelligent verrouille le compte contre les tentatives de connexion
pendant une minute après 10 tentatives infructueuses. Le compte se verrouille à nouveau après
chaque tentative de connexion infructueuse, pendant une minute dans un premier temps et plus
longtemps lors des tentatives suivantes.
 Smart Lockout suit les trois derniers hachages de mots de passe incorrects pour éviter
d'incrémenter le compteur de verrouillage pour le même mot de passe. Si quelqu'un entre plusieurs
fois le même mauvais mot de passe, ce comportement n'entraînera pas le verrouillage du compte.
Cela peut être intégré à des déploiements hybrides, en utilisant la synchronisation de hachage de
mot de passe ou l'authentification directe pour protéger les comptes Active Directory sur site contre
le verrouillage par des attaquants.
 Chaque centre de données Azure Active Directory suit le verrouillage indépendamment. Un
utilisateur aura (seuil limite * nombre de centres de données) nombre de tentatives, si l'utilisateur
atteint chaque centre de données.
 Smart Lockout utilise un emplacement familier par rapport à un emplacement inconnu pour
faire la différence entre un mauvais acteur et l'utilisateur authentique. Les emplacements inconnus
et familiers auront tous deux des compteurs de verrouillage séparés.
 La fonctionnalité peut être utilisée pour interdire une liste personnalisée de mots de passe
faibles :
• La liste de mots de passe interdits personnalisés peut contenir jusqu'à 1000 termes.
• La liste des mots de passe interdits personnalisés est insensible à la casse.
• La liste de mots de passe interdits personnalisés prend en compte la substitution de caractères
courants. Exemple : "o" et "0" ou "a" et "@"
• La longueur de chaîne minimale est de 4 caractères et la longueur maximale est de 16
caractères.

Le verrouillage intelligent est toujours activé pour tous les clients Azure AD avec ces paramètres
par défaut qui offrent un mélange intéressant de sécurité et de convivialité. La personnalisation des
paramètres Smart Lockout, avec des valeurs spécifiques à votre organisation, nécessite des licences
Azure AD payantes pour vos utilisateurs.

Référence : https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-
password-smart-lockout

FONDAMENTAUX - PROTECTION PAR MOT DE PASSE :

 La protection par mot de passe Azure AD vous permet d'éliminer les mots de passe faciles à
deviner et de personnaliser les paramètres de verrouillage pour votre environnement. Son utilisation
peut réduire considérablement le risque d'être compromis par une attaque par pulvérisation de mot
de passe. Microsoft maintient et met à jour une liste de mots de passe faibles et vulnérables, mais en
tant que locataire propriétaire, vous pouvez également définir vos propres mots de passe incorrects.

La stratégie de mot de passe que vous définissez dans Azure peut également être
synchronisée avec votre annuaire local à l'aide du logiciel DC Agent de protection par mot de passe
Azure AD. Cet agent peut être trouvé sur https://www.microsoft.com/en-us/download/details.aspx?
id=57071

Pour plus d'informations et de détails, vous pouvez trouver un aperçu complet sur
https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad

ACCES CONDITIONNEL – INTRODUCTION :

L'accès conditionnel est l'outil utilisé par Azure Active Directory pour rassembler les signaux,
prendre des décisions et appliquer les politiques organisationnelles. Vous pouvez utiliser des signaux
d'identité dans le cadre de vos décisions de contrôle d'accès. Comme premier exemple, examinons
l'accès conditionnel pour protéger nos identités Azure Ad. L'accès conditionnel peut être activé dans
Azure AD si vous disposez d'une licence premium PI ou P2.

Les stratégies d'accès conditionnel, dans leur forme la plus simple, sont des instructions si-
alors : si un utilisateur souhaite accéder à une ressource, il doit effectuer une action. Exemple : Un
responsable du service d'assistance souhaite accéder à l'application du service d'assistance
informatique et doit effectuer une authentification multi facteur pour y accéder. Les politiques
d'accès conditionnel utilisent des signaux pour valider certains paramètres, les décisions d'autoriser
réellement l'accès à une application ou d'appliquer d'autres contrôles de sécurité, et ces politiques
d'accès conditionnel peuvent être appliquées dans différentes applications (par exemple, SharePoint
Online ou des applications sur site).

Quels sont les signaux typiques dans l'accès conditionnel ?

 Appartenance à un utilisateur ou à un groupe : par exemple, l'utilisateur est-il membre d'un

groupe privilégié ?
 Informations sur l'emplacement IP : peuvent être basées sur des adresses IP ou des plages
d'adresses IP de confiance spécifiques
 État et conformité de l'appareil : les appareils de plates-formes spécifiques ou marqués d'un
état spécifique peuvent être utilisés lors de l'application de l'accès conditionnel. Dans la plupart des
cas, l'état de conformité est vérifié avec Intune qui est le service MDM de Microsoft.
 Détails de l'application : les utilisateurs tentant d'accéder à des applications spécifiques
peuvent déclencher différentes politiques d'accès conditionnel.
 Détection des risques en temps réel et calculée : l'intégration des signaux avec Azure AD
Identity Protection permet aux stratégies d'accès conditionnel d'identifier les connexions à risque.
 Microsoft Cloud App Security (MCAS) : permet de surveiller et de contrôler en temps réel
l'accès aux applications et les sessions utilisateur

Quelles sont les décisions courantes avec l'accès conditionnel ?

 Bloquer l'accès
 Autoriser l'accès (Cependant, des contrôles supplémentaires peuvent être demandés) :
 Exiger une authentification multi facteur
 Exiger que l'appareil soit marqué comme conforme (l'état est validé par Intune)
 Exiger un appareil joint Azure AD hybride
 Exiger une application client approuvée

Documentation de référence Microsoft :

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

À titre d'exemple particulier, l'accès conditionnel pourrait être utilisé pour bloquer l'authentification
héritée : https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-
authentication

ACCES CONDITIONNEL - STRATEGIES COURAMMENT UTILISEES :

Certaines des politiques d'accès conditionnel les plus couramment utilisées incluent :

Exiger MFA pour les administrateurs  : Les comptes auxquels sont attribués des droits
d'administration sont souvent la cible d'attaquants. Exiger une authentification multi facteur réduit le
risque que ces comptes soient compromis.

Exiger MFA pour la gestion Azure  : Les outils de gestion Azure peuvent fournir un accès hautement
privilégié aux ressources, qui peuvent modifier les configurations à l'échelle de l'abonnement, les
paramètres de service et même la facturation de l'abonnement.

Accès conditionnel basé sur les risques  : Les organisations disposant d'Azure AD Premium P2 peuvent
créer des stratégies d'accès conditionnel qui exploitent les détections de risques d'Azure AD Identity
Protection (par exemple, forcer la réinitialisation d'un mot de passe pour les utilisateurs à haut
risque)

Bloquer l'accès par emplacement : Vous pouvez contrôler l'accès à vos applications cloud en fonction
de l'emplacement d'un utilisateur (cela peut inclure des plages d'adresses IP ou des pays/régions
entiers).
Notez que cette liste est limitée et que de nombreuses autres politiques peuvent être créées pour
sécuriser davantage votre service d'identité (par exemple, les applications critiques ne sont
accessibles qu'aux appareils appartenant à un domaine).

AUTHENTIFICATION MULTI FACTEUR :

Azure Multi-Factor Authentication (MFA) permet aux administrateurs de mieux protéger les
données et les applications par plusieurs facteurs requis avant d'autoriser l'authentification. Plusieurs
facteurs différents sont disponibles, en mettant l'accent sur l'équilibre entre convivialité et sécurité.

Quels types de « facteurs » sont disponibles ?

 Application Microsoft Authenticator : l'application Microsoft Authenticator fournit un niveau

de sécurité supplémentaire à votre compte professionnel ou scolaire Azure AD ou à votre compte
Microsoft. L'application Microsoft Authenticator est disponible pour Android, iOS et Windows Phone.
 Jetons matériels OATH : OATH est une norme ouverte qui spécifie comment les codes de mot
de passe à usage unique (OTP) sont générés. Azure AD prend en charge l'utilisation de jetons OATH-
TOTP SHA-1 de 30 ou 60 secondes.
 Message SMS : un SMS est envoyé au numéro de téléphone mobile lié à l'identité dans Azure
AD contenant un code de vérification. Entrez le code de vérification fourni dans l'interface de
connexion pour continuer.
 Appel vocal : un appel vocal automatisé est passé au numéro de téléphone que vous
fournissez. Répondez à l'appel et appuyez sur # sur le clavier du téléphone pour vous authentifier
 Mots de passe d'application : certaines applications autres que les navigateurs ne prennent
pas en charge l'authentification multi facteur. Si un utilisateur a été activé pour l'authentification
multi facteur et tente d'utiliser des applications autres que le navigateur, il ne peut pas s'authentifier.
Un mot de passe d'application permet aux utilisateurs de s'authentifier avec succès. Il est important
de noter, cependant, que lorsque l'authentification multi facteur est appliquée via des politiques
d'accès conditionnel, vous ne pouvez pas créer de mots de passe d'application. Ainsi, vous devrez
activer MFA par utilisateur.

Des informations supplémentaires sont disponibles via la page de documentation officielle de

Microsoft sur https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-
howitworks

API DE SECURITE MICROSOFT GRAPH :

Les grands environnements cloud sont basé sur des appels d'API REST, Microsoft a décidé de
créer une API de sécurité graphique centralisée. Partie intégrante de Microsoft Graph, l'API de
sécurité Microsoft Graph s'intègre aux solutions de sécurité de Microsoft et de ses partenaires dans
un modèle fédéré. Nous présenterons brièvement les concepts de base de l'API Microsoft Graph
Security.
Comment fonctionne l'API de sécurité Microsoft Graph ?

L'API Graph utilise les mêmes normes que celles décrites précédemment dans ce cours  : elles
partagent une infrastructure d'authentification commune basée sur OpenID Connect, OAuth 2.0 et
une API Web Representational State Transfer (REST) avec des formats de réponse JavaScript Object
Notation (JSON) standard. Si vous utilisez des applications personnalisées, vous devrez enregistrer
ces applications pour autoriser l'accès à l'API Microsoft Graph.

Discutons de certains scénarios courants publiés par Microsoft pour l'utilisation de l'API Microsoft
Graph :

 Rationalisez la gestion du cycle de vie des alertes pour la surveillance de la sécurité Un

analyste se connecte à une application de sécurité intégrée à l'API de sécurité Microsoft Graph.
L'analyste peut désormais afficher les alertes de sécurité de haute gravité provenant de différents
fournisseurs de sécurité.

Exemple d'appel REST :

GET https://graph.microsoft.com/vl.O/security/alerts?$filter=severity eq 'high’

 Création automatisée d'incidents de sécurité pour la surveillance de la sécurité / la réponse

aux incidents Intégrez votre système de billetterie existant avec les alertes de sécurité qui ont été
déclenchées dans Azure. Si un ticket est mis à jour dans votre système de ticket, ces informations
peuvent être transmises à l'API Microsoft Graph à l'aide d'appels REST.

Exemple d'appel REST :

PATCH https://graph.microsoft.com/vl.O/security/alerts/{alert id}

Content-type: application/json

{ "assignedTo": “ErikVanBuggenhout", "vendorlnformation": { "provider": "String",

"vendor": "String" } }

 Utiliser des services personnalisés de renseignements sur les menaces : Une menace a été
découverte; vous souhaitez télécharger des informations sur cette menace vers Azure. L'indicateur
de menace peut être envoyé/intégré à l'aide de l'API Microsoft Graph Security. La solution Microsoft
peut alors alerter l'organisation si le fichier est détecté.

Exemple d'appel REST :

POST beta/security/tilndicators/

Content-type: application/json

{ "action": "alert", "confidence": 0, "description": "MD5 hash on watch while system

vulnerabilities being addressed", "expirationDateTime": "2019- 03-01T21:43:37.5031462+00:00",

"externalld": "CUSTOM-MD5-Indicator", "fileHashType": "MD5", "fileHashValue":

"fe8a8226a4cfd0deffe209069a7e64d908b74de8", "severity": 0, "targetProduct": "Azure

Sentinel", "threatType": "WatchList", "tlpLevel": "green"}

 Gérez de manière proactive les risques de sécurité : En interrogeant l'entité de score sécurisé
de l'API de sécurité Microsoft Graph, l'organisation peut rapidement récupérer le score de sécurité
Microsoft résumé le plus récent. Par exemple, une liste peut être générée pour valider les
améliorations de sécurité qui ont un impact important sur les utilisateurs finaux.
Exemple d'appel REST:

GET /security/secureScoreControlProfiles?$filter=user!mpact eq 'High’

Une documentation supplémentaire sur l'API Microsoft Graph Security est disponible sur
https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWm9G4

CONTROLE D'ACCES BASE SUR LES ROLES AZURE (RBAC)  :

Azure Role Based Access Control a un lien fort avec Azure AD. Comme dans Azure, nous
pouvons définir plusieurs ressources telles que des conteneurs, des serveurs virtuels, des bases de
données et bien d'autres. Dans de nombreux cas, nous voyons que ces ressources sont gérées avec
un compte local ou intégré, cela rend la gestion des utilisateurs très complexe et augmente le risque
de compromission. L'accès basé sur les rôles activera Azure AD en tant que service d'identité pour
des ressources spécifiques.

Un principal de sécurité est un objet dans Azure AD qui représente un utilisateur, un groupe,
un principal de service ou une identité managée qui demande l'accès aux ressources Azure. Microsoft
fournit les définitions suivantes pour ces concepts :

 Utilisateur : une personne qui possède un profil dans Azure Active Directory. Vous pouvez
également attribuer des rôles aux utilisateurs d'autres locataires.
 Groupe : un ensemble d'utilisateurs créé dans Azure Active Directory. Lorsque vous attribuez
un rôle à un groupe, tous les utilisateurs de ce groupe ont ce rôle.
 Principal de service : identité de sécurité utilisée par des applications ou des services pour
accéder à des ressources Azure spécifiques. Vous pouvez le considérer comme une identité
d'utilisateur (nom d'utilisateur et mot de passe ou certificat) pour une application.
 Identité managée : une identité dans Azure Active Directory qui est automatiquement gérée
par Azure. Vous utilisez généralement des identités managées lors du développement d'applications
cloud pour gérer les informations d'identification pour l'authentification auprès des services Azure.

Définition du rôle, la liste suivante comporte quatre rôles intégrés fondamentaux :

 Propriétaire : a un accès complet à toutes les ressources, y compris le droit de déléguer

l'accès à d'autres.
 Contributeur : peut créer et gérer tous les types de ressources Azure, mais ne peut pas
accorder l'accès à d'autres.
 Lecteur : peut afficher les ressources Azure existantes.
 Administrateur d'accès utilisateur : vous permet de gérer l'accès des utilisateurs aux
ressources Azure.
 Champ d'application :

 Si vous attribuez le rôle Propriétaire à un utilisateur dans l'étendue du groupe

d'administration, cet utilisateur peut tout gérer dans tous les abonnements du groupe
d'administration.
 Si vous attribuez le rôle Lecteur à un groupe dans l'étendue de l'abonnement, les membres
de ce groupe peuvent afficher chaque groupe de ressources et chaque ressource de l'abonnement.
 Si vous attribuez le rôle Contributeur à une application au niveau du groupe de ressources,
elle peut gérer les ressources de tous les types dans ce groupe de ressources, mais pas les autres
groupes de ressources de l'abonnement.

IDENTITES MANAGEES AZURE – INTRODUCTION :

Un problème courant qui se produit sur site ainsi que dans le cloud est de savoir comment
gérer les informations d'identification dans les applications (par exemple, les informations
d'identification codées en dur). La sécurisation de ces informations d'identification est l'un des
principaux défis de la création d'applications cloud. Les identités gérées sont la solution de Microsoft
à ce problème. Vous pouvez utiliser l'identité pour vous authentifier auprès de n'importe quel service
qui prend en charge l'authentification Azure AD, y compris Key Vault, sans aucune information
d'identification dans votre code.

Nous pouvons faire une distinction entre deux types d'identité managée différents :

Identité gérée attribuée par le système  : Ce type d'identité est activé directement sur un système
spécifique. L'identité est également approuvée par l'abonnement de l'instance. Une fois créées, les
informations d'identification sont provisionnées sur l'instance.

Identité managée attribuée par l'utilisateur  : Ce type d'identité est créé en tant que ressource Azure
autonome. Azure crée une identité dans le locataire Azure AD qui est approuvée par l'abonnement
utilisé. Une fois créée, l'identité peut être attribuée à une ou plusieurs instances de service Azure.

Imaginez que vous ayez une application Web qui doit se connecter à un service de base de
données, "Azure SQL". Nous devrons d'abord accorder au serveur Web (identité attribuée par le
système) l'accès au serveur Azure SQL. Vous devrez également activer l'authentification Azure AD
pour le serveur SQL. Vous pouvez sélectionner « Identité gérée attribuée par le système ». Dans un
deuxième temps, vous devez créer un utilisateur dans la base de données qui représente l'identité
attribuée par le système du serveur Web.

Une fois l'utilisateur connu, vous pouvez obtenir un jeton d'accès à l'aide de l'identité
managée attribuée par le système de la machine virtuelle et l'utiliser pour appeler Azure SQL. Un
tutoriel complet sur cet exemple de scénario est décrit sur
https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/
tutorial-windows-vm-access-sql.

IDENTITES MANAGEES AZURE - COUP D'ŒIL SUR LES JETONS D'ACCES  :

 Cette diapositive vous donne un exemple de ce à quoi ressemble réellement le jeton d'accès
et de la manière dont les identités managées sont intégrées dans Azure.

Les étapes suivantes se produisent lorsqu'un service Azure spécifique doit valider si cette
identité particulière a accès à la ressource :

1. Toute ressource Azure peut demander au fournisseur d'identité géré local un jeton d'accès
pour l'identité d'une machine virtuelle spécifique ;
2. Le fournisseur d'identité renvoie le jeton d'accès pour l'identité managée de cette machine
virtuelle ;
3. Une fois validée, l'identité managée peut utiliser son autorisation, par exemple, pour
demander des secrets dans Azure Key Vault ;
4. Le coffre de clés Azure est compatible avec les identités managées et valide le jeton et les
autorisations. Si toutes les autorisations sont correctes, l'identité managée est en mesure de
récupérer les clés du coffre-fort Azure.

Score de sécurité d'identité :

Nous aimons tous un peu la concurrence, et Microsoft a intégré plusieurs mécanismes de

notation que vous pouvez utiliser pour vous comparer aux pairs de l'industrie. Le score de sécurité
des identités est disponible dans toutes les éditions d'Azure AD, cependant, certaines
recommandations nécessaires pour améliorer votre score ne sont disponibles qu'avec les licences
premium.

Toutes les 48 heures, Azure examine votre configuration de sécurité et compare vos
paramètres avec les meilleures pratiques recommandées. Sur la base du résultat de cette évaluation,
un nouveau score est calculé pour votre annuaire. Chaque recommandation est mesurée en fonction
de votre configuration Azure AD. Si vous utilisez des produits tiers supplémentaires à la place des
produits Microsoft pour "se conformer" aux bonnes pratiques, vous pouvez indiquer cette
configuration dans les paramètres d'une action d'amélioration.

Les recommandations typiques sont :

 Activer MFA
 Utiliser des rôles administratifs limités
 Activer des fonctionnalités supplémentaires telles que la politique de risque de connexion
 C'est un point de départ idéal pour valider votre exposition actuelle et élaborer un plan pour
améliorer encore vos mécanismes de gestion des identités et des accès.

AZURE AD IDENTITY PROTECTION-INTRODUCTION:

Azure AD Identity Protection aide à détecter les identités compromises en utilisant des
algorithmes d'apprentissage automatique et des heuristiques pour détecter les anomalies et les
incidents suspects. Il détecte les connexions à risque, crée des alertes exploitables et permet de
définir des politiques d'accès basées sur les risques.

Microsoft fournit les fonctionnalités de protection d'identité suivantes :

Vulnérabilités et comptes à risque : Détecte automatiquement les configurations non sécurisées en

fonction des meilleures pratiques de Microsoft et fournit des mesures d'atténuation exploitables.
Niveaux de risque calculés des connexions individuelles et des utilisateurs.

Détections de risques : Basé sur l'apprentissage automatique, la détection des anomalies et les
renseignements sur les menaces, Identity Protection signale les tentatives d'authentification
suspectes telles que les connexions à partir de services d'anonymisation IP connus ou
d'emplacements inconnus.

Accès conditionnel basé sur les risques : Définissez des politiques d'accès aux applications cloud en
utilisant Azure AD comme fournisseur d'identité en fonction des détections de risques. Des
conditions telles que la conformité des appareils, les emplacements ou les protocoles client peuvent
être utilisées pour accorder ou bloquer de manière granulaire l'accès à des applications cloud
sélectionnées

Référence :

https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview.

PROTECTION DE L'IDENTITE AZURE AD - TABLEAU DE BORD  :

Cette diapositive vous donne un exemple typique de tableau de bord Azure Identity, sur
lequel vous pouvez immédiatement identifier les détections de risques, les événements et les
vulnérabilités qui ont été trouvés dans cette configuration Azure AD.

PRESENTATION DE LA GESTION DES IDENTITES PRIVILEGIEES (PIM)  :

 Pour implémenter le principe du moindre privilège dans Azure AD, Privileged Identity
Management (PIM) peut être utilisé pour attribuer des privilèges administratifs à la demande, limités
dans le temps, lorsqu'ils sont approuvés par un flux de travail.

Dans PIM, les fonctionnalités suivantes sont disponibles (à partir de :

https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-
configure

 Fournir un accès privilégié juste à temps aux ressources Azure AD et Azure : cela limitera la
période pendant laquelle un compte privilégié est exposé (par exemple, une règle FW dynamique) ;
 Attribuez un accès limité dans le temps aux ressources en utilisant des dates de début et de
fin : cela limitera la période pendant laquelle un compte privilégié a accès ;
 Exiger une approbation pour activer les rôles privilégiés : vous pouvez créer vos propres flux
d'approbation au cas où un accès privilégié serait requis ;
 Appliquer l'authentification multi facteur pour activer n'importe quel rôle ;
 Utilisez la justification pour comprendre pourquoi les utilisateurs s'activent : vous pouvez
intégrer des messages dans votre flux et disposer d'une piste d'audit ;
 Recevez des notifications lorsque des rôles privilégiés sont activés : surveillez en permanence
l'utilisation des comptes à privilèges élevés ;
 Effectuer des examens d'accès pour s'assurer que les utilisateurs ont toujours besoin de
rôles ;
 Télécharger l'historique d'audit pour l'audit interne ou externe.

CONNEXION A AZURE AD :

Par défaut, Azure AD a la journalisation activée, la période de rétention dépend cependant

de votre licence.

Il est recommandé d'exporter ces journaux vers un compte de stockage Azure. Lorsque les
journaux sont exportés, vous pouvez définir votre propre période de conservation et, si un incident
s'est produit avant la période de conservation par défaut, vous pourrez analyser les événements plus
anciens via ce compte de stockage. Notez que vous ne pouvez pas exporter les journaux si vous
utilisez la licence gratuite Azure AD.

Les journaux suivants sont disponibles :

1. Journaux d'audit, qui incluent les détails suivants  :

 Date and time of the occurrence
 Service that logged the occurrence
 Category and name of the activity (what)
 Status of the activity (success or failure)
 Target
 Initiator / actor (who) of an activity
 2. Journaux de connexion, qui incluent les détails suivants  :
 Sign-in date
 Related user
 Application the user has signed in to
 Sign-in status
 Status of the risk detection
 Status of MFA requirement

UN EXEMPLE D'ENQUETE DE DETECTION DES RISQUES AZURE AD :

Dans Azure’s Identity Protection Risky Sign-In, nous pouvons enquêter davantage et trier les
tentatives d’authentification qui ont été signalées comme suspectes. Une enquête par un analyste
est nécessaire en raison du taux élevé de faux positifs et des options de réglage limitées disponibles.

Notez que l'aperçu initial fournit quelques informations prêtes :

 Adresse IP de la connexion : "185.153.179.23"

 Résultat de la tentative : "Échec"
 Raison du résultat : "L'utilisateur n'a pas réussi le défi MFA (non interactif)"
 L'application client : "Applications mobiles et clients de bureau"

Nous avons cependant besoin de quelques informations supplémentaires pour faire une évaluation
correcte !

En prenant du recul et en examinant toutes les connexions à risque, nous remarquons

immédiatement plusieurs échecs provenant de la même adresse IP à Vancouver (Colombie-
Britannique, Canada). Notre exemple d'organisation (NVISO) est européen sans présence au Canada,
donc, de telles tentatives sont en effet suspectes. Dans ce cas précis, nous pouvons identifier une
attaque par devinette de mot de passe.

UN EXEMPLE D'AUTHENTIFICATION HERITEE :

 En se référant à la présentation donnée par Sean Metcalf et Mark Morowczynski, il est bon
de noter que vous pouvez détecter les demandes de connexion d'authentification héritées dans les
journaux !

FONCTIONNALITES DE DETECTION AVANCEES -AZURE ATP :

Azure ATP vous permet de surveiller votre Azure AD pour les attaques avancées et intègre un
agent AATP installé sur votre contrôleur de domaine local. Azure ATP combine les événements
générés dans votre domaine local et les événements générés dans votre environnement Azure.

Reconnaissance : Identifiez les utilisateurs malhonnêtes et les tentatives des attaquants pour obtenir
des informations. Les attaquants recherchent des informations sur les noms d'utilisateur,
l'appartenance à un groupe d'utilisateurs, les adresses IP attribuées aux appareils, les ressources,
etc., en utilisant diverses méthodes.

Identifiants compromis : Identifiez les tentatives de compromission des informations d'identification

des utilisateurs à l'aide d'attaques bmte force, d'échecs d'authentification, de modifications
d'appartenance à un groupe d'utilisateurs et d'autres méthodes.

Mouvements latéraux : Détectez les tentatives de déplacement latéral à l'intérieur du réseau pour
mieux contrôler les utilisateurs sensibles, en utilisant des méthodes telles que Pass the Ticket, Pass
the Hash, Overpass the Hash, etc.

Dominance de domaine : Mise en évidence du comportement de l'attaquant si la domination du

domaine est atteinte, grâce à l'exécution de code à distance sur le contrôleur de domaine et à des
méthodes telles que DC Shadow, la réplication malveillante du contrôleur de domaine, les activités
Golden Ticket, etc.

Reference: https://docs.microsoft.com/en-us/azure-advanced-threat-protection.

CAPACITES DE DETECTION AVANCEES - AZURE SENTINEL  :

 Azure Sentinel est un SIEM « natif du cloud » proposé par Microsoft qui vise à remplacer les
solutions SIEM sur site typiques. Azure sentinel est basé sur des espaces de travail d'analyse de
journaux et des connecteurs de données, il examinera ces journaux et les mappera par rapport aux
cas d'utilisation (appelés "Analytics") qui sont activés. L'objectif principal est de fournir une solution
flexible qui peut facilement s'intégrer à la fois avec d'autres services cloud (tels qu'Azure AD) et des
ressources sur site (par exemple, les journaux de pare-feu locaux).

Vous trouverez plus d'informations sur Azure Sentinel sur

https://docs.microsoft.com/nl-nEazure/sentinel/overview.

AZURE SENTINEL - EXEMPLE DE REGLES :

Les cas d'utilisation sont définis dans la page d'analyse, les analyses sont utilisées pour
corréler les alertes aux incidents. Par défaut, Azure Sentinel a des règles de corrélation intégrées,
celles-ci peuvent être activées et utilisées pour votre environnement Azure. De nouvelles règles de
corrélation seront ajoutées fréquemment. Vous pouvez créer vos propres règles de corrélation et
essayer d'affiner le taux de détection pour minimiser les faux positifs. Pour la protection des
identités, vous avez les alertes de protection des identités Azure et bien d'autres.

CONCLUSION POUR 560.5 :

 Ce laboratoire met fin à notre session 560.5. Comme nous l'avons vu, les attaques Microsoft
Active Directory permettent à un testeur d'intrusion d'effectuer un mouvement latéral et d'accéder
plus profondément à une organisation cible et de mieux comprendre ses risques commerciaux. Les
environnements entièrement sur site se font rares. La plupart des organisations intègrent Azure AD
d'une manière ou d'une autre. Cette intégration ouvre cependant différents lieux d'attaque, souvent
similaires ou liés aux attaques de dominance de domaine qui sont déjà bien connues.

Notre prochaine section, 560.6, comprendra un laboratoire pratique d'une journée, dans
lequel vous ferez partie d'une équipe de test d'intrusion attaquant une organisation cible. Dans le
cadre de cet atelier de test d'intrusion, vous participerez à un événement Capturer le drapeau pour
démontrer les compétences que vous avez acquises dans les laboratoires tout au long du cours.