HoneyPot

AS-REP Roast

AS-REP Roast est une attaque ciblant les comptes avec pré-authentification désactivée dans Kerberos. Voici comment ça fonctionne :

  1. Ciblage : L'attaquant identifie les utilisateurs avec pré-authentification désactivée.

  2. Demande de TGT : L'attaquant envoie une requête au KDC pour obtenir un TGT, qui est délivré sans vérifier le mot de passe.

  3. Capture du TGT : Le TGT est chiffré avec la clé dérivée du mot de passe de l'utilisateur.

  4. Attaque hors ligne : L'attaquant capture le TGT et tente de le casser hors ligne pour récupérer le mot de passe en utilisant des outils comme Hashcat.

👉 Kerberos avec pré-authentification :

  • L'utilisateur doit prouver qu'il connaît son mot de passe en se connectant

  • Le KDC vérifie cette preuve avant de délivrer un TGT.

👉 Kerberos sans pré-authentification :

  • Le KDC délivre un TGT sans exiger de preuve du mot de passe.

  • Vulnérabilité : Les attaquants peuvent capturer le ticket et tenter de casser le mot de passe hors ligne, surtout si celui-ci est faible.

🍯 honeypot

Dans le cas d'un honeypot, un compte avec pré-authentification désactivée est utilisé comme appât. Ce compte a un mot de passe fort (plus de 100 caractères) et déclenche une alerte si un TGT est demandé pour ce compte, car cela ne devrait venir que d'un attaquant.

Le compte en question doit être nommé "servicename" (ou un autre nom, sauf en cas de conflit). Son mot de passe sera généré aléatoirement lors du déploiement du script.

Pour détecter une attaque, il faut créer un compte "servicename" et surveiller l'événement 4768 (Demande de TGT), par l'utilisateur winlog_event_data_TargetUserName:servicename.

Source :

LogoAS_REP Roastinghackndo

Outil :

LogoGitHub - HarmJ0y/ASREPRoast: Project that retrieves crackable hashes from KRB5 AS-REP responses for users without kerberoast preauthentication enabled.GitHub
Pour aller plus loins .... ASRepCatcher

ASRepCatcher permet d'intercepter les messages AS-REP sans avoir besoin que les utilisateurs aient la pré-authentification désactivée – ce qui est une contrainte majeure dans des attaques traditionnelles comme ASREPRoast.

ARP est utilisé pour associer des adresses IP à des adresses MAC sur un réseau local. Lorsque l'attaquant réussit à empoisonner les tables ARP des machines ciblées, il peut intercepter, modifier ou rediriger le trafic réseau. Cela permet à l'attaquant d’effectuer des attaques de type man-in-the-middle (MITM).

ARP Spoofing

1. Table ARP

Chaque appareil sur un réseau maintient une table ARP qui associe les adresses IP aux adresses MAC. Exemple :

IP
MAC

192.168.1.50

00:11:22:33:44:55

192.168.1.100

66:77:88:99:AA:BB

2. Envoi de faux paquets ARP

L'attaquant envoie des paquets ARP falsifiés pour tromper les appareils du réseau. Par exemple, l'attaquant peut envoyer un paquet ARP qui dit :

192.168.1.50 --> 00:11:22:33:44:55  (adresse MAC de l'attaquant)

3. Effet sur les cibles

Le paquet ARP falsifié est accepté par les appareils du réseau, qui mettent à jour leur table ARP en associant l'adresse IP de la victime (ici, 192.168.1.50) à l'adresse MAC de l'attaquant (ici, 00:11:22:33:44:55).

L'attaquant devient un intermédiaire :

  • Intercepter les paquets envoyés par la victime.

  • Modifier les paquets (si l'attaquant le souhaite).

  • Les renvoyer à la machine d'origine (dans une attaque de type MITM - "Man in the Middle").

Processus ARP Spoofing dans ASREPCatcher

  1. Création de paquets ARP falsifiés : L'attaquant envoie des paquets ARP falsifiés sur le réseau pour associer l'adresse IP de la passerelle (ou du serveur Kerberos) à son adresse MAC. Par exemple :

  2. Mise à jour des tables ARP des victimes : Les cibles du réseau mettent à jour leur table ARP en croyant que l'adresse MAC de l'attaquant est l'adresse de la passerelle (ou du serveur Kerberos). Cela redirige tout le trafic destiné à la passerelle vers l'attaquant.

  3. Effet sur le trafic : Le trafic des victimes est désormais envoyé à l'attaquant au lieu de la passerelle. L'attaquant peut alors intervenir dans le flux des paquets, ce qui permet deux modes d'attaque dans ASREPCatcher :

  • Listen Mode : L'attaquant se contente de sniffer les paquets Kerberos sans interférer directement.

  • Relay Mode : L'attaquant joue un rôle d'intermédiaire, où il peut relayer et potentiellement manipuler les paquets pour exécuter une attaque de type MITM.

LogoGitHub - Yaxxine7/ASRepCatcher: Make everyone in your VLAN ASRep roastableGitHub

GPP Password (Group Policy Preferences)

1

🔑 Fonctionnement

Dans le cadre de l'administration d'un domaine Active Directory, Microsoft permet aux administrateurs de stocker des informations sensibles (comme des mots de passe) dans des fichiers XML dans les GPO (Group Policy Objects). Ces mots de passe sont chiffrés, mais la méthode de chiffrement utilisée était vulnérable, et la clé de chiffrement a été rendue publique par Microsoft.

2

🍯 honeypot

  • Un fichier XML factice est placé dans un dossier ressemblant à un GPO, avec des identifiants fictifs.

  • Première alerte : Lorsqu'un attaquant accède au fichier, une alerte est déclenchée.

  • Deuxième alerte : Si l'attaquant tente de se connecter avec ces identifiants fictifs, une autre alerte est générée.

3

🎯 Bonne pratiques

  • Éviter de stocker des mots de passe dans les GPO : Ne jamais utiliser les préférences de stratégie de groupe pour stocker des mots de passe.

  • Utiliser des solutions sécurisées comme Microsoft LAPS pour gérer les mots de passe des administrateurs locaux.

  • Sécuriser les contrôleurs de domaine et les partages réseau avec des contrôles d'accès stricts.

  • Activer la pré-authentification Kerberos pour empêcher l'accès aux mots de passe sans validation.

Kerberosting

Dans Active Directory, tout utilisateur peut demander un ticket de service (TGS) pour n’importe quel SPN enregistré, car le KDC ne vérifie pas les autorisations d'accès, il se contente de délivrer un ticket contenant les informations de l'utilisateur (PAC). La vérification des droits est déléguée au service cible. Cela permet à un attaquant de récupérer un ticket chiffré avec la clé du compte de service et de lancer une attaque par force brute pour tenter de découvrir son mot de passe.

Service Principal Names (SPN) - c'est l'identifiant d'un service (nom_du_service_et_nom-machine). Ces comptes de service sont souvent utilisés par des applications ou des serveurs.

La plupart des services utilisent des comptes machine (du type NOMDEMACHINE$) avec des mots de passe longs et aléatoires, donc ils ne sont pas vulnérables aux attaques par force brute. En revanche, les comptes de service avec des mots de passe choisis par des humains sont beaucoup plus vulnérables et constituent la cible principale des attaques Kerberoast.

Lister les comptes utilisateurs avec un ou plusieurs SPN :

LogoEmpire/data/module_source/credentials/Invoke-Kerberoast.ps1 at master · EmpireProject/EmpireGitHub

Exploitation

Le KDC fournit simplement un ST basé sur la demande d'un utilisateur authentifié avec un TGT valide. Cependant, l'autorisation (c'est-à-dire si l'utilisateur a réellement le droit d'utiliser un service) est gérée par le service cible après la réception du ticket.

Cette séparation entre authentification (qui est gérée par le KDC) et autorisation (qui est gérée par le service cible) peut être exploitée, notamment dans l'attaque Kerberoast, où un attaquant obtient des tickets pour des services auxquels il n'a pas accès, puis essaie de les casser hors ligne pour découvrir les mots de passe des comptes de service.

Fonctionnement

  1. Demande d'un Service Ticket (ST) :

    • L'attaquant, ayant un TGT valide, envoie une demande au Ticket Granting Service (TGS) du KDC pour obtenir un Service Ticket (ST) pour le SPN d'un service ciblé (ex : MSSQLSvc/dbserver.example.com).

  2. Récupération du Service Ticket (ST) :

    • Le TGS délivre un ST chiffré avec la clé secrète du compte de service. Ce ticket est intercepté par l'attaquant.

  3. Brute-force du Service Ticket (ST) :

    • L'attaquant tente de casser le ST hors ligne en utilisant des outils comme John the Ripper ou Hashcat, en testant des mots de passe possibles jusqu'à déchiffrer le ticket et retrouver le mot de passe du compte de service.

  4. Accès au service ciblé :

    • Une fois le mot de passe trouvé, l'attaquant utilise ce mot de passe pour se connecter au service (ex : serveur SQL) et obtenir un accès non autorisé aux données ou systèmes.

🍯 honeypot

  1. Création d'un compte de service factice :

    • Créez un compte utilisateur fictif (ex : sap2-service) avec un SPN associé (ex : MSSQLSvc/fake-service.example.com). Ce compte ne doit avoir aucune utilité réelle mais sera un appât.

    • Le mot de passe du compte sera fort (plus de 100 caractères) pour décourager l'attaque par brute-force.

  2. Configuration du honeypot :

    • Associez le compte fictif à un SPN pour un service (ex : base de données, serveur web).

    • Activez un mécanisme pour déclencher une alerte lorsqu'un Service Ticket (ST) est demandé pour ce compte. Cela peut se faire en surveillant les événements Windows Security Event 4768 (demande de TGT) et 4769 (demande de Service Ticket).

  3. Alertes en cas d'exploitation :

    • Première alerte : Lorsque l'attaquant tente d'obtenir un ST pour le compte factice, une alerte est déclenchée.

    • Deuxième alerte : Si l'attaquant tente de casser le ST ou d'utiliser le ticket pour s'authentifier, une autre alerte est générée indiquant que le honeypot a été compromis.

Remédiation

  • Éviter les SPN sur des comptes utilisateurs : Ne pas associer des SPN à des comptes utilisateurs. Utilisez des comptes d'ordinateurs ou des comptes de service gérés (MSA) pour les services (mdp aléatoire).

  • Utiliser des comptes de service gérés (MSA) : Les MSA ont des mots de passe générés aléatoirement et changés automatiquement, rendant l'attaque par brute-force beaucoup plus difficile.

  • Limiter les SPN aux services nécessaires : Ne déployez des SPN que pour les services qui en ont besoin, réduisant ainsi la surface d'attaque.

DNS Posioning

Dans un environnement Windows, lorsqu’une machine ne parvient pas à résoudre un nom de domaine via DNS, elle se rabat automatiquement sur des protocoles de résolution alternatifs :

  • mDNS (Multicast DNS)

  • LLMNR (Link-Local Multicast Name Resolution)

  • NBNS (NetBIOS Name Service)

Ces protocoles utilisent le multicast ou broadcast, ce qui signifie que toutes les machines du même réseau local (vLAN) peuvent voir les requêtes... et répondre.

Cela crée une vulnérabilité : un attaquant peut intercepter ces requêtes et répondre avec une fausse adresse IP, une technique connue sous le nom de DNS poisoning (empoisonnement DNS). Cela permet notamment de détourner du trafic ou de récupérer des identifiants.

🛡️ Mécanisme de détection

Un script de surveillance envoie régulièrement (toutes les 90 secondes) une requête LLMNR et NBNS avec un nom de domaine généré aléatoirement, par exemple g73hsd8.local. Ce nom étant fictif, aucune machine légitime ne devrait y répondre.

✅ Si aucune réponse : comportement normal. ⚠️ Si une réponse est reçue : une machine sur le réseau tente probablement d’intercepter le trafic → déclenchement d’une alerte de sécurité envoyée au SIEM.

🔁 Exemple — Ce qui se passe :

  1. La machine A demande l’IP de g73hsd8.local en DNS → Échec.

  2. Windows émet alors une requête LLMNR ou NBNS :

    "Hey, est-ce que quelqu’un sur le réseau connaît g73hsd8.local ?"

  3. Toutes les machines voisines voient cette requête.

🧨 L’attaque :

Une machine contrôlée par l’attaquant (machine B) voit cette requête et répond : 👉 "Oui, moi je suis g73hsd8.local, voici mon IP."

Le poste A croit parler à une machine légitime, mais communique en réalité avec l’attaquant.

LSASS DUMP

LSASS (Local Security Authority Subsystem Service) est le processus Windows chargé de :

  • Vérifier les identités des utilisateurs (login local et domaine)

  • Gérer les changements de mot de passe

  • Créer les jetons d’accès (access tokens)

  • Enregistrer les événements de sécurité dans le journal Windows

Au démarrage, la machine crée en mémoire deux comptes fictifs Domain_Admin_<rnd> et Support_<rnd> dans LSASS, puis enregistre ces chaînes via une requête DNS OPT. Lorsqu’un attaquant dump LSASS (MITRE T1003.001) et tente d’utiliser l’un de ces comptes, l’audit LSASS le détecte et lève une alerte. En corrélant l’alerte avec la requête DNS (même hôte = faux positif, hôte différent = attaque réelle), on identifie rapidement un credential dumping sans impacter les utilisateurs légitimes.

Responder

Quand un utilisateur ou un service tente d’accéder à un nom d’hôte inexistant (ex. : domaine-controller.local) :

  1. Le système essaie d’abord via DNS. Si cela échoue :

  2. Il tente ensuite de résoudre le nom via LLMNR (Link-Local Multicast Name Resolution) ou NetBIOS Name Service (NBT-NS), selon la configuration du réseau.

  3. Ces requêtes sont envoyées en sur le réseau local.

Un attaquant avec Responder à l'écoute sur le réseau intercepte ces requêtes et répond "oui, c’est moi ce nom", se faisant passer pour la machine ou le service demandé.

  1. Le poste client tente alors de s’authentifier auprès de l’attaquant avec ses identifiants Windows (NTLM hash).

  2. L’attaquant capture ces identifiants et peut ensuite :

    • Tenter de craquer le hash.

    • Faire une attaque "Pass-the-Hash".

PreviousAuthentificationNextPage

Last updated