Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collapse and Expand Group Members/Relationships #89

Open
deletehead opened this issue Sep 11, 2023 · 3 comments
Open

Collapse and Expand Group Members/Relationships #89

deletehead opened this issue Sep 11, 2023 · 3 comments
Labels
enhancement New feature or request ticketed (automation only) Ticket has been created internally for tracking

Comments

@deletehead
Copy link

Feature Description:

Requesting the ability to collapse nodes that are automatically expanded in the UI. This feature was available in Ye Olde BloodHound. Without it, it makes working with large/complex AD environments very difficult in the UI.

Current Behavior:

I have a query from one node to another (not necessarily an exploitable one ;D) that shows thousands of "extra" nodes and edges. A node is a member of a large group that has relationships with other systems.

Currently, the UI expands out other similar edges that are unnecessary to the attack path being queried. For instance, in the below query, a group has CanRDP to hundreds/thousands of systems (it's the known "Citrix systems need CanRDP but don't actually allow RDP" issue -- used for demonstration as it's not a real issue).

As seen below, the attack path is essentially unreadable and requires significant effort to make use of by zooming, rearranging, etc.

image

Desired Behavior:

Only the relevant nodes and edges to the attack path being queried should be shown. Ideally, there would be an option to expand or collapse groups as in Ye Olde BloodHound.

Use Case:

It will benefit users in large AD environments that have complex relationships by making the visualization readable.

@deletehead deletehead added enhancement New feature or request triage This issue requires triaging labels Sep 11, 2023
@martinsohn
Copy link
Contributor

Perhaps your issue can be solved with a different query. Exactly which query are you using?
When querying a path from one node to another, you usually won't get unnecessary edges and nodes listed - so something may be wrong with your query.

@deletehead
Copy link
Author

@martinsohn -- This was indeed a simple query, it was just a complex environment. Was this tested in a very large environment?
For example, in the image above, that is a simple query of an attack path from "[email protected]" to "DOMAIN [email protected]". For some reason, it shows extraneous nodes. In this instance, the "DOMAIN USERS" group had the ability to RDP to a large number of Citrix systems (at least from an AD perspective, not in reality). It showed the start node as a member of DOMAIN USERS, and then showed a massive amount of irrelevant CanRDP edges. Only one of these edges was relevant to the attack path.

Either the exclusion of irrelevant edges (i.e., irrelevant to the simple attack path being queried) or the ability to collapse extraneous edges similar to how the old BloodHound could expand/collapse nodes would be really great.

Please let me know if this makes sense. I can also provide a ton of other examples if needed.

@martinsohn
Copy link
Contributor

It would be helpful if you could isolate and share one of these scenarios of extraneous nodes and edges, also if you could share your query.

I have just tested a User -> Domain Admin path in a complex environment (>160k nodes and millions of relationships), where the Attack Path went through Domain Users with CanRDP edge to 100's of systems. I cannot reproduce what I believe your issue looks like.

  1. Using Path Finding I get an attack path: User-[MemberOf]->Domain Users-[CanRDP]->Systems on which Domain Admins have sessions->Domain Admins.

  2. Using queries
    This query (limited to 6, as it otherwise times out):
    MATCH p=(u:User)-[*1..6]->(g:Group)
    WHERE u.name CONTAINS "USER"
    AND g.name = "DOMAIN [email protected]"
    RETURN p

And this (not looking at DA):

MATCH p=(u:User)-[:MemberOf*1..]->(g:Group)-[r:CanRDP]->(c:Computer)
WHERE u.name CONTAINS "USERNAME"
RETURN p

In your scenario, were there any outgoing edges from the systems/nodes which Domain Users have CanRDP to?
I.e., your paths go like this (which would be a bug):

  • (User)-[CanRDP]->(System1) END
  • (User)-[CanRDP]->(System2) END
  • (User)-[CanRDP]->(System3) END

Or like this (which is not a bug):

  • (User)-[CanRDP]->(System1)-[HasSession]->(DA) END
  • (User)-[CanRDP]->(System2)-[HasSession]->([Other nodes and edges ])>-(DA) END
  • (User)-[CanRDP]->(System3)-[HasSession]->(DA) END

@StephenHinck StephenHinck added ticketed (automation only) Ticket has been created internally for tracking and removed triage This issue requires triaging labels Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request ticketed (automation only) Ticket has been created internally for tracking
Projects
None yet
Development

No branches or pull requests

3 participants