Credential Guard - Schutz vor Pass-the-Hash
Credentials Guard: Ein Türsteher als Schutz vor dem direkten Zugriff auf die LSA - Local System Authority.
Schaut euch die Technik Beschreibungen von Microsoft an, die möchte ich nicht wiederholen. Ich zeige euch später das Problem an dem Credential Guard und was er nicht schützt, aber da er seit der 1607 trivial zu integrieren ist, sollte man ihn einschalten. Der Aufwand ist gering, der Nutzen aber auch ...
Was schützt der Credential Guard? Die Kennworte der Accounts, die in der Local System Authority verwaltet werden. Was ist mit den Kennworten in der Anmeldeinformationsverwaltung? Wo man zB seinen Oultook Office 365 Account liegen hat, oder das Kennwort für den Proxy Zugang oder seine Terminalserver Zugänge?
Die letztgemannten werden nicht geschützt! Deren Hashes, meist sogar die Kennworte in Plaintext sind abgreifbar.
Voraussetzungen, siehe Device Guard - Microsoft Defender Application Control
Das schöne an der Konfiguration ist, wenn ihr Device Guard einsetzt, dann ist Credential Guard schon von euch aktiviert worden.
Computerkonfiguration\Administrative Vorlagen\System\Device Guard
Virtualisierungsbasierte Sicherheit aktivieren
- Plattformsicherheitsstufe auswählen:
Sicherer Start (Sicherer Start mit DMA geht nicht in Hyper-V Gen2 System) - Virtualisierungsbasierter Schutz der Codeintegrität:
Ohne Sperre aktiviert (Mit UEFI Sperre aktviert, dann muss man lokal am Rechner sein, wenn man DGuard abschalten möchte und die Taste "F3" beim Bootvorgang drücken) - UEFI Speicherattribute nicht aktiviert
- CredentialGuard Konfiguration
Ohne Sperre aktiviert (oder siehe oben) - Sichere Startkonfiguration
Nicht konfiguriert (SecureBoot ist schon im UEFI angeschaltet worden, zudem konnten 2 Systeme, virtuell und Blech, nicht mehr starten, wenn es über die GPO zusätzlich gesetzt wurde
-> Lösung Neuinstallation!! ;-)
Gern genommen, bringt aber nichts - Anmeldeinformationsverwaltung deaktivieren:
Computerkonfiguration\Sicherheitseinstellungen\Lokale Richtlinien\Dienste
"VaultSvc" = Deaktiviert (Anmeldeinformationsverwaltung)
Das deaktiviert nur den Zugriff auf die Schnittstelle in den Einstellungen, es kommt zu einer Fehlermeldung. Die Schnittstelle kann weiterhin per rundll32 aufgerufen werden. Die Credentials werden weiterhin gespeichert und sind mit Tools wie mimikatz auslesbar. Siehe Screenshot unten ...
Das war es mit der Richtlinie ist der Credential Guard aktiv. Oder anders gesagt, ihr könnt Credential Guard ohne Device Guard nutzen, aber nicht anders herum.
Kontrolle, ob Credential Guard aktiviert ist:
Zum einen findet ihr die lsalso.exe in der Liste der laufenden Prozesse und zum anderen steht es in in den Systeminformationen (msinfo32.exe)
Ein großes Problem, das wir haben ist, das wir den Schutz vor Pass-the-Hash nur für die Windows Anmeldekennungen erhalten. Andere können weiterhin in Plaintext vorliegen.
Fazit: Credential Guard sollte man unbedingt aktivieren, weil es nur ein Schalter ist, aber es rettet nicht die Welt. Horroscenario: Ein AdminAccount meldet sich an einem unsicheren Client an und speichert seine MSTSC RDP Credentials auf diesem System oder seinen Login für irgendeinen Mist ... oder das macht der Chefentwickler für seinen Webdienst und hat aus Faulheit mal wieder dasselbe Kennwort wie in der Domäne.
Wir können soziale oder strukturelle Probleme nicht mit Technik lösen!
