Gerade in der aktuellen Zeit hört/liest man wieder viel über IT-Infrastrukturen, die angegriffen wurden – mal erfolgreich und mal (gerade so) nicht erfolgreich. Häufig wird dabei erwähnt, dass es sich um alte, jahrelang gewachsene Umgebungen handelt, welche aufgrund der Vielzahl der verschiedenen Administratoren unterschiedlich intensiv betreut wurden. Folglich geht damn davon aus, dass bei einer neu eingerichteten Infrastruktur die Anzahl der Schwachstellen nahezu gegen 0 gehen sollte, leider ist dem aber nicht so. In diesem Artikel geht es um eine frisch aufgesetzte Active Directory und welche Schwachstellen es trotz modernem Betriebssystem (Windows Server 2022) vorhanden sind – und wie man sie schließt.
Für die Analyse der Schwachstellen wird die Software „PingCastle“ (Download-Seite) verwendet, welche meines Erachtens sehr einfach zu bedienen ist und dennoch extrem überschaubar darstellt, welche Lücken vorhanden sind, sowie häufig auch Empfehlungen mit angibt.

Inhaltsverzeichnis: Schwachstellen beheben

1. „Network topography“
2. „Object configuration“
3. „Provisioning“
4. „Account take over“
5. „Irreversible change“
6. „Audit„
7. „Backup„
8. „Network sniffing„
9. „Pass-the-credential„
10. „Reconnaissance„
11. „Weak password„

Umgebung

Es ist ein frisch installierter Server mit Windows Server 2022, auf dem ein Active Directory („demolabor.intern“) eingerichtet wurde. Es gibt noch weitere Memberserver für andere Demo-Zwecke (siehe bspw. RemoteApp 2022 – Teil 1), das beeinflusst aber die Analyse nicht.

Risikoanalyse durchführen

Nachdem Download von PingCastle, kann dies einfach entpackt und ausgeführt werden, eine Installation ist nicht notwendig. Die Anwendung läuft als Consolen-Anwendung und eine Eingabe erfolgt mithilfe von Tastatureingaben, wie bspw. die <ENTER>-Taste.
In den meisten Fällen ist die Option „1-healthcheck – Score the risk of a domain“ ausreichend. Es folgt die Angabe einer Domäne oder durch erneutes Betätigen der <ENTER>-Taste wird die Domäne genommen, in die sich der aktuelle User/Computer befindet.
Nach Abschluss findet sich im selben Ordner eine HTML- & eine XML-Datei. Das Öffnen der HTML-Datei zeigt den erstellten Bericht.

Initial hat eine neue Active Directory einen Risikowert von 65/100. Das Risikomodell stellt dabei eine Verteilung der gefundenen Schwachstellen dar. Im weiteren Verlauf des Artikels wird auf diese initial gefundenen Schwachstellen eingegangen.

Schwachstellen beheben

1. „Network topography“

Diese Schwachstelle hat einen Wert von „5“ und sagt aus, dass das Subnetz des Domain-Controllers nicht deklariert (= angegeben) ist. Diese Angabe wird im Tool „AD Sites and Services“ nachgeholt.

Hier in den Bereich „Sites\Subents“ wechseln, mit einem Rechtsklick das Kontext-Menü öffnen und „New Subnet…“ wählen. Das Prefix eintragen, die Site auswählen (häufig ist diese noch nicht individualisiert und heißt „Default-First-Site-Name“) und auf <OK> klicken.

2. „Object configuration“

Diese Schwachstelle hat einen Wert von „1“ und sagt aus, dass es mindestens einen Account gibt, bei dem das Kennwort nie abläuft. Wenn man sich die Details anschaut, wird der initial erstellte Account „Administrator“ gelistet.

Im Tool „AD Users and Computers“ wird in den Container „Users“ gewechselt, dort ein Rechtsklick auf „Administrator“ gemacht und im Kontextmenü der Eintrag „Properties“ ausgewählt. Im Reiter „Account“ wird im unteren Bereich der Haken bei „Password never expires“ entfernt und auf <OK> geklickt.

3. „Provisioning“

Diese Schwachstelle hat einen Wert von „10“ und sagt aus, dass nicht-Administratoren in der Lage sind bis zu 10 Computer in die Domäne aufzunehmen.

Mithilfe von PowerShell lässt sich der aktuelle Wert auslesen, sowie ein Anzahl der Geräte verändern – aus Sicherheitsaspekten natürlich auf den Wert „0“, sodass kein Gerät unerlaubt hinzugefügt werden kann.

Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

Set-ADDomain -Identity 'DC=DEMOLABOR,DC=intern' -Replace @{"ms-DS-MachineAccountQuota"="0"}

Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

4. „Account take over“

Diese Schwachstellen hab einen Wert von „30“ und sagen aus:

1. Anzahl der Administratoren-Accounts, die nicht in der Gruppe „Protected Users“ sind
2. Anzahl der Accounts, die sensitive sind und nicht das Flag „This account cannot be delegated“ haben

Beide Punkte können schnell mit einem Schwung gelöst werden:

1. Im Tool „AD Users and Computers“ die Accounts suchen und in deren Properties gehen
2. Im Reiter „Account“ im unteren Bereich den Haken setzen bei „Account is sensitive and cannot be delegated“ setzen und auf <Apply> klicken
3. Im Reiter „Member Of“ in die AD-Gruppe „Protected Users“ aufnehmen und auf <Apply> klicken

Schritt 3 kann alternativ auch über den Weg durchgeführt werden:

1. Im Tool „AD Users and Computers“ in die AD-Gruppe „Protected Users“ gehen
2. Dort beide Accounts hinzufügen und auf <OK> klicken

5. „Irreversible change“

Diese Schwachstellen hab einen Wert von „20“ und sagen aus:

1. Die AD-Gruppe „Schema Admins“ ist nicht leer
2. Der „Recycle Bin“ ist nicht aktiv

Für die Lösung dieser beiden Punkte wird zuerst der 2. Punkt erledigt, denn dieser erfordert das Recht, dass Änderungen am Schema der Active Direcotry durchgeführt werden dürfen. Mit dem „Recycle Bin“ ist das seit Windows Server 2008 R2″ verfügbare Feature des Papierkorbs für die Active Directory gemeint (Details siehe The AD Recycle Bin: Understanding, Implementing, Best Practices, and Troubleshooting – Microsoft Tech Community).

Zum Aktivieren des AD-Papierkorbs:

1. Anmeldung als Enterprise-Administrator am Domain-Controller mit der FSMO-Rolle „Domain Naming Master“
2. Ausführen folgender PowerShell-Befehle, sowie der Bestätigung mit „y“ für „yes“:

Import-module ActiveDirectory
Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target DEMOLABOR.intern

y

Optional kann noch die Aufbewahrungszeit (in Tagen) ausgelesen und geändert werden – ebenfalls mithilfe von PowerShell:

Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=DEMOLABOR,DC=intern" -Property msDS-DeletedObjectLifetime | fl

Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=DEMOLABOR,DC=intern" -Partition "CN=Configuration,DC=DEMOLABOR,DC=intern" -Replace:@{"msDS-DeletedObjectLifetime" = 365}

Zum Leeren der AD-Gruppe „Schema Admins“ wird das Tool „AD Users and Computers“ geöffnet, in die AD-Gruppe „Schema Admins“ gegangen, dort dann die bestehenden Accounts entfernt und auf <OK> geklickt.

6. „Audit“

Diese Schwachstellen hab einen Wert von „10“ und sagen aus:

1. PowerShell Auditierung ist nicht vollständig eingerichtet
2. Eine Audit-Richtlinie für Domain-Controller sammelt keine Schlüssel-Ereignisse

Leider sagen auch die Verlinkungen in dem Bereich des Risikomodells nicht sonderlich viel aus.

Der erste Punkt wird mithilfe einer GPO gelöst, welche das Auditieren aktiviert. Im Tool „Group Policy Management“ wird die GPO „A-C-PO-ADM-WC-WPS_PowerShell-Logging_v1.0“ erstellt, anschließend im Bereich „Computer > Policies > Administrative Templates > Windows Components > Windows PowerShell“ die Optionen aktiviert:

• „Turn on Module Logging“ -> hier als Modul „Microsoft.PowerShell.*“ eintragen
• „Turn on PowerShell Script Block Logging“

Anschließend wird die GPO direkt ganz oben in der Domäne verlinkt.

Für den zweiten Punkt werden folgende drei GPOs angelegt:

1. A-C-PO-WS-SS-LP-AP_Audit-Level-01-Simple_v1.0
2. A-C-PO-WS-SS-LP-AP_Audit-Level-02-Advanced_v1.0
3. A-C-PO-WS-SS-LP-AP_Audit-Level-03-DomainServicesAccess_v1.0

Für die „Simple“-GPO wird im Bereich „Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policies“ alle Policies aktiviert und sowohl „Success“ als auch „Failure“ ausgewählt.

Für die „Advanced“-GPO werden im Bereich „Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration > Audit Policies“ diese Bereiche aktiviert:

• ss
• aa

Beide GPOs werden direkt ganz oben in der Domäne verlinkt.

Für die „DomainServicesAccess“-GPO wird im Bereich „Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration > Audit Policies > DS Access“ alle Polices aktiviert und sowohl „Success“ als auch „Failure“ ausgewählt. Anschließend wird sie in der OU „Domain Controllers“ verlinkt.

Hinweis zu den GPO-Namen:
Ich habe im Artikel Einfache Namen für GPOs erläutert, wie ich die Namen der GPOs wähle. Vereinzelt gibt es den Fall, dass von dieser Konvention abgewichen wird, sodass es übersichtlicher ist. In dem aktuellen Fall wird die 3. GPO („A-C-PO-WS-SS-LP-AP_Audit-Level-03-DomainServicesAccess_v1.0″) nicht ganz oben verlinken und greift damit nicht für Alle, sondern nur für die Server des Types Domain Controller. Folgerichtig müsste die GPO eigentlich „S-C-PO-WS-SS-LP-AP_Audit-Level-03-DomainServicesAccess_v1.0″ heißen. Nachteil ist aber, sie ist dann nicht übersichtlich direkt unter den anderen Audit-GPOs, sondern kommt erst wesentlich später bzw. weiter unten bei den Server-GPOs.

7. „Backup“

Diese Schwachstellen hab einen Wert von „20“ und sagen aus:

1. Die Anzahl der Domänen-Controller ist zu gering um eine Redundanz zu bieten
2. Das letzte Backup der AD ist älter als X Tage

Auf den ersten Punkt gehe ich hier nicht detailliert ein, denn es muss lediglich ein Server als Member-Server in die Domäne aufgenommen werden, anschließend die AD-Domain Services installiert werden und der Member-Server zum Domain-Controller heraufgestuft werden. Wie dies grundsätzlich funktioniert, ist bspw. im Artikel HowTo: Hinzufügen eines Windows Server Core DomainControllers zu einer AD beschrieben. Die PowerShell-Befehle funktionieren ebenso in einer Installation mit Desktop-Oberfläche.

Wenn beide Domain-Controller funktional sind, dann sollten folgende Schritte für das AD-Backup auf beiden eingerichtet werden – optimaler Weise mit einem zeitlichen Versatz.

Sofern der Domain-Controller eine VM ist, dann eine weitere VHDX einbinden, formatieren und bereitstellen (ich nehme hier gerne den Laufwerksbuchstaben „B“, wie „Backup“). Ist der Domain-Controller eine physikalische Maschine, dann muss entweder eine interne Platte dafür genutzt werden oder eine USB-Platte oder zur Not auch ein Netzlaufwerk. Achtung: Bei Wahl eines Netzlaufwerkes wird jedoch die Backupdatei jedes mal überschrieben und man kann somit nur auf das letzte Backup zugreifen. Bei einer (USB-)Platte bzw. einer anderen virtuellen Platte kann man auf frühere Backup-Stände zugreifen.
Anschließend das Server Feature „Windows Server Backup“ hinzufügen und dann im Server Manager unter Tools starten. Den „Backup Schedule Wizard“ starten und entsprechend konfigurieren. Wichtig ist hierbei die Option „System State“, alles andere ist beispielhaft eingestellt und muss auf die vorliegenden Bedürfnisse angepasst werden.
Tipp: Hat man die Domain-Controller virtualisiert und sichert man die gesamte VM nochmal mit einem anderen Tool (bspw. Altaro Backup), reicht die Konfiguration mit „Windows Server Backup“ an dieser Stelle aus. Nutzt man keine Backup-Software oder hat man einen physikalischen Server, würde ich lieber grundlegend „Full server (recommended)“ oder die Option „Bare metal recovery“ auswählen.

Über die Aktion „Backup once…“ und der Auswahl „Scheduled backup options“ wird nun das erste Backup erstellt.
Auf dem zweiten Domain Controller würde ich das Backup 1h später durchführen. Ein zweites Backup macht die Sache nicht sicherer, es ist lediglich meine persönliche Best-Practice“ die Domain-Controller identisch einzurichten. Fällt bspw. der erste DC längerfristig aus (weil physikalisch) und man hat dort das Backup nicht konfiguriert, dann könnte das im Zweifelsfalle doof werden 😉

8. „Network sniffing“

Diese Schwachstellen hab einen Wert von „0“ und sagen aus:

1. Es wurde keine GPO gefunden, die „LLMNR“ deaktiviert oder es gibt mindestens eine GPO, die es explizit aktiviert
2. Authentifizierte Benutzer können DNS-Einträge erstellen

Für den ersten Punkt kann man mithilfe einer GPO zur Lösung kommen. „LLMNR“ steht für „Link-Local Multicast Name Resolution“ und arbeitet auf UDP-Port 5355; es ermöglicht IPv4- & IPv6-Systemen den Namen andere Computer im Netzwerk aufzulösen, wenn kein DNS-Server zur Verfügung steht, durch Broadcast-Anfragen im lokalen L2-Netzwerksegment.

LLMNR kann lokal mit folgendem PowerShell-Befehl per Registry-Eintrag deaktiviert werden:

New-Item "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT" -Name DNSClient  -Force
New-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMultiCast -Value 0 -PropertyType DWORD  -Force

Per GPO kann dies auch auf folgendem Weg in der kompletten Domäne angewandt werden. Die GPO „A-C-PO-AT-NW-DNSC_LLMNR-Deaktivation_v1.0“ erstellen und im Bereich „Computer Configuration > Policies > Administrative Templates > Network > DNS Client“ die Option „Turn off multicast name resolution“ auf „enabled“ stellen.

Wenn man nun also LLMNR deaktiviert, sollte man auch gleich einen Blick auf „NetBIOS over TCP/IP“ bzw. „NBT-NS (UDP/137,138;TCP/139)“ werfen, denn dies ist der Vorgänger zu LLMNR. „NetBIOS over TCP/IP“ muss für jede einzelne Netzwerkkarte deaktiviert werden, eine einfache GPO-Steuerung gibt es leider nicht, allerdings gibt es zwei Workarounds:

1. Via PowerShell-Skript beim Starten des Computers als Startup-/Logon-GPO
2. Über ein sog. Flag im DHCP Server

Es wird also die GPO „A-C-PO-WS-Scripts-Startup_NetBIOSoverTCPIP_Deaktivation_v1.0“ angelegt und folgendes Skript als Startup-Skript „NetBIOSdeaktivation.bat“ hinterlegt:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy ByPass -file "\\DEMOLABOR.intern\SysVol\DEMOLABOR.intern\Policies\{55392125-F00B-4492-B0F3-3C9F0A848D9F}\Machine\Scripts\Startup\NetBIOSdeaktivation.ps1" 

Das Batch-Skript startet daraufhin das PowerShell-Skript „NetBIOSdeaktivation.ps1“ mit folgendem Inhalt:

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}

Warum auf diesem Weg mit zwei Skripten? Normalerweise verbietet es die Ausführungsrichtlinie (Executionpolicy), dass ein nicht-signiertes PowerShell-Skript ausgeführt wird. Man benötigt also eine eigene PKI und ein Code-Signing Zertifikat. Aktuell habe ich dies nicht in der DEMO-Umgebung und für alle, die dies auch nicht haben, gibt es mit diesen beiden Skripten dann also eine Möglichkeit zur Skriptausführung – dank dem Parameter „ExecutionPolicy bypass“.

Der Vorteil vom PowerShell-Skript ist, dass hier alle möglichen Netzwerkkarten berücksichtigt werden und NetBIOS dort deaktiviert wird.

Das Flag über den DHCP-Server ist in den Server-Optionen im Reiter „Advanced.

Zum Lösen des zweiten Punktes (Authentifizierte Benutzer können DNS-Einträge erstellen) geht man in die DNS-Server Konsole und macht einen Rechtsklick auf die Forward-Zone der Domäne und wählt im Kontextmenü „Properties“.
Dann auf den Reiter „Security“ und den Haken für die „Authenticated Users“ bei „Create all child objects“ entfernen und auf <Apply> klicken. Die „Authenticated Users“ verschwinden dann, da sie keine weiteren Rechte hatten. Mit <OK> können die Properties geschlossen werden.

9. „Pass-the-credential“

Diese Schwachstellen hab einen Wert von „25“ und sagen aus:

1. Der Druckspooler-Dienst von X Domain-Controllern ist per remote erreichbar
2. LAPS scheint nicht installiert/eingerichtet zu sein

Für den ersten Punkt wird die GPO „S-C-PR-CPS-Services_Disable-PrintSpooler_v1.0“ erstellt und im Bereich „Computer Configuration > Preferences > Control Panel Settings > Services“ einen Rechtsklick im rechten Bereich machen und im Kontextmenü die Option „New > Service“ wählen.
Dann diese Einstellungen setzen:

• Reiter „General“
  • Startup: Disabled
  • Service name: Spooler
  • Service action: Stop service
• Reiter „Recovery“
• First/Second/Subsequent failure: Take no action

Tipp: Leider kann man im Dialog für den Service nicht nach Name sortieren. Im englischen System findet man den „Spooler“ als Name „Print Spooler“.

Die GPO muss dann auf „Domain Controllers“ verlinkt werden.

Der zweite Punkt ist etwas aufwändiger und wird im separaten Artikel „AD-Security: Verwendung von LAPS“ durchgeführt.

10. „Reconnaissance“

folgt …

11. „Weak password“

folgt …