Overview

Domain Groups enumeration (T1069.002) is the act of querying Active Directory or a domain controller to map out domain-level groups and their memberships. Attackers use this information to identify high-value targets — specifically accounts with elevated privileges such as Domain Admins, Enterprise Admins, or custom delegated admin groups — so they can prioritize credential theft, lateral movement, or privilege escalation toward those accounts.

This technique is a critical early warning signal because it almost always appears in the reconnaissance phase before a major escalation event. Detecting it gives your team a window to intervene before the attacker reaches their actual objective. Missing it means you may not see the threat until a domain admin account is compromised or ransomware is executing.

Attacker Perspective

After gaining an initial foothold, attackers enumerate domain groups to build a map of who holds the keys to the kingdom before making their next move.

• BloodHound/SharpHound: Automated LDAP-based enumeration that queries all domain groups, memberships, and ACLs in bulk; the collected data is later visualized to find the shortest path to Domain Admin.
• Net.exe commands: Simple built-in Windows commands such as net group "Domain Admins" /domain or net group /domain require no special tools and blend in with legitimate IT activity.
• PowerView/SharpView: PowerShell-based AD recon using functions like Get-DomainGroup, Get-DomainGroupMember, or Find-ForeignGroup that query LDAP directly and can evade simple process-name detection.
• ldapsearch (Linux/macOS): Direct LDAP queries against a domain controller from a Linux host using commands like ldapsearch -x -b "DC=corp,DC=local" "(objectClass=group)", often used post-compromise on Linux servers joined to AD.

This technique is attractive because it uses legitimate system tools and protocols, produces no immediate system changes, and gives attackers high-value intelligence with very low risk of causing an observable incident response trigger.

Detection Strategy

Required Telemetry

• Windows Process Creation (Sysmon Event ID 1 or Security Event ID 4688): Captures command-line arguments for every spawned process. Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation, set to Success. For command-line logging, also enable: Administrative Templates → System → Audit Process Creation → Include command line in process creation events. Sysmon requires a deployed configuration with at minimum a ProcessCreate rule.
• PowerShell Script Block Logging (Event ID 4104): Captures the full content of PowerShell script blocks, including deobfuscated content. Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging → Enabled, or via registry: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Without this, PowerShell-based enumeration is nearly invisible.
• Windows Security Event ID 4661 and 4662: Logs access to AD objects. Enable via Advanced Audit Policy → DS Access → Audit Directory Service Access, set to Success. Event 4662 fires when an operation is performed on an AD object (such as a group), and is critical for catching LDAP-based enumeration tools like SharpHound.
• Windows Security Event ID 4799: Fires specifically when a security-enabled local group membership is enumerated. Enable via Advanced Audit Policy → Account Management → Audit Security Group Management, set to Success.
• Network/DNS Logs: LDAP traffic (TCP/UDP 389, LDAPS 636, Global Catalog 3268/3269) between workstations and domain controllers should be baselined. Unexpected workstation-to-DC LDAP spikes are a strong indicator of automated enumeration tools like SharpHound.
• Linux: auditd rules to capture execution of ldapsearch: add -a always,exit -F exe=/usr/bin/ldapsearch -k domain_enum to /etc/audit/rules.d/audit.rules. Use auditd logs shipped to your SIEM via auditbeat or syslog forwarding.
• macOS: Unified System Log / auditd: Enable endpoint security framework or use Jamf/osquery to capture process execution events for commands like dscacheutil -q group and dscl . -list /Groups.

Key Indicators

• net.exe domain group queries: In process creation logs (Sysmon EID 1 or Security EID 4688), look for Image ending in \net.exe or \net1.exe where CommandLine contains group and /domain. Example pattern: CommandLine = "*net* group* /domain*". Parent process is suspicious if it is cmd.exe or powershell.exe spawned by an unexpected parent like a browser or Office application.
• SharpView execution: In process creation logs, look for OriginalFileName = SharpView.exe or Image ending in \SharpView.exe. Also look for any process where CommandLine contains PowerView function names such as Get-DomainGroup, Get-DomainGroupMember, Find-ForeignGroup, or ConvertFrom-SID.
• PowerShell script block content (EID 4104): In ScriptBlockText, look for strings: Get-AdGroup combined with -Filter, Invoke-AzureHound, Get-DomainGroupMember, Get-NetGroupMember, or ldap:// connection strings within a script block. Deobfuscated content makes this reliable even when attackers encode their payloads.
• BloodHound/SharpHound process and network indicators: Process creation with Image ending in \SharpHound.exe, or CommandLine containing -CollectionMethod All or --CollectionMethods. Correlate with a spike in LDAP connections from that host to domain controllers on port 389 or 3268 within a short time window (e.g., hundreds of LDAP requests in under 60 seconds from a single non-DC host).
• ldapsearch on Linux/macOS: In auditd logs, look for exe = /usr/bin/ldapsearch with cmdline containing objectClass=group or memberOf. Unusual source hosts (non-AD-admin Linux servers) querying LDAP ports on domain controllers are high fidelity.
• AD Object Access (EID 4662): Look for events where Object Type is group and Accesses includes Read Property, generated in rapid succession from a single source account or host. Legitimate tools do not typically perform hundreds of group reads in seconds.

Detection Logic

Rule 1: Net.exe Domain Group Enumeration
IF process_name IN ("net.exe", "net1.exe") AND command_line CONTAINS "group" AND command_line CONTAINS "/domain" AND NOT (user IN [known_it_admin_accounts] AND parent_process IN ["mmc.exe", "services.exe"]) THEN alert(medium)

This catches the simplest, most common form of domain group enumeration using built-in Windows tools. Expect moderate alert volume in environments where IT admins regularly use net commands; tuning with known admin account exclusions will reduce noise significantly.

Rule 2: PowerShell Domain Group Enumeration Functions
IF event_id = 4104 AND script_block_text CONTAINS_ANY ("Get-DomainGroup", "Get-DomainGroupMember", "Get-NetGroupMember", "Get-AdGroup", "Find-ForeignGroup", "Invoke-AzureHound", "Get-NetGroup") THEN alert(high)

This targets PowerShell-based AD recon tools (PowerView, SharpView, AzureHound). Alert volume should be low in most environments; these function names have almost no legitimate use outside of dedicated AD management scripts from known administrators.

Rule 3: Known Enumeration Tool Execution by Image or Original File Name
IF (process_image ENDSWITH "\SharpHound.exe" OR process_image ENDSWITH "\SharpView.exe" OR original_file_name IN ("SharpHound.exe", "SharpView.exe")) THEN alert(critical)

This is a high-precision rule targeting known offensive tools by binary name. False positive rate is near zero; any hit should be treated as a confirmed threat until proven otherwise.

Rule 4: LDAP Enumeration Spike from Non-DC Host
IF source_host IS NOT domain_controller AND destination_port IN (389, 636, 3268, 3269) AND destination_host IS domain_controller AND event_count > 200 WITHIN 60 seconds THEN alert(high)

This catches automated tools like BloodHound that generate abnormally high LDAP query volumes. Requires network flow or firewall log data and a baseline of normal LDAP query rates per host. Expect some initial noise from legitimate backup or monitoring tools that poll AD frequently.

Tuning Guidance

• IT Admin Tooling: Administrators using RSAT tools (e.g., Active Directory Users and Computers, AD PowerShell module) will regularly run Get-AdGroup and similar commands. Exclude known admin workstations and service accounts by maintaining a watchlist: user IN [it_admin_sa_list] AND source_host IN [admin_workstations].
• Monitoring and Management Platforms: Tools like Microsoft SCCM, CrowdStrike, SolarWinds, or Varonis may perform scheduled AD enumeration. Identify their service accounts and exclude: user IN ["sccm_svc", "varonis_svc"] or parent_process = "ccmexec.exe".
• CI/CD and DevOps Pipelines: Automated scripts in Azure DevOps, Jenkins, or Terraform pipelines sometimes query AD groups for role assignments. Review pipeline service accounts and exclude: user IN [pipeline_service_accounts] AND source_host IN [build_servers].
• Helpdesk and Tier 1 Support Staff: Helpdesk personnel may use net group /domain to verify user group memberships. Consider scoping the alert to exclude non-privileged-group queries or restricting exclusions to specific source hosts: source_host IN [helpdesk_hosts] AND command_line NOT CONTAINS "Domain Admins".
• Scheduled Scripts: Home-grown PowerShell scripts that audit group memberships for compliance purposes may trigger Rule 2. Tag these scripts in your asset inventory and exclude by script path or signing certificate: script_path STARTSWITH "\\fileserver\compliance_scripts\".

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Pull the raw event directly from your SIEM or log source (Sysmon EID 1, Security EID 4688, or EID 4104) and confirm the fields match — specifically that the command-line value and process image are exactly as alerted, not a display artifact or parsing error.
2. Identify the affected host and user: Extract the hostname, username, and source IP from the alert event; cross-reference these against your asset inventory and identity store to determine if the account is a standard user, service account, or privileged admin — escalate immediately if the account is unprivileged but querying admin group membership.
3. Pull the full process tree and command-line chain: In Sysmon or your EDR console, pivot on the process GUID or PID to retrieve the full parent-child process chain; a suspicious chain such as winword.exe → cmd.exe → net.exe /domain or mshta.exe → powershell.exe → SharpView.exe is a strong indicator of post-exploitation activity.
4. Check for related enumeration commands in the same session: Search your SIEM for all process creation events from the same host and user within a ±30-minute window of the alert; look for additional discovery commands targeting users (net user /domain), shares (net view), sessions (query session), or network config (ipconfig, arp -a) — clusters of discovery commands are a strong red flag.
5. Check for network connections and files written to disk: In Sysmon EID 3 (network connections) and EID 11 (file creation), look for LDAP connections to domain controllers, any newly created files with extensions like .json, .zip, or .csv (BloodHound output format), or tools dropped to suspicious paths like %TEMP%, C:\ProgramData\, or C:\Users\Public\.
6. Look for lateral movement originating from this host: Query Windows Security EID 4624 (logon events) and EID 4648 (explicit credential use) on other systems for logon events sourced from the affected host after the enumeration time; also check for new SMB connections (EID 5140) and remote service creation (EID 7045) that may indicate the attacker moved laterally using the information gathered.
7. Escalation decision: Treat the activity as a confirmed incident requiring full IR response if you observe any of the following: the executing account is unprivileged, the process parent chain includes a known initial access vector (phishing lure, web shell), known offensive tooling names are present, or lateral movement events are found; treat as likely benign and close with documentation if the user is a known admin, the parent process is a legitimate management tool, and no other suspicious activity is present in the session window.

Response Playbook

Containment

• Isolate the affected host from the network immediately using your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate, Carbon Black quarantine) or by applying a firewall ACL to block all traffic except your SIEM/EDR agent; leave the machine powered on to preserve volatile memory artifacts for forensics.
• Disable the affected user account in Active Directory immediately using Disable-ADAccount -Identity <username> or via the AD Users and Computers console; do not reset the password yet, as this may alert the attacker without stopping active sessions.
• Invalidate all active Kerberos tickets and sessions for the affected account by running klist purge on known session hosts and forcing a ticket expiration; in Azure AD environments, use the Revoke-AzureADUserAllRefreshToken cmdlet to kill all active tokens.
• Block identified C2 IPs or domains at the perimeter firewall and internal DNS resolver; if BloodHound output files were staged, check for any exfiltration connections to external IPs and null-route those destinations immediately.
• Kill the malicious process on the affected host via EDR if the host cannot be immediately isolated; record the PID, process name, and file hash before termination for use in threat hunting across the broader environment.

Eradication

• Search for and delete any offensive tools dropped to disk: Use your EDR to hunt for files matching known BloodHound/SharpHound/SharpView/PowerView hashes or names across all endpoints; also search for recently created files in %TEMP%, C:\ProgramData\, and C:\Users\Public\ within the incident timeframe.
• Identify and remove any persistence mechanisms added: Check Scheduled Tasks (EID 4698), new services (EID 7045), Run key registry entries (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), and startup folder items on the affected host and any hosts the user authenticated to during the incident window.
• Reset credentials for all accounts that executed or were touched by the malicious activity: This includes the primary affected account, any accounts whose credentials may have been harvested from memory, and any service accounts that were queried as part of the enumeration; use a freshly provisioned admin workstation to perform these resets.
• Audit the specific domain groups that were enumerated and review their membership for unauthorized additions; focus especially on Domain Admins, Enterprise Admins, Schema Admins, and any custom privileged groups identified in the attacker’s queries.
• Rotate any API keys, secrets, or cloud credentials accessible from the affected host or user profile, including Azure service principal credentials, AWS access keys stored in environment variables or credential files, and SSH private keys present in the user’s home directory.

Recovery

• Re-image the affected host if there is any doubt about the completeness of eradication, or if the host was compromised for more than a short window before containment; do not simply clean the host and reconnect if the initial access vector has not been fully confirmed and closed.
• Re-enable the affected user account only after confirming that no persistence mechanisms remain, that credentials have been reset, that MFA is enforced on the account, and that the re-enabled account is being actively monitored for the next 72 hours post-restoration.
• Monitor the previously affected host and user account for 72 hours post-remediation using elevated logging sensitivity in your SIEM; create a temporary watchlist rule that fires on any process execution, network connection, or authentication event from that host or account and routes it directly to an analyst queue.
• Conduct a post-incident review to document the full attack timeline from initial access through detection, including any detection gaps identified; present findings to the security team within five business days of incident closure and update runbooks accordingly.
• Update detection rules with any new IOCs discovered during the investigation, including new tool hashes, renamed binary patterns, or novel command-line arguments observed; share relevant IOCs via your threat intelligence platform or ISAC if the activity appears to be part of a broader campaign.