Huntress Shows How to Detect SOAPHound’s LDAP Enumeration in Event ID 1644

Summary
Huntress explains how Active Directory transforms SOAPHound’s non-existent-attribute LDAP filter into `(! (FALSE))` in Event ID 1644 logs, and describes detection patterns using the filter, attributes, client details and SDFlags.
Key points
- SOAPHound uses Active Directory Web Services (ADWS) over port 9389; its LDAP queries can appear in Event ID 1644 as originating from localhost, complicating source attribution.
- The filter `(!soaphound=*)` is logged as `(! (FALSE))` after Active Directory processes the non-existent attribute, removing the tool name from the logged query.
- The article recommends correlating the FALSE pattern with SOAPHound-related attributes and, depending on the operation, `SDFlags:0x7` to improve detection specificity.
- The author tested the behavior in a lab and reports that queries for other non-existent attributes also produced the FALSE pattern and returned domain objects.
- The post includes Sigma detection logic and shows example Event ID 1644 patterns for domain-object and certificate-template enumeration.
- The article contains conflicting statements about when SOAPHound uses `SDFlags:0x7`; its closing takeaway says this is mode-dependent and appears when `nTSecurityDescriptor` is requested.
Article Details
- Defense Focus
- Detect SOAPHound and related LDAP enumeration by identifying the transformed (! (FALSE)) filter in Event ID 1644 and correlating it with SOAPHound-associated attributes and SDFlags.
- Detection Methods
- Match Event ID 1644 messages containing the transformed (! (FALSE)) filter.
- Increase confidence by checking for SOAPHound-associated attributes, including msDS-Behavior-Version, gPCFileSysPath, gPLink, gPOptions, and nTSecurityDescriptor.
- Use the presence of sensitive attributes such as userPassword, unixUserPassword, and msDS-AllowedToDelegateTo as an additional detection condition.
- Consider SDFlags:0x7 alongside the filter and attribute patterns, accounting for the article's conflicting descriptions of when SOAPHound uses this control.
- Data Sources
- Windows Event ID 1644 LDAP search logs, including filter, selected attributes, server controls, client, and search scope
- Active Directory Domain Services LDAP query telemetry
- SOAPHound source code for comparison with observed attribute lists
- Rule Types
- Sigma detection rules using EventID and message-content matching
- Platforms
- Active Directory Domain Controllers
- Defensive Actions
- Do not rely on matching the original (!soaphound=*) query; Active Directory may log it as (! (FALSE)).
- Build layered detections using the transformed filter, attribute selection, and server-control fields rather than the filter alone.
- Treat Event ID 1644 client addresses of [::1] as a possible ADWS localhost proxy, not necessarily the original client.
- Validate detection logic against real SOAPHound execution and account for differences between enumeration modes.
MITRE ATT&CK
People
Vendors
Products
Tools
ImpacketIn Part 1, we learned that Impacket's LDAP reconnaissance tools use OID-based filters that get transformed into bitwise operations in Event ID 1644 logs, breaking our string-matching detection rules.SharpHoundThis differs significantly from SharpHound (Part 3), which uses SDFlags:0x4 or 0x5 only when needed for security descriptor enumeration.SigmaSIGMA Rule 1: High-fidelity SOAPHound detectionSOAPHoundHomeBlogFrom Code to Coverage (Part 4): Hunting SOAPHound - The (!FALSE) Pattern