Flexible Security for Your Peace of Mind

Sichern Sie Authentifizierungstokens indem Sie die Delegierung von Administratorkonten verhindern

Die zugrundeliegenden Funktionen der Kerberos-Authentifizierung in Active Directory bedeuten, dass Zugriffstoken für verschiedene Zwecke an Benutzer und Computer delegiert werden können. Angreifer können die integrierten Funktionen von Active Directory via Impersonation und Delegation ausnutzen, um sensible Ressourcen oder Daten zu kompromittieren. In diesem Artikel werden wir die empfohlenen Einstellungen in Active Directory beschrieben, um das Risiko im Zusammenhang mit der Delegierung von Konten auf unsicheren Computern und Administratorkonten zu mindern.

Access Token und Identitätswechselstufen

In einer Client-Server-Umgebung ermöglicht ein spezielles Token, das so genannte Impersonation-Token (Identitätswechseltoken), einem Thread die Ausführung im Sicherheitskontext eines Benutzers oder Computers.

Bestimmte Netzwerkdienste, die in der Umgebung laufen, bestimmen die zugewiesenen Berechtigungen und Zugriffsebenen auf der Grundlage des Identitätswechseltokens. Wenn beispielsweise bestimmte Serverdienste ausgeführt werden, verwenden sie kurzzeitig das Identitätswechseltoken, um die zugewiesenen Berechtigungen und die Ressourcen zu bestimmen, auf die ein Benutzer zugreifen kann.

Wenn dieser Token aufgerufen wird, bedeutet dies, dass der Client dem Server erlaubt hat, in seinem Namen als Client zu handeln. Es gibt verschiedene Stufen des Identitätswechsels, die von Microsoft als Impersonation-Levels ( Identitätswechselstufen) bezeichnet werden. Jede Stufe bestimmt die Berechtigung des Servers, im Namen des Clients zu handeln.

Es gibt vier Identitätsstufen:

  • Anonym – Der Client ist für den Server anonym. Der Server kann sich zwar für den Client ausgeben, aber das Identitätswechseltoken enthält keine Informationen über den Client.
  • Identify (Identifizieren) – Die Standardstufe des Systems ist für Identify konfiguriert. Mit dieser Stufe kann der Server die Identität des Clients nachbilden, um ACL-Prüfungen (Access Control List) durchzuführen.
  • Impersonate (Identitätswechsel) – Mit der Stufe Impersonate kann der Server die Identität des Clients und seines Sicherheitskontextes annehmen. Der Server kann unter der Identität des Clients auf lokale Ressourcen zugreifen. Bei Remote-Ressourcen kann er nur auf Ressourcen zugreifen, die sich auf demselben System wie der Server befinden.
  • Delegate (Stellvertretung) – Der Delegate-Level ist der mächtigste und gefährlichste der Impersonation-Level (Identitätsstufen). Wenn sie ausgewählt ist, kann der Server die Anmeldeinformationen des Clients, sowohl lokal als auch remote, verkörpern. Diese können an alle Computer weitergegeben werden.

Mehr Informationen zu den Impersonation Levels (Identitätswechselebenen) erhalten Sie direct bei Microsoft:  EN: Impersonation Levels (COM) – Win32 apps | Microsoft Learn; DE: Identitätswechselebenen

Für die Verwendung der Identitätsstufe  “Stellvertretung” sind zusätzliche Anforderungen zu erfüllen. Dazu gehören:

  • Der Client muss die Identitätsstufe auf RPC_C_IMP_LEVEL_DELEGATE setzen.
  • Das Serverkonto muss im Active Directory-Dienst mit dem Attribut “Trusted for delegation” gekennzeichnet sein.
  • Alle fraglichen Server und Clients müssen in der gleichen Domäne ausgeführt werden.

Auswirkungen auf die Sicherheit von delegierbaren Administratoren

Mit frei verfügbaren Tools müssen Angreifer nur einen Client kompromittieren und auf ein Standardkonto zugreifen. Sobald sie einen Fuß in der Tür haben, können sie Tools wie Meterpreter verwenden, um die verfügbaren Stellvertretung-Tokens aufzulisten. Privilegierte Konten mit verfügbaren Sellvertretung-Tokens können dazu führen, dass der Angreifer ein privilegiertes Benutzer-Token, wie z. B. ein Domänen-Administrator-Konto, stehlen kann. Sobald der Angreifer über ein Domänenadministratorkonto verfügt, sind die Möglichkeiten endlos.

Sobald sie über privilegierte Konten auf hoher Ebene verfügen, haben sie es oft auf Backup-Dateien abgesehen, die wertvolle Ziele enthalten können, wie z. B. Backups der NTDS.DIT-Datenbank von Active Directory. Wenn sie gefunden werden, können sie die Datenbank an einen anderen Ort kopieren und ein Offline-Tool ausführen, um die Konten in der Organisation weiter zu kompromittieren.

Die Einstellung “Account is sensitive and cannot be delegated”

Microsoft hat eine Einstellung in den Active Directory-Domänendiensten bereitgestellt, mit der das Problem entschärft werden kann. Darüber hinaus wird empfohlen, eine Active Directory-Einstellung für privilegierte Konten in der Domäne zu aktivieren. Die Einstellung in den Kontoeigenschaften lautet ” Account is sensitive and cannot be delegated”.

Wenn diese Einstellung konfiguriert ist, wird dem Konto das Token für das Delegate (Stellvertretung)-Level entzogen, wodurch die Anmeldeinformationen des Benutzers entfernt werden. Wenn sie konfiguriert ist, wird die Anmeldung zu einer ANONYMOUS-Anmeldung ohne Ressourcenberechtigungen.

“The Account is sensitive and cannot be delegated” Einstellungsoption in Active Directory

Wenn Computer kompromittiert werden, die für das Delegation-Level berechtigt sind, dann können Angreifer diese nutzen, um auf Daten zuzugreifen, die auf anderen Servern gespeichert sind, indem sie delegierte Anmeldeinformationen verwenden. Daher empfiehlt Microsoft, die Einstellung ” Account is sensitive and cannot be delegated” (Konto ist vertraulich und kann nicht delegiert werden) auf allen unsicheren Computern zu verwenden, die wenig oder keine physische Sicherheit oder Administratorkonten haben, wie z. B. Domänenadministratoren.

Domänenadministratorkonten haben enorme Domänenprivilegien und praktisch unbegrenzten Zugriff auf Serverressourcen und Daten in der Organisation. Wenn Computer für die Delegation zugelassen sind, können Sie außerdem eingeschränkte Delegation und andere Einstellungen verwenden, um das Risiko bei der Verwendung von Delegation zu verringern.

Specops Delegable Admins Bericht

Aus Sicherheitsgründen und zur Stärkung der Cybersicherheitslage Ihres Unternehmens ist es von entscheidender Bedeutung, einen Überblick über Administratorkonten zu haben, für die nicht die Einstellung ” Account is sensitive and cannot be delegated” konfiguriert ist. Sie können zwar PowerShell-Skripte erstellen, um die verschiedenen Attribute von Benutzern und Computern in der Domäne abzufragen, aber es gibt einen viel einfacheren Weg. Unser kostenloser Specops Password Auditor enthält einen Bericht “Delegable Admins” welcher eben jene Accounts auflistet.

Mit dem Bericht “Delegable Admins” bietet Specops Auditor einen schnellen Überblick über alle Konten auf Admin-Ebene. Unternehmen, die an der Sicherung von Authentifizierungstoken interessiert sind, werden diesen Bericht nützlich finden, um zu prüfen, welche Konten in ihrer Umgebung als ” vertraulich und nicht delegierbar” gekennzeichnet werden sollten.

Delegable Admins Bericht im Specops Password Auditor

Neben dem Delegable Admins-Bericht bietet Specops Auditor viele weitere Funktionen und Berichte, die nützlich sind, um die Sicherheit von Active Directory-Konten zu erhöhen, einschließlich der Ermittlung von Konten mit kompromittierten Passwörtern.

FAQ zu Delegation und Identitätswechsel

Warum kann Delegierung gefährlich sein? Die Delegierung von unsicheren Computern oder privilegierten Konten, wie z. B. Domänenadministratorkonten, kann zwar in bestimmten Anwendungsfällen eingesetzt werden, stellt aber ein Ziel für Angreifer dar, um Angriffe zur Ausweitung der Berechtigungen durchzuführen.

Gibt es Möglichkeiten, das Risiko der Konto-Impersonation zu mindern? Ja, Microsoft bietet eine Einstellung in Active Directory mit der Bezeichnung “Konto ist sensibel und kann nicht delegiert werden”. Wenn diese Option für ein Konto gesetzt wird, wird das Konto als vertraulich eingestuft und die Berechtigung auf Delegation-Level entfernt, wodurch eine ANONYMOUS-Anmeldung erzwungen wird. Wenn Delegation-Level verwendet wird, sollte außerdem die eingeschränkte Delegierung konfiguriert werden, um den Bereich der Delegierung zu begrenzen. Letzendlich müssen Administratoren alle Administratorkonten, die nicht als vertraulich gekennzeichnet sind, im Blick behalten.

Wie können Administratorkonten ohne das als sensibel gekennzeichnete Konto gefunden werden? Mithilfe von PowerShell können Sie konfigurierte Attribute abfragen und Administratorkonten finden, die nicht als sensibel gekennzeichnet sind. Specops Password Auditor bietet jedoch mit dem Bericht “Delegable Admins” einen einfacheren Weg. Er ermöglicht die Erstellung von ausführlichen Berichten, in denen delegierbare Administratorkonten und andere kennwortrelevante Audits aufgeführt sind.

Specops Password Auditor
Überprüfen Sie Ihr Active Directory jetzt auf riskante Einstellungen oder passwortrelevante Schwachstellen

(Zuletzt aktualisiert am 14/02/2023)

Tags: , , ,

Zurück zum Blog