Introducing BloodHound 4.2 — The Azure Refactor
The BloodHound Enterprise team is proud to announce the release of BloodHound 4.2 — The Azure Refactor.
This release includes the following major features:
A ground-up rewrite of AzureHound in Golang
12 new and/or improved abuse edges
The introduction of post-processing in FOSS BloodHound
Important note: BloodHound 4.2 requires a minimum version of Neo4j 4.4.
Read on for more details about this release:
New Attack Primitives with More on the Way
This release includes several new abuse edges and improves on existing edges by adding coverage for more Azure objects. In total, we have 12 edges in this release that are either brand new or have been significantly improved:
You can find the full details for all these edges in the updated ReadTheDocs. Let’s take a closer look at a few of the above edges:
Thanks to some very interesting research by Dirk-jan Mollema from Outsider Security, BloodHound now includes another Resourced Based Constrained Delegation (RBCD) vector with the WriteAccountRestrictions edge. Dirk-jan found that the “Write Account Restrictions” property set in Active Directory includes the ability to write to the “ms-DS-AllowedToActOnBehalfOfOtherIdentity” property, which allows you to perform the RBCD attack.
Functionally, this edge is similar to the AddAllowedToAct edge that already exists in BloodHound, but uses a new edge name to indicate that the permissions are coming from a different source. You can read more about the property in Dirk-jan’s fantastic blog post.
Thanks to some phenomenal work by Simon Décosse, BloodHound now includes attack paths where a principal can read the clear-text password for a computer by having both the DS-GetChanges and DS-GetChangesInFilteredSet privileges.
This edge is also the product of a new feature in BloodHound FOSS called post-processing, which you can read about further down in this blog post.
For a long time it has been frustrating to work with attack path results in BloodHound that include “GetChanges” or “GetChangesAll” edges, but not both — false positive attack paths where you’ve got one half of the privileges you need to perform a DCSync attack.
Similar to SyncLAPSPassword, the DCSync edge is the product of a new feature in BloodHound called post-processing. The end result is faster collection, easier analysis, and the elimination of false positives in attack paths.
Azure environments are chock full of attack paths, and as the industry studies and develops tradecraft around those attack path possibilities, we are working hard to incorporate those as nodes and edges in the BloodHound graph. One of the most exciting abuse primitives centers on taking advantage of managed identity assignments.
BloodHound will now track managed identity assignments between Virtual Machines and service principals. We are starting with Virtual Machines, but will soon be adding collection capabilities for several other Azure objects as well.
More Edges Coming
We have a lot more edges coming. This release lays the foundation for us to be able to add edges in the future at a much faster rate. We are hoping to release updates soon that include edges focused on abusable MS Graph app roles, more objects with managed identity assignments, more Azure abuses around user logons, and on-prem AD abuses including ADCS.
Ground-up Rewrite of AzureHound
There’s no denying it: the legacy version of AzureHound was painfully slow. So slow, in fact, that the initial authentication you did against Azure could easily expire before data collection could even finish. Legacy AzureHound also had many problems that made it a poor solution for how we support our BloodHound Enterprise customers:
It required user interaction to authenticate
That user interaction could not be done in a headless context
Deploying on non-Windows boxes required frustrating setup and ongoing maintenance
All of these problems and more are why we decided to fully rewrite AzureHound in Golang for our BloodHound Enterprise customers. Today we are releasing this fully rebuilt AzureHound as free and open source software, with several features that are purpose-built for our red team users:
Flexible authentication options. You can authenticate with a username/password combo, a service principal certificate or secret, a JWT, or refresh token.
Filtering your data collection by tenant, management group, or subscription. Further filter your collection to atomic object types, and even to particular abuse types.
Feed output to one JSON file for easy import into the BloodHound database.
AzureHound is also insanely fast now. Thanks to language, architecture, and design choices made by its primary author, Dillon Lees, coupled with the introduction of post-processing, AzureHound is now at least 5 times faster than its predecessor:
Major Contributions from BloodHound Users
We want to express our deep gratitude to Jonas Lieb at RedTeam Pentesting for an amazing pull request he made to BloodHound. This PR from Jonas corrects a major cross-site scripting vulnerability in the FOSS BloodHound GUI. Thank you, Jonas!
Dirk-jan Mollema at Outsider Security published some outstanding research regarding a different way to get write access on an important property in Active Directory that enabled RBCD. Thank you very much, Dirk-jan for publishing this research and for helping us get this into BloodHound as a new edge!
Simon Décosse submitted an absolutely phenomenal PR all about a novel abuse primitive. This is likely the best PR we have ever received of this type, as it included all the necessary changes to all parts of the product to bring it up to fully supporting a new abuse primitive — the ability to synchronize LAPS passwords without needing full DCSync rights. Thank you very much for this amazing PR, Simon!
The Introduction of Post-Processing into FOSS
When we first introduced it in 2016, BloodHound found attack paths based on three things:
Who had local admin rights where
Who was signed on to what computer
Who belonged to what security groups
Our graph model at that time was extremely simple. Just three types of nodes and three types of edges:
Despite its simple look, even then we had to be very careful with how we designed BloodHound’s cypher queries in order to keep the application performant.
Over the years this graph model has substantially grown in scope and complexity. With the ACL Update, the Container Update, BloodHound 2.0, BloodHound 3.0, BloodHound 4.0, 4.1, and today’s update, the graph model now looks like this:
This is just the design of the graph. Real graphs often have tens or hundreds of thousands of nodes and millions or billions of relationships.
This growing complexity presents unique challenges with maintaining a performant application while also letting users get tons of value out of the product without needing to become experts in the underlying mechanics of Active Directory, Azure Active Directory, and the other systems we model.
The solution to these problems and a few others is something we call “post processing”. I’m not going to go in-depth on how post processing works here, but the outcomes you will experience as a user from this behind-the-scenes feature include better performance, better context-specific queries, and fewer false positives in attack paths. I’ll go into the specifics of how post-processing works in an upcoming Twitter thread or blog post.
BloodHound 4.2 represents a big milestone, as it is the second major update to the FOSS product to incorporate features and code from BloodHound Enterprise. This release not only dramatically improves BloodHound’s enumeration and attack path analysis capabilities for Azure, but it also serves as a major foundation for faster improvement of the FOSS product going forward.
Stay in touch with us by joining the BloodHoundGang Slack.
Introducing BloodHound 4.2 — The Azure Refactor was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.
Leer másSecurity Boulevard