Correlating Windows Events 5156 and 1644 to Attribute ADWS Queries
Summary
A tested method correlates Windows Events 5156 and 1644 to attribute Active Directory Web Services LDAP queries to their source IP, using port matching when logs are retained or a roughly 60–80 ms time window.
Key points
- ADWS can make LDAP diagnostic logs show localhost as the query client, obscuring the originating host.
- Event 5156 records permitted network connections, including the source IP for inbound ADWS traffic on port 9389.
- Port-based correlation can link Event 5156 to Event 1644 when the original connection event is still retained; persistent connections may make it unavailable in live DC logs.
- In three tests, the external connection event preceded the corresponding LDAP query event by about 60–80 ms, supporting timestamp-based correlation.
- The article describes a script that tries port matching first and then uses a timing window to attribute queries.
- To reduce false positives from normal RSAT use, the approach looks for suspicious Event 1644 patterns, including [all_with_list], SDflags:0x7, and (!(FALSE)).
- The author says SIEM retention makes this correlation practical even when high Event 5156 volume causes older events to roll out of a domain controller's Security log.
Article Details
- Defense Focus
- Attribute Active Directory Web Services (ADWS) LDAP queries to their originating host by correlating Windows Filtering Platform Event 5156 with Directory Service Event 1644, using Event 1138 to associate the ADWS session with the authenticated user.
- Detection Methods
- Correlate Event 5156 and Event 1644 by timestamp within approximately 60–80 ms; the article reports this interval across three test runs.
- Where retained, use the original Event 5156 connection and matching port for deterministic correlation; otherwise use timestamp correlation.
- Prioritize Event 1644 patterns such as [all_with_list], SDflags:0x7, (!(FALSE)), high-volume localhost queries, and nTSecurityDescriptor requests to distinguish suspicious enumeration from routine ADWS activity.
- Correlate Event 1138 with Events 5156 and 1644 to connect the source IP, ADWS session, authenticated user, and LDAP query.
- Use Get-ADWSAttribution.ps1 for automated collection and correlation, with port-based correlation attempted before timestamp fallback.
- Data Sources
- Windows Security log: Windows Filtering Platform Event 5156
- Active Directory Web Services log: Event 1138
- Directory Service log: Event 1644
- SIEM-retained Security logs
- Forensic EVTX backups
- Rule Types
- Event-correlation detection using a tight timestamp window
- Port-based network-event correlation
- LDAP query-pattern detection in Event 1644
- Platforms
- Windows
- Splunk
- Sentinel
- Defensive Actions
- Forward Security logs to a SIEM and retain Event 5156 long enough for correlation; the article notes that high event volume can cause older events to roll off a domain controller.
- Correlate suspicious Event 1644 LDAP patterns with Event 5156 rather than alerting on every ADWS connection to port 9389.
- Include Event 1138 in the correlation chain to associate the ADWS session with the authenticated user.
- Use timestamp correlation when the original connection event is no longer available locally, and port-based correlation when the relevant original event is retained.
- Use Get-ADWSAttribution.ps1 to monitor and attribute correlated queries.
MITRE ATT&CK
T1069.002 · Domain GroupsThe article identifies LDAP queries requesting nTSecurityDescriptor and SDflags:0x7 as patterns associated with ACL enumeration and attack-path discovery.T1087.002 · Domain AccountThe article describes ADWS-based enumeration of Active Directory users and computers, including queries associated with BloodHound enumeration.
People
Adam BienvenuAcknowledged for helping review the article.Andrew SchwartzAuthor of the article describing Event 5156 correlation for ADWS query attribution.Anton OvrutskyAcknowledged for helping review the article.Charlie ClarkSuggested correlating network Event 5156 to identify the originating host for ADWS requests.Jonathan JohnsonConducted prior RPC research demonstrating Event 5156 correlation; also collaborated on the cited client-server correlation post.Matt AndersonAcknowledged for helping review the article.Michael HaagAcknowledged for helping review the article.Nasreddine BencherchaliAcknowledged for helping review the article.Tyler BohlmannAcknowledged for helping review the article.
Products
BloodHoundThe BloodHound Slack challengeMicrosoft Active DirectoryA threat actor enumerated our entire AD with Get-ADComputer, and none of our detections fired. The problem wasn't their evasion - it was an architectural blind spot in how PowerShell talks to Active Directory.Microsoft SentinelSIEM (Splunk/Sentinel)Microsoft WindowsThe only way to derive the originating host is through netsession enumeration, but its even harder with SOAPy because you can proxy in the traffic from a non-windows session."SplunkSIEM (Splunk/Sentinel)
Tools
Get-ADWSAttribution.ps1Running Get-ADWSAttribution.ps1 during active SOAPy enumeration:RSATYou could detect it with traffic to 9389 (ADWS) but there's an even bigger problem there, all of RSAT uses ADWS. So sysadmins doing normal operations would trigger false positives.SOAPyEg when using soapy? ADSi has been very reliable for us, also in very mature environments.