(KUD) Unconstrained
Last updated
Was this helpful?
Last updated
Was this helpful?
If an account (user or computer), with unconstrained delegations privileges, is compromised, an attacker must wait for a privileged user to authenticate on it (or ) using Kerberos. The attacker service will receive an ST (service ticket) containing the user's TGT. That TGT will be used by the service as a proof of identity to obtain access to a target service as the target user. Alternatively, the TGT can be used with in order to gain local admin privileges over the TGT's owner.
If the coerced account is "" or a member of the "" group, its TGT will not be delegated in the service ticket used for authentication against the attacker-controlled KUD account.
Nota bene: the native, RID 500, "Administrator" account doesn't benefit from that restriction, even if it's added to the Protected Users group (source: ).
In order to abuse the unconstrained delegations privileges of an account, an attacker must add his machine to its SPNs (i.e. of the compromised account) and add a DNS entry for that name.
This allows targets (e.g. Domain Controllers or Exchange servers) to authenticate back to the attacker machine.
By default, the salt is always
For users: uppercase FQDN + case sensitive username = DOMAIN.LOCALuser
For computers: uppercase FQDN + host + lowercase FQDN hostname without the trailing $ = DOMAIN.LOCALhostcomputer.domain.local
In case, for some reason, attacking a Domain Controller doesn't work (i.e. error sayingCiphertext integrity failed.) try to attack others (if you're certain the credentials you supplied were correct). Some replication and propagation issues could get in the way.
All of this can be done from UNIX-like systems with , and (Python).
the account is a user: users can't edit their own SPNs like computers do. Attackers need to control an (or any other user that has the needed privileges) to edit the user's SPNs. Moreover, since tickets received by krbrelayx will be encrypted with RC4, attackers will need to either supply the NT hash (-hashes argument) or the salt and password (--krbsalt and --krbpass arguments)
Once the krbrelayx listener is ready, an (e.g. , , PetitPotam) can be operated. The listener will then receive a Kerberos authentication, hence a ST, containing a TGT.
The TGT will then be usable with Pass the Ticket (to act as the victim) or with (to obtain local admin privileges over the victim).
Once the KUD capable host is compromised, can be used (on the compromised host) as a listener to wait for a user to authenticate, the ST to show up and to extract the TGT it contains.
Once the monitor is ready, a (e.g. , ) can be operated. Rubeus will then receive an authentication (hence a Service Ticket, containing a TGT). The TGT can be used to request a Service Ticket for another service.
Alternatively, the TGT can be used with in order to gain local admin privileges over the TGT's owner.
Once the TGT is injected, it can natively be used when accessing a service. For example, with , to extract the krbtgt hash
