Ausgangslage: Anmeldedaten bleiben zu lange erreichbar

Viele AD-Kompromittierungen werden nicht dadurch groß, dass ein einzelnes Benutzerkonto kompromittiert wird. Sie werden groß, 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 Identitäten betroffen".

Credential Guard reduziert genau diesen Hebel. Die Funktion nutzt Virtualization Based Security, um bestimmte abgeleitete Domain-Credentials aus der normalen Windows-Umgebung herauszulösen. LSASS bleibt für Windows sichtbar und nutzbar, aber sensible Geheimnisse werden in einem isolierten Prozessbereich verarbeitet. Das macht Credential-Diebstahl nicht unmöglich, erhöht aber den Aufwand deutlich und schneidet mehrere klassische Seitwärtsbewegungswege 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 für Systeme, auf denen Domain-Anmeldedaten besonders wertvoll sind oder regelmäßig privilegierte Sessions entstehen.

Zielbild: Credential Guard dort, wo Credentials zählen

Ein belastbares Zielbild hat konkrete Eigenschaften:

  1. Admin- und Tier-0-Workstations nutzen Credential Guard standardmäßig. Systeme für Domain-, Server-, PKI-, Backup- und Identity-Administration werden zuerst betrachtet.
  2. Normale Clients folgen in Wellen. Der breite Rollout kommt erst nach Pilot, Kompatibilitätstests 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-Abhängigkeiten sind getestet. Gespeicherte Credentials, alte Authentifizierungswege und bestimmte Credential-Provider werden vorab geprüft.
  5. UEFI Lock wird bewusst behandelt. In der Pilotphase bleibt die Rücknahme 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 läuft.

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

Umsetzung: erst Prüfung, dann Wellen-Rollout

1) Scope nach Risiko festlegen

Starte nicht mit allen Clients. Beginne mit Systemen, auf denen höchstwertige Identitäten verwendet werden:

  • Privileged Access Workstations und Admin-Jumphosts,
  • Helpdesk- und Server-Administrations-Clients,
  • Systeme für Domain Controller, AD CS, Entra Connect, Backup, EDR, PAM und Virtualisierung,
  • Management-Server, auf denen regelmäßig privilegierte Tools laufen,
  • hochkritische Client-Gruppen, die Zugriff auf sensible Geschäftsdaten haben.

Domain Controller brauchen eine eigene Bewertung. Credential Guard ist in erster Linie ein Client- und Workstation-Hardening-Baustein für Credential-Isolation. Auf DCs sind andere Kontrollen wie Tiering, LSASS Protected Process, eingeschränkte 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. Prüfe 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

Ergänzend 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 können. Für den Rollout ist entscheidend, dass du denselben Messpunkt dauerhaft nutzt und nicht nur "Policy gesetzt" mit "Schutz aktiv" gleichsetzt.

3) Kompatibilität vor dem Erzwingen testen

Credential Guard verändert 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-Abhängigkeiten haben,
  • Helpdesk-Tools, Remote-Support und Endpoint-Management,
  • Entwickler- oder Admin-Workflows mit RunAs, MMC, RSAT und PowerShell Remoting.

Der Test muss echte Arbeitsabläufe 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 Betriebsabhängigkeit auftauchen.

4) Policy über GPO oder MDM setzen

In klassischen AD-Umgebungen läuft die Einführung häufig über 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 über Intune Security Baselines oder Endpoint Security Policies abgebildet werden. Entscheidend ist nicht das Werkzeug, sondern der Scope, die Nachweisbarkeit und der Rückfallplan.

5) Pilot sauber schneiden

Ein sinnvoller Pilot ist klein, aber echt:

  1. Zwei bis fünf Hardwaremodelle oder Standard-Client-Builds auswählen.
  2. Admin- und Nicht-Admin-Nutzung getrennt testen.
  3. VPN, RDP, WLAN, SSO, Browser, RSAT, PowerShell Remoting und EDR-Health prüfen.
  4. Helpdesk und Endpoint-Team in die Fehlersuche einbinden.
  5. Ereignisse, Support-Tickets und Performance-Auffälligkeiten für 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 läuft.

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.

Für 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

Für die Flotte gehört der Check in vorhandene Management-Werkzeuge. Einzelne PowerShell-Ausgaben sind gut für Analyse und Fehlersuche, aber kein dauerhaftes Compliance-System.

7) Ausnahmen eng und befristet führen

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 enthält:

  • betroffene Systeme oder Gruppen,
  • fachlichen Owner,
  • konkreten technischen Grund,
  • Risikoentscheidung,
  • Ablaufdatum,
  • geplante Ablösung oder Herstellerklärung,
  • kompensierende Maßnahmen wie weniger privilegierte Nutzung, eingeschränkte Admin-Logons oder Netzsegmentierung.

Ohne Ablaufdatum wird Credential Guard schnell zu einer Policy für "alle neuen Geräte außer 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-Gerätegruppen bilden.
  4. Credential Guard ohne harte Rücknahmesperre testen.
  5. SSO, VPN, RDP, Admin-Tools und EDR-Kompatibilität validieren.
  6. Compliance-Messung aufbauen.
  7. Tier-0- und Admin-Systeme zuerst verbindlich machen.
  8. Standard-Clients in Wellen nachziehen.
  9. Ausnahmen befristen und regelmäßig reviewen.
  10. Zielzustand in Client-Baselines und Join-/Provisioning-Prozesse übernehmen.

Credential Guard ist am stärksten, wenn neue Systeme direkt korrekt provisioniert werden. Nachträgliches Aufräumen in einer heterogenen Flotte bleibt möglich, ist aber deutlich aufwändiger.

Vorteile

  • Weniger verwertbare Credentials im normalen OS-Kontext: NTLM-Hashes und Kerberos-Material sind schwerer aus einer kompromittierten Session zu gewinnen.
  • Besserer Schutz für Admin-Workflows: Privilegierte Sessions auf PAWs, Admin-Clients und Management-Systemen werden robuster.
  • Starkes Signal für Tiering: Systeme mit wertvollen Identitäten bekommen eine messbare technische Zusatzbarriere.
  • Passt zu weiteren AD-Maßnahmen: LSASS Protected Process, WDigest-Off, NTLM-Reduktion, Protected Users und restriktive Logon-Pfade ergänzen sich.
  • Gute Compliance-Fähigkeit: Der Zustand lässt sich über 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 können blockieren.
  • Kompatibilität ist der Hauptaufwand: SSO, VPN, RDP, Credential-Provider und Legacy-Authentifizierung müssen real getestet werden.
  • Rollback kann hart werden: UEFI-Lock-Varianten erschweren die Rücknahme. Das gehört nicht unvorbereitet in den Pilot.
  • Schützt nicht alle Geheimnisse: Lokale Konten, Browser-Tokens, Applikationsgeheimnisse und bereits kompromittierte Sessions brauchen eigene Kontrollen.
  • Kein Ersatz für Least Privilege: Wenn Admins überall interaktiv arbeiten dürfen, 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 prüfen: Entscheidend ist, ob Credential Guard wirklich auf dem Endpunkt läuft.
  • UEFI Lock zu früh setzen: Ein Pilot muss einfach rücknehmbar bleiben.
  • Admin-Systeme nicht priorisieren: Breiter Client-Rollout ist gut, aber Tier-0- und Admin-Workstations liefern den größten Risikonutzen.
  • RDP und gespeicherte Credentials vergessen: Genau dort fallen alte Arbeitsabläufe häufig auf.
  • SSO-Agenten nicht einbeziehen: Drittanbieter-Credential-Provider können unerwartete Nebenwirkungen erzeugen.
  • Ausnahmen nicht befristen: Dauerhafte Ausnahmegruppen untergraben den Sicherheitsgewinn.
  • Credential Guard als Allheilmittel verkaufen: Es ist ein Schutzbaustein, kein Ersatz für AD-Tiering, MFA, PAWs und saubere Rechte.
  • Keine neue Provisioning-Regel setzen: Neue Geräte müssen 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-Kompatibilität testen.
  • [ ] Pilotgruppe mit echten Admin-Workflows aufbauen.
  • [ ] Aktivierung über Win32_DeviceGuard, LsaIso und Endpoint-Management-Compliance verifizieren.
  • [ ] Support- und Rollback-Prozess für Pilotgeräte dokumentieren.
  • [ ] Ausnahmen mit Owner, Grund, Ablaufdatum und kompensierenden Maßnahmen führen.
  • [ ] Tier-0- und Admin-Systeme zuerst verbindlich machen.
  • [ ] Standard-Clients in Wellen nachziehen.
  • [ ] Zielbaseline in Provisioning, Join-Prozess und regelmäßige Compliance-Reviews übernehmen.