​
Introduction and Architecture

Attack Paths are chains of abusable privileges and user behaviors that create direct and indirect connections between computers and users. They exist due to years of misconfigurations and a lack of visibility into how privileges are applied. Attack Paths cannot be patched through traditional methods because they are misconfigurations, not vulnerabilities.

SpecterOps built BloodHound Enterprise following the principles of Attack Path Management (APM). The primary goal of APM is to solve the Attack Path problem directly. APM is a fundamentally different, unique methodology designed to help organizations understand, empirically quantify the impact of, and eliminate Attack Path risks.

​
Single-Tenant Architecture Diagram

Customer Data Residency and Subprocessors

Customers may request that their tenant reside within one of the supported AWS regions below. Existing customers may request migration to an alternate region should residency needs demand.

  • United States: US-EAST-1 (Northern Virginia)
  • Canada: CA-CENTRAL-1 (Montreal)
  • Europe: EU-CENTRAL-1 (Frankfurt)
  • United Kingdom: EU-WEST-2 (London)
  • Australia: AP-SOUTHEAST-2 (Sydney)
  • Middle East: ME-CENTRAL-1 (UAE)

Additionally, BloodHound Enterprise utilizes Pendo to provide in-product tours and behavior monitoring. Customer data is not sent to Pendo. More information on Pendo’s data privacy, security policies, and certifications is available here.

​
AWS Datacenter Security

BloodHound Enterprise is hosted within AWS, which touts a litany of security certifications and is subject to regular audits and certifications. Certifications for AWS include ISO 27001, SOC 1 and 2, etc.

​
Customer Data Storage and Separation

​
Separation of Customer Data

BloodHound Enterprise is deployed in a single-tenancy model within AWS. Each customer environment is configured with its own database, API, and UI servers, and data is not commingled between customers.

Each tenant has unique authentication keys defined for authentication between services within the overall system.

​
Data Backup and Retention

Data backup occurs via Amazon EBS and Amazon RDS backup functionality. All backups are encrypted using the methods listed below in the Customer Data Security section.

All backups are retained for seven (7) days.

​
Customer Data Security

BloodHound Enterprise uses available Amazon encryption functionalities to encrypt all data using AES-256 with an Amazon-managed key. This applies to all servers in the BloodHound Enterprise infrastructure. Backup snapshots utilize the same encryption mechanisms.

AWS security groups isolate all BHE installations. They do not have permission to reach other customer assets.

More information on EBS volume encryption can be found here. Information specific to RDS volume encryption can be found here.

​
Network Communications

​
Web Browser and SharpHound/AzureHound connections

BloodHound Enterprise uses a shared AWS Application Load Balancer. The load balancer policy has been set to ELBSecurityPolicy-TLS13-1-2-2021-06. With this policy, BloodHound Enterprise:

  • Does not support SSL renegotiation for client or target connections.
  • Does not support custom TLS/cipher policies.
  • Enforces TLS v1.2 minimum.

​
Supported protocols

  • TLS v1.3
  • TLS v1.2

​
Supported ciphers

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES128-SHA256
  • ECDHE-RSA-AES128-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES256-SHA384
  • ECDHE-RSA-AES256-SHA384

More information on supported TLS policies can be found here.

​
Certificates

The Amazon certificate authority provides customer-facing TLS certificates. This CA is trusted by all major browsers and operating systems and includes:

  • RSA 2048 public key.
  • Automatic renewal on an annual basis.
  • Private keys are never exposed to SpecterOps. Amazon retains full control.

More information about the TLS certificates we use can be found here.

​
Authentication and Role-Based Access

​
Authentication Details

BloodHound Enterprise provides built-in authentication via username and password, with the option to enable TOTP-based multi-factor authentication.

Customers may additionally choose to enable SAML 2.0-based Single Sign-On to control authentication through an external, third-party provider such as Azure AD SAML, ADFS, or Okta. User access and role assignment are controlled within the BloodHound Enterprise product, and both SP- and IDP-initiated authentication flows are supported.

​
Local Authentication Specifications

​
Password Expiration and Complexity

All passwords configured locally expire every 90 days.

  • Passwords configured via local authentication require:
  • At least 12 characters in length
  • At least one lowercase letter
  • At least one uppercase letter
  • At least one number
  • At least one symbol (One of: !@#$%^&*)

​
Brute Force Resistance

Although BloodHound Enterprise does not lock a user out from attempted brute forcing, API calls against the BloodHound Enterprise authentication API are limited to one call per second, making a successful brute force attack impossible before a password rotation occurs.

All other API endpoints are limited to 55 calls per second.

​
Password Hashing

All passwords are hashed utilizing the Argon2id key derivation function with a unique 16-byte salt length per Argon2id recommendations. For more information on Argon2, see here.

​
Session Expiration

User-interface sessions expire after eight (8) hours.

​
Role-Based Access Control

BloodHound Enterprise User Roles

​
Third-Party Assessments and Certifications

​
Penetration Testing

BloodHound Enterprise undergoes annual penetration tests at a minimum.

Results from these tests can be made available upon request under NDA. All critical-, high-, and medium-risk findings have been remediated.

​
Certification

BloodHound Enterprise is included in the scope for the following certifications held by SpecterOps:

  • ISO/IEC 27001:2013 – Valid until April 15, 2026
  • ISO/IEC 27017:2015 – Valid until April 15, 2026
  • SOC 2 Type I - Certified June 12, 2023
  • SOC 2 Type II - Certified October 5, 2023

​
Patching

Operating system security patches are fetched daily and applied automatically. The rest of the BloodHound Enterprise infrastructure utilizes Amazon-provided services, and Amazon performs security patching automatically.

We follow security mailing lists, RSS feeds, etc., and periodically review for CVEs in supporting software we use in BHE environments.

​
Access to Data

Only the BloodHound Enterprise infrastructure engineers maintain persistent access to BHE environments. All SpecterOps employees must pass criminal background checks as a condition of employment.

In some instances, select developers are provided temporary access to systems for debugging purposes. This activity is monitored and logged. Access is revoked at the end of the event.

​
Logging and Monitoring

BloodHound Enterprise captures login and administrative actions within an Audit log that includes the following information:

  • Who attempted the action (user ID, user name, email)
  • What action was attempted
  • The status of the action (intent/success/failure)
  • When it occurred
  • Source IP(s) associated with the request

This information is available from the API of a running BloodHound Enterprise environment.

​
Data Collection Overview

For SharpHound, see SharpHound Data Collection and Permissions.

For AzureHound, see AzureHound Enterprise System Requirements and Deployment Process.