Découvrir les voies d'attaque indirectes vers les contrôleurs de domaine virtualisés dans Azure

Au sein de Netwrix Security Research, nous aidions un client avec une évaluation Entra ID et savions qu'ils avaient déjà effectué un tiering AD sur site. Nous savions aussi qu'ils avaient des contrôleurs de domaine virtualisés dans Azure, mais il était difficile de savoir quel serveur Windows était réellement un DC. Nous avons découvert qu’Azure Run Command permet d’exécuter des commandes en tant que SYSTEM, nous l’avons donc utilisé pour faire de la reconnaissance et identifier les DC.

Tout ce qui est montré dans cet article (captures d’écran, noms des machines, noms d’utilisateur) provient d’un environnement de laboratoire que nous avons reconstruit par la suite pour démontrer la technique. Aucune donnée client n’est utilisée.

Pour contexte, la documentation de Microsoft décrit Run Command comme un moyen d'exécuter des scripts PowerShell dans une VM Windows via l'agent VM, principalement pour des tâches de gestion générale comme résoudre des problèmes d'accès ou de réseau sur une machine. Il ne vérifie pas le type de VM concernée. Il fonctionne tout aussi bien sur un contrôleur de domaine que sur n'importe quelle autre VM.

Nous avons décidé de coder un script PowerShell avec Claude qui nous permet d’exécuter une commande sur plusieurs machines Windows en même temps, au lieu de cliquer dans la console Exécuter la commande une VM à la fois. Il suffit d’avoir la permission Microsoft.Compute/virtualMachines/runCommand/action, incluse avec Virtual Machine Contributor ou plus.

L’astuce est d’exécuter chaque appel Invoke-AzVMRunCommand dans un ThreadJob au lieu du Start-Job habituel. Start-Job lance un nouveau processus PowerShell par VM et recharge le module Az à chaque fois, ce qui ralentit vite au-delà de quelques machines. ThreadJob tourne sur un thread dans le même processus, donc en lancer plusieurs à la fois coûte presque rien. Nous gardons une file de toutes les VM trouvées et la complétons jusqu’à un nombre fixe en cours d’exécution (20 par défaut). Nous remplissons une place dès qu’une se termine, sans attendre qu’un lot complet soit fini avant de commencer le suivant.

Voici à quoi ressemble l'exécution de whoami via le portail pour une machine à la fois :

Voici la même commande exécutée sur toutes les machines virtuelles de l’abonnement en une seule fois, via le script PowerShell :

Une fois cela en place, l’étape suivante était de trouver les DC. La vérification est simple : exécuter Get-Service NTDS sur chaque VM Windows en fonctionnement via Run Command. NTDS est le service qui gère la base de données AD DS, donc s’il est présent et actif, cette machine est un contrôleur de domaine.

Une machine virtuelle fonctionnait clairement, mais Run Command a échoué en tentant d’y accéder, tandis que toutes les autres machines virtuelles de l’abonnement répondaient correctement. Le nom seul était déjà un indice fort. L’échec de Run Command correspond exactement à ce que l’on attend d’un contrôleur de domaine bien sécurisé, avec des outils de sécurité renforcés qui gênent. Prendre cette erreur au pied de la lettre et continuer aurait signifié ne signaler aucun contrôleur de domaine dans l’abonnement.

Au lieu de se fier à l’erreur, nous avons interrogé AD directement. Toute VM jointe au domaine accessible par Run Command est utilisée pour interroger AD via LDAP. Aucun module Active Directory nécessaire, juste [adsisearcher], un accélérateur de type PowerShell intégré qui fonctionne déjà sur toute machine jointe au domaine.

La vérification est un bit userAccountControl appelé SERVER_TRUST_ACCOUNT, valeur 8192. AD ne le définit qu’une fois qu’un ordinateur est promu en DC. Nous avons ajouté deux vérifications supplémentaires : le groupe principal 516 (le groupe « Domain Controllers ») et un objet NTDS Settings correspondant dans la partition Configuration.

Une chose cependant : un nom d’hôte correspondant ne prouve pas à lui seul qu’il s’agit de cette VM, ni même qu’elle est dans Azure. Les noms changent, sont tronqués et parfois réutilisés. Nous vérifions donc d’abord l’IP, en résolvant le nom d’hôte du DC en une IP depuis l’intérieur du domaine et en la comparant à l’IP privée qu’Azure rapporte pour cette VM. Cette IP n’existe que si la machine fonctionne vraiment dans Azure, donc une correspondance là est aussi fiable que possible. Quand le DNS ne résout pas, nous revenons à la comparaison des noms d’hôte, bien que ce soit moins fiable car les noms peuvent changer de façons que les IP ne font pas.

Une fois que nous avons pu confirmer de manière fiable que la machine qui avait rencontré une erreur plus tôt était un contrôleur de domaine, la vraie question était qui pouvait exécuter des commandes arbitraires en tant que SYSTEM dessus, car ce type d'accès est de niveau Tier-0, point final. Ce n’est pas celui qui a Domain Admin ; le client avait déjà réglé cela avec leur hiérarchie. C’est celui qui a des permissions Azure sur cette VM spécifique, car Run Command ne tient pas compte de l’AD. Il ne considère que Azure RBAC.

Voici à quoi cela ressemble. Quelques utilisateurs apparaissent plusieurs fois (une ligne par rôle), aux côtés d’un groupe et de deux principaux de service, tous avec Owner ou Contributor quelque part dans la chaîne, la plupart hérités de l’abonnement plutôt qu’assignés directement sur la VM. Chacun d’eux peut invoquer Run Command contre un contrôleur de domaine et exécuter du code en tant que SYSTEM. Rien de tout cela n’a à voir avec qui est réellement dans les Domain Admins on-prem.

À ce stade, le script demande également si vous souhaitez générer un graphique de type BloodHound à partir de ces données pour visualiser quels principaux de sécurité ont un chemin, direct ou indirect, vers un contrôleur de domaine virtualisé dans Azure. Pour notre laboratoire, cela correspond à 12 principaux ayant un chemin vers le DC, la plupart hérités de l'abonnement plutôt qu'assignés directement à la VM. Cliquez sur un nœud et la barre latérale détaille exactement ce que c'est et comment il y est arrivé, y compris l'appartenance au groupe, donc un nœud Groupe affichant "3 membres" n'est pas qu'un simple décompte. Vous pouvez réellement voir qui s'y trouve.

Recommandation

Étiquetez vos contrôleurs de domaine dans Azure avec quelque chose comme Tier-0-OnPrem-AD sur la ressource VM. Cela semble évident, mais la plupart des environnements que nous avons vus ne le font pas, c’est pourquoi les identifier a demandé un vrai travail au lieu de simplement filtrer par étiquette. Une fois étiqueté, vous pouvez créer une politique : refuser les nouvelles attributions de Propriétaire ou de Contributeur sur tout ce qui porte cette étiquette, ou alerter en cas de changement.

Le marquage vous indique seulement ce qui se passe à l'avenir. Il ne corrige pas ce qui est déjà en place. Chaque environnement que nous avons examiné a accumulé des autorisations sur ces machines virtuelles au fil du temps, la plupart héritées du groupe de ressources ou de l’abonnement, pas attribuées directement. C’est justement pour cela que c’est facile à négliger.Passez en revue qui a actuellement accès et demandez, pour chaque personne et principal de service, s’ils ont encore besoin d’être Propriétaire ou Contributeur sur une machine qui est un contrôleur de domaine.

Une fois configuré, filtrer consiste simplement à ajouter la colonne de niveau ou à taper Tier-0-OnPrem-AD dans la barre de filtre, et tous les DC s’affichent. Aucun script nécessaire. Ce qui nous a pris toute une chaîne d’énumération est désormais un filtre en deux clics pour n’importe qui dans l’équipe.

Références

1. Microsoft Learn : Exécutez des scripts dans une VM Windows sur Azure avec l’action Exécuter des commandes
   https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command
2. Microsoft Learn : Service de métadonnées d’instance Azure pour machines virtuelles
   https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service