(KUD) Unconstrained
Last updated
Last updated
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 force it) 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 S4U2self abuse in order to gain local admin privileges over the TGT's owner.
If the coerced account is "is sensitive and cannot be delegated" or a member of the "Protected Users" 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: sensepost.com).
Unconstrained delegation abuses are usually combined with an MS-RPRN abuse (printerbug), MS-EFSR abuse (petitpotam), MS-FSRVP abuse (shadowcoerce), r PrivExchange to gain domain admin privileges.
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.
All of this can be done from UNIX-like systems with addspn, dnstool and krbrelayx (Python).
When attacking accounts able to delegate without constraints, there are two major scenarios
the account is a computer: computers can edit their own SPNs via the msDS-AdditionalDnsHostName attribute. Since ticket received by krbrelayx will be encrypted with AES256 (by default), attackers will need to either supply the right AES256 key for the unconstrained delegations account (--aesKey argument) or the salt and password (--krbsalt and --krbpass arguments).
the account is a user: users can't edit their own SPNs like computers do. Attackers need to control an account operator (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)
By default, the salt is always
For users: uppercase FQDN + case sensitive username = DOMAIN.LOCALuser
For computers: uppercase FQDN + hardcoded host text + lowercase FQDN hostname without the trailing $ = DOMAIN.LOCALhostcomputer.domain.local
(using DOMAIN.LOCAL\computer$ account)
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.
Once the krbrelayx listener is ready, an authentication coercion attack (e.g. PrinterBug, PrivExchange, 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 S4U2self abuse (to obtain local admin privileges over the victim).
