Resource-based Constrained Delegation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
To jest podobne do podstawowej Constrained Delegation, ale zamiast nadawania uprawnień do obiektu, aby podszywać się pod dowolnego użytkownika w stosunku do usługi. Resource-based Constrained Delegation ustawia w obiecie, kto może podszywać się pod dowolnego użytkownika w stosunku do niego.
W tym przypadku, ograniczony obiekt będzie miał atrybut o nazwie msDS-AllowedToActOnBehalfOfOtherIdentity z nazwą użytkownika, który może podszywać się pod dowolnego innego użytkownika w stosunku do niego.
Inna ważna różnica między tym Constrained Delegation a innymi delegacjami polega na tym, że każdy użytkownik z uprawnieniami do zapisu nad kontem maszyny (GenericAll/GenericWrite/WriteDacl/WriteProperty/etc) może ustawić msDS-AllowedToActOnBehalfOfOtherIdentity (W innych formach Delegacji potrzebne były uprawnienia administratora domeny).
W Constrained Delegation powiedziano, że flaga TrustedToAuthForDelegation
w wartości userAccountControl użytkownika jest potrzebna do wykonania S4U2Self. Ale to nie jest całkowita prawda.
Rzeczywistość jest taka, że nawet bez tej wartości, możesz wykonać S4U2Self w stosunku do dowolnego użytkownika, jeśli jesteś usługą (masz SPN), ale jeśli masz TrustedToAuthForDelegation
, zwrócone TGS będzie Forwardable, a jeśli nie masz tej flagi, zwrócone TGS nie będzie Forwardable.
Jednakże, jeśli TGS użyte w S4U2Proxy NIE jest Forwardable, próba nadużycia podstawowej Constrained Delegation nie zadziała. Ale jeśli próbujesz wykorzystać Resource-Based Constrained Delegation, to zadziała (to nie jest luka, to funkcja, najwyraźniej).
Jeśli masz uprawnienia do zapisu równoważne nad kontem Komputera, możesz uzyskać uprzywilejowany dostęp do tej maszyny.
Załóżmy, że atakujący ma już uprawnienia do zapisu równoważne nad komputerem ofiary.
Atakujący kompromituje konto, które ma SPN lub tworzy jedno (“Usługa A”). Zauważ, że każdy Użytkownik Administrator bez żadnych innych specjalnych uprawnień może utworzyć do 10 obiektów Komputera (MachineAccountQuota) i ustawić im SPN. Więc atakujący może po prostu utworzyć obiekt Komputera i ustawić SPN.
Atakujący nadużywa swojego uprawnienia DO ZAPISU nad komputerem ofiary (Usługa B), aby skonfigurować resource-based constrained delegation, aby umożliwić Usłudze A podszywanie się pod dowolnego użytkownika w stosunku do tego komputera ofiary (Usługa B).
Atakujący używa Rubeus, aby przeprowadzić pełny atak S4U (S4U2Self i S4U2Proxy) z Usługi A do Usługi B dla użytkownika z uprzywilejowanym dostępem do Usługi B.
S4U2Self (z konta SPN, które zostało skompromitowane/stworzone): Prosi o TGS Administratora dla mnie (Nie Forwardable).
S4U2Proxy: Używa nie Forwardable TGS z poprzedniego kroku, aby poprosić o TGS od Administratora do komputera ofiary.
Nawet jeśli używasz nie Forwardable TGS, ponieważ wykorzystujesz Resource-based constrained delegation, to zadziała.
Atakujący może przekazać bilet i podszyć się pod użytkownika, aby uzyskać dostęp do Usługi B ofiary.
Aby sprawdzić MachineAccountQuota domeny, możesz użyć:
Możesz stworzyć obiekt komputera w obrębie domeny używając powermad:
Używając modułu PowerShell activedirectory
Używanie powerview
Przede wszystkim stworzyliśmy nowy obiekt Komputera z hasłem 123456
, więc potrzebujemy hasha tego hasła:
To będzie drukować hashe RC4 i AES dla tego konta. Teraz atak może być przeprowadzony:
Możesz wygenerować więcej biletów, pytając tylko raz, używając parametru /altservice
w Rubeus:
Zauważ, że użytkownicy mają atrybut o nazwie "Nie można delegować". Jeśli użytkownik ma ten atrybut ustawiony na True, nie będziesz w stanie go podszyć. Ta właściwość jest widoczna w BloodHound.
Ostatnia linia poleceń wykona pełny atak S4U i wstrzyknie TGS z Administratora do hosta ofiary w pamięci. W tym przykładzie zażądano TGS dla usługi CIFS od Administratora, więc będziesz mógł uzyskać dostęp do C$:
Dowiedz się o dostępnych biletach serwisowych tutaj.
KDC_ERR_ETYPE_NOTSUPP
: Oznacza to, że Kerberos jest skonfigurowany tak, aby nie używać DES ani RC4, a Ty dostarczasz tylko hasz RC4. Podaj Rubeus przynajmniej hasz AES256 (lub po prostu podaj mu hasze rc4, aes128 i aes256). Przykład: [Rubeus.Program]::MainString("s4u /user:FAKECOMPUTER /aes256:CC648CF0F809EE1AA25C52E963AC0487E87AC32B1F71ACC5304C73BF566268DA /aes128:5FC3D06ED6E8EA2C9BB9CC301EA37AD4 /rc4:EF266C6B963C0BB683941032008AD47F /impersonateuser:Administrator /msdsspn:CIFS/M3DC.M3C.LOCAL /ptt".split())
KRB_AP_ERR_SKEW
: Oznacza to, że czas bieżącego komputera różni się od czasu DC i Kerberos nie działa poprawnie.
preauth_failed
: Oznacza to, że podana nazwa użytkownika + hasze nie działają przy logowaniu. Mogłeś zapomnieć wstawić "$" w nazwie użytkownika podczas generowania haszy (.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local
)
KDC_ERR_BADOPTION
: Może to oznaczać:
Użytkownik, którego próbujesz naśladować, nie ma dostępu do żądanej usługi (ponieważ nie możesz go naśladować lub nie ma wystarczających uprawnień)
Żądana usługa nie istnieje (jeśli prosisz o bilet na winrm, ale winrm nie działa)
Utworzony fakecomputer stracił swoje uprawnienia do podatnego serwera i musisz je przywrócić.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)