Élévation de privilèges et domination du domaine

Un point d'appui est rarement l'objectif. Dans une mission AD, le but est généralement de démontrer un chemin vers le statut d'administrateur de domaine ou, plus précisément, vers le contrôle du niveau 0, c'est-à-dire des DC et de l'infrastructure d'identité.

L'élévation de privilèges dans AD enchaîne l'élévation locale, le vol d'identifiants et les erreurs de configuration de l'annuaire jusqu'à l'accès aux ressources les plus sensibles.

Depuis un interpréteur de commandes à faibles privilèges sur un hôte, vous devez généralement obtenir les droits SYSTEM locaux pour extraire les identifiants. Les vecteurs courants d'élévation locale comprennent :

• Chemins de service non entourés de guillemets et autorisations de service faibles.
• Binaires de service accessibles en écriture ou détournement de DLL.
• Stratégie MSI AlwaysInstallElevated.
• Usurpation de jeton, avec la famille Potato qui exploite SeImpersonatePrivilege.

Avec SYSTEM, vous extrayez les identifiants mis en cache et vous pivotez. Chaque nouvel identifiant peut ouvrir l'accès à de nouveaux hôtes et à des privilèges plus élevés.

La boucle est la suivante : extraire → identifier les cibles accessibles dans BloodHound → se déplacer latéralement → extraire à nouveau. Répétez jusqu'à ce qu'un identifiant privilégié apparaisse.

Les ACL mal configurées constituent une voie d'élévation fiable qui ne nécessite aucun exploit. Si vous contrôlez une identité disposant de droits sur un objet privilégié, vous pouvez vous accorder l'accès.

• ForceChangePassword sur un utilisateur vous permet de réinitialiser son mot de passe.
• GenericWrite sur un utilisateur vous permet de lui définir un SPN et d'effectuer un Kerberoasting dessus, ou de définir le RBCD.
• WriteDacl sur un groupe vous permet de vous y ajouter.
• AddMember sur un groupe privilégié constitue une élévation directe.

Les erreurs de configuration de la délégation permettent efficacement d'usurper l'identité d'utilisateurs à forte valeur.

• Délégation sans contrainte : forcez un DC à s'authentifier, avec PrinterBug ou PetitPotam, capturez son TGT, puis effectuez un DCSync.
• Délégation contrainte fondée sur les ressources : avec des droits d'écriture sur un ordinateur, ajoutez un compte contrôlé à son msDS-AllowedToActOnBehalfOfOtherIdentity et usurpez l'identité de n'importe quel utilisateur via S4U.

Les services de certificats Active Directory introduisent une élévation fondée sur les certificats. Des modèles mal configurés permettent à des utilisateurs faiblement privilégiés d'inscrire des certificats qui s'authentifient comme n'importe quelle identité.

• ESC1 : le modèle autorise un SAN fourni par le demandeur ainsi qu'un EKU d'authentification client.
• ESC8 : relais NTLM vers le point de terminaison d'inscription web.

Un certificat associé à un DA est durable et résiste aux réinitialisations de mots de passe.

Une fois que vous contrôlez une identité disposant des droits de réplication des modifications de l'annuaire, vous pouvez usurper l'identité d'un DC et extraire le hachage de n'importe quel compte, y compris celui de krbtgt, via le protocole de réplication standard. Aucun code n'est exécuté sur le DC.

Avec les hachages de krbtgt et de niveau DA, vous obtenez la domination. Les options de persistance comprennent :

• Ticket d'or : falsifier des TGT à partir du hachage krbtgt.
• DCShadow : enregistrer un DC pirate pour diffuser des modifications malveillantes dans l'annuaire.
• AdminSDHolder : installer une porte dérobée dans le modèle ACL réappliqué chaque heure aux groupes protégés.
• Persistance fondée sur les certificats via ADCS.

Les actions à fort impact génèrent des signaux détectables.

• DCSync depuis une adresse IP source qui n'est pas celle d'un DC : événement 4662 avec le GUID de réplication.
• Les outils de coercition déclenchent des authentifications anormales de comptes d'ordinateur.
• Modifications des ACL d'AdminSDHolder, signalées par l'événement 5136.
• Inscription anormale de certificats avec des SAN qui ne correspondent pas au demandeur.

Contenir la domination du domaine nécessite des défenses architecturales.

• Administration par niveaux stricte : les administrateurs du niveau 0 n'ouvrent une session que sur des hôtes du niveau 0.
• Restreignez les droits de réplication et vérifiez qui détient les droits DCSync.
• Renforcez les modèles ADCS, activez l'approbation des inscriptions et corrigez les voies liées à PetitPotam et aux relais.
• Corrigez les ACL d'AdminSDHolder et surveillez les modifications des groupes protégés.
• Préparez une procédure opérationnelle de double rotation de krbtgt.

Pour les constats de domination, documentez la chaîne d'attaque complète : chaque privilège obtenu, l'erreur de configuration qui l'a rendu possible et la correction minimale. Donnez la priorité aux mesures correctives qui interrompent la chaîne le plus tôt possible, par exemple la correction d'une voie ACL, plutôt qu'aux corrections ponctuelles.

Supprimez les tickets falsifiés, les délégations pirates et les certificats de test avant de clore la mission.

Validez votre compréhension de la domination du domaine.

Vous avez suivi le chemin qui mène du point d'appui initial au contrôle complet du domaine.

• L'élévation locale permet l'extraction d'identifiants ; BloodHound guide les pivots.
• Les erreurs de configuration des ACL, le détournement de la délégation et les voies ESC d'ADCS permettent une élévation sans exploit.
• DCSync extrait krbtgt ; les tickets d'or et AdminSDHolder assurent la persistance.
• La segmentation par niveaux, l'audit des droits de réplication et le renforcement d'ADCS interrompent la chaîne.

Le cours sur Active Directory et Kerberos est maintenant terminé.