Sicherung Ihrer Group Managed Service Accounts

Übersicht über Gruppenverwaltete Dienstkonten

Die traditionelle Praxis, reguläre Benutzerkonten als Dienstkonten zu verwenden, legt die Last des Passwortmanagements auf die Benutzer. Infolgedessen bleiben die Passwörter der Konten oft jahrelang gleich — was sie sehr anfällig für Brute-Force-Angriffe und Missbrauch macht. Gruppenverwaltete Dienstkonten (gMSAs) bieten eine sicherere Möglichkeit, automatisierte Aufgaben, Dienste und Anwendungen auszuführen.

gMSA wurden in Windows Server 2016 eingeführt und können auf Windows Server 2012 und höher genutzt werden. gMSA-Passwörter werden vollständig von Windows verwaltet: Sie werden zufällig generiert und automatisch geändert. Darüber hinaus müssen die Passwörter von keinem Benutzer bekannt sein, da die Dienstkonten selbst auf dem Server 'installiert' werden, der zur Abfrage der Passwortinformationen von Active Directory zur Laufzeit dient. Als Ergebnis sind gMSAs weit weniger anfällig für Missbrauch und Kompromittierung als Benutzerkonten, die als Dienstkonten verwendet werden.

Sicherheit von Group Managed Service Accounts

gMSAs sind ein spezifischer Objekttyp in Active Directory: msDS-GroupManagedServiceAccount. Diese Objekte haben spezielle Attribute, die mit ihnen in Verbindung stehen, bezüglich ihres Passworts und dessen Rotation. Ähnlich wie bei LAPS, möchten Sie sicherstellen, dass der Zugriff auf gMSA-Attribute nur auf die Active Directory-Objekte beschränkt ist, die sie benötigen.

gMSA-Attribute und Berechtigungen

gMSAs haben die folgenden Attribute:

• msDS-ManagedPassword— Ein BLOB mit dem Passwort des gMSA
• msDS-ManagedPasswordID— Die Schlüssel-ID, die verwendet wurde, um das aktuelle gMSA-Passwort zu generieren
• msDS-ManagedPasswordPreviousID— Die Schlüssel-ID, die zur Generierung des vorherigen gMSA-Passworts verwendet wurde
• msDS-GroupMSAMembership— Eine Liste der Objekte, die Berechtigung haben, das Passwort für das gMSA abzufragen
• msDS-ManagedPasswordInterval— Das Intervall (Tage), in dem das Passwort geändert wird

Da die Passwortinformationen im msDS-ManagedPassword-Attribut gespeichert sind, werden Sie definitiv wissen wollen, wer in Ihrer Umgebung in der Lage ist, das Passwort abzufragen. Diese Information wird im msDS-GroupMSAMembership-Attribut festgelegt.

Allerdings ist es etwas komplizierter als nur dieses Attribut, da auch die Berechtigungen des Active Directory eine Rolle spielen. Wenn aus irgendeinem Grund ein Benutzer oder Objekt konfiguriert ist, um das Passwort über das msDS-GroupMSAMembership-Konto abzufragen, benötigen sie immer noch 'Lesen'-Berechtigungen für das msDS-ManagedPassword-Attribut des gMSA.

Das bedeutet, es gibt zwei Wege, um gMSA-Passwörter zu sichern:

• Stellen Sie sicher, dass nur die notwendigen Objekte die Berechtigung haben, das Passwort abzufragen und dass sie in der msDS-GroupMSAMembership existieren
• Stellen Sie sicher, dass nur administrative Benutzer, die Zugriff benötigen, und Computerkonten, auf denen gMSAs installiert sind, die Berechtigung zum Lesen des Attributs haben. Außerdem stellen Sie sicher, dass nur Administratoren die Fähigkeit haben, das gMSA und seine Attribute zu ändern, sodass niemand sich selbst zum msDS-GroupMSAMembership-Attribut hinzufügen kann.

Idealerweise würden Sie gMSAs über beide Wege absichern, um einem Angreifer die Möglichkeit zu nehmen, eine der oben genannten Szenarien auszunutzen. Im Folgenden zeigen wir, wie schlecht verwaltete Berechtigungen oder Konfigurationen eines gMSA zu einem Kompromiss des Kontos und Privilege Escalation oder lateraler Bewegung führen können.

Missbrauch des gMSA-Passworts

Das Missbrauchen eines gMSA ist konzeptionell relativ einfach. Zuerst, beschaffe sein Passwort mit einem Tool wie Mimikatz oder durch direktes Abfragen aufgrund unsicherer Konfigurationen in Active Directory. Da gMSAs Dienstkonten sind, sind sie normalerweise ziemlich privilegiert, sodass man dann normalerweise in der Lage ist, sich seitwärts zu bewegen oder zu eskalieren.

Lassen Sie uns ein Beispiel-Szenario durchgehen.

1. Zuerst kompromittieren wir das gewöhnliche Windows-Benutzerkonto ‘notadmin’ durch eine Technik wie Phishing. Dieses Konto hat minimale Privilegien in Active Directory, ist aber ein lokaler Administrator auf dem Computer, auf den wir gelandet sind.

2. Als Nächstes werden wir versuchen herauszufinden, ob gMSA existieren. Das ist sehr einfach zu bewerkstelligen, wenn Sie Zugriff auf das Windows PowerShell-Cmdlet haben. Ein einfaches Skript auszuführen, verschafft uns alle verwalteten Dienstkonten in Active Directory:

      Get-ADServiceAccount -Filter *
      

3. Mit einigen kleinen Änderungen am Skript können wir identifizieren, wer Zugriff hat, um die gMSA-Passwörter abzufragen:

      Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
      

Wie wir sehen können, ist nur das Kevin Joyce-Konto in der Lage, die Passwörter für diese Dienstkonten abzufragen:

4. Wir können den Umfang der Ziele, die wir anstreben, eingrenzen, indem wir überprüfen, ob diese Dienstkonten Mitglied einer der privilegierten Gruppen sind, und von dort aus können wir tiefer in die festgelegten Berechtigungen eines der Objekte eindringen:

      Get-ADServiceAccount -Filter * -Properties memberof
      

Wenn wir uns die Ergebnisse hier ansehen, können wir feststellen, dass das gMSA-Dienstkonto Mitglied der Domain Admins ist, also wird dies dasjenige sein, das wir zu nutzen versuchen werden.

5. Indem wir ein Skript, das in einem Beitrag über Microsoft LAPS modifiziert haben, konnten wir eine Auflistung aller Objekte erhalten, die Berechtigungen über ein verwaltetes Dienstkonto haben, einschließlich Vollzugriff, Alle Eigenschaften schreiben oder Eigenschaft schreiben für das spezifische gMSA-Attribut. Die Ausgabe finden Sie unten, und das Skript ist am Ende verlinkt.

6. Wie Sie sehen können, hat das notadmin-Konto Vollzugriff auf das gMSA-Konto. Dies ermöglicht es uns, das msDS-GroupMSAMembership-Attribut zu ändern, was uns wiederum erlaubt, das Passwort für das verwaltete Dienstkonto abzurufen:

      Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
      

7. Jetzt, da wir das Passwort tatsächlich abfragen können, schauen wir mal, was wir damit anfangen können:

      Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
      

      $pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
      

8. Der im Attribut gespeicherte Wert ist ein BLOB, der die Daten für das Passwort enthält, nicht das Passwort selbst, daher müssen wir das Passwort mit einem Tool wie DSInternals dekodieren:

      $pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
      

Dies verschafft uns das SecureCurrentPassword und CurrentPassword. Das CurrentPassword scheint auf den ersten Blick nutzlos zu sein, aber das liegt daran, dass alle Zeichen UTF-16 sind. Das SecureCurrentPassword kann in einen NTLM-Hash umgewandelt und verwendet werden in einem Pass-the-Hash-Angriff mit Mimikatz, um unsere Privilegien zu erhöhen.

9. Um das pass the hash-Verfahren durchzuführen, müssen wir einfach mimikatz ausführen und diesen Befehl verwenden:

      sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
      

10. Jetzt, da wir eine Shell haben, die als gMSA-Dienstkonto ausgeführt wird, welches Mitglied der Domain Admins war, können wir tun, was wir wollen, um Active Directory zu kompromittieren. Eine der schnellsten, aber wahrscheinlich lautesten Methoden, die wir dafür verwenden können, ist die Ausführung eines DCSync attack und das Stehlen des Hashes des krbtgt-Kontos:

      lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
      

gMSA-Schutz & Überwachung

Es gibt Strategien, die Sie nutzen können, um Missbrauch von gMSA zu verhindern und zu erkennen.

Berechtigungen

Der offensichtlichste und wohl wichtigste Schutz, den Sie einrichten können, ist sicherzustellen, dass angemessene Berechtigungen für Ihre gruppenverwalteten Dienstkonten festgelegt sind. Zu verstehen, wer Schreibzugriff auf diese Objekte hat, ist entscheidend für deren Schutz; jemand, der sich selbst zu dem Attribut hinzufügen kann, das steuert, wer das Passwort abfragen kann, hat theoretisch bereits Zugang, dieses Konto zu übernehmen und seine Privilegien zu missbrauchen.

Das Nächste wäre zu verstehen, wer die Fähigkeit hat, die Passwörter dieser Konten abzufragen und wer genau solchen Zugriff benötigt. In Wirklichkeit sollte das einzige Konto, das das Passwort eines gMSA erhalten kann, das Computerkonto sein, auf dem das gMSA installiert ist.

Ereignisprotokolle

Es gibt ein Ereignis, das Sie in den nativen Ereignisprotokollen suchen können, das Ihnen hilft zu identifizieren, wer die Passwörter von gMSA-Konten abfragt. Wenn Sie die Richtlinie ‘Audit directory service access’ für Ihre Domäne aktivieren und eine SACL für die gMSAs konfigurieren, die Sie überwachen möchten, können Sie Ereignisprotokolle generieren, wenn Personen das Attribut msDS-ManagedPassword abfragen:

Wenn Sie diese Einstellung aktivieren und eine neue SACL erstellen, wird ein Ereignisprotokoll mit der Ereignis-ID 4662 generiert; es sieht so aus:

Wie Sie sehen können, wurde protokolliert, dass das 'notadmin'-Konto eine Eigenschaft auf dem gMSA-Konto gelesen hat. Die gelesenen Eigenschaften sind die in das Schema für Active Directory gespeicherten GUIDs, aber mit ADSI Edit können wir sehen, dass die hervorgehobene GUID dem msDS-ManagedPassword-Attribut entspricht.

Angenommen, Sie haben eine Art von Ereignisprotokoll-Weiterleitung oder eine SIEM-Lösung, wären diese Protokolle äußerst wertvoll, um festzustellen, wer auf diese Attribute zugreift.

Netwrix StealthDEFEND

Eine weitere Option ist ein Tool wie Netwrix StealthDEFEND. Netwrix StealthDEFEND verlässt sich nicht auf native Ereignisprotokolle und kann den Zugriff auf gMSA-Passwörter und die Zuweisung von Hochrisikoberechtigungen direkt nach der Installation erkennen. Zum Beispiel würde das oben gezeigte Szenario folgende Bedrohung generieren, wenn das Konto 'notadmin' das Passwort abfragt:

Darüber hinaus können Sie mit Netwrix StealthDEFEND einfach ein Playbook erstellen, das ausgeführt wird, wenn Missbrauch von gMSA erkannt wird. Das Playbook kann mehrere Schritte umfassen, wie zum Beispiel die Anforderung, dass das Täter-Benutzerkonto auf eine MFA-Anfrage reagiert, das Konto deaktiviert oder ein ServiceNow-Vorfall erstellt wird.

Anhang

gMSA-Berechtigungscodes:

      <#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
      

Ansicht RohdatengMSA_Permissions_Collection.ps1 gehostet von GitHub

FAQ

Was ist ein gMSA?

Ähnlich wie verwaltete Dienstkonten (MSA) sind gruppenverwaltete Dienstkonten (gMSAs) verwaltete Domänenkonten, die dazu dienen, Dienste und Zugriffsmanagement sicherer zu gestalten. Die gMSA-Funktionalität bietet automatisches Passwortmanagement durch den Domänencontroller (DC), vereinfachtes Management des Dienstprinzipalnamens (SPN) und die Möglichkeit, das Management an andere Administratoren zu delegieren, was die Active Directory security verbessert und die Anzahl der Konten mit privilegiertem Zugriff minimiert.

Was ist der Unterschied zwischen MSAs und gMSAs?

Im Gegensatz zu einem MSA kann ein gMSA mit mehreren Computern verknüpft werden.

Wie findet man ein Gruppenverwaltetes Dienstkonto?

Um eine Liste der gMSAs auf Ihrem Domain-Controller zu erhalten, öffnen Sie den Server-Manager > Tools > Active Directory Users and Computers > Verwaltete Dienstkonten.

Kann ein gMSA ein Domain-Admin sein?

Ja, ein gMSA-Konto kann Mitglied von Domain Admins sein, obwohl diese Praxis für die Informationssicherheit gefährlich sein kann.

Wie kann ich ein gMSA erstellen?

Gruppenverwaltete Dienstkonten werden mit dem Cmdlet New-ADServiceAccount erstellt.