Abwehr von Identitätsdiebstahl (Credential Theft) im Microsoft Windows Server 2016

In Teil vier der Blogserie geht es darum, wie man den Diebstahl von Credentials in Verbindung mit Windows Server 2016 verhindern bzw. abwehren kann. Die beiden folgenden Features sind auch nicht mit Windows Server 2016 neu erschienen.

  • Credential Guard
  • Remote Credential Guard

Credential Guard gibt es bereits seit den Anfängen von Windows 10. Remote Credential Guard ist seit dem Anniversary Update von Windows 10 verfügbar. Da dies der Fall ist, werden die beiden Features, ebenso wie die bisher vorgestellten Features in dieser Blogserie, hier auch nicht in aller Ausführlichkeit beschrieben.

Credential Guard

Durch den Einsatz von Credential Guard sind Angriffe mittels „Pass the hash“ oder „Pass the ticket“ nicht mehr möglich. Ebenso hat Malware, selbst wenn sie mit administrativen Rechten laufen sollte, keinen Zugriff auf die gespeicherten Geheimnisse. Dies liegt daran, dass die durch die Local Security Authority (LSA) abgelegten Hashes der Domänen Benutzer nicht länger im lokalen LSA Store gespeichert werden, sondern in einer neuen virtualisierten Komponente, die Isolated LSA Prozess (LSAIso) genannt wird. Diese beschützt die darin gespeicherten Geheimnisse durch die Nutzung von virtualization-based Security (VBS), so dass diese nicht mehr durch entsprechende Tools ausgelesen werden können. Alle Passwort-Hashes der lokalen Benutzer können jedoch weiterhin ausgelesen werden. Ebenfalls auch diejenigen Credentials, die vor der Aktivierung von Credential Guard dazu genutzt worden sind, sich an dem System zu authentifizieren. Standardmäßig werden die letzten 10 Anmeldeinformationen gespeichert. Die Kommunikation zwischen LSA und LSAIso geschieht mittels Remote Procedure Calls (RPC).

Quelle: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard

Ohne Credential Guard können diese Informationen mit speziellen Tools ausgelesen werden. Die Namen dieser Tools werde ich hier nicht nennen, aber sie sollten eigentlich den Lesern, die sich schon einmal mit „Pass the hash“ oder „Pass the ticket“ Angriffen befasst haben, bekannt sein.

Credential Guard kann auf mehreren Wegen aktiviert werden. Im Einzelnen sind dies:

  • Durch Gruppen Richtlinien
  • Über einen Eintrag in der Registrierung
  • Durch das Device Guard und Credential Guard Hardware readiness Tool

Für die Kennwörter von lokalen Administratoren bietet sich LAPS an, die Microsoft Lösung um sichere Passwörter für lokale Administratoren zu erzeugen, so dass nicht auf allen Computern dasselbe Passwort verwendet wird. Die Komplexität des Passwortes lässt sich ebenfalls festlegen. Mit Hilfe dieses Tools können die Passwörter auch in regelmäßigen Intervallen erneuert werden. Die Intervalle lassen sich ebenfalls festlegen. Mehr Informationen zu LAPS gibt es hier: https://technet.microsoft.com/en-us/mt227395.aspx.

Mein Kollege Alexander Benoit hat dazu ebenfalls einen Blogartikel verfasst, in dem auch die Einrichtung von LAPS beschrieben wird. Dieser ist hier zu finden: https://de.it-pirate.eu/microsoft-local-administrator-password-solution-laps/

Credential Guard kann nicht nur auf physischen Computern eingesetzt werden, sondern auch in virtuellen Maschinen. Die Aktivierung bzw. Nutzung erfolgt auf die gleiche Weise, wie die, die vorhin schon beschrieben worden ist. Für die Nutzung in virtuellen Maschinen gelten jedoch die nachfolgend genannten Voraussetzungen:

  • Der Hyper-V Host muss eine I/O Management Memory Unit (IOMMU) besitzen und mindestens Windows Server 2016 oder Windows 10, Version 1607 installiert haben
  • Die virtuelle Maschine muss eine Generation 2 VM sein, einen aktivierten virtuellen TPM Chip besitzen und mindestens Windows Server 2016 oder Windows 10 installiert haben

Diese Voraussetzungen, für den Einsatz von Credential Guard auf virtuellen Maschinen, können auch unter dem folgenden Link nachgelesen werden: https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-manage.

Der Einsatz von Credential Guard auf einem Domain Controller bringt jedoch keinerlei Vorteile. Credential Guard schützt keine Credentials, die auf der Festplatte oder im Active Directory SAM gespeichert sind. Erhält ein Angreifer einen (nicht autorisierten) Zugang zu einem Domain Controller und ist in der Lage Informationen aus dem LSASS Speicher zu lesen, dann hat er bereits Domänen Administratoren Rechte erlangt. In diesem Fall, unter Berücksichtigung der am Anfang dieses Abschnittes genannten Informationen, bringt Credential Guard keinen zusätzlichen Schutz auf Domain Controllern. Siehe dazu auch den folgenden Link:

https://blogs.technet.microsoft.com/datacentersecurity/2017/02/21/why-you-should-not-enable-credential-guard-on-domain-controllers/

Bevor man schließlich Credential Guard in einer Produktivumgebung ausrollt und aktiviert, sollten alle Applikationen, die eine Autorisierung verwenden, im Vorfeld ausgiebig getestet werden, ob diese auch noch wie gewünscht funktionieren. Unter https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard sind einige weitere Szenarien zu finden, in denen Credential Guard keine Hilfe darstellt. Dies sind unter anderem Key Logger oder physische Angriffe. Zum Abschluss noch ein weiterführender Link zu Credential Guard:

Übersicht Credential Guard: https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard

Remote Credential Guard

Remote Credential Guard (RCG) erweitert gewissermaßen die Idee von Credential Guard. Damit werden die Authentifizierungs-Tickets für Remote Desktop Session Hosts geschützt. Die Credentials der Person, die sich anmeldet, verlassen niemals die lokale Maschine von der aus die Anmeldung durchgeführt wird; vorausgesetzt man nutzt zur Authentifizierung Kerberos. Dazu muss man, wenn man sich verbinden will, den Host-Name verwenden und nicht die IP-Adresse. Im Speicher des RDP Servers werden keinerlei Credentials gespeichert. Dadurch ist es einem bösartigen Prozess auf dem RDP Server nicht möglich, dort Credentials zu sammeln.

Die folgende Übersicht zeigt, was die Unterschiede von RCG im Vergleich zu einer RDP Verbindung zu einem Server, der mit Credential Guard geschützt ist, und zu einer normalen RDP Verbindung, zu einem ungeschützten Server, sind.

Quelle: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/remote-credential-guard

Da Remote Credential Guard erst mit dem Anniversary Update von Windows 10 (Version 1607) eingeführt worden ist, kann es in den vorherigen Versionen in Verbindung mit Windows Server 2016 nicht eingesetzt werden. Unter dem folgenden Link gibt es sowohl eine Übersicht zu Remote Credential Guard als auch eine Liste von Einschränkungen, die bei der Nutzung von RCG beachtet werden müssen.

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/remote-credential-guard

Dies war der letzte Teil der Blogartikelserie zu Sicherheitsfeatures, die in Windows Server 2016 zur Verfügung stehen. Die übrigen Features und Themen von Microsoft Windows Server 2016 wurden von meinen Kollegen betrachtet, die jeweils eigene Blogartikel dazu verfasst haben.

Teil 1: Grundlegendes zur Sicherheit im Microsoft Windows Server 2016
Teil 1.1: Sicherheit im Bereich Virtualisierung (Shielded VMs)
Teil 1.2: Sicherheit im Bereich Virtualisierung (Hyper-V Container & Software Defined Networking)
Teil 2: Sicherung des OS
Teil 3.1: Verwaltung von Identitäten (Just Enough Administration)
Teil 3.2: Verwaltung von Identitäten (Just in Time Administration & MFA)
Teil 4: Abwehr von Identitätsdiebstahl (Credential Theft)

Add new comment
By submitting this form, you accept the Mollom privacy policy.