dsquery is a Windows command-line tool that queries Active Directory for users, groups, computers and other directory objects. Attackers use it for domain reconnaissance and target discovery before credential theft or lateral movement. Defenders should monitor for unusual directory enumeration from non-administrative systems and restrict who can run directory query tools.
What dsquery is actually doing
dsquery is a Windows directory-query utility for Active Directory. It can search for users, groups, computers, organizational units and other directory objects from the command line, which makes it useful for quick discovery, scripting and troubleshooting. Because it speaks directly to directory metadata, it is also a common reconnaissance tool in environments where attackers already have some foothold.
The practical effect is simple: dsquery helps answer “what objects exist, and how are they named or grouped?” rather than “what actions can those objects take?” That distinction matters, because enumeration alone does not change access, but it can reveal targets, naming patterns, administrative structure and potentially valuable systems to probe next.
When defenders see dsquery used outside normal admin workflows, it often indicates directory reconnaissance that fits common adversary discovery patterns. That does not prove compromise by itself, but it does mean the command deserves the same attention as other legitimate tools that are frequently reused during an intrusion.
Why attackers like it for reconnaissance
dsquery is attractive because it is native, quiet compared with custom tooling and often blends into ordinary Windows administration. Attackers can use it to map domain structure, identify likely high-value accounts, locate computer objects and narrow their search before credential theft, privilege escalation or lateral movement.
That “living off the land” characteristic is why dsquery belongs in the same defensive conversation as other dual-use Windows utilities. A command-line query against Active Directory may be routine on an admin workstation, but the same query from a non-administrative host, at unusual times or in bulk, can be an early sign that someone is building an attack path.
For defenders, the most useful interpretation is behavioural rather than purely technical. Focus on who ran it, from where, how often, and whether the query scope matches the user’s normal job function. A single lookup from a directory admin is not the same signal as repeated enumeration from a workstation that never normally performs administrative discovery. The Living off the Land Guide is a good companion reference for understanding why dsquery sits inside a broader class of dual-use utilities.
How to monitor and constrain dsquery use
Detection should start with process and command-line telemetry, especially where you can distinguish administrative tooling from user endpoints. Watch for dsquery launched from endpoints that do not normally manage Active Directory, use of unexpected accounts, repetitive broad searches and queries that occur alongside other discovery tools such as nltest, net, whoami or adfind.
Prevention is mostly about reducing unnecessary exposure. Limit directory-query tooling to approved admin systems, restrict local execution rights where possible and pair that with tight administrative separation so everyday users cannot freely run discovery commands on domain objects. On the monitoring side, correlate dsquery activity with logon source, account type and subsequent movement so a query is interpreted in context rather than as an isolated event.
Use ordinary security logging, not just endpoint alerts, to keep the picture complete. Command-line visibility, directory service auditing and identity-aware correlation make it easier to tell the difference between legitimate administration and a staged reconnaissance sequence. MITRE ATT&CK Enterprise Matrix helps anchor dsquery behaviour to the reconnaissance and discovery phase so your detections stay behaviour-focused.
Risk and Threat Considerations
dsquery is risky because it can convert simple directory visibility into an attacker’s map of the environment. The tool itself is not malicious, but it lowers the effort needed to enumerate accounts, systems and groups, which can make later credential attacks or lateral movement more efficient and less noisy.
Failure mechanism: An operator with limited access, or an attacker using a stolen account, runs broad directory queries from a system that should not be performing administrative discovery. The queries reveal object names, group structure and target candidates, which are then used to focus follow-on abuse.
Impact: The result is improved attacker targeting, reduced search cost and faster progression from initial foothold to privilege abuse or movement across the domain. In mature environments, the bigger risk is not the query itself but the missed opportunity to detect the reconnaissance stage before more damaging activity begins.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1087 — Account Discovery | dsquery enumerates directory accounts and groups for reconnaissance. |
| Recommendation — Map dsquery activity to discovery detections and alert on abnormal account enumeration. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Monitoring dsquery needs command, host and account logging to spot reconnaissance. |
| Recommendation — Centralize process and command-line logs for directory-query activity. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Command execution telemetry is needed to detect dsquery abuse and investigate it. |
| AC-6 — Least Privilege | Restricting who can run directory-query tools reduces reconnaissance exposure. | |
| IA-5 — Authenticator Management | Reconnaissance often precedes credential theft, making credential hygiene relevant. | |
| Recommendation — Enable audit generation for directory-query commands on admin and endpoint systems. Limit dsquery execution rights to approved administrative roles and systems. Rotate and protect credentials that could be used to pivot after directory discovery. | ||
Practitioner Guidance
What to verify: Confirm whether dsquery execution is expected on the source host, under the account used, and at the volume and timing observed. If the answer is “no” on any of those points, treat it as a security review event rather than routine admin activity.
Decision rule: If the command came from a non-admin workstation or an account outside the normal admin set, prioritize investigation of the session and surrounding activity before assuming it was benign. If it came from an approved management host, validate that the query scope matches the operator’s role and change window.
Practitioner takeaway: dsquery is best handled as a visibility signal, not just a utility, because the security value lies in knowing when directory enumeration is normal and when it is the first observable step in an intrusion.