The 5 Active Directory misconfigurations we find in almost every internal audit

In almost every internal audit we run, the domain ends up falling. And it is almost never down to a sophisticated flaw or an exotic zero day. It is down to a handful of configurations that repeat company after company, that piled up over years and that no one looked at again.

They are configuration mistakes, not software bugs, so they show up in no patch bulletin. But an attacker with an unprivileged starting position finds them in a matter of minutes. These are the five that open the door for us most often.

Service accounts that can be kerberoasted

In Active Directory, any authenticated user can request a service ticket for an account that has an SPN attached. That ticket is encrypted with the service account’s password, so whoever requests it can take it home and try to crack it offline, with no noise and no account lockouts.

The problem is that many service accounts were created years ago with short or reused passwords and they often hold high privileges. An unprivileged attacker requests the ticket, cracks it on their own machine and turns up with a service account that is frequently an administrator of something important.

The fix is to use managed service accounts (gMSA), which rotate the password automatically at lengths that are impossible to crack. Where that is not possible, use long random passwords of more than 25 characters. It is also worth reviewing which accounts keep an SPN that is no longer used.

Accounts without Kerberos pre-authentication

There is an option on user accounts called “do not require Kerberos pre-authentication”. When it is enabled, anyone can ask the domain controller for a piece of data encrypted with that account’s password, again to crack it quietly offline.

It tends to be set on old accounts, on integrations with Unix systems or on applications that needed it at some point and no one reverted. Each of those accounts is a password an attacker can go after offline from the very first minute, without even holding valid credentials.

The fix is straightforward. Review which accounts have that option enabled and disable it on every one that does not genuinely need it, which is usually almost all of them. For the few that must keep it, set a long random password.

Passwords in clear text where they should not be

This is one of the ones that most surprises us to keep finding. It shows up almost every time.

On one side, the description or notes field of user accounts, where someone wrote down the password “to remember it” years ago. Any domain user can read those fields. On the other, Group Policy Preferences (GPP) that stored passwords in the SYSVOL share encrypted with a key Microsoft published more than a decade ago, so decrypting them is trivial. SYSVOL is readable by anyone who is authenticated.

The fix is to search and delete. There are tools that sweep the descriptions across the whole domain and the SYSVOL looking for these leftovers. Whatever turns up gets removed, the affected password is rotated and it becomes a rule that credentials do not live in attributes or in scripts.

Excessive permissions over privileged objects

Control of a domain is not always won by being an administrator. Sometimes it is enough to hold dangerous permissions over the right accounts or groups.

In almost every domain we audit there are ordinary accounts, with no privileged look to them, that can nonetheless change an administrator’s password, modify who belongs to a privileged group or rewrite the permissions of a critical object. These are permissions like GenericAll or WriteDACL that were delegated badly at some point or inherited without anyone planning it. For an attacker they are a motorway, because chaining two or three of those permissions reaches domain administrator without exploiting any vulnerability.

The fix is the most laborious on the list. You have to map who holds permissions over what, above all on the privileged accounts and groups, to then trim everything that is not justified. Tools that draw these relationships help to see the paths an attacker would follow.

Unconstrained delegation

Delegation in Kerberos lets a service act on behalf of a user to reach another service. It is useful and sometimes necessary, but it has a dangerous variant we call unconstrained delegation.

When a server has unconstrained delegation enabled, it keeps in memory the tickets of any user who connects to it, including those of a domain administrator. If an attacker controls that server, or gets an administrator to connect, they walk away with a ticket that hands them the entire domain. And this kind of delegation still turns up enabled on servers that never needed it.

The fix is to remove unconstrained delegation wherever it is not needed, which is almost always. Where delegation is genuinely required, the constrained variant is used, which limits which specific services can be delegated to. The most sensitive accounts, on top of that, are marked as never allowed to be delegated.

What these five have in common

None of these five things is a vulnerability in the classic sense. There is no patch that closes them, they do not show up in the kind of automated scanner that scores with colours and almost always coexist with compliance that is perfectly in order. They are configurations, decisions someone made years ago that time turned into holes.

That is why we find them again and again. And that is why an automated scan almost never sees them. It takes someone looking at the domain the way an attacker looks at it, chaining permissions and relationships instead of going through a list. It is exactly the difference we wrote about in why passing a compliance audit does not mean you are secure.

If it has been a while since anyone looked at your Active Directory with those eyes, the odds are that at least two or three of these five are waiting.

---

If you want us to audit your Active Directory from the position of an internal attacker, write to us at [email protected].