or what considerations you should make when querying LDAP to gain better insight on your target.
LDAP (Lightweight Directory Access Protocol) is the backbone of Active Directory (AD). It’s how domain controllers store and retrieve directory information (like user accounts, groups, and permissions), and when you query LDAP, you’re accessing the domain controller’s brain (sort of).
When you’re deep in a red team engagement, one of the first things you need to do is gather intel: quietly. Active Directory holds a lot of valuable information, but if you’re not careful, you’ll trip alarms faster than you can say “beacon”. That’s where awareness can help you to stay under the radar, because mastering the art of stealthy enumeration can save your engagement.
Whether you’re on a red team engagement or just trying not to light up every SIEM within 10 kilometers, understanding how LDAP gets logged and how to avoid looking like a noisy pentest tool is essential.
Here’s a summary that started out of simple curiosity and turned into personal research, hands-on testing, and a fair bit of frustration… all part of the learning experience, I suppose.
LDAP enumeration gets flagged from three main angles, and each has its own traps that depend on how mature the blue side is.
LDAP queries are monitored through API Hooking and the Microsoft-Windows-LDAP-Client ETW provider. This provider operates in user space and captures key details like the search filters that the query asks. It’s important to remember that legitimate system processes generate LDAP traffic all the time. So, from a detection standpoint, this creates a challenge: not all LDAP traffic is suspicious.
For red teamers, this means one thing: if you want to stay quiet, start by understanding what normal looks like. Instead of running LDAP queries directly from a suspicious or custom process (which might trigger alerts), it’s often better to leverage or tunnel through an allowed process to blend in with normal activity.
This is where things like BOFs or SOCKS proxying come in handy: they let you route your actions through legitimate processes, keeping a lower profile and avoiding unnecessary attention.
Unless LDAPS is enforced, all your LDAP queries travel in cleartext. That means every attribute you request, every filter you build: it’s all on the wire. If LDAPS is in place, consider it a small victory: it reduces network-level exposure. However, encryption alone doesn’t make you invisible because LDAPS protects confidentiality, not stealthiness. Defenders can still detect unusual query patterns or high volumes.
But if it’s simple LDAP, assume everything you send is being watched, logged, and potentially analyzed. In that case, your OPSEC posture should adapt accordingly.
This layer is the real obstacle for red teamers. Something like Microsoft Defender for Identity (MDI) is just one example of solutions that operate directly on Domain Controllers, passively inspecting LDAP traffic and profiling query patterns over time. They don’t rely on endpoint agents, so even if you’ve bypassed the endpoint and network layers, your traffic still flows through the DC, where the analysis happens.
These solutions often build behavioral baselines and maintain signatures of known offensive tools. If your LDAP queries look like SharpHound, Rubeus, or other widely used reconnaissance utilities, there’s a good chance you’ll get… burned.
That’s why blending in matters. Mimicking legitimate admin behavior, using native tools, limiting query scope, and avoiding aggressive filters can help reduce visibility.
Now let’s talk about decoy/canary objects deployed in Active Directory environments. Yep, they exist and from a detection engineering perspective, they’re actually pretty fascinating (it’s worth exploring this area further).
Here’s the fundamental idea: if any LDAP query touches a canary object, alarms go off (obviously). And we can think of this event as if someone is going to take a look at that query and if it seems legit, fine. If it’s not… they’re releasing the hounds.
But when we talk about canary objects, there’s a crucial detail that’s often overlooked: the type of attribute you’re querying.
Whenever you query Active Directory using LDAP, the Domain Controller has to search across thousands (if not millions) of objects. To keep things efficient, it relies on indexes.
samAccountName, distinguishedName, pretty common stuff.You see where this is going, right?
If you query for something like adminCount=1 or run a bitmask filter like (userAccountControl:1.2.840.113556.1.4.803:=16777216), you’re asking the DC to access every object within the target DN to evaluate the presence of the specified attribute, including any canary object.
Now, the problem is, how the f**k can I know which attributes are indexed?
Fair question. And this is where the old book-scraping method comes to the rescue: Active Directory Cookbook. Buried in its pages there are two LDAP queries you can run directly against the AD Schema partition to reveal exactly what we need.
The schema tells us how every object and attribute in the directory is defined, including whether it’s indexed.
searchbase: cn=Schema,cn=Configuration,<ForestRootDN>
# To list indexed attributes:
(&(objectcategory=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=1))
# To list non-indexed attributes:
(&(objectcategory=attributeSchema)(!(searchFlags:1.2.840.113556.1.4.803:=1)))
Keep that in mind.
When you enumerate don’t just fire off everything you know. You must think. As a Red Team Operator you are responsible for the kind of detection you might trigger, and often manually crafting LDAP queries might just be your safest path forward.
I know, it’s boring, tedious, slow - and yes we could stack more adjectives here - but necessary.
So, don’t treat LDAP recon as something to launch during your coffee time:
Because, like the old Benjamin says: if you fail to plan… you plan to feed every alert rule in the SIEM.
Yeah, it’s written in his book, really, why don’t you trust me?
These tools give you a peek into the LDAP baseline of your environment.
self promotion here: looking for a lab? give ad-training-lab a try.