BloodHound

Bloodhound

LACheck supports writing AdminTo and Session collected into json output that can be uploaded to BloodHound

This output is only meant to augment an existing BloodHound collection with updated Administrative privileges for a single user and Sessions collected from hosts that Administrative privileges have been identified

The /bloodhound switch will write a randomly-named encrypted zip file to disk which can be downloaded, extracted, and uploaded to BloodHound

The output file will attempt to write the file to the following directories:

1. current directory
2. current user's temporary directory
   1. i.e.: C:\Users\<user>\AppData\Local\Temp\
   2. does not correlate the impersonated user context for Cobalt Strike's make_token or kerberos_ticket_use
3. C:\Users\Public\

/user

BloodHound requires resolving users and computers to SIDs. Due to impersonation techniques such as Cobalt Strike's make_token and kerberos_ticket_use, LACheck may not be able to accurately determine the user context for a collection. The /user arguement is required to supply LACheck with the userprincipalname (format = [email protected]) of the context it is ran under in order to accurately correlate the collection information.

Correlation

AdminTo

The /user flag specifies the current user that enumeration is running under.

Due to impersonation methods such as Cobalt Strike's make_token and kerberos_ticket_use, it is difficult to accurately determine the current user's context and it must be explicitly specified.

BloodHound correlates objects by their SID; LDAP is queried based upon the provided userprincipalname from the /user flag to return the SID for the account.

Note

Currently, accounts built-in Administrators and Managed Service Accounts that do not have userprincipalname attributes are unable to accurately query for their SID and are not supported for accurate AdminTo relationships in BloodHound.

Sessions

Users are returned from LDAP for all parent/child domains of the current Active Directory forest and stored in a dictionary of userprincipalname:SID key value pairs.

userprincipalname format = [email protected]

For accounts such as built-in Administrators and Managed Service Accounts that do not have userprincipalname attributes, the following conversion is done to construct their key:

• samaccountname is used for the username
• The domain name is extracted from the DC fields of the user's DistinguishedName
  • i.e.: CN=Administrator,CN=Users,DC=dev,DC=contoso,DC=com
  • fqdn = dev.contoso.com

Every user from enumerated sessions is then searched for against the key value pairs of domain accounts.

Session enumeration often return NETBIOS names rather than FQDNs which are necessary for userprincipalname format.

In order to resolve this mismatch, any userprincipalname formats are converted to NETBIOS username format using Active Directory Service Interfaces ADS_NAME_TYPE_ENUM.

All enabled users pulled from LDAP in order to correlate their SIDs for BloodHound-compatible output are stored in a dictionary of key:value pairs consisting of their NETBIOS username and their SID.