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

Workstation logon restriction not taken into account #170

Closed
jbfuzier opened this issue Apr 17, 2018 · 3 comments
Closed

Workstation logon restriction not taken into account #170

jbfuzier opened this issue Apr 17, 2018 · 3 comments

Comments

@jbfuzier
Copy link

Hi,

There is a feature to limit an account log on authorization to a set of workstation.
It seems this restriction is not taken into account to modelise the attack path.

I have an example where users get a specific domain account with restricted "log on to" the user workstation. All those domain accounts are member of a high priviledged group which is member of local admin group of every users PC in the domain. The "log on to" is what is preventing all those users from being admins of every workstations.

The graph is showing attack path that are not real because it is not taking into account this restriction.

https://ravingroo.com/267/active-directory-user-workstation-logon-restriction/

@andyrobbins
Copy link
Contributor

Hi jb,

Thanks for taking the time to open up the issue. Unfortunately there are several mechanisms that could prevent a user from logging onto a system, including the workstation logon restriction you bring up. With any of those mechanisms it's important (for now) that:

  1. That information is retrievable remotely by any authenticated user in the domain, by default
  2. It doesn't make existing path finding queries grossly more complex, or require the usage of external path processing outside of Neo4j, and/or APOC
  3. Path finding queries continue to function as expected even if the BloodHound user has chosen not to import that information

This issue is further complicated by the fact that even though a user may have local admin rights due to being a member of a certain group, the workstation logon restriction is explicitly defined per-user.

Because of those requirements, the complexity, and because in our experience the usage of the allowed workstations control is fairly rare, this is a low priority for us at this time. That can change though, and we may come back to this issue with a fix later.

In the meantime, for issues like this and other issues, I would recommend attempting to collect and parse that information yourself and alter your graph accordingly. You may be able to do something like this:

  1. Collect from each user what workstations they are allowed to log onto, and export that information to CSV.
  2. In Neo4j, import that CSV and establish new relationships between those users and computers. You could call this relationship "AllowedToLogOnTo", for example.
  3. For each user in the DB, match on two paths: one being the computers they have local admin rights to explicitly and through group membership, the other being computers they have the AllowedToLogOnTo edge to.
  4. Filter the results of the first path so that only computers that are also in the second path are returned.

That will at least let you see what computers users have admin rights to as well as being allowed to log onto them.

There may also be a much more obvious solution I'm not seeing, so I'll keep this issue open for a few weeks to see if anyone has a good suggestion. :)

Andy

@jbfuzier
Copy link
Author

Thanks very much for your detailled reply :)

@rvazarkar
Copy link
Contributor

Closing this, as I dont think we can realistically implement this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants