SharpHound returns prematurely on segmented networks

[mgeeky]

Hello there,

I've noticed couple of caveats to CollectionMethod selection on highly secured/segmented networks. No SharpHound output can be provided here, but only brief description of my findings after playing around.

Network: A big domain, of dozen of domain controllers, subdomains, trusts, tens of thousands of AD objects. Enumeration over VPN, LDAP. From a local admin authenticated session.

1. Since the network is basically cutting out ICMP traffic, there is no way to gather up SMB Sessions, which I guess makes methods like: Session, ComputerOnly, LoggedOn, SessionLoop fail. SharpHound after couple of tries yielded me around 500-1500 objects, always failing around that 1500 mark. No explanatory message in -Verbose. Informed me that 0 hosts failed ping, 0 hosts timedout. SharpHound finishes in 00:01:30.
2. I've tried playing with --SkipPing and ping timeout - nothing changed in the output
3. Specyfing manually following methods: --CollectionMethod Group,RDP,LocalGroup,DCOM,Trusts,ACL,Container,ObjectProps - resulted in 1500 objects as well.
4. Running --SkipPing --CollectionMethod Default in turn, rapidly yielded 26237 objects enumerated, but then got severly slowed down to +11-121 of increment per one line of status (30 seconds I suppose).
5. Playing with --DomainController had no reflection on the results.

So there is definitely a corner case about CollectionMethod setup, when ICMP is filtered-out, the network is well segmented. Due to the nature of project where I've tested this Ingestor, I don't think I will be able to help in debugging it further, sorry for that.

[rvazarkar]

SharpHound does not use ICMP to check if a host is alive. It uses a port check for port 445. So ICMP filtering should make no difference. I'm not sure how to really work with this issue, as it's pretty hard to replicate