Credential Guard: Windows vor Pass-the-Hash- und Pass-the-Ticket-Angriffen schützen

Dieses Mechanismus können sich aber auch Angreifer mit Tools wie Mimikatz zunutze machen, indem sie den Hash aus dem Speicher auslesen und sich damit Zugang zu Systemen im Netzwerk verschaffen.

Aktiviert man Credential Guard, dann hält nicht mehr die LSA des Betriebs­systems die Secrets vor. Vielmehr übernimmt diese Aufgabe die LSA in einem zusätzlichen schlanken Windows-Kernel.

Dieser läuft auf einem höheren Trust-Level in einer virtuellen Maschine, so dass ein direkter Zugriff auf dessen Speicher aus dem eigentlichen OS nicht möglich ist. Daher muss die lokale LSA mit dem sicheren Gegenstück über Remote Procedure Calls (RPCs) kommunizieren.

Kein SSO mit unsicheren Protokollen

Sobald Credential Guard aktiviert wurde, ist ein Single-sign-on mit NTLMv1, MS-CHAPv2, Digest und CredSSP nicht mehr möglich. Anwendungen, die eine Authentifizierung über diese Protokolle erfordern, werden die Benutzer dann mit einem Anmelde­dialog zur erneuten Eingabe ihrer Kennung konfrontieren.

Eine weitere Einschränkung besteht darin, dass Credential Guard die Verwendung von Unconstrained Kerberos Delegation oder DES-Verschlüsselung nicht erlaubt. Daher sollte man vor der großflächigen Nutzung dieses Features prüfen, ob die damit einhergehenden Einschränkungen zu Problemen mit vorhandenen Anwendungen führen.

Systemvoraussetzungen

Bevor man Credential Guard aktiviert, sollte man sicherstellen, dass die jeweiligen Rechner die nötigen Voraus­setzungen dafür erfüllen. Diese sind:

• 64-bit-Version von Windows 10 bzw. 11 oder Windows Server ab 2016
• UEFI-Firmware mit aktiviertem Secure Boot.
• CPU mit Virtuali­sierungs­erwei­terungen Intel VT-x oder AMD-V mit SLAT-Support
• TPM v 1.2 oder 2.0

Microsoft stellt ein Hardware Readiness Tool in Form eines PowerShell-Scripts zur Verfügung, das diese Bedingungen prüft.

Credential Guard aktivieren

Das Feature lässt sich über mehrere Wege aktivieren. Das gängigste Verfahren dürften nach wie vor die Gruppen­richtlinien sein. In Frage kommen auch Intune oder das direkte Setzen eines Registry-Schlüssels.

Entscheidet man sich für ein GPO, dann findet man die zuständige Einstellung unter Computer­konfiguration => Richtlinien => Administrative Vorlagen => System => Device Guard. Sie heißt Virtualisierungs­basierte Sicherheit aktivieren und steuert gleich mehrere VBS-Funktionen.

Für die Konfiguration von Credential Guard stehen vier Optionen zur Auswahl:

• Deaktiviert
• Mit UEFI-Sperre aktiviert
• Nicht konfiguriert
• Ohne Sperre aktiviert

Mit UEFI-Sperre aktiviert speichert die Einstellung dauerhaft in der Firmware. Sie lässt sich daher nicht durch Zurück­setzen der Gruppen­richtlinie entfernen. Vielmehr muss man sie physisch an jedem PC deaktivieren. Ohne Sperre aktiviert hingegen erlaubt das Ändern der Ein­stellung via GPO.

Sobald die Gruppen­richtlinie auf den Zielrechnern greift, kann man mittels msinfo32.exe prüfen, ob das Feature tatsächlich aktiviert wurde.

Alternativ kann man nachsehen, ob ein Prozess namens LsaIso läuft. Allerdings ist dieser immer vorhanden, sobald auch nur ein VBS-Feature aktiv ist.

Credential Guard in VMs

Mit Credential Guard lässt sich auch das Gast-OS in einer virtuellen Maschine schützen. Diese muss mit ihrer virtuellen Hardware die gleichen Voraussetzungen erfüllen wie ein physischer Rechner. Daher kommen nur VMs der Generation 2 in Frage. Für diese muss man Secure Boot sowie ein virtuelles TPM aktivieren.

Zusätzlich muss man sich überzeugen, dass für VMSecurity die Eigenschaft Virtualization­Based­Security­Opt­Out nicht auf $true gesetzt wurde. Abfragen kann man dies mit

Get-VMSecurity -VMName <Name-der-VM>

Ändern kann man diese Einstellung bei Bedarf mit

Get-VMSecurity -VMName <Name-der-VM> -VirtualizationBasedSecurityOptOut $false

Die Aktivierung von Credential Guard für eine VM erfolgt über die gleichen Methoden wie für einen physischen Rechner, also etwa über die oben erwähnte Gruppen­richtlinie.