Overview

Domain Account Discovery (T1087.002) is a technique where adversaries enumerate domain user accounts and groups to map out the Active Directory environment. Attackers use this information to identify high-value targets — domain admins, service accounts, and privileged users — that they can subsequently compromise to escalate privileges or move laterally across the network.

Every security team needs visibility into this technique because it is a near-universal step in both targeted intrusions and ransomware campaigns. Detecting domain enumeration early — before an attacker acts on the intelligence they gather — gives defenders a critical window to interrupt the attack chain before damage occurs.

Attacker Perspective

Once an attacker has an initial foothold, enumerating domain accounts is typically one of the first reconnaissance steps taken to understand what targets are worth pursuing.

• Net utility abuse: Running net user /domain and net group "Domain Admins" /domain from a compromised workstation to list all domain users and identify privileged group membership.
• PowerShell AD enumeration: Using Get-ADUser -Filter * -Properties * or Get-ADGroupMember -Identity "Domain Admins" -Recursive via PowerShell remoting or a local shell to pull detailed account attributes including last logon, password age, and account status.
• BloodHound/SharpHound collection: Executing SharpHound.exe -c All or the PowerShell equivalent Invoke-BloodHound -CollectionMethod All to perform LDAP-based bulk enumeration and graph the relationships between users, groups, and computers for attack path planning.
• LDAP direct queries: Using ldapsearch -x -H ldap://DC01 -b "DC=corp,DC=com" "(objectClass=user)" from a Linux or macOS host, or dsquery user -limit 0 on Windows, to query Active Directory directly and export account data without relying on the Net utility.

This technique is attractive because it requires no special exploits, uses built-in OS tools or widely available utilities, blends easily with legitimate IT activity, and provides the attacker with a complete roadmap of targets before they make their next move.

Detection Strategy

Required Telemetry

• Windows — Process Creation (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation → Success. Also enable command-line logging: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. This captures the full command line of every process launch, which is essential for detecting net user /domain and similar commands.
• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging → Enabled, or set registry key HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Captures the full content of PowerShell scripts and commands, including Get-ADUser and Get-ADGroupMember cmdlets.
• Windows — PowerShell Module Logging (Event ID 4103): Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Module Logging → Enabled, registry: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1. Logs individual pipeline executions of PowerShell modules, providing redundant coverage for AD cmdlets.
• Windows — Security Log — LDAP Query Activity (Event ID 1644): Enables logging of expensive, inefficient, or specific LDAP queries on Domain Controllers. Enable via registry on each DC: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics → 15 Field Engineering = 5. Captures LDAP searches that enumerate user objects, which SharpHound and ldapsearch will generate.
• Windows — Active Directory — Directory Service Access (Event ID 4662): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → DS Access → Audit Directory Service Access → Success. Logs access to AD objects — essential for catching direct LDAP reads of user and group objects on Domain Controllers.
• Windows — Sysmon (Event ID 1 — Process Creation, Event ID 3 — Network Connection): Deploy Sysmon with a community-vetted config (e.g., SwiftOnSecurity or Olaf Hartong’s modular config). Event ID 1 provides richer process telemetry including hashes, parent process GUIDs, and full command lines. Event ID 3 captures outbound network connections from enumeration tools connecting to LDAP (TCP 389) or LDAPS (TCP 636).
• Linux — Auditd Rules: Add the following rules to /etc/audit/rules.d/audit.rules to capture execution of ldapsearch and related tools:
  -a always,exit -F arch=b64 -S execve -F path=/usr/bin/ldapsearch -k domain_enum
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/ldapwhoami -k domain_enum
  These rules generate EXECVE audit records that capture the full argument list passed to LDAP utilities.
• macOS — Unified Log / EndpointSecurity Framework: Use an EDR agent (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) or enable OpenBSM auditing to capture execve calls for dscacheutil, dscl, and ldapsearch. Configure the BSM audit class for process events: add lo,aa flags to /etc/security/audit_control.
• Network — LDAP Traffic Logs: If your environment uses a network detection platform (Zeek, Suricata, or an NDR solution), enable LDAP protocol parsing. Zeek’s ldap.log and ldap_search.log (available via the ldap package) will capture queries, base DNs, and filters sent to Domain Controllers — invaluable for detecting bulk LDAP enumeration that never touches endpoint logs.

Key Indicators

• Net utility — domain user/group enumeration: Source: Windows Security Event ID 4688 or Sysmon Event ID 1. Check process_name = "net.exe" or process_name = "net1.exe" with command_line containing /domain in combination with user or group. Example patterns: net user /domain, net group /domain, net group "Domain Admins" /domain.
• PowerShell AD cmdlets: Source: Event ID 4104 (Script Block Logging). Check ScriptBlockText for values containing Get-ADUser, Get-ADGroupMember, Get-ADGroup, Get-ADObject, or Get-ADPrincipalGroupMembership. Flag especially when combined with -Filter * or -Properties *, which indicate bulk enumeration.
• SharpHound / BloodHound execution: Source: Sysmon Event ID 1 or EDR telemetry. Check original_filename or file_description for SharpHound. Also check command_line for patterns like -CollectionMethod All, -c All, or Invoke-BloodHound. Hash-based detection: maintain a hash list of known SharpHound versions for file hash matching.
• LDAP enumeration from non-DC hosts: Source: Zeek ldap_search.log or Sysmon Event ID 3. Check destination_port = 389 or destination_port = 636 where source_host is not a Domain Controller, and the LDAP filter field contains (objectClass=user) or (objectClass=group) or (sAMAccountType=805306368).
• dsquery / dscacheutil execution: Source: Sysmon Event ID 1 (Windows) or Auditd EXECVE (Linux/macOS). Check process_name = "dsquery.exe" with command_line containing user and -limit 0. On macOS, check process_name = "dscacheutil" with arguments -q group or -q user, or process_name = "dscl" with arguments reading from /Active Directory/.
• Suspicious parent process: Source: Sysmon Event ID 1 or Windows Event ID 4688. Flag any of the above enumeration commands where parent_process_name is cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, or a known LOLBin. Enumeration launched from these parents is highly suspicious and rarely legitimate.
• Bulk LDAP query volume: Source: Windows Event ID 1644 on Domain Controllers or Zeek LDAP logs. Alert when a single source IP or host generates more than a threshold (e.g., 50) LDAP search operations within a 5-minute window, especially if the queries target objectClass=user or objectClass=group.
• Output files written after enumeration: Source: Sysmon Event ID 11 (FileCreate). Watch for creation of files with extensions .json, .zip, .csv, or .xml within seconds to minutes of an enumeration command executing, particularly in temp directories like %TEMP%, C:\Windows\Temp, or the user’s home directory. SharpHound writes BloodHound ZIP archives containing JSON files immediately after collection.

Detection Logic

Rule 1 (Broad — High Sensitivity): Domain Enumeration via Net Utility
IF process_name IN ["net.exe", "net1.exe"]
AND command_line MATCHES "/(user|group)\s.*/domain"
AND NOT parent_process_name IN ["msiexec.exe", "sccm.exe", "ccmexec.exe"]
THEN alert(severity=MEDIUM, label="T1087.002 - Net Domain Enumeration")

This catches the most common and lowest-skill form of domain enumeration. Expected volume: low to medium in most environments — a handful of alerts per day in environments without exclusions. Tune aggressively using the guidance below to suppress legitimate IT tooling before promoting to higher severity.

Rule 2 (Medium — Balanced): PowerShell Active Directory Bulk Enumeration
IF event_id = 4104
AND ScriptBlockText MATCHES "(Get-ADUser|Get-ADGroupMember|Get-ADGroup|Get-ADPrincipalGroupMembership)"
AND ScriptBlockText MATCHES "(-Filter \*|-Properties \*|Recursive)"
AND NOT user IN [approved_ad_admin_accounts]
AND NOT host IN [approved_admin_workstations]
THEN alert(severity=HIGH, label="T1087.002 - PowerShell AD Bulk Enumeration")

Targets bulk AD queries that are characteristic of attacker tooling rather than point-in-time administrative lookups. Expected volume: very low after exclusions are applied for legitimate admin accounts. Hits from standard user accounts or non-admin workstations should be treated as high priority.

Rule 3 (Narrow — High Precision): SharpHound / BloodHound Execution
IF (process_name MATCHES "(?i)sharphound"
OR original_filename MATCHES "(?i)sharphound"
OR command_line MATCHES "(-CollectionMethod|Invoke-BloodHound|c All|--zip)"
OR file_hash IN [known_sharphound_hash_list])
THEN alert(severity=CRITICAL, label="T1087.002 - Suspected BloodHound Enumeration")

This is a high-fidelity rule targeting the most common automated AD enumeration tool. False positive rate should be near zero outside of authorized red team exercises. Any alert from this rule warrants immediate escalation and investigation.

Rule 4 (Behavioral — Volume-Based): Bulk LDAP Enumeration from Endpoint
IF destination_port IN [389, 636, 3268, 3269]
AND source_host NOT IN [known_domain_controllers, approved_ldap_clients]
AND COUNT(distinct ldap_filter) > 10 WITHIN 5 minutes
AND ldap_base_dn MATCHES "DC="
THEN alert(severity=HIGH, label="T1087.002 - Bulk LDAP Query from Non-DC Host")

Detects the network-level footprint of tools like SharpHound or custom LDAP enumeration scripts that generate many distinct LDAP queries in a short period. Requires Zeek or an NDR platform with LDAP parsing. Expected volume: very low after approved LDAP clients (directory sync tools, monitoring agents) are excluded.

Tuning Guidance

• IT Helpdesk and AD Admin Activity: Sysadmins and helpdesk staff legitimately run net user /domain and Get-ADUser regularly. Exclude known admin accounts (user IN [ad_admin_group_members]) and dedicated admin workstations (host IN [jump_server_list, paw_list]) from Rules 1 and 2. Do not blanket-exclude AD admin groups from Rule 3 (SharpHound has no legitimate production use).
• Identity and Directory Sync Tools: Products like Azure AD Connect, Okta AD Agent, and similar identity providers make frequent bulk LDAP queries to Domain Controllers. Identify their service account names and source IP addresses and add them as exclusions in Rule 4: source_ip NOT IN [aadc_server_ip, okta_agent_ip] and user NOT IN [aadc_service_account, okta_service_account].
• Monitoring and Vulnerability Scanners: Tools like Tenable Nessus, Qualys, and SCCM inventory tasks may enumerate domain accounts as part of asset discovery. Exclude their source hosts: parent_process_name NOT IN ["ccmexec.exe", "nessus.exe"] and add scanner IPs to the LDAP exclusion list.
• HR and Provisioning Automation: Automated onboarding scripts or identity governance platforms (SailPoint, Saviynt) may run AD enumeration commands on a schedule. Work with the identity team to identify the service accounts and scheduled task contexts these use, then exclude the specific account-and-host combination rather than the account alone.
• Developer and DevOps Environments: CI/CD pipelines or application testing environments that integrate with AD may generate LDAP queries or PowerShell AD cmdlets. Identify these environments and add their host ranges to LDAP client exclusions. Flag any occurrence of these patterns on production hosts even if excluded from dev environments.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Pull the raw event directly from your SIEM or the originating log source (Windows Event Viewer, Sysmon operational log, or auditd journal) and confirm the event exists with the full field values shown in the alert. Ensure the timestamp, host, and user match what is expected and the event has not been duplicated or misformatted by log shipping.
2. Identify the affected host and user: Confirm the hostname, IP address, and the account that executed the command using Event ID 4688 fields SubjectUserName and SubjectLogonId, or Sysmon’s User field. Cross-reference the account in Active Directory to determine if it is a standard user, privileged account, service account, or one that has been previously flagged — any privileged account or service account running enumeration commands is an immediate escalation trigger.
3. Pull the full command-line and parent process chain: Use Sysmon Event ID 1 or Windows Event ID 4688 to retrieve the complete CommandLine and correlate via ParentProcessGuid or ParentProcessId to build the full process tree. Work backwards to the root parent — a chain ending at svchost.exe → cmd.exe → net.exe is far more suspicious than Explorer → cmd → net, and may indicate execution via a service or scheduled task.
4. Check for network connections and files written to disk: Search Sysmon Event ID 3 (NetworkConnect) for outbound connections from the host around the time of the alert — particularly to external IPs on ports 389, 636, 443, or 445, which may indicate data being staged or exfiltrated. Also search Sysmon Event ID 11 (FileCreate) for any new files written in the minutes following the enumeration command, especially ZIP, JSON, CSV, or XML files in temp directories that could be BloodHound output or staged enumeration data.
5. Look for lateral movement from this host: Search Windows Security Event ID 4648 (explicit credential use) and Event ID 4624 (logon) on other hosts in your environment where the source IP matches the investigated host. Also check Event ID 4768 and 4769 (Kerberos ticket requests) on Domain Controllers for tickets requested under the affected account from this host shortly after the enumeration activity, which may indicate the attacker is moving to their identified targets.
6. Search for persistence mechanisms added: On the affected host, review Sysmon Event ID 13 (RegistryValueSet) for changes to run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), and Event ID 12/13 for modifications to autostart locations. Check Windows Event ID 4698 (scheduled task created) and Event ID 7045 (new service installed) in the timeframe surrounding the alert. On Linux, inspect /etc/cron*, user crontabs, and ~/.bashrc for injected commands.
7. Escalation decision: Treat the event as a confirmed incident requiring immediate escalation if any of the following are true: (a) the account is privileged and the activity is out of pattern for that account’s baseline, (b) SharpHound or BloodHound artifacts are found on disk, (c) network connections to unknown external IPs are identified, (d) lateral movement evidence exists, or (e) persistence mechanisms have been added. If the command originated from a known admin account on an approved admin workstation with no additional suspicious activity, document as a tuning candidate and close as a false positive after confirming with the account owner.

Response Playbook

Containment

• Isolate the affected host from the network immediately but leave it powered on to preserve in-memory artifacts for forensic collection. Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, or SentinelOne Network Quarantine) to cut network access without shutting down, or physically disconnect the network cable on physical systems. Do not reimage or power off until forensics are collected.
• Disable the affected user account in Active Directory to prevent further use of potentially compromised credentials. Use Disable-ADAccount -Identity [username] in PowerShell or the Active Directory Users and Computers console. If the account is a service account, coordinate with application owners before disabling to understand service impact.
• Revoke all active sessions and Kerberos tickets for the affected account by resetting the account password immediately, which invalidates existing Kerberos tickets. Use Set-ADAccountPassword and Set-ADUser -Identity [username] -ChangePasswordAtLogon $true. Additionally, purge cached credentials on the host if possible using your EDR’s remote script capability.
• Block identified malicious IPs and domains at the firewall and DNS layer. If the investigation identified any external C2 or data exfiltration destinations, add block rules to your perimeter firewall and create DNS sinkhole entries for any identified domains. Notify your network team to confirm blocks are applied across all egress points.
• Kill any active malicious processes identified in the process tree investigation using your EDR console’s remote kill-process capability, or via Stop-Process -Id [PID] -Force executed through a remote management channel. Document the PID, process name, hash, and parent chain before terminating.

Eradication

• Remove all identified persistence mechanisms discovered during investigation: delete malicious scheduled tasks (Unregister-ScheduledTask -TaskName [name] -Confirm:$false), remove malicious registry run keys, and stop and delete any rogue services (sc delete [servicename]). Verify each removal by querying the artifact again to confirm it no longer exists.
• Hunt for and delete all attacker-dropped tools and payloads found on disk, including SharpHound binaries, custom enumeration scripts, and any output files (BloodHound ZIP archives, CSV exports). Use your EDR to search across the environment for matching file hashes from the investigation, not just on the initially compromised host.
• Reset credentials for every account that executed or was exposed to malicious activity, including the compromised user account, any accounts whose credentials may have been visible in memory on the host (check for LSASS access via Sysmon Event ID 10), and any service accounts associated with the system. Prioritize privileged accounts and those identified in the attacker’s enumeration output.
• Inspect all hosts the attacker touched via lateral movement for additional persistence, dropped tools, or signs of further compromise. Run the same persistence hunting queries (scheduled tasks, run keys, new services, new local accounts via Event ID 4720) across every host identified in the lateral movement investigation step.
• Rotate any secrets or API keys that may have been exposed. If the compromised host had access to secrets management systems, cloud credential files, or API keys stored in environment variables or config files, treat those secrets as compromised and rotate them immediately. Check for .aws/credentials, .ssh/ keys, and application config files containing plaintext credentials.

Recovery

• Before reconnecting the host to the network, verify it is fully clean by running a full EDR scan and reviewing the forensic artifacts collected. If confidence in the cleanliness of the host is less than certain — particularly if the attacker had extended dwell time or SYSTEM-level access — reimage the host from a known-good baseline rather than attempting to clean it in place.
• Re-enable the affected user account only after confirming no persistence remains on the host or any lateral movement targets, and only after credentials have been fully reset. Brief the user on the incident and require them to verify their account activity before returning to normal operations.
• Monitor the previously affected host, user account, and any lateral movement targets intensively for 72 hours post-remediation. Create temporary high-sensitivity detection rules in your SIEM scoped to these specific hosts and accounts, alerting on any recurrence of enumeration commands, new external network connections, or authentication anomalies.
• Document the complete incident timeline from initial compromise through containment and remediation, including all IOCs discovered (file hashes, IPs, domains, account names, host names). Share relevant IOCs with your threat intelligence platform and submit to appropriate sharing communities (ISAC, partner organizations) if applicable.
• Review and update your detection rules based on any new IOCs, techniques, or gaps identified during the investigation. If the attacker used an enumeration variant or tool not covered by existing rules, write a new detection before closing the incident. Conduct a formal lessons-learned review with the SOC team to identify any delays in detection or response that can be addressed through process improvements or additional telemetry.