Active Directory

A domain is a boundary of shared identity and policy. Domain controllers hold the directory database, replicate it among themselves, and answer the questions every joined machine asks: is this account real, is this password correct, may this account log on to that computer, what policy applies here. Domains group into a forest, and the forest is the real security boundary, because trust between domains in a forest is not something you can partially revoke.

Three mechanisms do most of the work. LDAP reads and writes the directory, and by default any authenticated account can read an enormous amount of it: every user, every group, every computer, every service principal name, every description field. Kerberos issues tickets that prove identity to services. NTLM is the older challenge-response mechanism that still runs almost everywhere for compatibility, and which is the basis of several attacks that have nothing to do with cracking a password. Group Policy pushes configuration and, because it does so from a share every machine reads, it is a distribution channel worth attacking on its own.

Permissions are the part that surprises people. Beyond group membership, every object in the directory carries an access control list, and rights such as resetting a password, writing to a group’s membership, or writing a specific attribute on a computer object are all delegable. Those delegations accumulate over a decade of operational fixes, and they are rarely written down anywhere.

The characteristic failure of Active Directory is not a vulnerability. It is accumulated privilege that nobody can see, and it is why an attack path tool is the first thing we run on an internal engagement. Read access to the directory is enough to build a graph of who can reach what, and in almost every estate that graph contains a route from an ordinary user to a domain administrator that consists entirely of legitimate permissions, granted individually for defensible reasons, over several years. Nobody granted the path. It emerged.

The specific links repeat across engagements. A helpdesk group with the right to reset passwords on accounts that turn out to include service accounts with high privileges. A group whose membership can be written by a group whose membership can be written by a group anyone can join. A computer object whose delegation settings allow it to request tickets on behalf of others. A certificate template that lets a low-privileged account request a certificate naming any user, which converts directory read access into domain administrator without a single password being cracked.

Then there is the data sitting in fields that everyone can read. Passwords in the description field of service accounts, still a real finding in 2026. Old logon scripts on a share with credentials in them. Deployment shares readable by all domain users. None of this needs an exploit.

Local administrator reuse is the fourth. One image, one password, every workstation. We recover the hash from the first machine and it is valid everywhere, which turns a single foothold into estate-wide lateral movement before any escalation is attempted.

The reason all of this survives is that Active Directory does not degrade when it is insecure. It keeps working perfectly. Nothing raises a ticket, nothing fails a health check, and the accumulated paths are invisible unless somebody deliberately looks for them.

Many estates now run both and treat them as one system, which produces gaps at the join. They are different products with different attack surfaces, and synchronisation between them is its own risk.

The important part is the last row. The account that synchronises the directory to the cloud holds extraordinary rights on both sides, and it is frequently excluded from the controls applied to everything else because it broke something once. A hybrid estate that treats its cloud tenant as separately secured, while a synchronisation account bridges the two with no conditional policy on it, has one identity boundary rather than two.

Believing membership of Domain Admins is the privilege inventory. It is a small part of it. The rights that matter are spread across object permissions, delegated administration and nested groups.

Treating read access to the directory as harmless. Everything an attacker needs to plan is readable by any authenticated account, and it is what makes the first hour of an internal test so productive.

Running services as domain accounts with human-chosen passwords. That is the precondition for kerberoasting, and it is the most common route from a standard user to something that matters.

Sharing the local administrator password across an image. It is the single fastest estate-wide movement primitive and it costs nothing to fix.

Assuming a tiering model exists because it was designed. Tier zero is only real if a tier zero credential can never land on a tier one machine, and that is a property to be tested rather than declared.

Map it before changing it. Run an attack path graph as a defender, from a normal user’s perspective, and read the shortest routes to your most privileged groups. That output is uncomfortable and it is the only accurate picture of the estate’s privilege model that exists.

Then cut the paths rather than the symptoms. Remove delegations nobody can justify. Flatten nested groups that grant administrative rights transitively. Move service accounts to managed passwords that the directory rotates. Randomise local administrator passwords per machine. Review certificate templates that allow a requester to specify the subject, which is the quietest full escalation route in a modern domain.

Separate the tiers and enforce the separation technically: administrative accounts that cannot log on to workstations, workstations that cannot reach domain controllers on administrative protocols, and privileged sessions from dedicated machines. Apply least privilege to the accounts that run things, not only to the people.

For detection, the useful signals are directory-specific: replication requests from a host that is not a domain controller, tickets requested for many service accounts in a short window, changes to privileged group membership, and certificate requests with a subject alternative name that does not match the requester.

Internal engagement reports are organised around the path rather than around a list of misconfigurations. We show where we started, each step, the permission or credential that made it possible, and where it ended. That structure is deliberate: a client can close one step and break the whole route, and a flat list of findings does not tell them which step to close first.

The evidence is the object names, the permissions as read from the directory, and the commands in their minimal form. Recovered credentials are not printed in the report body. Where the path relies on a delegation, we quote the access control entry, because the client’s directory team can verify it without taking our word for it.

Severity attaches to the path, not to each link. A password in a description field on an account with no rights is an observation. The same finding on an account that a certificate template lets us impersonate is one hop from the forest.

This is the work of testing a Windows estate from the inside, and it is where most Spanish corporate networks are actually decided.

Is Active Directory still relevant with cloud identity? In most Spanish mid-market and industrial estates it still authenticates the workstations, the file servers and the line-of-business applications. Cloud identity was added alongside it rather than replacing it, and the synchronisation between them is now part of the attack surface.

What is the difference between a domain and a forest? A domain is an administrative and replication boundary. A forest contains one or more domains that share a schema and trust each other implicitly. The forest is the security boundary: compromise of one domain in a forest should be assumed to be compromise of all of them.

Why can any user read so much of the directory? Because applications, logon processes and administrative tooling depend on it, and the default has been permissive since the beginning. Some of it can be restricted, most estates cannot restrict all of it, and the practical response is to remove the sensitive content from readable fields.

What is the fastest thing we can do to make it harder? Randomise local administrator passwords per host, move service accounts to directory-managed passwords, and remove password material from description fields and script files. Those three changes close the routes we use most often, and none of them require a project.