Full Report
Learn why your LDAP detection rules never fire and how to fix them. Hint: it's the OID-to-bitwise transformation.
Analysis Summary
# Best Practices: LDAP Detection & OID Transformation
## Overview
Active Directory (AD) reconnaissance often leverages LDAP queries to map users, groups, and permissions. However, detection rules frequently fail because attackers use Object Identifiers (OIDs) in their source code (e.g., Impacket), but Windows Domain Controllers transform these OIDs into bitwise operators within the logs. These practices address how to bridge the gap between attacker code and log visibility.
## Key Recommendations
### Immediate Actions
1. **Enable LDAP Logging on DCs:** Windows does not log LDAP queries by default. Set the Registry value `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\15 Field Engineering` to **5**.
2. **Update Detection Logic:** Audit existing SIEM rules for LDAP reconnaissance. If you are searching for OID strings like `1.2.840.113556.1.4.803`, update them to include the bitwise equivalent `&`.
3. **Monitor Event ID 1644:** This is the primary event for directory service queries on Domain Controllers.
### Short-term Improvements (1-3 months)
1. **Enable Client-Side Logging:** Enable `Microsoft-Windows-LDAP-Client/Debug` logs on sensitive endpoints or high-value targets to capture the "who" and "what process" behind a query.
2. **Deploy Specialized Tooling:** Implement tools like `LDAPMon` on administrative workstations to gain deeper visibility into client-side LDAP activity that standard event logs might miss.
3. **Map Common Tools:** Analyze common attack tools (Impacket, BloodHound, AdFind) and document the specific LDAP filters they use, specifically noting how their OIDs transform in your environment's logs.
### Long-term Strategy (3+ months)
1. **Correlate Network and Host Logs:** Develop a pipeline to correlate Event ID 1644 (from DCs) with Event ID 5156 (Windows Filtering Platform) to attribute "localhost" LDAP queries to their actual source IP addresses.
2. **Architectural Audit:** Address blind spots in Active Directory Web Services (ADWS) and LDAP Pings that do not appear in standard 1644 logs.
3. **Baselines:** Establish a baseline of "normal" LDAP query volume and complexity for service accounts and administrators to detect anomalies.
## Implementation Guidance
### For Small Organizations
- Focus on enabling **Event ID 1644** on Domain Controllers.
- Use basic SIEM alerts for high-volume queries or queries originating from non-admin workstations.
### For Medium Organizations
- Implement the Registry changes via Group Policy (GPO).
- Centralize **Event ID 1644** and **Event ID 30** (Client Debug) for a subset of critical servers.
- Monitor for specific bitwise operators used in common reconnaissance tools.
### For Large Enterprises
- Automated correlation of LDAP logs with network connection logs to identify the true source of queries.
- Monitor **SDFlags** and **nTSecurityDescriptor** queries, which are often indicators of advanced attack path discovery.
- Integration of ETW (Event Tracing for Windows) for real-time LDAP monitoring across the fleet.
## Configuration Examples
### Enabling DC Logging (Registry)
powershell
# Enable Field Engineering logging to capture LDAP queries (Event 1644)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" -Name "15 Field Engineering" -Value 5
### Detection Logic Transformation
| Attacker Code (OID) | Log Transformation (Bitwise) |
| :--- | :--- |
| `LDAP_MATCHING_RULE_BIT_AND` (1.2.840.113556.1.4.803) | `&` |
| `LDAP_MATCHING_RULE_BIT_OR` (1.2.840.113556.1.4.804) | `\|` |
**Example Query Search:**
Instead of searching for: `userAccountControl:1.2.840.113556.1.4.803:=16777216`
Search logs for: `(userAccountControl&16777216)`
## Compliance Alignment
- **NIST SP 800-53:** AU-2 (Event Logging), AU-6 (Audit Review, Analysis, and Reporting).
- **CIS Controls:** Control 8 (Audit Log Management), Control 5 (Account Management).
- **MITRE ATT&CK:** T1087 (Account Discovery), T1069 (Permission Groups Discovery).
## Common Pitfalls to Avoid
- **The OID Trap:** Writing detection rules based solely on documentation or source code without verifying how the Domain Controller actually renders the log.
- **Performance Overhead:** Setting "Field Engineering" logs to level 5 can be verbose. Monitor DC disk space and CPU utilization after enabling.
- **Localhost Blindness:** Relying solely on DC logs often shows the source IP as `127.0.0.1` for certain services (like ADWS), requiring correlation with other events to find the attacker.
## Resources
- **LDAPMon:** `github[.]com/jonny-jhnson/LDAPMon`
- **Microsoft Documentation:** `learn[.]microsoft[.]com/en-us/troubleshoot/windows-server/active-directory/event1644reader-analyze-ldap-query-performance`
- **Defanged Source:** `hXXps://www.huntress[.]com/blog/ldap-active-directory-detection-part-one`