Invalid paths including Protected Users
PLA-Chris opened this issue · comments
Is your feature request related to a problem? Please describe.
I'm always frustrated when Bloodhound produces attack paths for me that contain users in the Protected Users Group.
Describe the solution you'd like
Could we get some indicator on users in the Protected Users Group and have an option to exclude them from paths.
Describe alternatives you've considered
A change to the icon to indicate protected users.
An option in the drop down to remove any node or edge from being included without requiring that it be deleted before re-running a query.
Hi PLA-Chris,
Why do you want to exclude Protected Users members from paths in search? Is it because it is more challenging to obtain cached creds of a member of Protected Users from the memory of a computer?
Sure, if a path is predicated on a user having a session on a machine but there is no credential material (leaving possible token stealing if the session is still alive, we were recently on an engagement with sessions that showing that were 4 years old, etc.) then we deem them to be more difficult to and a potentially lower risk. Having the option to exclude the members of the 'Protected Users' group would allow us to focus on the higher risk, easier to exploit paths first. Even an indicator that in the icon would allow us to make a more educated decision about a particular path.
The edge option would allow us to exclude certain paths be it because of the protected users group or an unusual use of the DC DCOM groups etc.
Gotcha. Thanks for the explanation. I can definitely see the value in that.
For now, I would suggest:
- Delete all the HasSession edges for members of Protected Users
- Do searches for attack paths
- Upload the computers.json file again if you want to reintroduce the deleted edges
You can delete all HasSession edges of Protected Users members with this query:
MATCH p=(()-[r1:HasSession]->(u:User)-[r2:MemberOf]->(g:Group)) WHERE g.objectid ENDS WITH "-525" Delete r1
It is less convenient than having a filter in the UI, but it would work.
If you are interested (or anyone else is) in making a pull request for a UI filter, we would appreciate the contribution and be happy to accept the new feature!