Active Directory
Enumeration
Abusing GenericAll
GenericAll access right gives the user of the Identify full control over the ObjectDN account, allows the change of password on it without knowledge of the old password among other things:
For domain group, we can compromise the group by simply adding ourselves to it. We can also use the AllExtendedRights and GenericWrite access rights in a similar way as with user accounts.
Abusing WriteDACL
Permission to modify the DACL itself. We can apply additional access rights such as GenericAll, GenericWrite, or even DCSync if the targeted object is the domain object.
We then can perform the abuse of GenericAll with previous mentioned ways.
Unconstrained Delegation
With krbrelayx (no rubeus)
Constrained Delegation
While unconstrained delegation allows the service to perform authentication to anything in the domain, constrained delegation limits the delegation scope. Kerberos protocol does not natively support constrained delegation by default.
Does not matter which domain user or endpoint is used.
If we compromise the IISSvc account, we can request a service ticket to IIS for any user in the domain, including a domain administrator. (need the account password hash but not need to be in its context)
Resource-Based Constrained Delegation
We can compromise a backend service that has a compromised frontend service SID configured in its msDS-AllowedToActOnBehalfOfOtherIdentity property. The frontend service can use S4U2Self to request the forwardable TGS for any user to itself followed by S4U2Proxy to create a TGS for that user to the backend service. We can request admin account context on the frontend service to access the backend service.
This specific vector starts by compromising a domain account that has the GenericWrite access right on a computer account object. This technique is the only known way of turning GenericWrite on a computer object into code execution.
Since we have GenericWrite on appsrv01 (backend service), we can update any non-protected property on that object, including msDS-AllowedToActOnBehalfOfOtherIdentity and add the SID of a different computer (controlled frontend service).
We either have to obtain the password hash of a computer account or simply create a new computer account object with a selected password to act in the context of that computer account, and then execute the S4U2Self and S4U2Proxy extensions to obtain a TGS for appsrv01 after adding the SID of the controlled computer account in its msDS-AllowedToActOnBehalfOfOtherIdentity property.
By default, any authenticated user can add up to ten computer accounts to the domain and they will have SPNs set automatically.
Through Kali
Through Windows
It is not normally possible to set the msDS-AllowedToActOnBehalfOfOtherIdentity property for an arbitrary computer account. However, since our login user has the GenericWrite (also possible with GenericAll, WriteProperty, WriteDACL) access right to appsrv01, we can set this property.
Once a SID of the computer account is added, we can act in the context of that computer account and then execute the S4U2Self and S4U2Proxy extensions to obtain a TGS for appsrv01.
After obtaining the TGT for the myComputer machine account, S4U2Self will then request a forwardable service ticket as the administrator user to the myComputer computer account. Finally, S4U2Proxy is invoked to request a TGS for the CIFS service on appsrv01 as the admin user and injected into memory.
Our access to appsrv01 is in the context of the administrator domain admin user. We can use our CIFS access to obtain code execution on appsrv01, but in the process we will perform a network login instead of an interactive login. This means our access will be limited to appsrv01 and cannot directly be used to expand access towards the rest of the domain.
Last updated