Enumerating an Active Directory Environment

A directory is a gigantic database about people and computers, and a normal user is allowed to read much of it. That is what makes enumeration so powerful: nobody needs to "break in" to learn how the company is organized. In this lesson you will understand what is collected, why graph tools changed the game, and why even reading data needs authorization.

What enumeration means

Enumeration is the step where you list what exists: users, groups, computers, shared folders, policies, trusts and the relationships between them. In a standard test, this follows reconnaissance. Your goal is not to collect everything but to answer questions: "Who has administrator rights? Which accounts run services? Which computers matter most?"

A good analogy is a city map. Reconnaissance tells you the city exists. Enumeration gives you streets, buildings and who holds the keys to which doors.

Where the information comes from

Active Directory exposes its data mainly through LDAP, a directory query protocol. Any authenticated user can usually read a large part of the directory, because applications need to look people up. Typical readable data includes:

• User accounts: names, descriptions, last logon dates, group memberships, password policy settings.
• Groups and their members, including nested groups, where a group is a member of another group.
• Computer accounts: names, operating system labels, roles.
• Service accounts and the services they run, identified by "service principal names".
• Group policies and the organizational units they apply to.
• Trust relationships between domains.
• Permissions on objects, known as access control lists.

Other sources complement LDAP: network shares, name resolution and information collected from computers where you legitimately have a session. In a test, which sources you may use is defined by your rules of engagement.

The old way: lists and spreadsheets

For years, testers exported lists and read them manually. That works for a small domain. In a company with tens of thousands of accounts, nobody can mentally follow group A that is a member of group B that has the right to reset the password of an operator who is a member of group C. The relationships are the problem, and spreadsheets are bad at relationships.

The graph idea

Tools such as BloodHound changed this by representing the directory as a graph: nodes are users, groups and computers, and edges are relationships such as "is a member of", "has a session on", "can reset the password of" or "has administrative rights on". Once the data is in a graph, a computer can search for the shortest path between an ordinary account and a highly privileged group.

This is the same idea as a route planner. You do not ask for a list of all roads; you ask for the quickest way from A to B. A graph reveals chains that no single administrator saw, because each link, taken alone, looked reasonable.

Notice that this is a gift for defenders too. The same graph tells a security team which relationships to remove so that no short path to privileged groups remains. Many organizations run such analyses regularly on their own directory, with permission, precisely to cut attack paths before somebody else finds them.

A mindset: paths, not vulnerabilities

Beginners often search for a "vulnerability", meaning a missing patch. In Active Directory the dominant problems are configuration and relationship issues:

• Excessive group nesting that gives rights nobody intended.
• Accounts with permissions to modify other accounts or groups.
• Administrators who log in to many machines, leaving privileged sessions in many places.
• Old accounts with weak passwords that still have broad rights.
• Delegation settings that were never reviewed.

These are not fixed by installing an update. They are fixed by design and hygiene, which is why AD work is so valuable for a defender and for a tester.

How noisy is enumeration?

Careful testers know that every action leaves traces. Large volumes of directory queries from one workstation in a short time look unusual to a well configured monitoring system. This matters for two reasons. In a red team exercise, it shapes how you plan an action. In a standard pentest, it reminds you to tell the client's security team how to recognize your activity, or to agree on a coordination plan, so that real incidents are not confused with your test. We will return to this in chapter 3.

Handling data responsibly

A directory dump contains names, job titles, sometimes phone numbers. It is personal data. In a real engagement you must store it encrypted, limit it to what you need, share it only with the client and delete it after the retention period agreed in the contract. In your portfolio, never publish real data: use only fictional objects from your lab.

Your turn: find the path on paper

Here is a tiny fictional directory. Relationships are written as "A → B: relationship".

lea       -> HelpDesk       : member of
HelpDesk  -> svc-backup     : can reset password of
svc-backup-> SRV-FILES      : administrator on
SRV-FILES -> admin-chris    : has a session
admin-chris-> Domain Admins : member of

Questions: (1) Starting from the ordinary user lea, is there a path to Domain Admins? (2) Which single relationship would you remove to cut the path with the least impact? (3) What would you write in the report?

See a solution

1. Yes: lea belongs to HelpDesk, which can reset the password of svc-backup, which is administrator on SRV-FILES, where admin-chris has a session, and admin-chris is a member of Domain Admins. Five hops separate an ordinary user from the most powerful group.
2. The most defensible fix is to remove the right of HelpDesk to reset the password of a privileged service account, and then to prevent domain administrators from signing in to ordinary servers. Removing the HelpDesk right is quick and has limited business impact. Cutting the administrator session on the file server is a good second layer.
3. The report should describe the chain in plain language, show a simple diagram, rate the risk by the potential impact (domain compromise) and the number of steps (low effort), and give the fixes above in priority order. Do not just paste a screenshot of a graph.

Portfolio step

In your 01-active-directory folder, add a file named attack-path-exercise.md that reproduces your reasoning for the exercise above, then invent a second, different fictional path of your own and solve it. Recruiters appreciate candidates who can explain a path clearly.

In lesson 1.3 you will look at the authentication protocol behind most of these paths: Kerberos.