ADWS LDAP Query Attribution Failure: Correlating Event 1644 Localhost Source with Event 5156 to Recover True Attacker IP

Indicators

• Event 1644 entries in the Directory Service log showing 127.0.0.1 (localhost) as the LDAP query source IP
• High-volume or sensitive-attribute LDAP queries (adminCount=1, SPNs, ACLs, group membership) with no clear external attribution
• Event 5156 entries showing inbound connections to the domain controller on port 9389 (ADWS) within milliseconds of Event 1644 timestamps
• Spike in ADWS-related network connections to the domain controller correlating with enumeration activity
• LDAP query filters in Event 1644 consistent with AD reconnaissance tools (e.g., BloodHound, SharpHound, ldapsearch)
• Unusual source hosts or non-administrative accounts appearing in correlated Event 5156 records on port 9389

Likely causes

• Attacker is using ADWS (port 9389) rather than traditional LDAP (port 389/636), causing Event 1644 to log localhost as the source because ADWS proxies the request locally to the LDAP service
• ADWS design deliberately introduces an abstraction layer between the remote client and the AD LDAP engine, obscuring the originating IP in directory service audit logs
• Detection logic and SIEM queries not joining Windows Filtering Platform logs (Event 5156) with LDAP diagnostic logs (Event 1644), leaving a blind spot in attribution
• Attackers intentionally leveraging ADWS to bypass IP-based detection and alerting rules applied to Event 1644
• Insufficient audit policy configuration — Filtering Platform Connection auditing not enabled on domain controllers, preventing Event 5156 generation

Diagnostic steps

1. Enable LDAP query diagnostic logging on the domain controller: set the registry value HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\15 Field Engineering to 5. Configure the expensive/inefficient LDAP search threshold via the domain controller's ms-DS-Other-Settings attribute (e.g., ExpensiveSearchResultsThreshold=1) to ensure Event 1644 is generated for relevant queries.
2. Enable Windows Filtering Platform connection auditing on the domain controller: run 'auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable' from an elevated command prompt. Verify with 'auditpol /get /subcategory:"Filtering Platform Connection"'.
3. Confirm both Event 1644 (Directory Service log) and Event 5156 (Security log) are being forwarded to your centralised SIEM from all domain controllers. Check Windows Event Forwarding subscriptions or SIEM agent configuration to validate ingestion.
4. In your SIEM, query for Event 1644 entries where the source IP field is 127.0.0.1, indicating the query arrived via ADWS. Record the exact timestamp, LDAP filter, and requested attributes for each matching event.
5. For each Event 1644 with a localhost source, query Event 5156 for inbound connections to the domain controller on destination port 9389 within a ±60–80ms window of the Event 1644 timestamp. Example Splunk correlation: join EventCode=1644 (source=127.0.0.1) with EventCode=5156 (DestPort=9389) on host within a 80ms time window.
6. Extract the SourceAddress and SourcePort from the matched Event 5156 record — this is the true originating IP of the ADWS/LDAP query. Map this IP to a hostname and user account using DHCP logs, DNS, or your asset inventory.
7. Review the LDAP filter and requested attributes from the correlated Event 1644 (e.g., searches for adminCount=1, servicePrincipalName, nTSecurityDescriptor, or group membership) to determine whether the query pattern is consistent with known AD enumeration tools such as BloodHound or SharpHound.
8. Investigate the attributed source host and associated user account for signs of compromise: check logon events, process execution (Event 4688 or Sysmon Event 1), and lateral movement indicators. Escalate to incident response procedures if the host is unexpected or the account is non-administrative.
9. Build a persistent SIEM detection rule that automatically joins Event 1644 (source IP = 127.0.0.1) with Event 5156 (destination port = 9389) on the same domain controller within an 80ms window, and raises an alert when sensitive LDAP filter patterns are detected.

Resolution path

• Enable Event 1644 LDAP query diagnostic logging on all domain controllers via the NTDS Field Engineering registry key
• Enable Windows Filtering Platform connection auditing (Event 5156) on all domain controllers using auditpol
• Confirm both event sources are ingested by the centralised SIEM from every domain controller
• Identify Event 1644 entries where source IP is 127.0.0.1, flagging these as ADWS-proxied queries with hidden attribution
• Correlate each such Event 1644 with Event 5156 entries on destination port 9389 within a ±60–80ms time window on the same domain controller
• Extract the true source IP from the matched Event 5156 record and map to a host and user account
• Review the LDAP filter and attributes in Event 1644 to classify query intent (enumeration, reconnaissance, legitimate admin activity)
• Investigate the attributed host and account for compromise indicators and escalate to incident response if warranted
• Build persistent SIEM correlation rules to automate this attribution pattern across all future ADWS-based queries

Prevention

• Restrict access to ADWS (TCP port 9389) on domain controllers using host-based firewall rules (Windows Firewall or network ACLs) to only explicitly authorised management hosts and jump servers
• Enforce tiered administrative access (Privileged Access Workstations) to limit which accounts and hosts are permitted to query AD via ADWS
• Implement continuous alerting on high-volume or sensitive-attribute LDAP queries via Event 1644, even when the source IP appears as localhost
• Regularly audit Event 5156 entries on port 9389 for unexpected or non-PAW source IPs and review quarterly
• Deploy honeypot AD objects (fake privileged accounts, decoy SPNs) to detect enumeration activity and trigger high-confidence alerts
• Ensure SIEM ingestion covers both the Directory Service log and Security event log from every domain controller, with health monitoring for ingestion gaps
• Apply least-privilege principles to service and user accounts to limit the value of ADWS-based enumeration even if attribution is delayed

Tools

• Windows Event Viewer (Directory Service log for Event 1644; Security log for Event 5156)
• auditpol.exe (to enable and verify Filtering Platform Connection auditing)
• Windows Registry Editor / reg.exe (to configure NTDS Field Engineering diagnostic logging level)
• SIEM platform — Splunk, Microsoft Sentinel, Elastic SIEM (for cross-event log correlation within time windows)
• PowerShell (local event correlation and ad-hoc investigation scripting)
• BloodHound / SharpHound (attacker-side reference for identifying characteristic LDAP query patterns)
• Wireshark / Network capture (optional secondary validation of ADWS connection timing)

References

• The 60ms Window: How Event 5156 Solves the ADWS Attribution Problem – Huntress Blog
• Microsoft Docs: Configure Active Directory and LDS Diagnostic Event Logging (Event 1644)
• Microsoft Docs: Event 5156 – Windows Filtering Platform Connection Permitted