[Request for Feature] Machines' local groups and users memberships

[aress31]

I am not sure if this is a missing feature or if I just don't use Bloodhound properly, but the local admins section on Bloodhound only shows the Domain users part of the local administrators group. Is there any way to include the local users that are part of the local administrators group as well. I am asking this because, very often local administrators are reused accross a domain and hence compromising a local administrator on one machine can provide access to a lot more machines.

[Meatballs1]

You could have the same username, and the same password, used across the entire domain, but there is no way to verify this unless you actually perform a password spray/PTH attack.

You could have 'workstation_admin' users on every end-user device but they could all have unique passwords.

The only potential way to identify this via AD detection methods is if the same account is configured via group policy preferences.

[aress31]

@Meatballs1 you are spot on. However, - I am not sure if this is possible but I think that there are some available Powershell scripts to perform local groups/membership enumeration - enumerating local groups and theirs members whilst doing the computer enumerations and adding additional sections (and objects paramaters on the Neo4j model if needed) like 'workstation local groups' and showing the different membership relationship between the local groups and the local users could really help in a lot of different situation.

Let's take this the following example, the domain evilcorp use a few extra local admin named eviladmin on some specific machines of their domain although you are right and eviladmin could have a totally different passwords on these different machines, it could also be possible (and be very likely) that they share the same password. Thus, compiling a list of all the computers with the user eviladmin present on them could narrow down the scope for password spraying attacks, hence helping the pentester in generating less traffic on the network.

[andyrobbins]

Hey Alexandre, thanks for taking the time to open the issue to discuss this idea, and thanks Ben for your thoughts here too. This is something we've thought about for a long time as well, including the local principals that belong to interesting local groups (local admins, remote desktop users, and distributed com users).

The primary problem is exactly what Ben mentioned: there is no way to guarantee that the passwords between these local accounts will be the same. When you look at the other edges that exist in the BloodHound graph design, the attacks are almost always guaranteed to be valid, usually in spite of any compensating controls.

Whenever we introduce new edges to the graph design, we have to very carefully consider, measure, and test the impact that new edge has on the overall performance, usability, existing built-in queries, and future expandability of the project. That's an easier pill to swallow when the new edge represents a guaranteed new attack opportunity for the BloodHound user, as that brings along with it an enormous amount of value for every BloodHound user. But when that new edge comes with several caveats, that becomes very tough to justify.

The other thing to consider is that, if you are on a network where local admin passwords are common between systems, BloodHound really isn't going to help you as much as it would in an environment with, for example, LAPS deployed. If you drop into a network where the RID-500 account on your system has the same credential as the RID-500 system on a domain controller, you don't need BloodHound.

This is not to say that the idea isn't a good idea. It's a very good idea and personally I can think of several instances where having credential commonality mapped out would have saved me days of effort on a pentest or red team. If we can figure out how to (nearly) guarantee credential commonality in a way that doesn't require admin rights on each endpoint, we will very seriously consider adding that to the data model.

I'll keep this issue open for a while as the conversation is very interesting and I want to make sure others' voices are heard.

[aress31]

Hi Andy,

First of all thanks for your very detailed and quick reply. I was thinking more about adding this feature as extra information on computer nodes because as you said it is not guaranteed that account share passwords between them but it is still good to provide the tester with at least quick and easy visibility on which local users/groups are on a computer node that he is targeting.

This could be presented under a "Computer or Node Info" section, that will have a clickable text field like "See local groups". When clicking the link, all the machine's local groups would be displayed and cliking one of local group on the graph would show the membership relationships with the local users.

So far as great as Bloodhound is (and I love this tool), it only takes in consideration the domain accounts which is fair in AD environments but local accounts are also a very common way of compromising a domain (i.e. password reuse).

Therefore, I can think of two ways of implementing this new feature:

1. Update the DB model to include local admins and explicitly state that the paths are not guaranteed as local account with the same name does not mean local account with the same password.
2. Just display this data as information on the node and do not use it to compute the paths. This way I don't have to run extra PowerSploit commandlets or Poweshell scripts to determine which local groups and local users are on the machine that has spiked my interest.

I personally think that the second option would be great. Additionally, some pre-built queries could be added to for example get a list of all the computers with a specified local account or local group name so tester could easily create password spraying list and automatically remove machines which do not meet the requirements.

I am currently working on a red team engagement on a pretty big forest, more than 15000+ machines and users. I found a local Administrator account named evilaccount on a compromised machine. I obtained this acocunt credentials. I also found out that this account was present on a few other machines of the domain (probably a legacy account as the client is using LAPS ;)).

I am of course not going to check the 15000+ machines of the domain and I do not want to generate more noise by running some custom Powershell scripts to enumerate the local groups/users and keep this collection of data in text files (I much rather prefer to use the sleek BloodHound interface).

Ideally, what I would like to do on my engagements is to generate noise only once to gather most of the information needed for my engagement using a dispoable machine/user account to get more domain awarness. Therefore, adding this new feature to Bloodhound would be very welcome for the use case that I described.

I hope this helps and I am looking forward to hear what you are thinking about this.

Kind regards, Alex

[bao7uo]

I think it would be great to be able to map out which machines share a common user account, or accounts, e.g. "Show me all the workstations which contain the local user account "admin1x"