Additional - sAMAccountName Impersonation

Since my previous post I have subsequently discovered another attack path that may be useful. For these examples I used the internal.user account in the internal.zeroday.lab domain, as shown below:

This is a generic low privileged user.

 

Trusts

I updated my original tweet, but I wanted to explain in greater depth that this works across trusts.

As mentioned in a previous post, creating machine accounts across trusts is not only possible but can be incredibly useful. This is another example of that.

A forest trust is configured between the internal.zeroday.lab and external.zeroday.lab forests:

A new machine account (named NewComputer) is created across this trust on the external.zeroday.lab domain:

The SPNs can be cleared from this newly created account:

It is best to use the distinguished name of the machine account for changing the name:

Lastly, the name can be changed to the same name as the domain controller minus the '$':

At this point the attack is exactly the same as the initial example I gave in the original post, i.e., request a TGT for EDC1, rename the machine account back, perform S4U2self.

 

User Account

Another example of exploitation involved user account control. Two more prerequisites are required to perform the attack using a user account, the GenericAll privilege over the user account and access to the account credential. Any user account can be used to perform the attack.

There are several potential ways of obtaining the user account password when you have GenericAll over it, including Targeted Kerberoasting from Will Schroeder, Shadow Credentials by Elad Shamir and resetting the user password to name a few. At this point the assumption is the password has been obtained.

The user I'm running as (internal.user) has GenericAll over the target user (new.user):

Changing the samaccountname to that of the DC minus the '$' is also possible using PowerView:

The attack from this point mirrors the original post, which can be found here. Interestingly on patched servers you can rename a user account this way with GenericAll over it, but the S4U2self part fails with a KDC_ERR_TGT_REVOKED error due to the new Requestor PAC_INFO_BUFFER being included within the TGT's PAC.

EDIT: Charlie BROMBERG suggested GenericAll is not required and this works with GenericWrite or even WriteProperty on sAMAccountName for changing the samaccountname, but it is important to remember that the ability to request a TGT for this account is required too, so the higher the privileges, the more likely you are to be able to do this.

 

Conclusion

It is very important that all domain controllers throughout the whole enterprise are patched against these issues due to the impact of exploitation and the ease with which it can be performed.

While more limited, it may still be possible in situations where a machine account cannot be created / controlled or the renaming of machine account fails.