AD CS Account Persistence
Il s'agit d'un bref résumé des chapitres sur la persistance de la machine de la recherche impressionnante de https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf
Comprendre le vol de crédential utilisateur actif avec des certificats - PERSIST1
Dans un scénario où un certificat permettant l'authentification de domaine peut être demandé par un utilisateur, un attaquant a l'opportunité de demander et voler ce certificat pour maintenir la persistance sur un réseau. Par défaut, le modèle Utilisateur dans Active Directory autorise de telles demandes, bien qu'elles puissent parfois être désactivées.
En utilisant un outil nommé Certify, on peut rechercher des certificats valides permettant un accès persistant :
Il est souligné que la puissance d'un certificat réside dans sa capacité à s'authentifier en tant qu'utilisateur auquel il appartient, indépendamment de tout changement de mot de passe, tant que le certificat reste valide.
Les certificats peuvent être demandés via une interface graphique en utilisant certmgr.msc ou en ligne de commande avec certreq.exe. Avec Certify, le processus de demande de certificat est simplifié comme suit :
Une fois la demande réussie, un certificat avec sa clé privée est généré au format .pem. Pour le convertir en fichier .pfx, utilisable sur les systèmes Windows, la commande suivante est utilisée :
Le fichier .pfx peut ensuite être téléchargé sur un système cible et utilisé avec un outil appelé Rubeus pour demander un Ticket Granting Ticket (TGT) pour l'utilisateur, prolongeant l'accès de l'attaquant aussi longtemps que le certificat est valide (généralement un an) :
Un avertissement important est partagé sur la façon dont cette technique, combinée à une autre méthode décrite dans la section THEFT5, permet à un attaquant d'obtenir de manière persistante le hachage NTLM d'un compte sans interagir avec le service sous-système d'autorité de sécurité locale (LSASS), et ce depuis un contexte non élevé, offrant ainsi une méthode plus discrète pour le vol de crédentials à long terme.
Obtention de la persistance sur la machine avec des certificats - PERSIST2
Une autre méthode implique l'inscription du compte machine d'un système compromis pour un certificat, en utilisant le modèle par défaut Machine qui autorise de telles actions. Si un attaquant obtient des privilèges élevés sur un système, il peut utiliser le compte SYSTEM pour demander des certificats, offrant ainsi une forme de persistance:
Cet accès permet à l'attaquant de s'authentifier auprès de Kerberos en tant que compte machine et d'utiliser S4U2Self pour obtenir des tickets de service Kerberos pour n'importe quel service sur l'hôte, accordant ainsi à l'attaquant un accès persistant à la machine.
Extension de la persistance via le renouvellement de certificats - PERSIST3
La méthode finale discutée implique de tirer parti de la validité et des périodes de renouvellement des modèles de certificats. En renouvelant un certificat avant son expiration, un attaquant peut maintenir l'authentification auprès de l'Active Directory sans avoir besoin d'inscriptions de tickets supplémentaires, ce qui pourrait laisser des traces sur le serveur d'Autorité de Certification (CA).
Cette approche permet une méthode de persistance étendue, réduisant le risque de détection grâce à moins d'interactions avec le serveur CA et en évitant la génération d'artefacts qui pourraient alerter les administrateurs de l'intrusion.
Dernière mise à jour