Inaccurate object identification during import from .zip

[dkjajhqu2h3j]

Description:

Some, not all, domain groups are marked in green which is dedicated to user objects. They should be marked in yellow. This makes it hard to get a quick overview. If that also means that the affected domain groups are identified as user objects I do not know. However, I noticed that Exchange servers that by default are members of the domain group Exchange Servers, are not shown as members when viewing the domain group Exchange Servers object. If viewed from an Exchange server object, the edge MemberOf is shown.

In the picture below you can see the following which I believe is incorrect:

• The domain group Exchange Servers is marked in green, not in yellow. Compare that to the domain group Authenticated Users which is marked in yellow.
• The domain group Managed Availability Servers is marked in green, not in yellow.
• The domain group Domain Computers is marked in green, not in yellow.
• The domain group Exchange Trusted Subsystem is marked in green, not in yellow.
• The domain group Exchange Windows Permissions is marked in green, not in yellow.
• In the information pane on the right you can see that there are no members listed for the domain group Exchange Servers. This is in fact not correct since you can can see the edge MemberOf between the computer object Exchange1 and the domain group object Exchange Servers.

Component(s) Affected:

• [* ] UI
• API
• Neo4j
• PostgreSQL
• Data Collector (SharpHound, AzureHound)
• Other (tooling, documentation, etc.)

Steps to Reproduce:

1. Dump data using Sharphound.exe 2.3.3.
2. Probably not relevant, but I also performed a session collection loop after the initial dump.
3. Import all .zip files into Bloodhound CE 5.8.1 available April 26 (CET).
4. Search for for example the domain group Exchange Servers.

Expected Behavior:

A description of what you expected to happen.

Actual Behavior:

A description of what actually happened.

Screenshots/Code Snippets/Sample Files:

If applicable, add screenshots, relevant code snippets, or sample files that help illustrate the issue.

Environment Information:

BloodHound: [BloodHound version or revision]
Bloodhound CE 5.8.1.

Collector: [SharpHound version / AzureHound version]
Sharphound.exe 2.3.3.

OS: [your OS and version]
Kali 2024.1 and Windows 10 22H2.

Browser (if UI related): [browser name and version]

Node.js (if UI related: [Node.js version]

Go (if API related): [Go version]

Database (if persistence related): [Neo4j version / PostgreSQL version]

Docker (if using Docker): [docker version]

Additional Information:

Any additional context or information that might be helpful in understanding and diagnosing the issue.

Potential Solution (Optional):

If you have any ideas about what might be causing the issue or how it could be fixed, you can share them here.

Related Issues:

If you've found related issues in the project's issue tracker, mention them here.

Contributor Checklist:

• [*] I have searched the issue tracker to ensure this bug hasn't been reported before or is not already being addressed.
• [*] I have provided clear steps to reproduce the issue.
• [*] I have included relevant environment information details.
• [*] I have attached necessary supporting documents.
• I have checked that any JSON files I am attempting to upload to BloodHound are valid.

[rvazarkar]

Can you output the result of the following Neo4j Query:

MATCH (n:User) WHERE n.name="INSERT NAME OF NODE WITH WRONG TYPE HERE" RETURN labels(n);

Replace the value in the quotes with one of the groups, for example the "EXCHANGE SERVERS@ADLAB" group

[dkjajhqu2h3j]

No problem. However, it did not result in much. "No results match your criteria".

[dkjajhqu2h3j]

FYI. Using Bloodhound 4.3.1 and the same data dumps these errors do not occur.

[exploide]

I observed the same behavior. In my case, the Administrator user was displayed like a group. To help here, I tried to reproduce with a fresh import, but the Administrator is correct now. Instead I see some groups marked as users like @dkjajhqu2h3j described.

Affected is for example the Domain Admins group, here the German localization Domänen-Admins.

MATCH (n) WHERE n.name="DOMÄNEN-ADMINS@xxx" RETURN n

{
    "nodes": {
        "2": {
            "label": "DOM\u00c4NEN-ADMINS@xxx",
            "kind": "User",
            "objectId": "S-1-5-21-xxx-xxx-xxx-512",
            "isTierZero": true,
            "lastSeen": "2024-04-30T08:17:03.092Z",
            "properties": {
                "admincount": true,
                "description": "Administratoren der Dom\u00e4ne",
                "distinguishedname": "CN=DOM\u00c4NEN-ADMINS,CN=USERS,DC=xxx,DC=xxx",
                "domain": "xxx",
                "domainsid": "S-1-5-21-xxx-xxx-xxx",
                "isaclprotected": true,
                "lastseen": "2024-04-30T08:17:03.092Z",
                "name": "DOM\u00c4NEN-ADMINS@xxx",
                "objectid": "S-1-5-21-xxx-xxx-xxx-512",
                "samaccountname": "Dom\u00e4nen-Admins",
                "system_tags": "admin_tier_0",
                "whencreated": 1071636527
            }
        }
    },
    "edges": []
}

Trying to obtain the labels does not work:

MATCH (n:User) WHERE n.name="DOMÄNEN-ADMINS@xxx" RETURN labels(n)

{
  "http_status": 500,
  "timestamp": "2024-04-30T08:31:01.512850052Z",
  "request_id": "170894be-320c-41ef-8fba-8a11fd5fc1fa",
  "errors": [
    {
      "context": "",
      "message": "no matching target given for type: []interface {}"
    }
  ]
}

[elbae]

Hi, I'm using BloodHound 5.8.1 and I am facing the same problem.
We (me and @vari-sh) found out that by importing the .zip collection the problem is present, while unzipping the archive and uploading the data collected as single .json file solves the problem.

We first found out the problem in Neo4j (http://localhost:7474/browser/) while executing this query

MATCH p=(n:Group)<-[:MemberOf*1..]-(m)
WHERE n.objectid ENDS WITH "-512"
RETURN p

that returned a graph with some nodes tagged both as User and Group.

So our solution is unzip and import json file instead of zip file.

[StephenHinck]

@elbae - I've made sure the team is aware of this. This is very helpful context on where you noticed the issue! Thank you!

[dkjajhqu2h3j]

Given the new information from elbae, I ingested the same data as I originally did, this time by first extracting the .json files, into BHCE 5.9.0 and now the domain group Exchange Servers looks and behaves as expected.

[tothi]

same here. had similar issues with a zip (groups were treated badly as users), but it was working well by uploading and ingesting the jsons directly.

[StephenHinck]

This was resolved in yesterday's release, please see https://github.com/SpecterOps/BloodHound/releases/tag/v5.13.0