LDAP on port 389: what the callback traffic reveals

TL;DR: LDAP search filters can carry OAST canaries, command injection, path traversal, XXE, CRLF and SQL injection payloads that expose broader attack testing against domain controllers, according to Corelight research. The evidence is already in standard Zeek logs, so the real governance problem is not visibility alone but knowing how to validate whether a callback resolved.

Editorial analysis by NHI Mgmt Group, based on content published by Corelight: “When the fuzzers come knocking on port 389: Hunting injection canaries in LDAP”.

Key questions

Q: How should security teams investigate suspicious LDAP callback traffic?

A: Start by separating the payload from the proof.

Q: Why do directory protocols need deeper monitoring than basic authentication logs?

A: Directory protocols can carry crafted input that tests parsers, triggers downstream lookups, or attempts file and command access.

Q: Where do LDAP detections fail in practice?

A: They fail when teams stop at the suspicious payload and never check for callback evidence.

Practitioner guidance

• Map LDAP filter telemetry to suspicious payload families Create detections for oastify, bxss, traversal markers, XML entities, CRLF sequences, and load_file patterns in decoded ldap_search logs.
• Correlate LDAP probes with DNS lookups Pivot from suspicious LDAP input into DNS logs and check whether any internal host resolved the canary domain before escalating the event.
• Separate sanctioned testing from hostile probing Verify whether lookup traffic came from approved scanner subnets, a red-team VPN pool, or production hosts before treating it as an incident.

Bottom line: This article shows that old directory protocols can still be used as delivery paths for injection probes, so identity infrastructure should be monitored as an attack surface, not just a utility service.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →