Ausgangslage: Anmeldedaten bleiben zu lange erreichbar

Viele AD-Kompromittierungen werden nicht dadurch gross, dass ein einzelnes Benutzerkonto kompromittiert wird. Sie werden gross, weil auf einem Client, Admin-Host oder Server noch verwertbare Anmeldedaten liegen: NTLM-Hashes, Kerberos-Tickets, zwischengespeicherte Logon-Informationen oder Spuren aus interaktiven Admin-Sessions. Sobald ein Angreifer lokalen Admin-Zugriff auf ein System erreicht, wird aus "ein Host betroffen" schnell "weitere Identitaeten betroffen".

Credential Guard reduziert genau diesen Hebel. Die Funktion nutzt Virtualization Based Security, um bestimmte abgeleitete Domain-Credentials aus der normalen Windows-Umgebung herauszuloesen. LSASS bleibt fuer Windows sichtbar und nutzbar, aber sensible Geheimnisse werden in einem isolierten Prozessbereich verarbeitet. Das macht Credential-Diebstahl nicht unmoeglich, erhoeht aber den Aufwand deutlich und schneidet mehrere klassische Seitwaertsbewegungswege ab.

Wichtig ist die saubere Erwartungshaltung: Credential Guard ist keine alleinstehende AD-Sicherheitsstrategie. Es ersetzt kein Tiering, keine Admin-Workstations, keine MFA, keine Service-Account-Hygiene und keine Reduktion von NTLM. Es ist ein Schutzbaustein fuer Systeme, auf denen Domain-Anmeldedaten besonders wertvoll sind oder regelmaessig privilegierte Sessions entstehen.

Zielbild: Credential Guard dort, wo Credentials zaehlen

Ein belastbares Zielbild hat konkrete Eigenschaften:

  1. Admin- und Tier-0-Workstations nutzen Credential Guard standardmaessig. Systeme fuer Domain-, Server-, PKI-, Backup- und Identity-Administration werden zuerst betrachtet.
  2. Normale Clients folgen in Wellen. Der breite Rollout kommt erst nach Pilot, Kompatibilitaetstests und klarer Ausnahmeregel.
  3. VBS, Secure Boot und Hypervisor-Voraussetzungen sind bekannt. Der Rollout scheitert nicht an Firmware, BIOS-Settings oder inkompatiblen Treibern.
  4. SSO-, VPN-, RDP- und Legacy-Abhaengigkeiten sind getestet. Gespeicherte Credentials, alte Authentifizierungswege und bestimmte Credential-Provider werden vorab geprueft.
  5. UEFI Lock wird bewusst behandelt. In der Pilotphase bleibt die Ruecknahme einfach. Erst nach Stabilisierung wird entschieden, ob manipulationsresistentere Einstellungen sinnvoll sind.
  6. Compliance ist messbar. Intune, MDE, ConfigMgr, GPO-Reporting oder eigene PowerShell-Abfragen zeigen, wo Credential Guard konfiguriert ist und wo es wirklich laeuft.

Das Ziel ist nicht, einen einzelnen Schalter moeglichst schnell global zu setzen. Das Ziel ist, verwertbare Domain-Credentials auf den wichtigsten Windows-Systemen kontrolliert aus dem normalen Angriffspfad zu nehmen.

Umsetzung: erst Pruefung, dann Wellen-Rollout

1) Scope nach Risiko festlegen

Starte nicht mit allen Clients. Beginne mit Systemen, auf denen hoechstwertige Identitaeten verwendet werden:

  • Privileged Access Workstations und Admin-Jumphosts,
  • Helpdesk- und Server-Administrations-Clients,
  • Systeme fuer Domain Controller, AD CS, Entra Connect, Backup, EDR, PAM und Virtualisierung,
  • Management-Server, auf denen regelmaessig privilegierte Tools laufen,
  • hochkritische Client-Gruppen, die Zugriff auf sensible Geschaeftsdaten haben.

Domain Controller brauchen eine eigene Bewertung. Credential Guard ist in erster Linie ein Client- und Workstation-Hardening-Baustein fuer Credential-Isolation. Auf DCs sind andere Kontrollen wie Tiering, LSASS Protected Process, eingeschraenkte Logon-Pfade, Patchdisziplin und Zugriffskontrolle entscheidend. Setze DCs deshalb nicht blind in denselben Scope wie normale Clients.

2) Voraussetzungen read-only erfassen

Vor einer GPO oder Intune-Policy sollte klar sein, welche Systeme technisch geeignet sind. Pruefe mindestens Firmware-Modus, Secure Boot, Virtualisierung und vorhandenen VBS-Status.

Read-only Startpunkt auf einem Testsystem:

$ns = 'root\Microsoft\Windows\DeviceGuard'

Get-CimInstance `
  -ClassName Win32_DeviceGuard `
  -Namespace $ns |
  Select-Object `
    VirtualizationBasedSecurityStatus,
    SecurityServicesConfigured,
    SecurityServicesRunning,
    RequiredSecurityProperties,
    AvailableSecurityProperties

Ergaenzend lohnt sich ein Blick auf Secure Boot:

Confirm-SecureBootUEFI

Die Ausgabe muss pro Betriebssystemversion und Hardwaremodell interpretiert werden. Unterschiedliche Zahlenwerte in SecurityServicesRunning sind in Flotten normal, weil VBS, Hypervisor Code Integrity und Credential Guard getrennte Diensteigenschaften haben koennen. Fuer den Rollout ist entscheidend, dass du denselben Messpunkt dauerhaft nutzt und nicht nur "Policy gesetzt" mit "Schutz aktiv" gleichsetzt.

3) Kompatibilitaet vor dem Erzwingen testen

Credential Guard veraendert Authentifizierungsverhalten. Das ist gewollt, kann aber alte Betriebsannahmen brechen. Teste besonders:

  • RDP mit gespeicherten Domain-Credentials,
  • VPN-, WLAN- und 802.1X-Clients,
  • Drittanbieter-Credential-Provider und SSO-Agenten,
  • Smartcard- und Zertifikatsanmeldung,
  • Applikationen, die alte NTLM- oder CredSSP-Abhaengigkeiten haben,
  • Helpdesk-Tools, Remote-Support und Endpoint-Management,
  • Entwickler- oder Admin-Workflows mit RunAs, MMC, RSAT und PowerShell Remoting.

Der Test muss echte Arbeitsablaeufe enthalten. Ein erfolgreiches Windows-Login reicht nicht. Der Pilot ist erst belastbar, wenn Admins ihre normalen Tools nutzen, Remote-Pfade funktionieren und alte gespeicherte Credentials nicht stillschweigend als Betriebsabhaengigkeit auftauchen.

4) Policy ueber GPO oder MDM setzen

In klassischen AD-Umgebungen laeuft die Einfuehrung haeufig ueber Gruppenrichtlinien:

Computer Configuration
  Administrative Templates
    System
      Device Guard
        Turn On Virtualization Based Security

Wichtige Entscheidungen:

  • Virtualization Based Security aktivieren,
  • Credential Guard aktivieren,
  • Secure Boot als Schutzanker nutzen,
  • UEFI Lock in der Pilotphase vermeiden oder sehr bewusst einsetzen,
  • GPO nur auf Pilot-OUs oder klar definierte Sicherheitsgruppen anwenden.

In Microsoft-365-lastigen Umgebungen kann dieselbe Zielsetzung ueber Intune Security Baselines oder Endpoint Security Policies abgebildet werden. Entscheidend ist nicht das Werkzeug, sondern der Scope, die Nachweisbarkeit und der Rueckfallplan.

5) Pilot sauber schneiden

Ein sinnvoller Pilot ist klein, aber echt:

  1. Zwei bis fuenf Hardwaremodelle oder Standard-Client-Builds auswaehlen.
  2. Admin- und Nicht-Admin-Nutzung getrennt testen.
  3. VPN, RDP, WLAN, SSO, Browser, RSAT, PowerShell Remoting und EDR-Health pruefen.
  4. Helpdesk und Endpoint-Team in die Fehlersuche einbinden.
  5. Ereignisse, Support-Tickets und Performance-Auffaelligkeiten fuer mindestens einen normalen Arbeitszyklus beobachten.

Wenn Credential Guard im Pilot nicht sauber messbar ist, ist der Pilot nicht fertig. "GPO verlinkt" oder "Intune-Profil zugewiesen" ist nur der Start. Der relevante Zustand ist, ob Credential Guard auf dem Endpunkt wirklich laeuft.

6) Aktivierung verifizieren

Auf einem einzelnen System ist ein pragmatischer Check:

Get-Process `
  -Name LsaIso `
  -ErrorAction SilentlyContinue

Der isolierte LSA-Prozess ist ein starkes Signal, ersetzt aber nicht die Flottenmessung. Kombiniere Prozesssicht, Win32_DeviceGuard, Endpoint-Management-Compliance und Security-Telemetrie.

Fuer eine grobe lokale Statussicht:

$ns = 'root\Microsoft\Windows\DeviceGuard'

Get-CimInstance `
  -ClassName Win32_DeviceGuard `
  -Namespace $ns |
  Select-Object `
    VirtualizationBasedSecurityStatus,
    SecurityServicesConfigured,
    SecurityServicesRunning

Get-Process `
  -Name LsaIso `
  -ErrorAction SilentlyContinue

Fuer die Flotte gehoert der Check in vorhandene Management-Werkzeuge. Einzelne PowerShell-Ausgaben sind gut fuer Analyse und Fehlersuche, aber kein dauerhaftes Compliance-System.

7) Ausnahmen eng und befristet fuehren

Ausnahmen sind realistisch. Manche Altanwendung, VPN-Komponente oder Remote-Support-Strecke kann den Rollout bremsen. Trotzdem sollten Ausnahmen nicht zu einem zweiten Normalzustand werden.

Eine brauchbare Ausnahme enthaelt:

  • betroffene Systeme oder Gruppen,
  • fachlichen Owner,
  • konkreten technischen Grund,
  • Risikoentscheidung,
  • Ablaufdatum,
  • geplante Abloesung oder Herstellerklaerung,
  • kompensierende Massnahmen wie weniger privilegierte Nutzung, eingeschraenkte Admin-Logons oder Netzsegmentierung.

Ohne Ablaufdatum wird Credential Guard schnell zu einer Policy fuer "alle neuen Geraete ausser den wichtigen Altlasten". Genau dort liegen aber oft die wertvollen Sessions.

8) In Wellen ausrollen

Ein pragmatischer Ablauf:

  1. Zielgruppen nach AD-Risiko priorisieren.
  2. Hardware-, Firmware- und VBS-Eignung erfassen.
  3. Pilot-OUs oder Pilot-Geraetegruppen bilden.
  4. Credential Guard ohne harte Ruecknahmesperre testen.
  5. SSO, VPN, RDP, Admin-Tools und EDR-Kompatibilitaet validieren.
  6. Compliance-Messung aufbauen.
  7. Tier-0- und Admin-Systeme zuerst verbindlich machen.
  8. Standard-Clients in Wellen nachziehen.
  9. Ausnahmen befristen und regelmaessig reviewen.
  10. Zielzustand in Client-Baselines und Join-/Provisioning-Prozesse uebernehmen.

Credential Guard ist am staerksten, wenn neue Systeme direkt korrekt provisioniert werden. Nachtraegliches Aufraeumen in einer heterogenen Flotte bleibt moeglich, ist aber deutlich aufwaendiger.

Vorteile

  • Weniger verwertbare Credentials im normalen OS-Kontext: NTLM-Hashes und Kerberos-Material sind schwerer aus einer kompromittierten Session zu gewinnen.
  • Besserer Schutz fuer Admin-Workflows: Privilegierte Sessions auf PAWs, Admin-Clients und Management-Systemen werden robuster.
  • Starkes Signal fuer Tiering: Systeme mit wertvollen Identitaeten bekommen eine messbare technische Zusatzbarriere.
  • Passt zu weiteren AD-Massnahmen: LSASS Protected Process, WDigest-Off, NTLM-Reduktion, Protected Users und restriktive Logon-Pfade ergaenzen sich.
  • Gute Compliance-Faehigkeit: Der Zustand laesst sich ueber Betriebssystem- und Endpoint-Management-Daten nachweisen.
  • Kein neues Drittprodukt erforderlich: Die Funktion ist Teil moderner Windows-Sicherheitsarchitektur, sofern Edition, Hardware und Management passen.

Nachteile und Grenzen

  • Nicht jedes System ist geeignet: Alte Hardware, BIOS/UEFI-Einstellungen, Treiber oder Virtualisierungsanforderungen koennen blockieren.
  • Kompatibilitaet ist der Hauptaufwand: SSO, VPN, RDP, Credential-Provider und Legacy-Authentifizierung muessen real getestet werden.
  • Rollback kann hart werden: UEFI-Lock-Varianten erschweren die Ruecknahme. Das gehoert nicht unvorbereitet in den Pilot.
  • Schuetzt nicht alle Geheimnisse: Lokale Konten, Browser-Tokens, Applikationsgeheimnisse und bereits kompromittierte Sessions brauchen eigene Kontrollen.
  • Kein Ersatz fuer Least Privilege: Wenn Admins ueberall interaktiv arbeiten duerfen, reduziert Credential Guard nur einen Teil des Schadens.
  • Betrieb braucht Messung: Ohne Compliance-Daten entsteht schnell eine Scheinsicherheit durch gesetzte Policies.

Typische Stolperfallen

  • Nur "enabled" in der Policy pruefen: Entscheidend ist, ob Credential Guard wirklich auf dem Endpunkt laeuft.
  • UEFI Lock zu frueh setzen: Ein Pilot muss einfach ruecknehmbar bleiben.
  • Admin-Systeme nicht priorisieren: Breiter Client-Rollout ist gut, aber Tier-0- und Admin-Workstations liefern den groessten Risikonutzen.
  • RDP und gespeicherte Credentials vergessen: Genau dort fallen alte Arbeitsablaeufe haeufig auf.
  • SSO-Agenten nicht einbeziehen: Drittanbieter-Credential-Provider koennen unerwartete Nebenwirkungen erzeugen.
  • Ausnahmen nicht befristen: Dauerhafte Ausnahmegruppen untergraben den Sicherheitsgewinn.
  • Credential Guard als Allheilmittel verkaufen: Es ist ein Schutzbaustein, kein Ersatz fuer AD-Tiering, MFA, PAWs und saubere Rechte.
  • Keine neue Provisioning-Regel setzen: Neue Geraete muessen direkt mit der Zielbaseline kommen, sonst bleibt der Rollout ein Nacharbeiten.

Projekt-Checkliste

  • [ ] Admin-, Tier-0-, Helpdesk- und Management-Systeme als ersten Scope definieren.
  • [ ] Hardwaremodelle, Firmware-Modus, Secure Boot, Virtualisierung und VBS-Status erfassen.
  • [ ] GPO-, Intune- oder ConfigMgr-Zielbild festlegen.
  • [ ] UEFI-Lock-Strategie separat entscheiden und im Pilot nicht unbedacht aktivieren.
  • [ ] VPN, WLAN, RDP, SSO, Smartcard, RSAT, PowerShell Remoting und EDR-Kompatibilitaet testen.
  • [ ] Pilotgruppe mit echten Admin-Workflows aufbauen.
  • [ ] Aktivierung ueber Win32_DeviceGuard, LsaIso und Endpoint-Management-Compliance verifizieren.
  • [ ] Support- und Rollback-Prozess fuer Pilotgeraete dokumentieren.
  • [ ] Ausnahmen mit Owner, Grund, Ablaufdatum und kompensierenden Massnahmen fuehren.
  • [ ] Tier-0- und Admin-Systeme zuerst verbindlich machen.
  • [ ] Standard-Clients in Wellen nachziehen.
  • [ ] Zielbaseline in Provisioning, Join-Prozess und regelmaessige Compliance-Reviews uebernehmen.