Today’s my favorite tale of pentest pwnage (again)! This time we’re talking about sAMAccountName spoofing specifically. We also talk about my always-under-construction list of things I try early in a pentest for maximum pwnage:

• Run PingCastle
• Do the SharpHound/BloodHound dumps
• Run the DHCP poisoning module of Responder
• Check the ms-DS-MachineAccountQuota value in the domain – if its at the default (10), then any user can add machines to the domain.

Why is the ability to add machines to the domain important? Because in the case of the sAMAccountName spoofing, if you have a non-domain-joined machine like I do, you need the ability to add a computer object to the domain. Check the Pentestlab.blog article for more info, but essentially, if you have an unpatched domain controller and the ability to add computer objects to the domain, you can pull off the attack. The article goes into crazy good technical detail, and here’s my not-so-technical explanation:

If I was on a pentest, and the DC was called 7MS-DC01, and I could join a machine to the domain (which as a reminder – ANY user can do if the machine quota value is at the default value of 10), I could rename that machine account to be 7MS-DC01 without the dollar sign, request a TGT for the domain controller’s account, then restore the machine name back to what it was before. Now, because the TGT is stored in memory, we can use the S4U2self Kerberos extension to request a service ticket using a domain admin account. And because the original ticket belong to the 7MS-DC01 machine name which now doesn’t exist, Kerberos will look for 7MS-DC01$ and will issue the ticket for the requested service.

I might’ve butchered that explanation mom, but I tried my best!

TLDL/TLDR: find and exploit these unpatched domain controllers with noPac. Enjoy!