BloodHoundAD
SharpHound 2.7.2 incomplete domain users enumeration
Running SharpHound 2.7.2 with -c all or -c dconly only results in 2000-2500 users being enumerated in our environment when there are actually more than 120,000 users that were reliably enumerated with earlier versions.
Earlier version of Sharphound returning a complete set of users:
% jsonpp 20250715194931_users.json | tail
}
],
"meta": {
"methods": 6583295,
"type": "users",
"count": 146090,
"version": 6,
"collectorversion": "2.6.7.0"
}
}%
Current version:
% jsonpp 20250924134957_users.json | tail
}
],
"meta": {
"methods": 15725567,
"type": "users",
"count": 2516,
"version": 6,
"collectorversion": "2.7.2.0"
}
}
The number of users returned varies significantly from 2000 or 2500 up to 80,000 and 120,000 on some attempts. It seems possible this was introduced by new timeout code.
Looking into this one. v2.7 introduced adapting timeout logics around external system calls like LDAP queries. It's possible that these user queries are especially slow, timing out, and then even defeating the retry logics intended to avoid exactly this scenario.
The boundary between adaptive-timeout-backoff and query retries is pretty fuzzy. These may just be "missing" each other when they need to align ....
Will experiment and return.
@definitelynotagoblin thanks, it would be great if this could be fixed as we have to run a limited set of collection methods with v2.6.x to avoid SH never completing in our environment. I can provide a full console output log privately of a SH 2.7.2 run that completes but encounters this incomplete user enum issue.
bumping, been running SH for 8 hours and have only collected ~1500 objects out of 100,000+ that older versions could identify in less than 20 seconds in 2.5.7-8
Hello, same problem here.
With 2.5.9 => fast enum even on large domain. With 2.7.x => very slow enum (like 15-20 time longer) and sometimes SID are not resolved for all users OR results are incomplete.
Hey folks - appreciate the information and the comparisons between versions, it's really helpful information! We're actively digging into these issues and looking for solutions - stay tuned!
It seems very likely that - in cases where query time spikes suddenly as may happen when running large User queries - retries are exhausting before our adaptive timeout logic decides to back off its more aggressive strategies.
Because LDAP queries are already gated behind connection tests though, we can be pretty confident that they will get responses back, and we're not getting as much value out of enforcing adaptive timeout cutoffs on these volatile tasks.
The above PR trades the more aggressive adaptive timeout strategy for the old, generous one.