Detecting Active Directory LDAP Ping: Correlating Netlogon Logs and Event 5156

Summary

LDAP Ping bypasses Event 1644. For TCP-based ldapnomnom, netlogon.log records probed usernames and Event 5156 provides source IPs; true UDP cLDAP lacks Event 5156 attribution, requiring network-layer monitoring or MDI.

Key points

LDAP Ping is handled by Netlogon on a separate path from the LDAP engine, so it does not generate Event 1644.
The tested ldapnomnom version uses TCP by default, despite its README’s claim of producing no Windows audit logs.
With Netlogon debug logging enabled, netlogon.log records queried usernames and distinguishes disabled accounts from nonexistent ones, but does not record source IPs.
When Filtering Platform Connection auditing is enabled, Event 5156 captures the source IP for ldapnomnom’s TCP connections, including TLS connections.
True UDP cLDAP does not produce Event 5156 events in the tests; attribution requires packet capture, NDR, firewall logs, or MDI.
MDI detection 2437 can detect TCP and UDP LDAP Ping from DC sensors, but is threshold-based and may miss targeted or throttled enumeration.
Correlating netlogon.log entries with Event 5156 by timestamp can connect queried usernames to a source IP for TCP activity.

Article Details

Defense Focus: Detect anonymous LDAP Ping username enumeration and correlate the queried usernames with source attribution, especially where Event 1644 cannot observe the separate Netlogon processing path.
Detection Methods: Correlate usernames and response types in netlogon.log with source IPs from Event 5156; the article reports a five-second correlation window worked in tested configurations.
Monitor for the LDAP filter shape combining NtVer, AAC, and User as a high-fidelity enumeration signature.
Use packet capture, NDR, or firewall logs to attribute true UDP cLDAP, which did not generate Event 5156 in the reported tests.
Use Microsoft Defender for Identity alert 2437 to detect LDAP Ping enumeration, while accounting for its volume threshold and sensor-coverage requirements.
Look for bursts of Event 5156 connections and probes of disabled or honeytoken accounts; throttling can reduce volume-based signals.
Data Sources: Netlogon debug log (netlogon.log), including queried usernames and response details
Windows Filtering Platform connection auditing, Security Event 5156
Microsoft Defender for Identity sensor telemetry and alert 2437
Packet capture, NDR, or firewall logs for UDP cLDAP source attribution
LDAP network traffic, including the NtVer + AAC + User filter pattern
Event 1644, which the article reports does not capture true LDAP Ping
Rule Types: LDAP filter-pattern detection for the NtVer + AAC + User conjunction
Timestamp-based correlation of netlogon.log entries with Event 5156
Network IDS signature for UDP LDAP Ping traffic
Threshold-based LDAP Ping enumeration alerting
Platforms: Microsoft Defender for Identity sensors deployed on domain controllers
Windows Filtering Platform auditing
Windows Security Event Log
Network packet-capture, NDR, and firewall monitoring
Defensive Actions: Enable Filtering Platform Connection auditing to capture Event 5156 for TCP connections.
Enable Netlogon debug logging with nltest /dbflag:0x2080ffff and ship netlogon.log off the domain controller for monitoring.
Correlate Netlogon entries with Event 5156 to associate usernames with source IPs; do not rely on netlogon.log for source attribution.
Deploy Microsoft Defender for Identity sensors on every domain controller requiring coverage, and account for alert 2437's undisclosed volume threshold.
Use off-host network telemetry to attribute UDP cLDAP because the article's tests produced no Event 5156 for UDP queries.
Consider honeytoken accounts and investigate probes of disabled accounts or suspicious connection bursts.
Do not rely on Event 1644 to detect LDAP Ping; the article describes its absence as architectural rather than a logging-configuration issue.