Arbeiten mit lokalen Administratorkonten unter Windows, Teil II

Bevor wir uns eingehender mit eingeschränkten Gruppen befassen, dachte ich, es könnte vielleicht nicht schaden, einen genaueren Blick darauf zu werfen, wie Hacker Administratorkennwörter ausnutzen. Pass-the-Hash-Fans werden hier erfahren, inwieweit Hashes sogar mit lokalen Konten verwendet werden können. Außerdem hatte ich die Möglichkeit, LAPS (Windows Local Administrator Passwords Solution) zu testen. Wichtiger Hinweis: LAPS macht mir ein bisschen Angst.

Lokale Hashes weitergeben

Nachdem ich den ersten Post geschrieben hatte, stellte ich fest, dass Sie Hashes für Domänenkonten vielleicht gar nicht benötigen. Genau genommen speichert Windows die Hashes für lokale Konten auch in seiner Security Accounts Manager (SAM) Datenbank. Mit Hash Dumping-Tools wie crackmapexec und mimikatz können Sie sich diese Hashes anzeigen lassen.

Dies führt zu einer direkteren seitlichen Bewegungstaktik. Wie bereits beim letzten Mal erwähnt, ist es nicht ungewöhnlich, dass lokale Administratorkonten genau denselben Namen für mehrere Rechner haben. Das würde außerdem bedeuten, dass NTLM-Hashes ebenso gleich wären.

Angenommen ein Hacker erlangt Zugriff auf einen Server und vorausgesetzt er verfügt über ausreichend Rechte und sieht dann mithilfe von mimikatz nach, ob ein lokales Administratorkonto verfügbar ist: Dann kann er einen Versuch starten und den Administrator-Hash an psexec weitergeben, um eine Shell auf einem anderen Server zu knacken und auch dort die Administratorrechte zu erlangen.

Verstehen Sie, worauf ich hinaus will? Wenn Sie davon ausgehen, dass Administratorkennwörter auf verschiedenen Rechner gleich sind, dann sind Sie nicht mehr auf einen Domain-Level-Benutzer angewiesen, der einen Hash im LSASS-Speicher dieses Rechners hinterlassen hat. In diesem Post werden Sie mehr über LSASS erfahren, falls Sie der letzte Satz irritiert haben sollte.

Andererseits sind die lokalen Benutzer-Hashes immer da! Als Hacker oder Pen-Tester bedeutet das, dass Sie immer verschiedene Ideen ausprobieren und Ihre Chancen testen. Also gehen wir aufs Ganze!

Für meine Acme-Domäne habe ich dasselbe lokale Administratorkennwort sowohl auf meinem Masa- als auch auf meinem Taco-Server festgelegt – Taco ist außerdem mein Domämen-Controller. In diesem Szenario befinde ich mich bereits auf Masa und habe mimikatz und psexec hochgeladen.

Übrigens verfügen beide Tools über Quellcode. Daher dürfte es nicht so schwierig sein, sie so zu „optimieren“, dass sie nicht erkennbar sind.

Ich befand mich jetzt unter dem Radar von Masa, konnte aber dort nichts Interessantes finden. Für meine laterale Bewegung hatte ich mimikatz geladen und legte die Hashes über den Befehl lsadump::sam ab.

Angenommen Taco hat auch dasselbe Administratorkennwort, dann verwende ich sekurlsa:pth, um psexec zu starten und eine Shell auf Taco zu erlangen (siehe unten).

Erstaunlich!

Als ich das Administratorkennwort für Taco änderte, hat es nicht funktioniert und psexec konnte keine Shell knacken.

Lektion gelernt: es ist eine gute Idee, verschiedene Administratorkennwörter zu haben.

LAPS und Aspirin

Wenn Sie die lokalen Administratorkennwörter behalten möchten, müssen Sie diese verwalten. Wie bereits im ersten Teil erwähnt, können diese Konten deaktiviert werden und eingeschränkte Gruppen können verwendet werden, um Administratorrechte an Domain-Level-Konten zu übertragen.

Auf alle Fälle wünschen sich Benutzer diese lokalen Konten. Microsoft hat anscheinend den kollektiven Aufschrei von IT-Administratoren wahrgenommen und 2015 seine Local Administrator Passwords Solution (LAPS) veröffentlicht. Diese Lösung wird folgendermaßen beschrieben: „…Lösung des Problems der Verwendung eines gemeinsamen lokalen Kontos mit einem identischen Passwort auf jedem Computer in einer Domäne. LAPS behebt dieses Problem, indem es ein anderes zufälliges Kennwort für das allgemeine lokale Administratorkonto auf jedem Computer in der Domäne festlegt.“

Hört sich einfach an. Wie wir jedoch bereits vorher festgestellt haben, macht Microsoft niemals etwas ganz leicht und problemlos.

Der erste Hinweis war die LAPS-Architektur (siehe unten).

Hmm, es gibt hier eine Client- und Serverseite. In der Dokumentation wird außerdem darauf hingewiesen, dass PowerShell-Skripte ausgeführt werden müssen, und dann noch eine Stelle bezüglich Änderungen des Active Directory-Schemas.

Ich nahm die Herausforderung LAPS mutig an und ging mit der Installation so weit ich konnte, bevor mein Kopf anfing zu hämmern.

Das ist keine einfache Installation. LAPS wird auf Ihren Domämen-Controller sowie auf Client-Computer geladen, die Sie verwalten möchten. Ja, Sie verwenden die Group Management Console, um LAPS auf den Clients zu verteilen.

Wenn Sie die Installation korrekt vornehmen, wird das folgende Popup-Fenster angezeigt, sobald Sie im GPO-Editor zu Computerkonfiguration > Administrative Vorlagen > LAPS navigieren.

Ich hatte Angst davor, „OK“ zu drücken. Theoretisch generiert LAPS zufällige Kennwörter, die sich jetzt zentral auf dem Active Directory in einem neuen Attribut als Plaintext befinden — deshalb mussten Sie auch das AD-Schema aktualisieren.

Manche Sicherheitsprofis haben darauf hingewiesen, dass LAPS seine eigenen Probleme haben kann. Im Grunde genommen verlagern Sie das Problem lediglich von lokalen Rechnern auf das Active Directory.

Zurück zu eingeschränkten Gruppen

Im Anschluss an meinen Exkurs zu LAPS wendete ich mich den eingeschränkten Gruppen zu als die praktischste Möglichkeit für die Verwaltung lokaler Administratorkonten. Ich startete diesen Prozess im vorherigen Post, als ich eine neue AD-Gruppen namens Acme-IT erstellte, die dann an die lokale Administratorgruppe für jeden Rechner in der Acme-Domäne verteilt und dort abgelegt wurde.

Das ist ein ganz netter Trick und eingeschränkte Gruppen ermöglichen der IT die zentrale Steuerung des lokalen Administratorzugriffs.

Es wäre sogar noch schöner, wenn ich meine Domäne segmentieren könnte, sodass eine Benutzergruppe lokale Administratoren für eine Teilmenge der Rechner wäre und eine andere Gruppe eine andere Teilmenge kontrollieren würde – und ich so viele untergeordnete Gruppierungen einrichten könnte wie ich brauche.

Andernfalls wäre ich in die Falle getappt, einer kleinen Benutzergruppe zu ermöglichen, einen lokalen Administratorzugriff auf die gesamte Domäne zu haben! Gar nicht gut.

Und hier kommen Organisationseinheiten (OEs) ins Spiel. Es ist eine Möglichkeit, die Domäne aufzuteilen, sodass Sie spezielle GPOs mit jeder OE-Untergruppe verbinden können.

Sie richten zuerst diese untergeordneten OE-Einheiten in „Active Directory Users and Computer“ (siehe unten) ein. Ich habe für jede OE eine Teilmenge der Domänencomputer zugewiesen. In meinem Szenario ist Acme-1 den Servern Masa und Pimiento zugewiesen und Acme-2 dem Domämen-Controller Taco.

Ich musste außerdem daran denken, Active Directory-Gruppen einzurichten, die mit jeder dieser OEs verbunden werden — Acme-IT-1 und Acme-IT-2.

Zurück in der Group Management Console erscheinen diese OEs unter der Acme-Domäne (siehe unten). Ich habe jeder OE eingeschränkte Gruppenrichtlinien hinzugefügt, um sicherzustellen, dass die entsprechenden AD-Gruppen verwendet wurden.

Es ist einfacher als es sich anhört. Kurzum: Ich aktiviere Mitglieder von Acme-IT-1 als Administrator für Masa und Pimiento, und Acme-IT-2-Mitglieder für Taco.

Wir schließen dieses unglaublich spannende Thema im nächsten Post ab und – wie immer – möchte ich noch ein paar abschließende Gedanken anführen. In der Zwischenzeit holen Sie sich etwas Aspirin, damit Sie das erstmal verarbeiten können.