Tuesday, 1 March 2022

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.


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: