BloodHound Deep Dive Part 7: Detecting SharpHound and LDAP-Based ACL Abuse
Every offensive series on this site ends with the same question turned around: what does this look like from the blue team’s side? Sn1per Part 5 covered it for automated recon, Impacket Part 10 covered it for Kerberos and SMB abuse. This post covers it for SharpHound’s collection run and the GenericAll-to-ForceChangePassword chain from Parts 4 through 6.
What a collection run leaves behind
SharpHound’s collection is, mechanically, a large volume of LDAP reads against the domain controller, plus, unless DCOnly or Stealth is used, port 445 connections and further queries against every domain-joined computer it can reach. Neither Active Directory’s default audit policy nor a typical SIEM ignores that traffic; the question is whether anyone’s watching for the pattern.
Windows Security event 4662, “an operation was performed on an object,” fires when the Audit Directory Service Access policy is enabled and a principal reads or writes an AD object’s properties, which is exactly what ObjectProps and ACL collection methods do, object by object, thousands of times in a short window during a Default or DCOnly run. Event 4661, “a handle to an object was requested,” typically accompanies it. Neither event is unique to SharpHound: normal AD administration generates both. What isn’t normal is the volume and pattern: a single account generating thousands of 4662 events against User, Computer, and Group objects across the whole domain inside a few minutes is not what a helpdesk operator’s LDAP client does in the course of a day. That volume-over-time signature, not any single event, is what a detection rule should be built around, matching the same “the request is normal, the volume isn’t” pattern this site flagged for Kerberoasting in Impacket Part 4.
Environments running Microsoft Defender for Identity get a more direct version of the same signal: MDI sits on the domain controller itself and has purpose-built detections for reconnaissance tooling, including BloodHound and SharpHound by name, layered on top of the raw LDAP query volume Defender for Endpoint can also see client-side. Neither product needs custom tuning to notice a SharpHound run; both are looking for the same fan-out pattern a defender without either product would need to build by hand from 4662 volume.
Stealth collection, covered in Part 2, is a direct response to this: dropping LoggedOn, RDP, DCOM, PSRemote, LocalAdmin, CARegistry, and DCRegistry in favor of GPOLocalGroup trades local-group accuracy for a much smaller footprint against every non-DC computer in the domain. It doesn’t reduce the LDAP read volume against the DC itself, since GPOLocalGroup and the rest of DCOnly’s scope still come entirely from there. A defender watching DC-side LDAP volume specifically, rather than only watching for connections fanning out to workstations, sees a Stealth run about as clearly as a Default one.
What the ACL abuse chain leaves behind
The GenericAll-to-ForceChangePassword chain from Parts 4 through 6 is a different kind of event entirely: an LDAP write, not a read. A group membership modification and a password reset performed by bloodyAD, or manually, both generate their own directory service change events, and both are actions a legitimate helpdesk account performs routinely, which is exactly why the IT-HELPDESK group existed and held that permission in the first place. The signal here isn’t the write itself, it’s context: j.reyes modifying Backup Operators membership and then immediately resetting svc-legacy-scan’s password, two actions with no obvious operational link to each other, performed back to back by an account whose normal baseline is ticketing-system logins from WKS01, is the kind of correlation a SIEM rule can catch even though neither individual action would trip an alert on its own. autobloody, the tool from Part 6 that drives bloodyAD straight from a BloodHound-identified path, makes that back-to-back timing even tighter and, paradoxically, easier to catch: a human operator manually working the chain might pause between steps, automation won’t.
The defensive case for running BloodHound yourself
The more durable fix isn’t detecting the collection run or the abuse chain after the fact, it’s not having the IT-HELPDESK-to-Backup Operators GenericAll sitting there to find. That ACE existed in this lab because a 2024 ticketing-tool rollout granted it and nobody revoked it once the rollout finished, which is a completely ordinary way for AD permissions to accumulate over years of legitimate changes. BloodHound Enterprise’s whole commercial pitch, and the reason Community Edition is worth running defensively even without it, is continuous attack path management: running the same collection and the same queries this series has been running offensively, but on a schedule, against your own domain, so the GenericAll an attacker would eventually find gets found and revoked first. That’s the same logic Sn1per Part 5 applied to attack surface management generally: most of what an attacker’s tooling finds was already discoverable by the defender, and usually already was, weeks or months before it was actually looked at.
Next: Part 8, tying every part of this series together into one walkthrough, starting from the same foothold Impacket Deep Dive used and ending where the graph, honestly, runs out of edges.