Bug: Service Principal App ID node property displaying Service Principal Object ID instead of App ID
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
Research direction
Start in packages/go/analysis/azure/service_principal.go at getServicePrincipalAppID and trace FetchServicePrincipalApplications into packages/go/analysis/azure/queries.go. Reproduce with an AzureHound payload containing a service principal, then verify the node panel shows the application ID rather than the service principal object ID.
Written by the indexing model from the issue text.
Description
Description:
The node entity panel for AZServicePrincipal objects displays the object ID of the service principal in the App ID property instead of the application ID.
Are you intending to fix this bug?
Yes
Component(s) Affected:
- API
Steps to Reproduce:
Ingest an azurehound payload for an Entra ID tenant with a service principal (e.g., specterdev), search for a service principal in the Explore tab, and click a service principal node. Note that the object ID and app ID are the same and that the app ID does not reflect the application ID noted in Entra ID.
Expected Behavior:
The application ID should be displayed in the app ID property of the service principal node entity panel.
Actual Behavior:
The object ID is displayed in the app ID property of the service principal node entity panel instead of the application ID.
Environment Information:
BloodHound: 8.1.0
Collector: AzureHound 2.4.1
OS: Windows 11
Additional Information:
https://specterops.atlassian.net/browse/BED-6431
Potential Solution (optional):
The issue is that the FetchServicePrincipalApplications function called by getServicePrincipalAppID function (https://github.com/SpecterOps/BloodHound/blob/main/packages/go/analysis/azure/service_principal.go#L58 ) gets the end node (the service principal) instead of the application (the end node) on this line: https://github.com/SpecterOps/BloodHound/blob/0c823b12f27b29aa36df0342a49769e20a107e99/packages/go/analysis/azure/queries.go#L567
Changing FetchEndNodes to FetchStartNodes resolves the issue.
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.
- Dominant language
- Go
- Stars
- 3.4k
- Forks
- 376
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 97
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SpecterOps/BloodHound
-
bug triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
SpecterOps/BloodHound#2806 · 1 comment ·
-
bug triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SpecterOps/BloodHound#2709 ·
-
bug triage
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
SpecterOps/BloodHound#2534 · 3 comments ·
-
bug needs more info triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
SpecterOps/BloodHound#1692 · 3 comments ·
-
Bug: UI renders Unicode bidirectional override characters in Distinguished Names (visual spoofing) Openbug triage
Difficulty 3/5 1-2 days Newbie friendliness 68/100
SpecterOps/BloodHound#3270 · 7 comments ·
All issues in SpecterOps/BloodHound
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100