Catching a SharpHound run: the LDAP burst and the session fan-out

BloodHound is the tool that turned Active Directory attack paths from tribal knowledge into a graph anybody can query, and its collector, SharpHound, is what does the loud part. Nothing about the collection is an exploit. It reads the directory and asks hosts who’s logged on, which is exactly what a lot of legitimate software does too. So the detection isn’t about a forbidden action. It’s about the shape and speed of a normal action done at a volume no human workflow produces.

There are two behaviors worth building around, and they fail in different ways, so I run both.

Behavior one: the LDAP enumeration burst

SharpHound’s default collection reaches into LDAP and pulls a wide slice of the directory in one pass: users, groups, group memberships, computer objects, ACLs, GPO links, trusts. To an authenticating account this is a rapid sequence of LDAP queries against the domain controller, far more of the directory, far faster, than an ordinary application touches in a session.

If you turn on Directory Service Access auditing you’ll see event 4662 on the DC for object access, and in principle you can hunt the pattern there. The honest problem is that 4662 is one of the noisiest events a busy DC produces, so a naive rule drowns. Where it becomes workable is the burst framing: not “an account read a directory object,” which is constant, but “one account read a large and diverse set of directory objects inside a very short window.” That velocity-and-breadth pattern is hard for benign software to reproduce, because benign software queries the slice it needs, not the whole map.

This maps to a fistful of ATT&CK discovery techniques at once, Account Discovery (T1087), Permission Groups Discovery (T1069), and Domain Trust Discovery (T1482), which is itself a hint that you’re looking at a mapper rather than an app.

Behavior two: the session fan-out

The half that builds attack paths is session enumeration. To know which account is logged on where, SharpHound reaches out to many hosts and asks, using the same remote enumeration calls that admin tools use. On the wire that’s one source host opening connections to a large number of destinations on the SMB and RPC ports in a short span.

This is the signal I trust more, because volume from a single source is genuinely abnormal. A workstation talks to a handful of servers in a normal day. A workstation that suddenly touches four hundred hosts in ninety seconds is either a scanner, a management tool you can enumerate and exclude, or a collector. Sysmon EID 3 gives you process-attributed network connections to build this from, which is better than flow data because it tells you which process on the source did the fanning out. Remote System Discovery (T1018) is the label.

The cheap win: a honeytoken high-value object

Look, the highest-fidelity version of this isn’t a threshold on either behavior. It’s bait. Because BloodHound is used to find paths to high-value targets, you plant an object that looks like exactly that, a decoy account or group that reads as privileged, that no legitimate process has any reason to query, and you alert on any read of it. A SharpHound run enumerating the domain will touch it as a matter of course. Real workflows won’t, because the object is fictional. The false-positive rate lives near zero for the same reason it did with the Kerberos honeypot I described for service-ticket abuse: legitimate traffic to a decoy doesn’t exist.

The one caveat is to make the decoy credible. A privileged-looking object with a creation date of yesterday and no history is a tell to an operator who’s paying attention. Age it, give it plausible group memberships, and let it sit.

What I’d run

Deploy the session fan-out rule first, because single-source-to-many-hosts is the cleanest of the three and it catches the path-building half immediately. Plant the honeytoken second, because it’s five minutes and near-zero noise. Treat the 4662 LDAP-burst hunt as the third layer, tuned to breadth-and-velocity rather than any single read, and accept that it’s the one you’ll spend the most time keeping quiet. None of these depend on the collector being named SharpHound or run from a particular binary, which matters, because the tool gets recompiled and renamed constantly and the questions it asks do not.