11 minmedium
From Code to Coverage (Part 6): What netlogon.log Sees That Event 1644 Never Will
LDAP Ping is a pre-credential Active Directory reconnaissance technique that abuses the anonymous DC Locator protocol to enumerate valid usernames without generating authentication failures. The tool ldapnomnom claims to produce no Windows audit logs, but source code analysis confirms it uses TCP exclusively, making connections visible to Event 5156 (Windows Filtering Platform). Event 1644 is structurally blind to LDAP Ping because the query is dispatched to netlogon.dll, bypassing the LDAP search engine. netlogon.log captures every query and response including disabled-account state invisible to the attacker. True UDP cLDAP remains a blind spot for Windows event logging, requiring network-layer visibility or MDI for attribution.
Sens:7d
IOCs1
1filename
Detection / Hunteropenrouter
What Happened
Attackers can discover which usernames exist in an organization's Active Directory without logging in, by sending special probe messages called LDAP Pings to Domain Controllers. A tool called ldapnomnom claims this activity leaves no trace in Windows logs. The author proved this claim is wrong by reading the tool's source code: ldapnomnom actually uses standard network connections (TCP), which Windows can track through a feature called Event 5156. However, a different version of the same technique using UDP packets genuinely evades Windows event logs. The article shows that a log file called netlogon.log records every username probed, and when combined with Event 5156, defenders can see both what was queried and who did it. Organizations should enable netlogon debug logging and Windows Filtering Platform auditing on Domain Controllers, and consider deploying Microsoft Defender for Identity if they have not already.
Key Takeaways
- ldapnomnom claims to generate no Windows audit logs, but source code analysis reveals it uses TCP exclusively, making every connection visible to Event 5156 (Windows Filtering Platform).
- Event 1644 structurally cannot log LDAP Ping traffic because LDAP Ping is dispatched to the netlogon.dll handler in LSASS, bypassing the ntdsa.dll LDAP search engine that generates Event 1644.
- netlogon.log (enabled via nltest /dbflag:0x2080FFFF) captures every LDAP Ping query and response, including a defender advantage: disabled accounts produce a NlSamVerifyUserAccountEnabled line that attackers never see on the wire.
- True UDP cLDAP (e.g., via cldap_ping.py) is the real blind spot: no Event 5156, no LSASS network-layer connection tracking, leaving netlogon.log as the only Windows host-based detection source with no source IP attribution.
- Correlating netlogon.log entries with Event 5156 events within a five-second timestamp window provides full attribution: usernames from netlogon.log, source IP from Event 5156.
Affected Systems
- Windows Server Domain Controllers (all versions supporting Active Directory)
- Active Directory Domain Services
- Microsoft Defender for Identity (MDI) sensors on Domain Controllers
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Reconnaissance: Attacker performs anonymous rootDSE TCP LDAP query to gather domain name, forest, DC FQDN, functional levels, and site information
- Enumeration: Attacker runs ldapnomnom or cldap_ping.py with a username wordlist against the Domain Controller on port 389
- Processing: LDAP Ping filter is dispatched to netlogon.dll handler in LSASS, bypassing the ntdsa.dll LDAP search engine entirely
- Response: DC returns NETLOGON_SAM_LOGON_RESPONSE_EX with opcode 0x17 for valid enabled accounts or 0x19 for non-existent and disabled accounts (indistinguishable to attacker)
- Evasion: Attacker may switch to UDP cLDAP to eliminate Event 5156, use --throttle to defeat volume thresholds, or use --maxrequests to reset per-connection counters
- Follow-on: Attacker uses enumerated valid usernames for password spraying or targeted phishing, having confirmed which accounts exist without generating authentication failures
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: Yes
- Platforms: PowerShell (Get-LDAPingDetection.ps1), nltest, MDI external ID 2437
The article references a PowerShell correlation script (Get-LDAPingDetection.ps1) that joins netlogon.log entries with Event 5156 in a five-second window, but does not reproduce its code. It also documents nltest /dbflag:0x2080FFFF for enabling netlogon debug logging and references MDI external ID 2437 as a built-in detection. No rule bodies are provided in the article.
Detection Engineering Assessment
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | EDR products may capture process execution of ldapnomnom or cldap_ping.py on attacker workstations, but on the Domain Controller side, the key telemetry is Windows Event 5156 (WFP) and netlogon.log, which are OS log sources rather than EDR-specific. EDR visibility into LSASS handling of LDAP Ping traffic varies by vendor. |
| Network Visibility | High | Network-layer visibility (packet capture, NDR, Zeek) is the only reliable way to attribute true UDP cLDAP attacks. For TCP ldapnomnom, network monitoring can observe burst connection patterns to port 389. MDI sensors read packets directly off the DC NIC via Npcap. |
| Detection Difficulty | Moderate | Detection of TCP-based ldapnomnom is straightforward with Event 5156 and netlogon.log correlation. Detection of true UDP cLDAP is harder, requiring network-layer visibility or MDI. Low-and-slow enumeration using --throttle defeats volume-based thresholds, shifting the burden to content-based detection (filter pattern matching) and honeytoken-based alerting. |
Required Log Sources
- Windows Security Event Log - Event 5156 (Windows Filtering Platform connection auditing, requires Audit FPC enabled)
- netlogon.log (requires nltest /dbflag:0x2080FFFF, flat file at C:\Windows\debug\netlogon.log)
- Windows Security Event Log - Event 1644 (for authenticated LDAP queries, not LDAP Ping)
- Microsoft Defender for Identity sensor alerts (external ID 2437)
- Network flow logs or NDR for UDP 389 traffic attribution
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for bursts of Event 5156 entries targeting port 389 or 636 on Domain Controllers, where 8 or more connections originate from the same source IP within a 10-second window, indicating parallel LDAP Ping enumeration. | Windows Security Event Log Event 5156 with DestPort 389 or 636 and Application LSASS.exe | Reconnaissance | Medium. Legitimate DC Locator traffic from booting workstations can produce bursts, but typically from diverse source IPs rather than a single host making 8 parallel connections. |
| Consider hunting for netlogon.log entries containing 'Sam User Unknown Ex' or 'NlSamVerifyUserAccountEnabled' patterns that indicate LDAP Ping username enumeration, especially sequences of unknown responses for non-existent accounts. | netlogon.log at C:\Windows\debug\netlogon.log, requires nltest /dbflag:0x2080FFFF | Reconnaissance | Low. Legitimate DC Locator pings rarely include the User= element for non-existent accounts in rapid succession. |
| Consider hunting for UDP port 389 traffic to Domain Controllers from non-workstation sources, as true cLDAP over UDP indicates enumeration tooling that evades Event 5156. | Network flow logs, NDR, Zeek UDP connection logs, or firewall logs | Reconnaissance | Medium. Legitimate DC Locator uses UDP 389, but typically from domain-joined workstations during boot, not from unknown or external IPs. |
| Consider deploying honeytoken accounts and alerting on any LDAP Ping response returning opcode 0x17 (LOGON_SAM_LOGON_RESPONSE_EX) for those accounts, as their presence in an enumeration wordlist indicates targeted reconnaissance. | netlogon.log entries for honeytoken usernames, or MDI alerts | Reconnaissance | Low. Honeytoken accounts should never be referenced in legitimate DC Locator traffic. |
| Consider hunting for the LDAP filter pattern containing NtVer, AAC, and User conjunction elements in network traffic, as this combination distinguishes username enumeration from legitimate DC Locator pings. | NDR or packet capture with LDAP protocol parsing on port 389 | Reconnaissance | Low. Legitimate DC Locator pings typically omit the User= element or use it for actual logon validation, not bulk enumeration. |
Control Gaps
- Event 1644 is structurally blind to LDAP Ping traffic due to separate code paths in LSASS (netlogon.dll vs ntdsa.dll).
- Event 5156 does not fire for UDP cLDAP traffic because WFP tracks TCP connections, not individual UDP datagrams.
- netlogon.log is not enabled by default and is a flat file on the DC requiring manual log shipping.
- MDI external ID 2437 is threshold-based and can be evaded with --throttle or targeted low-volume wordlists.
- Source IP attribution is absent from netlogon.log entirely (shows as null).
Key Behavioral Indicators
- Burst of 8 parallel TCP connections to port 389 or 636 on a Domain Controller from a single source IP within seconds
- netlogon.log entries containing 'Sam User Unknown Ex' in rapid succession for multiple usernames
- netlogon.log entries containing 'NlSamVerifyUserAccountEnabled' indicating disabled accounts were probed
- LDAP filter containing NtVer + AAC + User conjunction pattern in network traffic to port 389
- UDP port 389 traffic to Domain Controllers from non-domain-joined or unknown hosts
- Process execution of ldapnomnom, cldap_ping.py, or ldeep with enum_users subcommand on any host
False Positive Assessment
Medium. Legitimate DC Locator traffic from domain-joined workstations produces LDAP Ping queries during boot and logon. The NtVer+AAC+User filter pattern can appear in legitimate scenarios when a client validates a specific account during logon. Burst patterns from a single IP could originate from automated provisioning systems or management tools. Correlation with netlogon.log content and volume thresholds helps reduce false positives, but low-and-slow enumeration using --throttle may blend with baseline DC Locator noise.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider enabling netlogon debug logging on Domain Controllers via nltest /dbflag:0x2080FFFF and shipping C:\Windows\debug\netlogon.log to your SIEM.
- If not already enabled, consider enabling Windows Filtering Platform Connection auditing (Audit FPC) on Domain Controllers to generate Event 5156 for all TCP connections to LSASS, including ports 389, 636, and 9389.
- Consider deploying honeytoken accounts in Active Directory and configuring alerts for any LDAP Ping response referencing those accounts in netlogon.log or MDI.
- If you have MDI deployed, verify that external ID 2437 is active on all Domain Controllers and review the threshold configuration against low-volume enumeration scenarios.
Infrastructure Hardening
- Evaluate whether network segmentation can restrict UDP port 389 traffic to Domain Controllers from only known domain-joined workstation subnets.
- Consider deploying network-level monitoring (NDR, Zeek, or packet capture) on Domain Controller segments to detect UDP cLDAP traffic that evades host-based Windows event logging.
- If applicable, evaluate whether your SIEM can ingest and correlate netlogon.log with Event 5156 using a five-second timestamp window for source IP attribution.
- Consider implementing content-based network IDS rules that detect the NtVer+AAC+User LDAP filter conjunction pattern on port 389 traffic.
User Protection
- Consider reviewing disabled Active Directory accounts, as their presence in the directory provides defenders with earlier warning during enumeration (NlSamVerifyUserAccountEnabled lines) compared to accounts that do not exist.
- If supported by your tooling, consider monitoring for LDAP Ping probes targeting service accounts, administrator accounts, and other high-value identities that would appear in attacker wordlists.
- Evaluate whether your EDR can detect execution of known enumeration tools (ldapnomnom, ldeep with enum_users) on endpoints within your environment.
Security Awareness
- Consider incorporating into existing security awareness programs the concept that attackers can validate username lists without attempting logins, meaning username secrecy alone is not a sufficient control.
- If applicable to your organization, consider educating IT staff that netlogon.log is a valuable forensic source that is not enabled by default and should be activated during troubleshooting and baseline monitoring.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping3 techniques
Additional IOCs
- File Paths:
C:\Windows\debug\netlogon.log- Netlogon debug log file that captures LDAP Ping queries and responses when debug logging is enabled via nltest /dbflag:0x2080FFFF. Not enabled by default. Contains enumerated usernames and account status but no source IP.
- Command Lines:
- Purpose: Anonymous AD username enumeration via LDAP Ping over TCP | Tools:
ldapnomnom| Stage: Reconnaissance |ldapnomnom --server <DC_IP> --tlsmode NoTLS --input <wordlist> - Purpose: Anonymous AD username enumeration via true UDP cLDAP Ping | Tools:
python3,cldap_ping.py| Stage: Reconnaissance |python3 cldap_ping.py -t <DC_IP> -f <wordlist> - Purpose: Enable netlogon debug logging to capture LDAP Ping traffic | Tools:
nltest| Stage: Detection Configuration |nltest /dbflag:0x2080FFFF - Purpose: Correlate netlogon.log entries with Event 5156 for source IP attribution | Tools:
PowerShell,Get-LDAPingDetection.ps1| Stage: Detection |.\Get-LDAPingDetection.ps1 -LookbackMinutes 5 -Honeytokens <account> - Purpose: Anonymous user enumeration via LDAP Ping using ldeep | Tools:
ldeep| Stage: Reconnaissance |ldeep ldap -d <domain> -s ldap://<DC_IP> -a enum_users <output_file>
- Purpose: Anonymous AD username enumeration via LDAP Ping over TCP | Tools:
- Other:
(&(NtVer=\x06\x00\x00\x00)(AAC=\x10\x00\x00\x00)(User=<username>))- LDAP Ping filter pattern used by ldapnomnom and cldap_ping.py. The NtVer+AAC+User conjunction is a fingerprint for username enumeration, distinguishing it from legitimate DC Locator pings. Documented by Sapir Federovsky at TROOPERS24.
Showing defanged values
- filenamecldap_ping.pyCustom Python script that sends genuine UDP cLDAP LDAP Ping requests to enumerate AD usernames. Uses stdlib SOCK_DGRAM with no TCP connection, evading Event 5156. Presence on a host indicates active AD reconnaissance tooling.
Stay currentSubscribe via RSS