Active Directory recon - Mastering LDAP Queries for Red Team Intelligence

Active Directory (AD) is the central nervous system of most enterprise networks. For a Red Team Operator, querying AD is often the most important phase of internal reconnaissance. It tells you where users are, who has admin rights, and where sensitive servers live.

While modern tools like BloodHound and PowerView get most of the attention, the built-in Microsoft tools dsquery and dsget can extract this data without importing PowerShell scripts that might trigger AMSI (antimalware scan interface).

In this guide, we’ll perform deep reconnaissance using only tools Microsoft provides.

Technical Prerequisite: The RSAT Problem

#

Before we dive into the commands, let’s address a major hurdle: dsquery is not installed by default on Windows workstations.

It’s part of the Remote Server Administration Tools (RSAT). If you land on a standard user’s laptop (for example, via a phishing payload), dsquery will likely return “command not found.” You typically find this tool on:

1. Domain controllers (where it’s always available).
2. IT admin workstations (where RSAT is intentionally installed).
3. Jump boxes / management servers.
4. Exchange/SQL servers.

Practical dsquery Commands for red teaming

#

If you have RSAT on the host (or you bring your own dsquery.exe), here’s how to put it to work.

Finding Passwords in Descriptions (The “Low Hanging Fruit”)

#

Administrators often leave sensitive information, including temporary passwords, in the object description field.

dsquery * -filter "(&(objectCategory=person)(objectClass=user)(description=*pass*))" -attr samid description

Finding Stale Accounts

#

Accounts that haven’t been used in months are prime candidates for takeover because their owners won’t notice if they are suddenly active.

# Find users inactive for more than 4 weeks
dsquery user -inactive 4

Enumerating High-Value Groups

#

We always want to know who the Domain Admins are.

dsquery group -name "Domain Admins" | dsget group -members

Note: This pipes the “DN” (Distinguished Name) from query to get, expanding the list.

Identifying Domain Controllers

#

Detailed information on domain controllers helps you plan attacks like Zerologon or PetitPotam.

dsquery server -o rdn

Advanced Hunting: SPNs and Delegation

#

This is where dsquery becomes an attack tool.

Identifying Kerberos Service Accounts (SPNs)

#

Service Principal Names (SPNs) identify service accounts. If a user account has an SPN, you can request a Kerberos ticket and crack it offline (Kerberoasting).

dsquery * -filter "(&(objectCategory=person)(objectClass=user)(servicePrincipalName=*))" -attr samid servicePrincipalName

Finding Unconstrained Delegation

#

Finding servers with Unconstrained Delegation is a high-priority red team task. If a Domain Admin connects to a server with this setting, their TGT is cached in memory, allowing you to impersonate them.

The magic number for TRUSTED_FOR_DELEGATION in the userAccountControl attribute is 524288.

dsquery * -filter "(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -attr samid ipv4Address

Finding adminCount=1 (Protected Users)

#

Users marked with adminCount=1 are (or were) members of a protected group (like Domain Admins).

dsquery * -filter "(&(objectCategory=person)(objectClass=user)(adminCount=1))" -attr samid

Chaining DSQuery and DSGet

#

The true power of DSQuery comes when you pipe it into dsget. dsquery finds the object, and dsget extracts specific attributes.

Finding User Email Addresses

#

Useful for Phishing or Password Spraying targets.

dsquery user -name "*Smith*" | dsget user -email

Finding Computer Operating Systems

#

Useful for targeting exploitable versions (for example Windows 7/2008).

dsquery computer -name "SRV*" | dsget computer -os -samid

What if dsquery is missing? (PowerShell ADSI)

#

If you are on a restricted machine without RSAT, you can use the built-in [ADSISearcher] type accelerator in PowerShell. This performs the exact same LDAP queries but uses .NET. It is stealthy, built-in, and powerful.

Example: Finding Domain Admins query equivalent

$searcher = [adsisearcher]"(objectCategory=group)"
$searcher.Filter = "name=Domain Admins"
$result = $searcher.FindOne()
$result.GetDirectoryEntry().member

Example: Finding SPNs (Kerberoasting Candidates)

([adsisearcher]"(&(objectCategory=user)(servicePrincipalName=*))").FindAll() | Select-Object -ExpandProperty Properties

This is quieter and works on every Windows machine since Windows 7.

OpSec and Forensic Considerations

#

Active Directory enumeration is not silent.

1. LDAP Traffic: dsquery generates standard LDAP queries (TCP 389). Defenders monitoring network traffic will see large LDAP search responses going to a workstation that shouldn’t be mapping the network.
2. Microsoft Defender for Identity (MDI): MDI (formerly ATA) has specific alerts for “Reconnaissance using Directory Services.” Bulk queries from a non-admin workstation can trigger this.
3. Honeytokens: Smart Blue Teams create fake accounts (for example da_admin). If you query for *admin* and touch that object, you trip an alarm.
4. Event Logs: Extensive querying can trigger generic LDAP events, though precise “Who queried what” logging (Event ID 4662) is rare unless SACLs are configured on the AD objects.

Conclusion

#

DSQuery remains a fundamental tool for Active Directory reconnaissance when it’s available. By understanding how to construct raw LDAP filters, you can uncover critical misconfigurations like delegation issues and Kerberoastable accounts without needing external scripts.

Remember: tools are just wrappers around protocols. Whether you use dsquery, PowerView, or raw ADSI, the underlying LDAP query is the same. Master the query, master the domain.

Happy hunting!

References

#

• Microsoft - DSQuery Documentation
• HackTricks - Active Directory recon
• LDAP Filter Syntax