Hybrid AD changer mot de passe pas assez pour arrêter les attaquants afin que la fenêtre d'exposition soit fermée

Lorsqu'une intrusion est détectée, Redémarrage du mot de passe C'est généralement le geste réfléchi et correct : rapide, visible et avec la promesse de couper l'accès de l'agresseur. Cependant, dans les environnements hybrides Windows / Active Directory, l'action n'élimine pas toujours instantanément tous les chemins d'authentification, et ce retard peut suffire à un adversaire pour maintenir ou restaurer sa présence.

Le problème a plusieurs visages: Windows conserve les hachages cache pour permettre une connexion non connectée, la synchronisation des hachages à Entre ID (Azure AD) n'est pas toujours immédiate et Kerberos utilise des tickets qui restent valables jusqu'à leur expiration. C'est-à-dire qu'après un changement de mot de passe, le hachage précédent peut coexister simultanément dans des machines déconnectées, des tickets Kerberos actifs et, en hybride, un hachage ancien non encore reproduit dans le cloud.

Du point de vue de la réponse incidente, cela a des implications pratiques: un attaquant qui a déjà capturé un hasch peut utiliser des techniques de type le pass-the-hash, continuer à utiliser les identifiants dans les paramètres déconnectés ou maintenir des sessions valides en utilisant des tickets. Les variantes les plus sérieuses, telles que les billets falsifiés (les billets dits Golden ou Silver), invalident directement l'efficacité d'un simple changement de mot de passe jusqu'à ce que ces composants critiques soient traités.

La bonne nouvelle est que beaucoup de ces vecteurs sont atténués par des mesures concrètes et ordonnées: isolat et désauthentification par la force des appareils commis - déconnecter du réseau, forcer la fermeture de session ou redémarrer et, si possible, purger les tickets Kerbero actifs sur l'équipement affecté -; deuxièmement, faire pivoter les identifiants critiques, y compris ceux des comptes de service avec privilèges; et troisièmement, effectuer un examen complet du répertoire pour détecter les permissions ou les ACL erronées, les nouveaux comptes, les SPD suspects ou les modifications à AdminSDHolder.

Il existe des mécanismes techniques qui aident à fermer la fenêtre d'exposition : forcer la synchronisation du mot de passe pour entrer dans l'ID (Azure AD Connect) ou activer les notifications de changement AD réduit le délai dans les environnements hybrides; et purger les tickets locaux avec les utilitaires natifs peut couper les sessions qui resteraient actives après la rotation des identifiants. Microsoft documente comment fonctionne la synchronisation du hash et comment forcer les synchronisations dans les environnements hybrides, informations utiles pour les équipes opérationnelles: https: / / learn.microsoft.com / azure / répertoire actif / hybride / how-to-connect-password-hash-synchronisation.

Pour les incidents plus graves où des tickets sont soupçonnés d'avoir été falsifiés, l'action la plus perturbatrice mais nécessaire est habituellement le redémarrage contrôlé du compte KRBTGT (généralement en deux étapes) pour invalider les TGT malveillantes. Cela nécessite une planification et des essais dans des environnements d'essai, et Microsoft offre des conseils techniques sur la procédure et ses risques: https: / / learn.microsoft.com / dépannage / windows-server / identity / reset-krbtgt-password.

Il ne faut pas oublier que la récupération n'est pas seulement technique : d'autres moyens doivent être recherchés pour permettre la réinscription sans mot de passe, tels que les délégations qui permettent la restauration des mots de passe, les permis persistants sur les ACL ou les comptes de haute droite qui n'ont pas été touchés. L'audit des changements récents dans les membres des groupes, des rôles ou des délégations privilégiés est aussi essentiel que la rotation des clefs.

Parallèlement, il convient de resserrer la surface pour rendre les futurs examens plus efficaces : imposer un MFA obligatoire à distance et pour les gestionnaires, réduire la base de compte avec des privilèges permanents, appliquer le principe du privilège minimum, et utiliser des solutions qui gèrent et alternent les mots de passe des comptes de service et les références locales (p. ex. LAPS ou autres gestionnaires secrets). La détection a autant d'importance que le confinement : en se basant sur les journaux d'authentification, les alertes de détection latérale et la télémétrie EDR/SIEM accélèrent l'identification des persistances.

Pour les équipes opérationnelles qui veulent des actions pratiques et ordonnées, je recommande d'abord de mettre en oeuvre un plan de confinement immédiat : isoler les systèmes touchés, forcer la session et redémarrer la fermeture, faire pivoter les références humaines et de service critiques, et lancer une synchronisation dirigée dans les environnements hybrides. Ensuite, effectuez une vérification détaillée de AD à la recherche de changements ACL, de nouveaux comptes avec des privilèges ou des modifications à AdminSDHolder, et documentez chaque étape pour la chaîne de garde et les leçons apprises.

Enfin, ne sous-estimez pas l'importance de la prévention et de l'exercice : des preuves régulières de réaction aux incidents, des simulations d'engagement de comptes privilégiés et le déploiement de contrôles tels que l'AMF sur toutes les voies critiques réduisent considérablement la dépendance à la réinitialisation des mots de passe comme seule défense. Pour mieux comprendre les techniques qui abusent des haches et des tickets, un bon résumé de la composante offensive est disponible dans la base de connaissances ATT & CK : https: / / attack.mitre.org / techniques / T1550 / 002 /.

Bref, un changement de mot de passe est nécessaire mais rarement suffisant. Une médiation efficace combine isolement, rotation des références correctes, invalidation des sessions et des tickets, vérification des permis et mesures préventives qui réduisent les possibilités de guichets à l'avenir.