
BloodHound OpenGraph collector per GitHub che mappa la struttura organizzativa, le autorizzazioni e i percorsi di attacco cross-cloud in un grafo navigabile per audit di sicurezza e risposta agli incidenti.

GitHound è un collector OpenGraph di BloodHound per GitHub, progettato per mappare la struttura e le autorizzazioni della tua organizzazione in un grafico di percorsi di attacco navigabile. Esso:
Modella le Entità Chiave di GitHub
Visualizza e Analizza in BloodHound
Con GitHound ottieni un grafico chiaro e interattivo del panorama delle autorizzazioni GitHub—perfetto per revisioni di sicurezza, audit di conformità e rapide indagini sugli incidenti.
Per la documentazione dettagliata, consulta BloodHound Docs - GitHound.
# 1. Load the collector
. ./githound.ps1
# 2. Create a session with your Personal Access Token
$session = New-GitHubSession -OrganizationName "YourOrgName" -Token (Get-Clipboard)
# 3. Run the collection
Invoke-GitHound -Session $session
# 4. Upload the resulting githound_<orgId>.json file to BloodHound
Se la raccolta viene interrotta, riprendi da dove eri rimasto:
Invoke-GitHound -Session $session -Resume
GitHound supporta sia le sessioni con Personal Access Token sia le sessioni di installazione GitHub App. Il flusso di lavoro esistente per GitHub App con ambito organizzazione è invariato:
. ./githound.ps1
$session = New-GitHubJwtSession `
-OrganizationName "YourOrgName" `
-ClientId $clientId `
-PrivateKeyPath $privateKeyPath `
-InstallationId $installationId
Invoke-GitHound -Session $session -CollectAll
La stessa funzione può anche creare sessioni abilitate per l'enterprise:
. ./githound.ps1
$session = New-GitHubJwtSession `
-EnterpriseName "YourEnterpriseSlug" `
-ClientId $clientId `
-PrivateKeyPath $privateKeyPath `
-InstallationId $installationId `
-PersonalAccessToken $pat
Le sessioni abilitate per l'enterprise mantengono più contesti di autenticazione sulla GitHound.Session restituita:
Headers: gli header del token di installazione della GitHub App usati per la raccolta normaleJwtHeaders: gli header JWT della GitHub App usati per gli endpoint a livello di app, come l'enumerazione delle installazioniPatHeaders: header opzionali del Personal Access Token per i percorsi di raccolta che richiedono l'autenticazione con token utentePer enumerare le installazioni che appartengono alla GitHub App autenticata:
Get-GitHubAppInstallation -Session $session |
Select-Object TargetType, InstallationId, Login, Name, SuspendedAt
Il parsing dei workflow è ora integrato in Invoke-GitHound quando usi -CollectAll. Il collector:
GH_Workflow grezzi e i contenuti dei workflowGH_WorkflowJob e GH_WorkflowStepGH_CanPwnRequest e GH_CanDispatchTogithound_<orgId>.jsonPer scopi di ripresa/debug, il checkpoint intermedio dell'analisi dei workflow viene scritto come githound_WorkflowAnalysis_<orgId>.json.
GitHound ora include una base minima di raccolta enterprise tramite Git-HoundEnterprise. Questo collector attualmente crea:
GH_EnterpriseGH_Organization per le organizzazioni membroGH_Contains dall'enterprise alle sue organizzazioniLa raccolta degli utenti enterprise tramite Git-HoundEnterpriseUser aggiunge:
GH_UserGH_HasMember dall'enterprise a quegli utentiLa raccolta SAML enterprise tramite Git-HoundEnterpriseSamlProvider aggiunge:
GH_SamlIdentityProviderGH_ExternalIdentityGH_HasSamlIdentityProvider dall'enterprise al providerQuesto percorso richiede una sessione basata su PAT perché GitHub espone il SAML enterprise tramite enterprise.ownerInfo.
La raccolta dei team enterprise tramite Git-HoundEnterpriseTeam aggiunge:
GH_EnterpriseTeamGH_AssignedTo dai team enterprise alle organizzazioni assegnateGH_MemberOf dai team enterprise ai nodi GH_Team ent: visibili all'org usando il matching delle proprietàmembers dei team enterprise e archi GH_HasRole dagli utenti a questi ruoliLa raccolta dei ruoli enterprise tramite Git-HoundEnterpriseRole aggiunge:
GH_EnterpriseRoleGH_Contains dall'enterprise a questi ruoliGH_HasRole dagli utenti assegnati direttamente e dai team enterpriseowners predefinito popolato da enterprise.ownerInfo.admins quando i dati admin enterprise basati su PAT sono disponibiliPer ora, le stringhe grezze delle autorizzazioni enterprise sono conservate sul nodo GH_EnterpriseRole nella sua proprietà permissions invece di essere espanse in archi di autorizzazione dedicati.
La raccolta SCIM enterprise attualmente aggiunge:
SCIM_UserSCIM_GroupSCIM_Provisioned da SCIM_User a GH_ExternalIdentitySCIM_Provisioned da SCIM_Group a GH_EnterpriseTeam quando GitHub espone il group_id del team enterpriseSCIM_MemberOf da SCIM_User a SCIM_GroupQuesto offre a GitHound un ponte indipendente dal provider dallo schema SCIM condiviso al modello nativo di identità e team enterprise di GitHub.
Quando un GH_SamlIdentityProvider raccolto identifica l'IdP a monte, GitHound può anche aggiungere archi di correlazione SCIM consapevoli del provider nell'output sidecar SCIM:
Okta_User -> SCIM_User
Okta_User.id = SCIM_User.externalIdOkta_Group -> SCIM_Group
Okta_Group.name = SCIM_Group.externalIdOkta_Group.oktaDomain = GH_SamlIdentityProvider.foreign_environmentidGitHound mantiene il layer SCIM nel proprio output sidecar, così queste mappature restano visibili senza mescolare i nodi nativi SCIM nel grafico enterprise principale nativo di GitHub:
githound_<entId>.json contiene i dati enterprise nativi di GitHubgithound_scim_<entId>.json contiene i nodi nativi SCIM e gli archi ponte SCIMgithound_saml_<entId>.json contiene i dati SAML e delle identità esternegithound_hybrid_<entId>.json contiene gli archi tra modelli come SAML_Implements, SAML_HasAccount e GH_SyncedTogithound_saml_<entId>.json contiene anche la topologia SAML normalizzata per il service provider GitHub, inclusi SAML_TrustsIssuer e SAML_HasAssertionConsumerServiceIl modello nativo del provider di identità GitHub rimane intatto negli output nativi GitHub/SAML:
GH_ExternalIdentityGH_HasExternalIdentityGH_MapsToUserIl layer SAML normalizzato in githound_hybrid_<entId>.json ora colloca SAML_HasAccount direttamente su GH_User, derivando match_values dalle proprietà SAML della GH_ExternalIdentity collegata, come saml_identity_name_id e saml_identity_username.