Aufdeckung indirekter Angriffswege zu virtualisierten Domänencontrollern in Azure

Im Netwrix Security Research-Team halfen wir einem Kunden bei einer Entra ID-Bewertung und wussten, dass er bereits AD-Tiering vor Ort durchgeführt hatte. Wir wussten auch, dass Domain-Controller in Azure virtualisiert waren, aber es war schwer zu erkennen, welcher Windows-Server tatsächlich ein DC war. Wir fanden heraus, dass Azure Run Command Befehle als SYSTEM ausführen kann, und nutzten das für Aufklärung und zur Identifikation der DCs.

Alles, was in diesem Beitrag gezeigt wird (Screenshots, Gerätenamen, Benutzernamen), stammt aus einer Laborumgebung, die wir anschließend zum Demonstrieren der Technik neu aufgebaut haben. Es handelt sich um keine Kundendaten.

Zum Kontext: Microsofts eigene Dokumentation beschreibt Run Command als Möglichkeit, PowerShell-Skripte innerhalb einer Windows-VM über den VM-Agenten auszuführen, hauptsächlich für allgemeine Verwaltungsaufgaben wie das Beheben von Zugriffs- oder Netzwerkproblemen auf einem Rechner. Es prüft jedoch nicht, um welche Art von VM es sich handelt. Es läuft problemlos auf einem Domänencontroller genauso wie auf jeder anderen VM.

Wir haben beschlossen, mit Claude ein PowerShell-Skript zu erstellen, das uns erlaubt, einen Befehl gleichzeitig auf mehreren Windows-Rechnern auszuführen, statt in der Run Command-Konsole jede VM einzeln anzuklicken. Dafür benötigen Sie nur die Berechtigung Microsoft.Compute/virtualMachines/runCommand/action, die mit Virtual Machine Contributor oder höher kommt.

Der Trick besteht darin, jeden Invoke-AzVMRunCommand-Aufruf in einem ThreadJob statt im üblichen Start-Job auszuführen. Start-Job startet für jede VM einen neuen PowerShell-Prozess und lädt das Az-Modul jedes Mal neu, was bei mehreren Maschinen schnell verlangsamt. ThreadJob läuft in einem Thread im selben Prozess, sodass das gleichzeitige Starten vieler kaum zusätzlichen Aufwand verursacht. Wir halten eine Warteschlange aller gefundenen VMs und füllen sie auf eine feste Anzahl gleichzeitig laufender Jobs auf (standardmäßig 20). Sobald einer fertig ist, füllen wir den Platz sofort wieder auf, ohne auf den Abschluss eines ganzen Batches zu warten.

So sieht es aus, wenn man whoami über das Portal für eine Maschine nach der anderen ausführt:

Hier wird derselbe Befehl über das PowerShell-Skript gleichzeitig auf allen VMs im Abonnement ausgeführt:

Nachdem das funktionierte, war der nächste Schritt, die DCs zu finden. Die Prüfung ist einfach: Führen Sie Get-Service NTDS auf jeder laufenden Windows-VM über Run Command aus. NTDS ist der Dienst, der die AD DS-Datenbank betreibt. Wenn er vorhanden und aktiv ist, ist diese Maschine ein Domänencontroller.

Eine VM lief eindeutig, aber Run Command schlug fehl, anstatt zu antworten, während alle anderen VMs im Abonnement problemlos reagierten. Der Name allein war schon ein starker Hinweis. Das Scheitern von Run Command passt genau zu dem, was man von einem richtig gesicherten Domänencontroller erwarten würde, bei dem strengere Sicherheitswerkzeuge stören. Diese Fehlermeldung einfach zu akzeptieren und weiterzumachen hätte bedeutet, keine Domänencontroller im Abonnement zu melden.

Statt dem Fehler zu vertrauen, fragten wir AD direkt. Jede domänengebundene VM, die Run Command noch erreichen kann, wird genutzt, um AD über LDAP abzufragen. Kein Active Directory-Modul nötig, nur [adsisearcher], ein integrierter PowerShell-Typbeschleuniger, der auf jeder domänengebundenen Maschine funktioniert.

Die Prüfung ist ein userAccountControl-Bit namens SERVER_TRUST_ACCOUNT mit dem Wert 8192. AD setzt dies erst, wenn ein Computer zum DC befördert wurde. Wir haben zwei weitere Prüfungen hinzugefügt: primäre Gruppe 516 (die „Domain Controllers“-Gruppe) und ein passendes NTDS Settings-Objekt in der Konfigurationspartition.

Eine Sache jedoch: Ein übereinstimmender Hostname allein beweist nicht, dass es diese VM ist oder dass sie überhaupt in Azure ist. Namen ändern sich, werden gekürzt und manchmal wiederverwendet. Deshalb prüfen wir zuerst die IP, indem wir den Hostnamen des DC innerhalb der Domäne in eine IP auflösen und mit der privaten IP vergleichen, die Azure für diese VM meldet. Diese IP existiert nur, wenn die Maschine tatsächlich in Azure läuft, daher ist eine Übereinstimmung hier so sicher wie möglich. Wenn DNS nicht auflöst, vergleichen wir stattdessen Hostnamen, behandeln diese aber als weniger zuverlässig, da Namen sich auf Arten ändern können, wie IPs es nicht tun.

Sobald wir zuverlässig bestätigen konnten, dass die Maschine, die zuvor einen Fehler hatte, ein Domänencontroller war, stellte sich die eigentliche Frage, wer beliebige Befehle als SYSTEM darauf ausführen kann, da dieser Zugriff Tier-0 ist, Punkt. Es ist nicht derjenige, der Domain Admin hat; der Kunde hatte das bereits mit seiner Einteilung geklärt. Es ist derjenige, der Azure-Berechtigungen auf dieser speziellen VM hat, denn Run Command interessiert sich nicht für AD. Es zählt nur Azure RBAC.

So sieht das aus. Einige Benutzer erscheinen mehrmals (eine Zeile pro Rolle), zusammen mit einer Gruppe und zwei Dienstprinzipalen, alle mit Owner oder Contributor irgendwo in der Kette, meist von der Subscription vererbt und nicht direkt auf der VM zugewiesen. Jeder einzelne von ihnen kann Run Command gegen einen Domänencontroller ausführen und Code als SYSTEM ausführen. Das hat nichts damit zu tun, wer tatsächlich in den lokalen Domain Admins ist.

An diesem Punkt fragt das Skript auch, ob Sie aus diesen Daten ein BloodHound-ähnliches Diagramm erstellen möchten, um zu visualisieren, welche Sicherheitsprinzipale einen direkten oder indirekten Pfad zu einem virtualisierten Domänencontroller in Azure haben. In unserem Labor sind das 12 Prinzipale mit Pfad zum DC, die meisten davon von der Subscription geerbt und nicht direkt der VM zugewiesen. Klicken Sie auf einen Knoten, und die Seitenleiste zeigt genau an, was es ist und wie es dorthin gelangte, einschließlich der Gruppenmitgliedschaft. Ein Gruppen-Knoten mit "3 Mitglieder" ist also nicht nur eine Zahl. Sie können tatsächlich sehen, wer darin ist.

Empfehlung

Markieren Sie Ihre Domänencontroller in Azure mit etwas wie Tier-0-OnPrem-AD auf der VM-Ressource. Das klingt offensichtlich, aber die meisten Umgebungen, die wir betrachtet haben, tun dies nicht, weshalb die Identifikation anfangs echte Arbeit war, statt einfach nach Tags zu filtern. Sobald sie markiert sind, können Sie eine Richtlinie erstellen: neue Besitzer- oder Mitwirkenden-Zuweisungen auf Objekten mit diesem Tag verweigern oder bei Änderungen benachrichtigen.

Tags zeigen nur, was künftig passiert. Sie beheben nicht, was bereits besteht. Jede Umgebung, die wir geprüft haben, hat im Laufe der Zeit Berechtigungen auf diesen VMs angesammelt, meist geerbt von der Ressourcengruppe oder dem Abonnement, nicht direkt zugewiesen. Deshalb wird es leicht übersehen.Überprüfen Sie, wer aktuell Zugriff hat, und fragen Sie für jede Person und jeden Dienstprinzipal, ob sie noch Owner oder Contributor auf einem Server benötigen, der ein Domänencontroller ist.

Ist das eingerichtet, bedeutet Filtern nur, die Ebenen-Spalte hinzuzufügen oder Tier-0-OnPrem-AD in die Filterleiste einzugeben, und alle DC erscheinen. Kein Skript nötig. Was uns eine ganze Enumeration-Pipeline gekostet hat, ist jetzt ein Zwei-Klick-Filter für jeden im Team.

Referenzen

1. Microsoft Learn: Führen Sie Skripte in einer Windows-VM in Azure mit der Aktion Befehle ausführen aus
   https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command
2. Microsoft Learn: Azure Instance Metadata Service für virtuelle Maschinen
   https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service