Best Practice versus Realität Identitätsrisiko Shadow-Admins

Der Begriff Shadow-IT beschreibt informationstechnische Identitäten, Systeme, Prozesse und Organisationseinheiten, die in den Fachabteilungen eines Unternehmens neben der offiziellen IT-Infrastruktur und ohne das Wissen des IT-Bereichs angesiedelt sind. Shadow Admins sind Identitäten, die meist als Abkürzung verwendet werden, um Abläufe zu erleichtern. Praktisch, aber die bergen große Risiken.

Shadow-IT-Instanzen sind weder technisch noch strategisch in das IT-Service-Management der Organisation eingebunden. sie werden nicht selten als Abkürzung verwendet, um Abläufe zu erleichtern – und dies entgegen bestehender Prozesse der IT. Ob das ein USB-Stick am Firmencomputer ist oder hoch privilegierter Service-Benutzer, der für andere als die vorgesehenen Tätigkeiten missbraucht wird. Shadow-IT ist allgegenwärtig und für Firmen ein ernst zu nehmendes Risiko. Denn Sicherheitsteams fehlt oft die nötige Transparenz, um wirksame Sicherheitskontrollen einziehen zu können.

Shadow-Administratoren: Das Pendant zur Shadow-IT, allerdings für Unternehmensidentitäten.

Die Definition umfasst sämtliche hoch privilegierte Konten, von denen IT oder Sicherheitsteams nichts wissen beziehungsweise, die innerhalb des Unternehmens völlig falsch verwendet werden. Folglich werden diese Konten nicht in PAM- oder andere Lösungen für das Identity Access Management verwaltet. Zu Shadow-Administratoren zählen häufig Service-, Admin- oder Helpdesk-Benutzer, die nicht standardmäßig zur Gruppe der Domänen-Administratoren gehören. Vielmehr wurden ihnen Privilegien für Objekte, Gruppen oder Benutzer zugewiesen - in diesem Fall mit Zugriff auf den Domain Level. Sie werden häufig falsch konfiguriert oder fälschlich in Unternehmensumgebungen verteilt.

Best Practice versus Realität

Gemäß Best Practices wird ein Admin-Benutzer angelegt, indem man das betreffende Konto der Domain-Admin-Gruppe in Active Directory (AD) hinzufügt. Der Benutzer selbst hat keine Administratorenrechte. Aber als Teil der Domain-Admin-Gruppe erhält er die Erlaubnis, auf privilegierte Server zuzugreifen und entsprechende Aktivitäten auszuführen. Dadurch bekommt er einen Überblick darüber, welche Konten über welche Privilegien verfügen. Theoretisch sollten IT-Teams anhand der Benutzerliste in der Domain-Admin-Gruppe all die privilegierten Konten erkennen können, die auf die „Kronjuwelen“ des Unternehmens zugreifen oder Änderungen vornehmen können. AD zeichnet automatisch auf, wenn innerhalb der Domain-Admin-Gruppe etwas passiert. Das dient dazu, den Prüfprozess zu optimieren und die Bereitstellung von Privileged Access Management (PAM)-Lösungen zu vereinfachen. Hier lassen sich alle Domain-Admins archivieren, anstatt den Zugriff Benutzer für Benutzer verwalten zu müssen. In einer idealen Welt würde man alle Administrator- und Dienstkonten gemäß diesem Protokoll angelegen. Die Realität sieht anders aus. Es gibt verschiedene Möglichkeiten, wie man ein Konto falsch konfigurieren und es mit höheren Privilegien ausstatten kann als es eigentlich haben sollte. IT-Teams ahnen nichts von der Existenz dieser Konten und haben keinerlei Überblick über die Aktivitäten.

Verschachtelte Gruppenmitgliedschaft

Verschachtelte Gruppenmitgliedschaften werden normalerweise eingerichtet, weil sie die Zuweisung von Berechtigungen über mehrere Domains hinweg erleichtern. Dies senkt üblicherweise den Aufwand für IT-Administratoren erheblich. Die Beziehung zwischen den einzelnen Gruppen wird jedoch tendenziell schnell unübersichtlich. Das führt dann beispielsweise dazu, dass unbeabsichtigt Administratorenrechte für eine ganze Gruppe gewährt werden. Rechte, die diese Gruppe nicht braucht und von deren Vergabe die IT-Abteilung keine Ahnung hat. Rechte, die folglich auch nicht innerhalb einer PAM-Lösung verwaltet werden. Wenn beispielsweise Gruppe A zu Gruppe B hinzugefügt wird, Gruppe B zu Gruppe C und Gruppe C Teil eines Domain-Admins ist, tröpfeln die Privilegien von Gruppe C zu Gruppe A herunter und machen jeden Benutzer innerhalb dieser Gruppe zu einem Schatten-Admin.

In einem realen Szenario könnte die Domain-Gruppe Vertrieb zur Gruppe der Backup-Operatoren hinzugefügt werden, die wiederum Teil der Exchange-Gruppe ist und ihrerseits Teil eines Domain-Administrators ist. Auf diese Weise erbt die gesamte Vertriebsgruppe die Administratorenrechte, die allen anderen Domänen, zu denen sie gehört, gewährt wurden. Gleichzeitig entgehen ihre Mitglieder der Prüfung der Domain-Admin-Gruppe. Denn die zeigt nur die Liste der Benutzer an, die direkt zu dieser Gruppe hinzugefügt wurden. Ein ernsthaftes Sicherheitsproblem, denn plötzlich hat man eine ganze Gruppe von Schatten-Administratoren, die weder verwaltet noch überwacht werden. Ideale Voraussetzungen für einen Angreifer, sich auf dieser Basis weiter im Netzwerk vorwärts zu bewegen.

Direkte ACL

Eine Access Control List (kurz ACL) ist eine Reihe von Regeln, die festlegen, welche Benutzer welche Berechtigungen für ein bestimmtes AD-Objekt halten, z.B. andere Benutzerkonten, Domains oder Rechnerkonten. Ein Schatten-Administrator entsteht, wenn ein Benutzer einer Kombination von ACLs zugewiesen wird, die ihm die gleichen Rechte zugestehen wie einem Administrator.

Wenn man eine Unternehmensumgebung auf exponierte, nicht verwaltete und falsch konfigurierte Identitäten scannt, stößt man häufig auf Benutzer, die eine Kombination von Berechtigungen halten, die sie faktisch zu Administratorkonten macht. Und zwar, ohne dass sie Teil der Administrator-Domain sind. So kann es beispielsweise vorkommen, dass ein Level 1 Helpdesk-Administrator, der für das Zurücksetzen von Passwörtern zuständig ist, eine unerklärliche Level-3-Berechtigung zum Hinzufügen von Konten zu einem Domain-Admin hält.

Solche Vorkehrungen werden meist zu einem Zeitpunkt getroffen, zu dem sie als sinnvoll erachtet wurden. Üblicherweise, um einen bestimmten Vorgang zu vereinfachen oder zu beschleunigen. Benutzer halten also Berechtigungen, die mit einem real nicht mehr existierenden Zweck verbunden sind und folglich gerne vergessen werden. Auch das sind Schatten-Admins, denn sie können auf

privilegierte Assets zugreifen und diese ändern, ohne dass sie in einer IT- oder einer PAM-Lösung verwaltet werden.

Chain of Ownership

Eine weitere Möglichkeit durch die Schatten-Admins versehentlich entstehen, ist die Chain of Ownership von Konten. Wenn Benutzer A, der über die Berechtigung zum Anlegen neuer Konten verfügt, Benutzer B anlegt, bleibt Benutzer A Besitzer von Benutzer B. Sollte Benutzer B höhere Privilegien erhalten, hätte Benutzer A - da er diesen Benutzer angelegt hat und ihn „besitzt“ - ebenfalls Zugriff auf dem gleichen Berechtigungslevel.

Diese Art von Schatten-Administratoren ist beispielsweise in Helpdesk-Gruppen üblich. In einem Fall entdeckte Illusive beim Scannen der potenziellen Angriffsfläche eines Unternehmens eine komplette Helpdesk-Gruppe, die effektiv Schatten-Administratoren waren. Diese Helpdesk-Gruppe hatte zunächst die Erlaubnis, neue Domain-Administratoren zu erstellen, die ihr danach wieder entzogen wurde. Nach dem Entzug der Privilegien verblieb der Gruppe aber die Eigentümerschaft an allen von ihr erstellten Domain-Admins. Einem Angreifer war es in der Folge gelungen, diese zu kompromittieren. So gelang es ihm, sich durch die gesamte Chain of Ownership zu bewegen und auf privilegierte Konten zuzugreifen.

Dies gilt auch für deaktivierte Konten. Übliche Scan-Tools heben Beziehungen zwischen aktiven Konten hervor und ignorieren diejenigen, die deaktiviert wurden. Wird ein Konto deaktiviert, verbleibt es im Besitz desjenigen Benutzers, der es ursprünglich angelegt hat. Auch hier kann ein Angreifer nach einer Kompromittierung das Konto wieder aktivieren und Privilegien ausweiten.

Schatten-Administratoren: Denken wie ein Angreifer, Risiken senken

Das Risiko eines Schatten-Administrators kommt selten allein. In einer Unternehmensumgebung gibt es normalerweise eine Fülle von nicht korrekten Konfigurationen und Fehlern, die gleichzeitig auftreten. Lokal auf einem System gespeicherte Anmeldeinformationen, gespeicherte FTP-, SSH- und Datenbank-Anmeldeinformationen und veraltete Passwörter für privilegierte Domain-Konten - die Liste lässt sich beliebig fortsetzen. Das Ganze verschlimmert sich zumeist, wenn ein AD in die Jahre kommt: Die Entropie steigt, neue Benutzer und neue Domänen werden angelegt und gerne Abkürzungen genommen. Gelingt es einem Angreifer, einen Schatten-Administrator zu kompromittieren, sind die Kronjuwelen oft nur noch einen Schritt weit entfernt. Das ist dann der "letzte Schritt" bis zur Übernahme der gesamten Domain. Unternehmen nutzen üblicherweise Penetrationstests, um Identitätsrisiken, wie z.B. Schatten-Administratoren, zu identifizieren. Red Teams verwenden Tools wie AdFind, Mimikatz und BloodHound, um solche Identitäten zu erkennen und den Weg zu den wichtigsten Unternehmens-Assets zu finden. Dieser Ansatz kommt jedoch schnell an seine natürlichen Grenzen. Denn er vermittelt nur ein statisches und unvollständiges Bild aller in der Umgebung existierenden Schatten-Administratoren. Dieses Bild reicht nicht aus, um Firmen vor den Risiken zu schützen, die durch Fehlkonfigurationen, andere Fehler und Versäumnisse im Geschäftsbetrieb ständig entstehen.

Sinnvoll ist eine kontinuierliche Überwachung der kompletten Angriffsfläche, um Schatten-Administratoren zu erkennen und zu beseitigen, sobald sie entstanden sind. Moderne Umgebungen verändern sich mit rasantem Tempo und entwickeln sich stetig weiter. Gleichzeitig werden die von Angreifern verwendeten Tools immer raffinierter. Im Idealfall sollte man die betroffenen Identitäten automatisiert erkennen und eindämmen können. Basis sind individuell definierte Richtlinien und die potenzielle Nähe zu den wichtigsten Unternehmens-Assets. Wenn Sicherheitsteams fortschrittliche Ransomware abwehren und den wichtigsten Angriffsvektor von heute, Identitäten, schützen wollen, dann müssen sie die Wege kennen, die ein Angreifer benutzen würde.

Über den Autor: Jochen Rummel ist Director Sales D/A/CH bei Illusive.

(ID:48389962)