Privileged ADUser Analyse

Arbeitsweise

1. Das Script ermittelt aus dem ActiveDirectory alle sensiblen, hochprivilegierten Gruppen automatisch. Zusätzlich kann die Liste durch Suchfilter und Ziel-OUs auf eigene Gruppen erweitert werden.
2. Im nächsten Schritt werden die AD-Benutzer ermittelt, welche in diesen Gruppen Mitglied sind. Dabei werden auch Gruppenverschachtelungen berücksichtigt. Diese Benutzer sind unsere Administratoren.
3. Nun werden alle Windows-Server der Domäne ermittelt.
4. Diese Server werden via PowerShell-Remoting kontaktiert. Für jeden Server wird die Liste der geplanten Aufgaben und die Liste der Services ermittelt und zum Scriptserver übertragen.
5. In den Listen werden die Sicherheitsprinzipale der geplanten Aufgaben und der Services bestimmt und mit der Liste der Administratoren aus Schritt 2 abgeglichen.
6. Alle bisher gesammelten Daten werden bewertet und für die Ausgabe wird eine HTML-Datei generiert.
7. Die HTML-Datei wird je nach Konfiguration als Email versandt oder im Internet Explorer angezeigt.

Voraussetzungen

• Ich habe das Script mit der PowerShell V4 und V5 programmiert. Daher sollte es auf Windows Server 2012R2 und höher gut laufen.
• PowerShell-Remoting über Windows-RemoteManagement (WinRM) ist zu den anderen Servern im Netzwerk erforderlich.
• Ebenso benötigt der Benutzer, der das Script ausführt, das Remoting-Recht auf die anderen Server. Dort angekommen muss er die geplanten Aufgaben und die Services auslesen können.
• Für die Mailfunktionalität sind entsprechende Anpassungen am Mailserver denkbar.

Setup

Das Script selber benötigt ein Arbeitsverzeichnis für sich, seine Konfigurationsdatei und seine Analyseergebnisse. Das könnte auf einem Server so aussehen:

Innerhalb der PowerShell-Scriptdatei sind keine Anpassungen erforderlich. Somit wird auch die digitale Signatur des Scriptcodes nicht beschädigt. Sämtliche Anpassungen an die eigene Infrastruktur werden über die ini-Datei vorgenommen:

Jede Zeile kann mit einem Semikolon auskommentiert werden (Zeile 18). Viele Angaben sind aber verpflichtend zu definieren! Ebenso müssen die Werte dahinter korrekt sein, da ich nicht alle möglichen Eingaben und daraus resultierende Fehler abgefangen habe. Die Konfiguration ist in 5 Sektionen unterteilt:

[Mailing]:
Hier könnt ihr die Mailfunktion steuern. Dabei stehen die üblichen Parameter zur Verfügung. Der Parameter MailAktiv reagiert auf die Werte „ja“ und „nein“. Bei „nein“ wird das Ergebnis im Internet-Explorer angezeigt (der ja immer noch der Standard-Browser auf Serversystemen ist).

[Filter: Organisationseinheiten mit Adminkonten]:
Das ist ein Array, also eine Sammlung von verschiedenen Organisationseinheiten im AD, in denen eure AdminGruppen gesucht werden sollen. Ihr könnt die Zeile 8 einfach duplizieren und den DN anpassen. In jeder OU (inklusive Unter-OUs) werden eure AdminGruppen gesucht.

[Filter: sensible ADGruppen]:
Vielleicht habt ihr eure AdminGruppen mit anderen Gruppen in den OUs gemischt? Dann könnt ihr mit diesem Array den Suchfilter definieren. Alle Zeilen (11 bis 15) werden mit ODER verknüpft. Die Eingaben aus meiner im Bild gezeigten Konfiguration entsprechen dieser AD-Abfrage:

[Filter: ausgenommene AdminAccounts]:
Mit diesem Array könnt ihr Accounts definieren, die problematisch sind, an denen aber nichts geändert werden kann. Das Script wird die Benutzer weiter überprüfen, aber in der Ausgabe werden sie in blauen statt roten Zeilen dargestellt4.

[Grenzwerte]: Hier kommen die Grenzwerte für einige Bewertungen rein:

• KRBTGT_PWDLaufzeit: Normal wird das Passwort des Users KRBTGT niemals ablaufen. Nur genau das ermöglicht die Erstellung von Kerberos-GoldenTickets… Also sollte dieses Passwort genauso altern, wie alle anderen. Hier könnt ihr das Alter in Tagen eingeben.
• Wenn Passworte ablaufen, dann wird euch das Script (regelmäßige Ausführung vorausgesetzt) vorher informieren. Mit den beiden Schwellwerten PWDAblauf_Warnung und PWDAblaufAchtung wird definiert, ab wann die Ausgabe gelb oder rot wird.
• PWsichereLaenge: ab dieser Passwortlänge könnte ein Passwort als sicher(er) gelten. Das Script wird bei der Bewertung darauf reagieren und keine Warnung ausgeben, selbst wenn das Passwort nicht abläuft. Falls ihr das nicht benötigt: setzt einfach den Wert auf 999.
• PWmindestLaenge: Sind Passworte zu kurz, dann könnten Sie erraten werden. Könnte ein Benutzer ein Passwort mit einer kürzeren Länge haben, dann wird dies als kritische Warnung in der Bewertung ausgegeben.
• PWhistory_Warnung: Passwortrichtlinien können eine PasswortHistory erzwingen, mit der die Wiederverwendung der X letzten Kennworte nicht erlaubt wird. Mit diesem Parameter könnt ihr angeben, welche Mindestanzahl an nicht wiederverwendbaren Kennworten konfiguriert sein muss. Definiert ihr beispielsweise den Wert 3, dann muss die KennwortHistory mindestens 3 betragen, sonst wird die Konfiguration als Fehler gewertet.
• POS_SCRequire: Man kann sich darüber streiten: ist ein Passwortverfahren sicherer als ein SmartCardlogon. Mit diesem Schalter könnt ihr eure Präferenz eintragen: Ist für euch RequireSmartCard sicherer, dann tragt ein J ein. Dann wird ein Benutzer mit diesem Attribut immer als sicher betrachtet. Seid ihr anderer Meinung, dann schreibt ein N in die Konfiguration.
• POS_ProtectedUser: Gleiches gilt für die Mitgliedschaft in der Gruppe Protected Users: ein J wird Mitglieder immer als sicher behandeln. Protected User können durchaus einen Sicherheitsgewinn darstellen. Nutzt ihr aber noch sehr viele Windows 7 / 2008R2, dann wird die Gruppenmitgliedschaft keinen Effekt haben! Dann wäre ein N als Wert sinnvoll.

Probiert es einfach mal durch. Für die Wertefindung wäre am Anfang ein MailAktiv = nein empfehlenswert.

Konfiguration als geplante Aufgabe

Meiner Erfahrung nach ist die Ausführung des Scriptes und die anschließende, mögliche Korrektur der Admin-Konfigurationen kein einmaliger Prozess. „Morgen“ werden ggf. neue Admins erstellt oder deren Nutzung wird negativ angepasst.

Daher empfehle ich die wiederholte Ausführung des Scriptes. Dies kann durch eine geplante Aufgabe auf einem Server erledigt werden. Die Berichte werden dann z.B. wöchentlich generiert und per Mail an euch versendet.

Der TaskAccount benötigt natürlich selber sehr hohe Rechte. Daher empfehle ich die Ausführung der Aufgabe mit einem gMSA – einem Group Managed Service Account.

Nun kommen wir zur eigentlichen Analyse. Das Script kann nach Anpassung der Konfigurationsdatei manuell gestartet werden. In der Ausgabe der PowerShell werden dabei schon einige Details sichtbar:

In der HTML-Datei finden wir die Ergebnisse in verschiedenen, farbigen Tabellen.

Admingruppen Level 1 und Level 2

Das könnte so aussehen:

Alle gefundenen Gruppen werden gelistet. Level 1 sind alle Gruppen mit dem AD-Attribut AdminCount – also sensible, hochberechtigte Systemgruppen:

Mitglieder dieser Standard-ADGruppen haben weitreichende Systemrechte. Alle sonstigen, also eure benutzerdefinierten Gruppen haben das Level 2.

Für jede Gruppe werden die aktuellen Mitglieder angezeigt. In den Gruppen Enterprise-Admins und Schema-Admins sollten keine dauerhaften Mitglieder vorhanden sein. Daher werden deren Mitglieder immer rot dargestellt.

privilegierte Accounts mit Gefährdungen

Sofern vorhanden werden hier alle Admins aufgelistet, zu denen mögliche Gefährdungen gefunden wurden:

Die Zeilen sind mit einem roten Muster versehen. Etliche Spalten verweisen auf Eigenschaften mit Gefährdungs- oder Problempotential, z.B. die Spalte PWEndless. Hat ein Benutzer ein nicht ablaufendes Kennwort, dann wird diese „Verfehlung“ mit einer dunkelroten Zelle dargestellt. So kann man recht einfach die Probleme überschauen. Ebenso ist es aber auch möglich, dass Zellen grün dargestellt werden. Damit wird ein positiver Zustand hervorgehoben. So könnte z.B. die Mitgliedschaft in der Gruppe „Protected Users“ gewertet werden.

Die letzte Spalte „Bewertung“ listet noch einmal alle Probleme als Stichpunkte auf. Folgende Bewertungen sind möglich:

Bewertungstext	Problem
-PWD laeuft ab	Das Passwort des Benutzers läuft in kürze ab. Hier gilt der Grenzwert PWAblauf_Warnung.
-PWD laeuft bald ab	Das Passwort des Benutzers läuft in weniger Tagen als der Grenzwert PWAblauf_Achtung ab.
-PWD abgelaufen	Das Passwort ist abgelaufen.
-kurzes PW	Das Passwort könnte kürzer als der Grenzwert PWmindestLaenge sein, da die Passwortrichtlinie zu schwach ist.
-nicht verwendet	Dieser privilegierte Account wurde noch nie verwendet:
-statisches PWD	Das Passwort ist statisch und muss nicht geändert werden:
-ProtectedUser	Der Benutzer ist Mitglied in einer Level-1-Gruppe, ist aber kein Mitglied der Gruppe „Protected Users“:
-kein PWD erforderlich	Der Benutzer kann auch ohne Passwort verwendet werden (Passwortrichtlinie mit 0 Zeichen Mindestlänge)
-Taskuser	Der Benutzer wird für mindestens eine geplante Aufgabe auf einem erreichten Server verwendet:
-ServiceUser	Der Benutzer wird für mindestens einen Dienst auf einem erreichten Server verwendet:
-kein Lockout	Für den Benutzer ist keine Kontosperre nach x fehlerhaften Anmeldungen definiert. Ein Online-BruteForce wäre möglich:
-schwaches PW	Für das Passwort schreibt die resultierende Passwortrichtlinie keine Komplexität vor und die Mindestlänge für sichere Passworte wurde nicht erzwungen:
-reversibles PW	Passworte können im ActiveDirectory umkehrbar gespeichert werden. Das ist natürlich nicht der Standardwert. Es gibt auch keinen guten Grund (mehr) das zu ändern:
-kein PreAuth	Kerberos 5 hat die Kerberos PreAuthentication eingeführt. Ein Benutzer muss sich also anmelden, bevor er ein KerberosTicket erhält. Das ist der Systemstandard. So ist es Mist:
+SmardCard-protected	Vielleicht nutzt ihr SmartCards als alleiniges Anmeldeelement. Dann wird dieser Aspekt positiv gewertet:

privilegierte Accounts mit Gefährdungen, aber manuell ausgenommen

Manche Accounts können nicht weiter geschützt werden. Es ist ärgerlich, aber ganz offensichtlich stand Sicherheit bei Microsoft, den Softwareherstellern und auch bei den Admins nicht sonderlich hoch im Kurs. ☹

Damit diese (hoffentlich wenigen) Accounts nicht jedesmal die Anzeige rot färben könnt ihr sie in der Konfigurationsdatei ausnehmen. Die Admins werden dann blau statt rot in einer eigenen Tabelle angezeigt:

Dies gilt natürlich nur, wenn Gefährdungen erkannt wurden. Ist der Account sicher, dann wird er selbstverständlich in der nächsten Tabelle in grün dargestellt.

privilegierte, sichere Accounts

Hier liegt das Ziel: möglichst alle privilegierten Accounts sollten gefährdungsfrei sein. Dann werden sie in dieser Ausgabetabelle angezeigt:

Mit einer gelben Level-Zelle werden alle Accounts der speziellen, systemeigenen Admingruppen dargestellt.

geplante Aufgaben, die mit AdminKennungen laufen

Falls auf einem Server remote eine geplante Aufgabe gefunden wurde, die mit einer der AdminKennungen automatisch ausgeführt wird, dann wird diese Tabelle sichtbar:

Denkt immer daran, dass dieses Kennwort unter den richtigen Voraussetzungen im Klartext ausgelesen werden kann. Hier mal ein Taskuser auf einem Windows Server 2016 (links), dessen Kennwort im Hacking-System (rechts) angezeigt wird:

Arbeitet einfach die Liste ab und „entschärft“ die Rechte der eingesetzten Accounts!

Services, die mit AdminKennungen laufen

Auch diese Tabelle wird nur gezeigt, wenn durch das Remoting auf einem Server ein Dienst gefunden wurde, der eine AdminKennung verwendet:

Auch diese Passworte müssen natürlich im System gespeichert werden. Und so können sie auch wieder ausgelesen werden. Links seht ihr die Adminkonsole der Dienste mit dem „geschützten“ Passwort. Rechts die Ansicht der Hacker…

Also gilt auch hier: arbeitet die Liste ab und „entschärft“ die Benutzerrechte!

Zusammenfassung der Scriptausführung

Die letzte Tabelle enthält die Zusammenfassung. Hier kann abgelesen werden, ob es beim Remoting Probleme gab. Sollten ein oder mehrere Server nicht erreichbar sein, dann wird natürlich die Auswertung der ServiceAdmins und TaskAdmins lückenhaft sein:

Prinzip Least Privilege

Das ist der ultimative Anspruch: so wenig Accounts wie möglich sollten mit höheren Rechten unterwegs sein! Wie oft habe ich schon Accounts gesehen, die einen Task oder einen Service befeuern und selber Mitglieder der Gruppe DomainAdmins sind!!!

Seit Windows Server 2012 können Group Managed Service Accounts eingesetzt werden. Diese werden im Betriebssystem wesentlich besser geschützt und zusätzlich wird das Kennwort vollautomatisch regelmäßig geändert! OK, nicht jede Software kann damit umgehen und die Konfiguration ist (auch in Windows Server 2019) immer noch nur über die PowerShell möglich. Aber hier kann vielleicht mein öffentliches Script „gMSA-Admin“ weiterhelfen!

Überlegt bei der Einrichtung einer neuen Software, welche Rechte wo benötigt werden. Fragt beim Hersteller nach. Klar läuft das Produkt mit DomainAdmin-Rechten… wie eine Firewall, in der alle Ports offen sind! Aber das geht bestimmt besser.

Konfigurationen im Active Directory

Viele von den zusätzlichen Schaltern, wie „Passwort kann nicht geändert werden“, „Passwort läuft nicht ab“, … sind einfach tabu. Ich selber habe einen Account in meinem Netzwerk, der hohe Rechte benötigt und nicht anders geschützt werden kann. Hier hilft mir dieses Script, denn es informiert mich, wenn das Passwort ausläuft. Dann generiere ich ein neues und trage es zeitgleich im AD und in der Software ein. Tada.

Bitte informiert euch über die Gruppe Protected Users. Einen Eindruck bekommt ihr in meinem Beitrag “Responder & MultiRelay Attacke” im Block “Nutzungsbeschränkung und Einschränkungen administrativer Accounts”

Password-Setting-Objects können zusätzlich zur Kennwort-Richtlinie die Anforderungen für Passworte und die Sperrdefinitionen verwendet werden. Erzwingt an den richtigen Stellen maximal sichere Richtlinien.

Ebenfalls interessant könnte mein Security-Scoping sein. Dabei gliedere ich die zu administrierenden Systeme in einzelne Bereiche, denen jeweils neue administrative Gruppen zugewiesen werden.

Eine Besonderheit stellt der Benutzer KRBTGT dar. Dessen Passwort(hash) wird verwendet, um die Kerberos-TGT’s zu verschlüsseln. (Hier erfahrt ihr mehr zum Thema) Auf diese baut die gesamte Sicherheit des AD auf. Dann muss doch dieses Passwort besonderen Ansprüchen genügen, oder? Leider sieht das im Default anders aus, denn das Passwort des KRBTGT-Users läuft NIEMALS ab! Ändert es bitte ebenso regelmäßig, wie die anderen Passworte. Dabei ist aber besondere Vorsicht geboten! Diesem Thema widme ich mich separat.

Probiert es einfach aus. Dann wird bald alles schön grün:

Der Betrieb und die Einrichtung einer sicher(er)en Infrastruktur sind mit Arbeit verbunden. Aber es gibt ein gutes Gefühl. Und denkt nur an all die Stunden und Tage, die ihr zum Beispiel sonst mit dem Aufräumen nach einer Ransomware-Attacke verbringen würdet… 🙂

Hier gibt es das Script in der aktuellen Version als freien Download. Die PDF gibt es hier.

Stay tuned!