# 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 : 

{% embed url="<https://beta.hackndo.com/kerberos-asrep-roasting/>" %}

Outil :&#x20;

{% embed url="<https://github.com/HarmJ0y/ASREPRoast>" %}

<details>

<summary>Pour aller plus loins .... ASRepCatcher</summary>

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 :&#x20;

* **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.

</details>

{% embed url="<https://github.com/Yaxxine7/ASRepCatcher/tree/main>" %}

***

## GPP Password (Group Policy Preferences)

{% stepper %}
{% step %}

### 🔑 Fonctionnement&#x20;

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.
{% endstep %}

{% step %}

### 🍯 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.
  {% endstep %}

{% step %}
🎯 **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.
  {% endstep %}
  {% endstepper %}

***

## 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.

{% hint style="info" %}
&#x20;**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.
{% endhint %}

{% hint style="success" %}
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.
{% endhint %}

Lister les comptes utilisateurs avec un ou plusieurs [SPN](https://beta.hackndo.com/service-principal-name-spn) :&#x20;

{% embed url="<http://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1>" %}

## **Exploitation**&#x20;

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.

{% hint style="success" %}

## 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.
  {% endhint %}

***

### 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."

&#x20;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 [**broadcast/multicast** ](#user-content-fn-1)[^1]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é.

4. **Le poste client tente alors de s’authentifier** auprès de l’attaquant avec ses **identifiants Windows (NTLM hash)**.
5. L’attaquant capture ces identifiants et peut ensuite :
   * Tenter de **craquer le hash**.
   * Faire une **attaque "Pass-the-Hash"**.

[^1]: **Broadcast** : Envoie à tout le réseau (ex. 255.255.255.255).\
    **Multicast** : Envoie à un groupe ciblé (ex. LLMNR → 224.0.0.252).