AD ACL Misconfigurations Are Everywhere and Nobody Is Checking

#Your Help Desk Has GenericAll Over Domain Admins. They Don't Know It.#link

I've run over forty AD assessments in the past five years. Every single one had ACL misconfigurations. Not edge cases. Not rare findings. Every. Single. One. The most common: a Help Desk group with ForceChangePassword rights over a Server Admin group, which has GenericAll over a user with DCSync privileges. Three hops. Five minutes of enumeration. Domain compromise.

ACLs are invisible to vulnerability scanners. Nessus won't flag them. Qualys won't flag them. They exist as permissions on AD objects, and the only way to find dangerous ones is to enumerate every ACE on every object and map the relationships. That's exactly what BloodHound does. And it's exactly what most organizations never do.

How do you enumerate ACLs for a specific user with PowerView?

The -ResolveGUIDs flag is essential. Without it, you get ObjectAceType: 00299570-246d-11d0-a768-00aa006e0529, which means nothing to a human. With it, you get User-Force-Change-Password. Always use -ResolveGUIDs unless you enjoy looking up GUIDs in the Microsoft schema documentation at 2am.

How does BloodHound visualize ACL attack paths?

Upload your SharpHound data. Search for wley in the BloodHound GUI. Click the Node Info tab. Scroll to Outbound Control Rights. You'll see First Degree Object Control: 1 (the ForceChangePassword over damundsen) and Transitive Object Control: 16. Sixteen objects that wley can eventually control through chained ACL abuse. Click the 16 and BloodHound draws the entire path.

You've mapped the ACL attack path. You know exactly which permissions chain into domain compromise. Now you execute it. And then you clean up, because leaving fake SPNs and modified group memberships in a client's production AD is how you get fired.