Eine Windows Active Directory-Testumgebung ist an sich eine grossartige Sache. Sie kann für das Testen neuer Einstellungen, für Training von Angriffstechniken und für Research genutzt werden. Daraus resultiert ab und an auch ein Labs-Artikel wie BloodHound – Auf der Jagd nach Domain-Admins. Die erste Version meiner Testumgebung habe ich vor einiger Zeit auf einem Notebook mit VMware Workstation gebaut, bestehend aus zwei Domain-Controllern, zwei Member-Server und zwei Clients. Anlässlich der Area 41 vom 15. und 16. Juni 2018 und unserem Workshop Adversary Simulation habe ich diese Umgebung als Basis genommen und diese weiter ausgebaut. Der Beginn einer Leidensgeschichte.

Der Hypervisor

Für den Area41-Workshop habe ich von unserem IT-Admin einen Server erhalten, den wir bisher für interne Testzwecke eingesetzt haben. Darauf war VMware ESXi 6.0 installiert und die Uptime des Servers betrug 220 Tage. Ich entschied mich für ein Upgrade auf vSphere 6.5, installierte alle Updates und begann dann meine bestehenden virtuellen Maschinen (VM) hochzuladen.

Durch den Hardwarewechsel ist die Windows Evaluation License der Windows 10 Clients nicht mehr gültig. Da unter Windows 10 die Lizenzverlängerung mit slmgr /rearm nicht mehr funktioniert, kann ich die Clients so nicht weiterverwenden. Das ist kein grosse Problem, ein Client kann leicht ersetzt werden, da dieser grösstenteils über Gruppenrichtlinien konfiguriert wird.

Ein grösseres Problem stellte die Performance des Servers dar, wenn alle VMs gleichzeitig liefen. Die Auslastung der Disks war so hoch, dass es beim Arbeiten in der VM nur noch schleppend voran ging. Ich ging also zurück zum IT-Admin, um eine SSD zu erschnorren.

Nach dem Einbau überlegte ich beim Initialisieren, ob ich die SDD mit VMFS6 formatieren sollte, oder mit VMFS5 wie die anderen beiden Disks. Nach längerem Zögern entschied ich mich für VMFS6.

Mit der SDD erwartete ich einen Leistungsschub, wurde aber enttäuscht. Das System agierte noch schwerfälliger als zuvor. Mittlerweile war das Arbeiten mit den VMs nicht mehr möglich, diese reagierten nur noch mit grossen Verzögerungen und brauchten eine Viertelstunde nur zum Starten. Es stellte sich heraus, dass VMware mit vSphere 6.5 einen neuen AHCI-Treiber (vmw_ahci) entwickelt hatte, welcher bei einigen Controllern zu Performance-Problemen führt. In der Auswertung der Disk-Performance war zu sehen, wie der Read- und Write-I/O kurz nach Start einbrach und dann auf wenigen KBps verblieb:

Über SSH kann der AHCI-Treiber durch den Befehl esxcli system module set --enabled=false --module=vmw_ahci deaktiviert werden. Der Rollback zum Legacy-Treiber und/oder das Update zum Build 5969303 scheint das Problem bei einigen anderen zu beheben. Bei meinem System blieb die Performance jedoch bescheiden. Auch das Durchprobieren von verschiedenen Einstellungen im BIOS führte nicht zu einer Verbesserung.

Ich entschied mich für einen Downgrade auf ESXi 6.0. Während dem Downgrade stellte ich jedoch fest, dass ESXi 6.0 VMFS6 formatierte Partitionen nicht lesen kann. Auch das Tool vmfs-tools unterstützt VMFS6 (noch) nicht.

Auf der SSD waren natürlich die meisten meiner VMs gespeichert. Da ich aber bis zum dem Zeitpunkt mit den VMs aufgrund der Performance-Problemen noch nicht viel arbeiten konnte und somit meine lokalen VMs noch aktuell waren, entschied ich mich, die SSD neu zu formatieren. Doch auch unter ESXi 6.0 bestand das Performance-Problem. Es schien zumindest nicht am neuen AHCI-Treiber zu liegen. Nach Diskussionen mit dem IT-Admin entschieden wir uns auf den Einsatz von XenServer.

Die Migration

Zur Migration auf XenServer können VMware-VMs in das OVF-Format exportiert werden, welches dann mittels XenCenter direkt importiert werden kann. Zu meiner Überraschung funktionierte der Export/Import-Vorgang problemlos. Unter XenServer gab es dann auch keine Performance-Probleme mit der SSD. Nur die Windows 2000 VM konnte aufgrund eines Bluescreens während dem Boot-Vorgang nicht mehr gestartet werden – dazu später mehr.

Nach der Umstellung begann ich auf allen VMs die VMware Tools zu de- und die XenServer Tools zu installieren. Das klappte auf allen Systemen soweit, bis auf einer Windows Server 2016 Core VM. Ich fand keine Möglichkeit die VMware Tools zu deinstallieren. VMware selber empfiehlt diese per Programs and Features zu deinstallieren, oder das VMware Tools Setup zu verwenden. Ein andere Möglichkeit schien es nicht zu geben. Die Option Programs and Features ist unter Windows Server Core aber nicht vorhanden und das VMware Tools Setupprogramm wollte ich nicht extra auf die VM kopieren. Falls jemand weiss, wie man die VMware Tools einfach deinstallieren kann, Tipps sind willkommen.

Ich deaktivierte fürs erste den VMware Tools Service und startete mit der Installation der XenServer Tools, welche als MSI-Paket vorliegen. Die Installation wurde jedoch von einer Software Policy geblockt. Da ich einige Hardening-Einstellungen bei diesem Server vorgenommen hatte, war ich nicht sonderlich überrascht. Aber auch nach stundenlangen Durchgehen der AppLocker Policy, Software Restrictions und diversen Registry-Keys konnte ich die Ursache nicht finden. Am Ende stellte sich heraus, dass die Installation mittels msiexec /i ohne weiteres funktioniert hätte.

Durch das Hin- und Herschieben und Starten der VMs gab es nun eine Inkonsistenz der AD-Replikation der beiden Domain-Controller. Der Secondary-DC hat zuerst 60min Zeitunterschied zum Primary-DC, was sich aber noch beheben liess. Nach einem Neustart begann sich jedoch das Event-Log mit Kerberos-Fehlermeldungen zu füllen. Ein schlechtes Zeichen. Auch hier verbrachte ich einige Zeit mit Analyse und diversen Workarounds zur Problembehebung. Schlussendlich half es den Maschinen-Account des Secondary-Domain-Controllers zurückzusetzen. Die beiden Domain Controller replizierten nun wieder. Bei den Member-Servern gab es glücklicherweise keine weiteren Probleme. Bis auf die Windows 2000 Maschine konnte die Migration also erfolgreich abgeschlossen werden.

Windows 2000 kehrt zurück

Die Windows 2000 Maschine ist eine der Challenges für den Area 41 Workshop, dementsprechend war ich interessiert daran diese wieder zum Laufen zu bringen. Der Bluescreen trat während des Boot-Prozesses auf, da Windows 2000 die Boot-Partition nicht finden konnte. Ursache dafür war vermutlich, dass Windows 2000 keinen Treiber für den Disk-Controller hatte. Als Workaround liess ich die VM nochmals unter VMware Workstation laufen, installierte dort die XenServer Tools 5.5 und migrierte die VM danach nochmals. Mit Erfolg, Windows 2000 startete nun:

Eine neuere Version der XenServer Tools kann unter Windows 2000 aber nicht installiert werden, da diese vom .NET-Framework abhängig ist. Es gibt zumindest eine Anleitung, wie das .NET-Framework 3.0 und 3.5 auch unter Windows 2000 installiert werden kann. Nachdem meine VM aber soweit ohne Probleme lief, verzichtete ich auf weitere Experimente.

Nebenbei stellte ich fest, dass das Windows Update unter Windows 2000 nicht mehr funktioniert. Möglicherweise sind die Anforderungen der TLS/SSL-Konfiguration der Windows-Update-Server zu hoch, sodass der Windows Update-Client keine Verbindung mehr aufbauen kann. Immerhin sind die meisten der Updates für Windows 2000 noch im Internet auffindbar – auf der Download-Seite von Microsoft verweisen die Download-Links jedoch ins Leere. Tipp für all diejenigen, die nun aus Nostalgie wieder einmal ein Windows 2000 starten möchten, benutzt die Windows 2000 JSLinux VM von Fabrice Bellard.

Ausblick

Die Migration der AD-Testumgebung auf XenServer ist schlussendlich geglückt, hatte mich aber mehr Aufwand gekostet wie ursprünglich gedacht. Mein temporärer Rollenwechsel vom Red Team zum Sysadmin hat mir wieder einmal gezeigt, wie viel Wissen, Aufwand und “Schmerzen” es benötigt, eine IT-Infrastruktur aufzubauen und am Laufen zu halten. Nicht umsonst gibt es den System Administrator Appreciation Day am letzten Freitag im Juli! Die Basis für den Area41-Workshop ist nun gelegt, die verbleibende Zeit verwende ich nun, um zusätzliche Systeme aufzusetzen, Schwachstellen zu präparieren und ein Monitoring zusammen mit unserem Blue Team aufzubauen. Bis bald an der Area41!

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• http://orbisvitae.com/ubbthreads/ubbthreads.php?ubb=showflat&Number=69204
• http://sysadminday.com/
• http://www.nxhut.com/2016/11/fix-slow-disk-performance-vmwahci.html
• https://area41.io/
• https://area41.io/workshops/#2
• https://bellard.org/
• https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/win2k.cfg&mem=192&graphic=1&w=1024&h=768
• https://docs.citrix.com/en-us/xencenter/6-5.html
• https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.storage.doc/GUID-7552DAD4-1809-4687-B46E-ED9BB42CE277.html
• https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-esxi-651-release-notes.html
• https://glandium.org/projects/vmfs-tools/
• https://support.microsoft.com/en-gb/help/325850/how-to-use-netdom-exe-to-reset-machine-account-passwords-of-a-windows
• https://www.vmware.com/support/developer/ovf/
• https://xenserver.org/