Let’s get one thing straight: This article is not at all a dig on BloodHound. BloodHound has been nothing short of revolutionary to the way attackers think about attacking large networks, and frankly, the way defenders should think about defending their network. It’s hard to overstate the impact BloodHound had on the infosec scene.
BloodHound visualizes the relationships between different entities and privileges in large networks and sheds light on ways to escalate privileges which are typically completely obscure to the administrators. It is applied only to Active Directory-based networks because virtually any large or mid-size organization in the west relies on Active Directory for identity and access management, but the underlying principles hold for any type of network with assets that are controlled by different identities.
Even though the idea of attack paths and thinking of access management as a mathematical graph precedes BloodHound, it has almost become synonymous to this idea.
But BloodHound does not paint the full picture. Some of the ideas presented here may seem far fetched, but they all have a precedent.
What is BloodHound?
Just so we are all on the same page, here is a quick summary of BloodHound.
BloodHound consists of essentially two components: the “ingestor”, a C# program which performs the data collection, and an electron app with a Neo4j back end. It inserts the data into the Neo4j database and visualizes queries as a graph.
Among many other things, the ingestor collects information about users, computers, groups, organizational units, group memberships (locally and in the domain) and active sessions. The electron app displays relationships between these objects and can be thought of as a route guidance system that can yield the shortest path from any object to the group of domain admins and much more. Here is an example path:
An example of a typical privilege escalation path in BloodHound
For more details, refer to the original blog post.
BloodHound for defenders
We know from leaks that real ransomware groups use BloodHound in an early stage of the attack; and we at SySS know from our own experience that any pentester worth their salt will run BloodHound to assess possibilities for lateral movement. If you, as a defender, want to be one step head, you must run BloodHound yourself regularly. The addendum “or a similar tool” would be appropriate here, but there simply is none. BloodHound provides such an invaluable insight into an Active Directory that one might wonder why Microsoft does not provide something like it for any paying customer without additional cost. Luckily, BloodHound is free and open source – even though there is an enterprise version if you prefer a payed solution – so you can get started right away. There are just a few things to consider.
First, the ingestor is considered malware by most endpoint protection solutions, even though it will not harm your computer or your network. You will have to create an exception for the ingestor.
Second, to get anything close to the full picture, i.e. to get the information about all sessions and local group memberships, you will need an appropriate service account. Starting with Windows Server 2019 or Windows 10 1709, authenticated users don’t have the necessary permission. But wait! Don’t use an account with full administrative permissions. We want to follow best practices and apply the principle of least privilege. Use group policies to assign the service account just the permissions to enumerate sessions and group memberships. Also, consider putting the account into the group “Protected Users” to make it immune to relay attacks. It will be connecting to all kinds of systems and who knows whether one of them is compromised. As a protected user, the BloodHound service account will be forced to use Kerberos, which makes certain attacks like NTLM relay impossible.
Tiering your network
According to Microsoft’s Enterprise Access Model (formerly known as the tier model), you should have at least three tiers. Meaning, the most powerful administrators in your organization need three different admin accounts on top of their regular user account. Each account must only access systems in their tier.
This mitigates lateral movement substantially, and the BloodHound graph of a properly tiered network will consist of at least three disconnected sections.
Not least because this requires special privileged access workstations, this often presents a Herculean task to most organizations. Nevertheless, it makes a lot of sense from a security perspective.
What’s next?
You successfully tiered your network according to the enterprise model and confirmed this with BloodHound? Great! Except …
BloodHound already knows dozens of edges, each of which represents a possibility to escalate privileges. In reality, there are much more. In fact, there are already projects which extend escalation paths in BloodHound. Let’s generalize the concept beyond the various access techniques of Active Directory.
Following the language of Microsoft’s official documentation on Active Directory and the language of Active Directory itself, BloodHound speaks of “user objects”. This is slightly misleading, because strictly speaking, the user is the person who is using the computer. What is meant by “user object”, is more accurately an account. It’s not a one-to-one mapping. A user can (and should, when employing the enterprise access model) have several accounts, and an account may not have any particular user associated with it. Instead, multiple users may have access to the account’s password. Those are often called service accounts, technical accounts or functional accounts. Administrators and pentesters alike often use the terms “user” and “account” interchangeably, but for the purpose of this article it’s important that we make this distinction. Also, it’s not always a user controlling an account – it can also be an attacker. Thus, we should speak of “persons” and “accounts”.
One person controlling several accounts
One account controlled by different persons
This is something BloodHound naturally cannot represent.
Now that we differentiate between those two, another attack vector becomes apparent: Persons with physical access to a machine should be assumed to have the possibility to gain administrative privileges on it, with one caveat. It becomes much harder when full disk encryption is used, of course, but depending on your threat model (“stolen laptop”, “‘evil maid’ attacks”, etc.) there are a host of attacks that you will still need to defend against:
- Cold Boot Attacks
- Direct Memory Access
- TPM Sniffing (see also here and our YouTube channel for a demonstration)
- Manipulating the boot loader
- Attacks on wireless input devices
Note that our computer is technically controlled by a keyboard, and the keyboard is controlled by the user/person. You left just the keyboard unattended in the wrong place? Well, now, the keyboard may be controlled by an attacker, too. For me personally, I lock my USB keyboard away along with my laptop when I leave the office. Wireless keyboards are banned entirely at SySS.
Something similar can be said about virtualization. Whoever controls the hypervisor controls the virtual machines that run on it. Sure, you can make a successful attack more expensive by deploying virtual TPMs and encrypt the virtual hard drives, but at the end of the day it’s the same situation as with physical access: whoever controls the (virtual) hardware controls the software on it. Have you made sure that no tier-1 administrator has access to the hypervisor hosting a tier-0 system? In other words, are there attack paths like in the following picture that BloodHound won’t show you?
An attack path involving hypervisor access
Another big issue that is regularly exploited during pentest engagements is password reuse. If you have successfully tiered your environment, and one admin chooses the same password for their tier-1 and tier-2 accounts, this may just be the vulnerability that causes your domain to fall. This is hard to represent with BloodHound because passwords are supposed to be secret, even though it is possible.
For a demonstration, see this YouTube video on SySS Pentest TV.
Password reuse between tiered accounts represents a sometimes overlooked escalation path
Password reuse is also a problem with local administrator accounts. Nowadays, it is easily solved by using LAPS, but we at SySS still find password reuse between machines regularly, which is often part of another escalation path that BloodHound cannot show you. Note that in reality this should be an undirected relationship, but for technical reasons BloodHound displays it as a directed edge.
Password reuse of the built-in admin account between different systems represents a much exploited escalation path that BloodHound does not show
Where do all your systems and appliances get their updates from? How big is your supply chain? They, too, have control that is not displayed by BloodHound. According to some, the SolarWinds hack was the largest attack up until then. Adversaries infiltrated SolarWinds and caused malicious updates to be distributed to SolarWinds customers, which ran their software on tier-0 systems. Lenovo arguably distributed malware on their laptops once, too.
Open source projects are not exempt either, by the way, as they can get hacked as well. Who controls your open source projects’ dependencies? How well did they choose their password? How diligent are they about keeping their MX record?
How trustworthy and how secure are your contractors (data centers, managed service providers, consultants, pentesters, and so on)? They often have high privileges and they, too, may have large networks with many attack vectors.
Beyond technical control
So far, we only considered technical or theoretical escalation paths. But security is hard in part because it always happens in the real, physical world, and abstractions are incomplete.
Hence, depending on your level of paranoia, we can go one step further, because control is not limited to the technical world. Who controls the person? At the minimum: their supervisor. Are they immune to extortion or bribes? Attackers have long since embraced the quite obvious and inelegant yet effective method of bribary, as shown by the so called LAPSUS$ gang. This attack vector is reminiscent of the rubber hose attack. Think about it: ransomware gangs can easily expect to get payed a seven digit sum after a successful hit. An investment of, say, a paltry $10,000 to bribe one employee into simply hitting WIN-R, CTRL-V, RETURN seems like a no brainer. Or into plugging-in a malicious USB drive. Can all of your employees resist?
How loyal are employees to their employer? Not just your employees, your contractor’s and vendor’s employees are relevant, too. Most famously, Edward Snowden arguably can be called a contractor’s administrator gone rogue.
And finally, the employer is typically bound to law enforcement in their country. Law enforcement follows orders of their government. Some became painfully aware of this after the beginning of Russia’s war on Ukraine. Note that in this particular case about Kaspersky there was no technical evidence that should concern anyone, but the mere possibility sufficiently contributes to the threat model that the BSI felt compelled to issue a warning. However, it is peculiar that the warning singled out Kaspersky instead of considering all Russian software products.
So our picture should look more like this (click right and open in a new tab):
A more realistic picture of the privilege escalation graph
At this point, anybody will have to realize that there will always be a residual risk. Our world is interconnected in manifold ways and we will always have to trust someone. You decide where the buck stops for you.
Not all edges are created equal
Not all is lost just yet. The world is not as black and white as a typical BloodHound graph may lead you to believe. It is still a mathematical abstraction of the real world and we can do a little bit better.
Let’s consider the edge CanRDP, as it is called in BloodHound, which means
that an account has the permission to log on to a system remotely with RDP.
But it doesn’t mean that the account has any sort of interesting permissions
on it, and without the necessary permissions it can’t steal credentials of
active or past sessions. BloodHound shows it anyway, since there is a chance
that the system is vulnerable to a local privilege escalation attack. Any
pentester will attest that this is actually the case from time to time, but
the likelihood of a successful attack is far from 100%.
Similarly, the edge AdminTo does not guarantee command execution on this
system. The attacker will still need to be able to reach a suitable service.
Appropriately defined firewall rules or a strict endpoint protection agent
may intervene, even though this is rare, so the likelihood of a successful
attack is close to 100%.
One of the few edge types that trivially ensures privilege escalation is MemberOf.
Sometimes it depends on more factors. Let’s consider the hypothetical
HasPhysicalAccess edge. With everything in its default configuration, the
risk we can assign to this edge type is very close to 100%, but with proper
hardening using full disk encryption in combination with a TPM in PIN mode
and a signed boot loader, it may be close to 0%. Not equal to 0%, though,
because of “evil maid” attacks.
This goes for any edge type, which makes our attack graph a directed and weighted graph. The likelihood of a successful execution of any given attack path is then the product of the likelihoods assigned to each edge. Some speak of “easiness of exploitation” (or its inverse, the “cost”), which stresses the offensive perspective, but you might just as well call it “risk” if you represent the defensive position.
Often, we can influence the easiness of exploitation, for example by employing multi-factor authentication. To reduce the risk of employees being bribed or blackmailed, you can introduce a four-eyes (or even six-eyes) principle, but this is rarely enforced at a fundamental level. Active Directory, the center and master of most corporations’ identity management, unfortunately knows neither MFA nor the four-eyes principle out of the box.
Everybody who has an interest in IT security has heard or said the old platitude: “Nothing is 100% secure.” It’s as true of a statement as it is useless. It can even be dangerous, as it can seduce us into submitting to defeatism. Let’s focus on the real challenge instead, which is to assess the risk, the potential damage and the cost to lower the risk, because only then can we decide if it is worth it to take action.
For example, we can probably all agree that the likelihood that Microsoft will roll out infected updates to our Windows systems is negligible (and if it does happen, then most likely because they were infiltrated, coerced by a government agency or became a hacking victim), while at the same time the cost of switching to something else is astronomic. Plus, it would simply shift the dependency elsewhere. Then again, the fact that the Chinese government seeks to ban Windows, or even all foreign made PCs emphasizes that threat models are entirely subjective. They evidently assign a much higher likelihood to the scenario that an OS manufacturer will roll out infected updates.
We are inching closer to a crucial question: How do we assign likelihoods to each edge? If you consider yourself a Bayesian, you will agree that everybody has different credences about each attack path. However, determining the likelihoods on edges in a particular organization’s attack graph shall be left for future research.
Conclusion
BloodHound focuses on Active Directory and these hypothetical edges are missing, because they represent real escalation paths exploited by real attackers:
SamePasswordSameAdminPasswordGuestMachineProvidesUpdatesTo
Taking the concept into the real world with all its physical and social aspects, the following hypothetical edges must be considered as well:
HasPhysicalAccessBribesBlackmailsSupervisesLawEnforcment
Last but not least, keep in mind that if you grant one single contractor access to your domain without sending out dedicated hardware, you are also trusting the contractor’s Windows domain, all vendors that supply updates to systems in that domain, all passwords that the vendors’ employees are using, that nobody falls for phishing or uses insecure passwords, that all their open source dependencies’ maintainers’ e-mail domains are handled securely, …