Case Study 1: BloodHound by SpecterOps --- Revolutionizing AD Attack Path Analysis

And Kerberoasting in the SolarWinds Attack

Part I: BloodHound --- From Research Project to Industry Standard

The Problem Before BloodHound

Before BloodHound's release in 2016, Active Directory security assessment was a painstaking manual process. Penetration testers would enumerate users, groups, permissions, sessions, and delegation settings individually, then attempt to mentally piece together attack paths. In a large enterprise with tens of thousands of objects and millions of ACL entries, this was practically impossible to do comprehensively.

Defenders faced the same challenge in reverse. Security teams had no way to visualize the complex web of relationships in their AD environments, making it impossible to proactively identify and remediate attack paths before adversaries found them.

The Innovation

In 2016, Andrew Robbins, Rohan Vazarkar, and Will Schroeder at SpecterOps released BloodHound, fundamentally changing both AD offense and defense. Their insight was elegant: Active Directory is a graph---objects are nodes, and relationships (group memberships, admin access, sessions, ACLs) are edges. By collecting this data and analyzing it with graph theory, they could automatically discover attack paths that no human could find manually.

BloodHound consists of three components:

  1. SharpHound (Collector): A C# data collector that enumerates AD relationships via LDAP, SMB, and RPC. It gathers group memberships, local admin relationships, active sessions, ACLs, trust relationships, and more.

  2. Neo4j (Database): A graph database that stores the collected data as nodes and edges, enabling rapid path-finding queries.

  3. BloodHound (UI): A web interface built on Electron that visualizes attack paths and provides pre-built queries for common attack scenarios.

How BloodHound Finds Attack Paths

Consider a scenario in the MedSecure environment:

Standard User: j.smith
  |
  |--> Member of "IT Support" group
         |
         |--> Local Admin on WS01, WS02, WS03
                |
                |--> admin.backup has active session on WS03
                       |
                       |--> Member of "Backup Operators"
                              |
                              |--> GenericAll on "Domain Admins" group

A human reviewing AD manually would need to: 1. Check j.smith's group memberships 2. Check where "IT Support" has local admin 3. Check who has sessions on those computers 4. Check each of those users' permissions 5. Trace the chain to a privileged target

BloodHound does this automatically across every object in the domain simultaneously, identifying all possible attack paths.

Impact on the Industry

BloodHound's release had a dual impact:

For Attackers/Red Teams: - Reduced AD enumeration from hours to minutes - Automatically identified attack paths invisible to manual analysis - Prioritized targets based on graph distance to Domain Admin - Became a standard tool in every serious penetration test

For Defenders: - Provided visibility into AD attack surfaces for the first time - Enabled proactive remediation of attack paths before exploitation - Created a common language for discussing AD security risks - Spawned an entire ecosystem of AD security tools

BloodHound in the MedSecure Engagement

During the MedSecure engagement, BloodHound revealed an attack path the team would likely never have found manually:

j.smith --> Local Admin on WS03 (via IT Support group)
  --> Harvest svc_ehr credentials (active session on WS03)
    --> svc_ehr has GenericWrite on ehr-db01$ computer account
      --> Set RBCD on ehr-db01$ (Resource-Based Constrained Delegation)
        --> Impersonate Administrator to ehr-db01
          --> ehr-db01$ has DCSync rights (misconfiguration)
            --> DCSync --> krbtgt hash --> Golden Ticket

This five-hop attack path, involving RBCD and an obscure DCSync misconfiguration, would have been nearly impossible to identify through manual enumeration alone. BloodHound found it in seconds.

Part II: Kerberoasting in the SolarWinds Attack

The SolarWinds Context

The SolarWinds supply chain attack (APT29/Cozy Bear) is the most sophisticated publicly documented cyberattack in history. While the initial access was through the SUNBURST backdoor implanted in SolarWinds Orion software, the attackers' movement through victim networks employed classic Active Directory attack techniques---including Kerberoasting.

How APT29 Used Kerberoasting

After the SUNBURST backdoor provided initial access to victim networks, the APT29 operators needed to escalate their privileges within Active Directory. According to analysis by Microsoft's Detection and Response Team (DART) and FireEye/Mandiant, the attackers employed Kerberoasting as one of their credential harvesting techniques.

The process in victim environments:

  1. Foothold Establishment: SUNBURST provided code execution as the Orion service account on the SolarWinds server. Since Orion monitors infrastructure, the server was typically domain-joined and the service account had authenticated domain access.

  2. SPN Enumeration: The attackers queried LDAP for user accounts with Service Principal Names set, identifying Kerberoastable accounts.

  3. Ticket Requests: Using the Orion service account's Kerberos access, the attackers requested TGS tickets for identified service accounts.

  4. Offline Cracking: The encrypted tickets were exfiltrated and cracked offline against password lists. Given the resources available to a nation-state actor, even moderately complex passwords were vulnerable.

  5. Credential Leverage: Cracked service account credentials provided lateral movement to additional servers and services within the victim network, eventually leading to domain administrator access.

Why Kerberoasting Was Strategically Chosen

APT29's use of Kerberoasting was strategically sound:

  • Low Detection Profile: Kerberoasting generates legitimate Kerberos traffic. Requesting service tickets is a normal operation that blends into baseline authentication activity.
  • No Direct DC Attack: Unlike brute force or credential stuffing, Kerberoasting does not generate failed authentication events on the domain controller.
  • Offline Cracking: All password cracking happens on the attacker's infrastructure, producing zero network traffic and zero log entries during the cracking phase.
  • Scalable: Once authenticated, the attacker can request tickets for every service account in the domain, maximizing the chance of finding a weak password.

Detection Gaps

In many victim organizations, Kerberoasting was not detected because:

  1. Lack of monitoring: Most organizations did not monitor Event ID 4769 (TGS request) for anomalous patterns.
  2. Encryption type blindness: Even organizations monitoring Kerberos events did not filter for RC4 encryption type (0x17), which is the primary indicator of Kerberoasting.
  3. Service account hygiene: Many organizations had service accounts with passwords that had not been changed in years, making offline cracking trivial.
  4. No baseline: Without a baseline of normal TGS request patterns, anomalous bursts of requests went unnoticed.

🔵 Blue Team Perspective

BloodHound for Defense

Organizations should run BloodHound against their own environments proactively: - Schedule regular BloodHound collections and analysis - Use BloodHound to identify and remediate high-risk attack paths - Track the number of attack paths over time as a security metric - Use BloodHound's data to prioritize AD hardening efforts - Consider BloodHound Enterprise for continuous monitoring

Kerberoasting Defense

  1. Group Managed Service Accounts (gMSAs): Use gMSAs for all service accounts. They have 120-character random passwords rotated automatically every 30 days.
  2. Password Policy for Service Accounts: If gMSAs are not possible, enforce minimum 25-character passwords with regular rotation.
  3. Monitor Event ID 4769: Alert on TGS requests with encryption type 0x17 (RC4) from user accounts, especially when multiple tickets are requested in a short timeframe.
  4. Reduce SPN Exposure: Remove unnecessary SPNs. Regularly audit which accounts have SPNs and whether they need them.
  5. Honeypot Accounts: Create service accounts with SPNs but strong passwords and no real service. Any TGS request for these accounts indicates Kerberoasting activity.
  6. AES-Only Authentication: Configure service accounts to only support AES encryption, making cracking significantly harder.

Deploying BloodHound Defensively

# Regular defensive BloodHound collection
.\SharpHound.exe -c All -d yourdomain.local --stealth

# Key defensive queries:
# "Find Shortest Paths to Domain Admins" -- remediate these first
# "Find Kerberoastable Accounts with Most Privileges" -- priority for gMSA migration
# "Find Computers where Domain Users are Local Admin" -- remove this immediately
# "Find Principals with DCSync Rights" -- audit for non-default entries

Discussion Questions

  1. BloodHound is freely available to both attackers and defenders. Do you believe its release has been a net positive or negative for overall security? Why?
  2. Why do organizations continue to use traditional service accounts with weak passwords when gMSAs have been available since Windows Server 2012?
  3. How could the SolarWinds victim organizations have detected Kerberoasting in real-time, given that the traffic appears legitimate?
  4. What is the ethical responsibility of security tool developers when their tools can be used offensively?
  5. How should organizations prioritize the remediation of BloodHound-identified attack paths when they have hundreds of findings?

References

  • SpecterOps: "An Introduction to BloodHound" (Original release blog post)
  • Andrew Robbins, Rohan Vazarkar, Will Schroeder: BloodHound GitHub Repository
  • Microsoft DART: "Analyzing Solorigate" technical analysis
  • FireEye/Mandiant: "SUNBURST Additional Technical Details"
  • Tim Medin: "Attacking Kerberos: Kicking the Guard Dog of Hades" (DerbyCon 2014, original Kerberoasting talk)
  • Sean Metcalf (AD Security): "Kerberoasting Without Mimikatz"
  • CISA: Alert AA21-008A on SolarWinds response