LDAP Reconnaissance Detection Guide: Catch Directory Enumeration Beyond BloodHound Collectors

Any authenticated account can read most of Active Directory over LDAP, so attackers map users, groups, service accounts and certificate templates within hours of a foothold, often with ordinary administration tools that never trip a malware alert. Graph collectors such as BloodHound get most of the attention, but the same reconnaissance is done with generic LDAP clients from Linux hosts, AdFind, Sysinternals AD Explorer snapshots, Active Directory Web Services and targeted queries for service principal names (SPNs) and Active Directory Certificate Services (AD CS) objects. This guide is for detection engineers, identity security teams and domain controller owners. It covers the telemetry that captures LDAP searches, how to turn on and tune event 1644, detection patterns for each enumeration style, baselining the many legitimate directory readers, and how to respond. For attack path analysis and detecting graph collection specifically, see the BloodHound and Active Directory Attack Path Guide.

Key takeaways

• Reconnaissance is read traffic. LDAP enumeration uses legitimate searches that domain controllers answer by design, so detection relies on who is asking, from where, how much and for which attributes.
• Event 1644 is the native search log. With Field Engineering diagnostic logging at level 5, domain controllers record expensive, inefficient and slow searches with the client IP and filter; it is costly, so run it in targeted windows or on selected DCs.
• SPN and AD CS queries are high-value signals. Enumeration of accounts with SPNs precedes Kerberoasting, and reads of the Public Key Services container precede certificate abuse; both are rarely done by ordinary clients.
• Baseline the legitimate readers first. Identity sync, IGA connectors, mail systems, scanners and assessment tools read the whole directory every day; allowlist them by account and source, not by account alone.
• Decoys turn noise into certainty. A decoy account or object that no legitimate process reads gives a near zero false positive alert the moment it appears in a search result or an access audit.

What LDAP reconnaissance looks like

MITRE ATT&CK files most directory enumeration under Discovery: Domain Account (T1087.002), Domain Groups (T1069.002), Domain Trust Discovery (T1482) and Group Policy Discovery (T1615). ATT&CK procedure examples for T1087.002 include AdFind (S0552) used by groups such as BlackByte (G1043), and AD Explorer used by LAPSUS$ (G1004). The technique description also names ldapsearch for listing domain users and groups from Linux. The point for defenders: the tooling is generic and often signed, so the query pattern matters more than the binary.

A snapshot deserves special attention. The AD Explorer documentation describes saving snapshots of an AD database for offline viewing and comparison. Defenders use the feature for change tracking; an attacker who takes one walks away with a full map of accounts, groups and permissions and needs no further queries. Detection must therefore happen during collection, and a single large read from an unexpected host is enough to act on.

Telemetry sources and what each one sees

Microsoft's own option illustrates the identity sensor row. Microsoft Defender for Identity classic alerts include Security principal reconnaissance (LDAP) (external ID 2038, with a 15-day learning period per computer), Account Enumeration reconnaissance (LDAP) (2437) and Honeytoken was queried via LDAP (2429). Its Defender-format alerts add, among others, Possible SPN enumeration via LDAP, Possible SPN enumeration via ADWS, Possible Active Directory Certificate Services enumeration, Possible Active Directory enumeration via ADWS and Suspicious LDAP query targeting sensitive attributes. Its data is queryable in the IdentityQueryEvents advanced hunting table, which records queries against Active Directory objects with columns such as QueryType, QueryTarget, Query, Protocol, AccountUpn, DeviceName and DestinationDeviceName. Other identity threat detection products provide comparable LDAP analytics; see the ITDR Buyer's Guide for evaluation criteria.

Turning on and tuning event 1644

Event 1644 is the only native Windows record of the LDAP filter a client sent. Microsoft documents it in its Event1644Reader guidance; enhanced 1644 data is native from Windows Server 2012 R2.

Enabling it

• Diagnostic level: set the 15 Field Engineering REG_DWORD under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics to 5. No restart is required. On AD LDS the key sits under the instance's service name.
• Side effects: Microsoft notes that level 5 causes other events to be logged too, and that diagnostic levels of 3 or more need more resources and can degrade server performance. It advises resetting the value to 0 when you are not collecting.
• Log size: Microsoft recommends increasing the Directory Service event log to 200 MB when Field Engineering logging is enabled. Forward events to the SIEM quickly so a busy DC does not overwrite them.

Thresholds

Three REG_DWORD values under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters decide which searches are logged.

Lowering thresholds raises volume quickly. Test changes on one DC in a site, measure events per hour for a week, then decide. Because only searches over a threshold are logged, a small targeted query can stay below them. Treat 1644 as one layer alongside SACL-based decoys and sensor or network telemetry, not as complete coverage.

Operating models

• Always on, selected DCs: enable on DCs that serve workstation subnets, where attacker queries are most likely to land, and leave application-facing DCs at level 0.
• Hunting windows: enable fleet-wide for a defined period (for example after an intrusion indicator or during a purple team exercise), then revert.
• Performance analysis double use: the same data finds badly written application queries; share it with directory operations so the logging has two owners.

Detection patterns by enumeration style

Bulk directory reads and snapshots

• Volume by source: alert when one client IP or account returns a large share of all user, group or computer objects within an hour, and the source is not on the allowlist.
• Security descriptor reads: a snapshot or ACL review reads nTSecurityDescriptor across many objects. Searches requesting it from workstations are rare outside sanctioned assessments.
• Configuration and schema partitions: broad reads of the Configuration naming context from user workstations are unusual.

SPN enumeration

• Filter content: 1644 filters or sensor records that test servicePrincipalName on user objects.
• Sequence: SPN search followed within minutes by Kerberos service ticket requests (event 4769) from the same source for several user-based service accounts. The sequence is stronger than either event alone. See the Kerberoasting and AS-REP Roasting Defence Guide.
• Attribute hunting variants: searches on userAccountControl flags for pre-authentication not required or delegation, and on adminCount, are part of the same planning phase.

AD CS enumeration

• Location: reads of pKICertificateTemplate and pKIEnrollmentService objects under CN=Public Key Services from hosts that are not CAs, PKI administration servers or management tools.
• SACL option: a read SACL on the Certificate Templates container generates event 4662 for each access; scope it to failure and success reads by non-administrative principals and test volume first, since enrolment clients also read templates.
• Follow-on: enumeration followed by certificate requests for unusual templates. See the Certipy and Certify AD CS Tooling Detection Guide and How to audit AD CS certificate templates.

Non-Windows and non-domain sources

• Source context: LDAP binds to DCs from IP ranges that are not domain-joined workstations, servers or known appliances, such as VPN pools, cloud subnets and lab networks.
• Bind type: simple binds from user accounts. The LDAP Security Deep Dive Guide covers bind audit events and signing enforcement.

ADWS

• Port 9389: connections to ADWS from workstations outside the administrator population. Where the tooling allows, record ADWS queries in the sensor, because 1644 thresholds and LDAP network monitoring on 389 alone will not show them.

Decoys

• Decoy accounts and objects: a decoy user with an attractive description or an SPN, monitored with a read SACL (4662) and any authentication attempt, produces an alert no legitimate process should cause. See Decoy accounts in Active Directory.

Where identity fits: the legitimate readers

Most whole-directory reads in a healthy domain come from non-human identities: directory sync to the cloud identity provider, IGA and PAM connectors, HR provisioning, mail and collaboration servers, vulnerability scanners, backup products and assessment tools such as PingCastle. They are also attractive to attackers, because a stolen connector account blends into that baseline.

• Allowlist by pair: exclude a reader only for its account plus its expected source hosts and schedule. The same account querying from a workstation is an alert.
• Inventory them: list every service account that performs bulk reads and its owner. See How to build a service account inventory from Active Directory.
• Restrict what they can read: where an application needs only a subset, scope it with an OU-level search base and fine-grained read permissions so a compromise exposes less.
• Sanctioned assessments: register assessment runs (PingCastle, BloodHound, internal red team) with the SOC in advance, with account, source and time window, and use them to test that the detections fire. See ITDR validation.

Decision guidance: native logging, sensor or both

Small organisations: start with two or three decoy accounts with SACLs and a SIEM rule on LDAP and ADWS connections from unexpected subnets, then run 1644 in hunting windows. Large organisations: deploy a sensor on every DC, keep 1644 on workstation-facing DCs, and maintain the reader allowlist as a governed list with owners.

Rolling out detection

1. Map the readers. Run 1644 on one DC per site for a week in a hunting window and list every source returning more than the expensive threshold.
2. Build the allowlist. Record account, source hosts, schedule and owner for each legitimate reader.
3. Deploy decoys. Create decoy accounts and set read auditing SACLs; enable Audit Directory Service Access on DCs.
4. Write the first rules in alert-only mode. Bulk reads by unlisted sources, SPN search followed by service ticket requests, AD CS container reads from non-PKI hosts, ADWS from non-admin workstations, decoy access.
5. Test with sanctioned runs. Run a registered assessment and confirm each rule fires within the target time.
6. Tune and promote. Adjust thresholds and allowlists, then route the rules to the SOC queue with a response runbook.
7. Roll back safely. If DC performance suffers, set Field Engineering back to 0 (no restart required) and rely on decoys and sensor data while you narrow the scope.

Responding to an alert

• Triage questions: Is the source on the allowlist? Is the account a person or a service account, and is this its normal host? Did Kerberos ticket requests, certificate requests or lateral connections follow?
• Containment: if unsanctioned, isolate the source host and disable or reset the account used. A directory snapshot cannot be recalled, so assume the attacker holds the map and prioritise the paths it reveals: service accounts with SPNs, vulnerable templates and delegation.
• Follow-on hunting: use the Identity Threat Hunting Guide and, if Tier 0 is at risk, the Active Directory Domain Compromise Response Playbook.

Detection and measurement

• Coverage: percentage of DCs feeding LDAP search telemetry (1644, sensor or both) to the SIEM.
• Detection rate: share of sanctioned enumeration runs that raised an alert within one hour, per enumeration style in the table above.
• Allowlist hygiene: number of bulk readers without an owner or documented source; target zero.
• Decoy integrity: decoys tested in the last quarter and confirmed to alert.
• Alert precision: share of LDAP reconnaissance alerts closed as unsanctioned activity versus known readers, tracked monthly to guide tuning.

Common failure patterns

• Leaving Field Engineering at level 5 indefinitely on every DC, then turning it off fleet-wide after a performance complaint and losing all visibility.
• Allowlisting by account only, so a stolen sync or scanner account enumerates the directory from a workstation without an alert.
• Watching port 389 only, missing ADWS on 9389, global catalog queries on 3268 and LDAPS on 636.
• Treating enumeration as low severity. SPN and AD CS reads are planning for credential theft; the alert should trigger hunting for what follows.
• Never testing. Rules written from documentation and never exercised with a sanctioned run often fail on field names, thresholds or log forwarding gaps.

Framework mapping

Practitioner checklist

• Decide where event 1644 runs (selected DCs or hunting windows), set the Directory Service log to at least 200 MB and forward it.
• Record the threshold values on each DC and test any change on one DC first.
• Enable Audit Directory Service Access and place read SACLs on decoy accounts and the AD CS Certificate Templates container after volume testing.
• Monitor LDAP, LDAPS, global catalog and ADWS connections to DCs by source subnet.
• Build and govern an allowlist of bulk directory readers by account, source and schedule, each with an owner.
• Correlate SPN searches with subsequent service ticket requests, and AD CS reads with certificate requests.
• Register sanctioned assessments with the SOC and use them to test every rule.
• Write a response runbook that assumes a completed snapshot means the attacker holds the directory map.

Standards and references

• MITRE ATT&CK: Account Discovery: Domain Account (T1087.002)
• Microsoft Learn: Use Event1644Reader.ps1 to analyze LDAP query performance
• Microsoft Learn: Configure Active Directory and LDS diagnostic event logging
• Microsoft Learn: Event 4662, an operation was performed on an object
• Microsoft Learn: Defender for Identity alerts
• Microsoft Learn: IdentityQueryEvents table
• Microsoft Sysinternals: AD Explorer
• SpecterOps: Certified Pre-Owned

Related NHI Mgmt Group resources: Active Directory Security Monitoring and Event IDs Guide · Discovery and Reconnaissance Techniques Guide · ITDR Guide · Honeytokens and Canary Credentials Guide