1. Introduction
Active Directory (AD) is not just a directory service; it is the nervous system of the modern enterprise.
It controls who has access to what, enforces security policies, and manages the identity of every user and machine in the network.
At the heart of this system lies the Domain Controller (DC) , the brain that authenticates requests and authorizes access. If you control the DC, you control the infrastructure.
When an organization first deploys Active Directory, they create a Domain (e.g., corp.local).
This acts as a security boundary. Every employee's laptop, every database server, and every printer joins this domain to participate in the network. Over time, this structure grows complex.
Administrators organize these objects into Organizational Units (OUs), logical containers mirroring the business structure, such as IT, HR, Finance, or Engineering.
For a penetration tester or a Red Teamer, understanding this hierarchy is not optional; it is the prerequisite for any meaningful attack path. You are not just looking for a vulnerability; you are looking for the relationships that bind these objects together.
2. Active Directory Enumeration: Mapping the Battlefield
Enumeration is the phase where we turn the “unknown” into the known. Before launching any exploits, we must build a high-fidelity map of the environment.
We need to identify high-value targets (like the “Domain Admins” group), discover where they are logged in, and understand the trust relationships between different users and computers.
In a typical engagement, you start with a foothold , a compromised workstation that is already joined to the domain.
This is your beachhead. From this vantage point, you don’t need to hack the Domain Controller immediately; you simply need to ask it questions.
Since Active Directory is designed to be a phonebook, it is remarkably willing to answer queries from any authenticated user, regardless of their privilege level. We will use this intrinsic feature to query the AD database (NTDS.dit) for users, groups, and computers.
3. Enumerating Users, Groups, and Computers
The first step in our reconnaissance is a census. We need to know who lives here. By utilizing PowerShell and the .NET framework, specifically the LDAP (Lightweight Directory Access Protocol) provider, we can query the Global Catalog.
In the practical example (referenced in your video content), we leverage a custom PowerShell script to interact with the System.DirectoryServices.DirectorySearcher class.
This class allows us to perform LDAP search queries against the domain. We aren’t just listing names; we are extracting metadata. We want to know: Who is a member of the “Backup Operators” group? Which users have “Do not require Kerberos pre-authentication” enabled? Which computers are running outdated operating systems?
💡 Expert Insight: The Power of ADSI You don’t always need heavy tools like BloodHound or RSAT installed. The “ADSI Accelerator” ([adsisearcher]) is built into PowerShell on every Windows machine by default.
A simple one-liner like ([adsisearcher]"(&(objectClass=user)(adminCount=1))").FindAll() can instantly reveal every high-privileged admin user in the domain without triggering the antivirus alerts that common hacking tools might generate. This technique is known as "Living off the Land."
4. Enumerating Logged-in Users and Active Sessions
Once we know who the users are, the next critical question is where they are. This is the concept of Session Hunting. If we can find a machine where a Domain Admin is currently logged in, and we can compromise that machine, we can dump their credentials from memory (LSASS) and take over the domain.
To achieve this, we rely on two specific Windows APIs that offer different vantage points:
- NetWkstaUserEnum: This API queries the “Workstation Service” on a remote machine. It is highly accurate and returns a list of users interactively logged onto that specific computer. However, it has a steep cost: it generally requires local administrative privileges on the target machine to function.
- NetSessionEnum: This API queries the “Server Service.” It doesn’t tell you who is typing on the keyboard; it tells you who has a network session established with that machine (e.g., someone accessing a file share). Crucially, this often does not require administrative privileges to query against a Domain Controller or File Server.
By combining these two data sources, we can triangulate the location of key personnel without tripping alarms.
5. Enumerating Service Principal Names (SPN)
Finally, we must identify the services running across the infrastructure. In Active Directory, a service (like SQL Server, IIS, or Exchange) must be linked to a specific account so that it can authenticate using Kerberos. This link is called a Service Principal Name (SPN).
Think of an SPN as a unique identifier , a name tag — that tells the Kerberos system: The MSSQL service on Server-01 is running under the context of the ‘svc_sql’ user account.
Enumerating SPNs is a powerful alternative to traditional port scanning. Instead of sending noisy network packets to every port on every server (which alerts the SOC), we simply query the Domain Controller for a list of all SPNs. The DC happily returns a list of every SQL server, Web server, and Exchange server in the domain, along with their IP addresses and port numbers.
💡 Expert Insight: The Kerberoasting Opportunity SPN enumeration is the precursor to one of the most effective attacks in AD: Kerberoasting.
Once you verify that a user account has an SPN associated with it, you can request a Kerberos ticket (TGS) for that service. This ticket is encrypted with the service account’s password hash. You can take this ticket offline and attempt to crack it. If the service account has a weak password, you gain a foothold with zero direct interaction with the target server.
0 comments