What is Attack Path Management?

Microsoft Active Directory and Azure Active Directory are directory service products that provide several critical services to organizations: identity and access management, endpoint management, business application management, and much, much more.

Organizations See Active Directory as:

FOUNDATIONAL

Active Directory is the foundation upon which access is managed for endpoint management services, identity and authentication services, email authentication, and critical business operations are built, making it one of — if not THE most — critical services used by organizations of all sizes.

UBIQUITOUS

Active Directory is by far the most widely used directory service product. Banks, government and military agencies, retailers, small businesses, and the vast majority of the Fortune 500 use Active Directory³. That ubiquity comes with several benefits for organizations, including a rich community to get support, a highly mature Active Directory management and engineering training ecosystem, and a large talent pool filled with thousands of professionals with years (even decades) of experience in Active Directory.

POWERFUL

Active Directory includes several powerful features that simplify user and endpoint management, increase uptime, and streamline the endpoint user experience. Features like security group delegation, Group Policy, and domain trusts enable Active Directory admins to organize and control the IT environment so that it best serves the requirements of the organization.

Adversaries See Active Directory as:

FOUNDATIONAL

Because the entire organization is tied into Active Directory, an attacker can gain control of any computer, any user, any business process by first taking control of Active Directory.

UBIQUITOUS

Because Active Directory is so widely used, an attacker can invest time, money, and effort into developing their skills at attacking Active Directory, and then use those same skills and tools to attack almost any organization.

POWERFUL

The features that make Active Directory so powerful from the administrative side are the very same features that attackers love to abuse. Some of the most widely used tools for attacking Active Directory (BloodHound, Mimikatz, Responder) do not use exploits, but abuse features in Active Directory and Windows instead.

³ https://ww2.frost.com/frost-perspectives/active-directory-holds-the-keys-to-your-kingdom-but-is-it-secure/

Adversaries have been targeting Active Directory for decades, and there are at least 5 major reasons why they continue to love targeting Active Directory today:

Active Directory Security Issue #1: Unmatched Payoff

Taking control of Active Directory is not the end goal for any adversary. Adversaries’ true objectives range from industrial/nation-state espionage to ransomware deployment, and everywhere in between. While taking control of Active Directory is not the end goal, no other adversary tactic provides the guarantee of achieving the true objective that taking control of Active Directory does. Why is this?

When an endpoint is joined to Active Directory, several mechanisms allow the administrators of Active Directory to take control of that⁴ endpoint — this is, of course, by design. For example, organizations use this control to perform tasks across all endpoints in an enterprise like installing anti-virus, configuring local security policies, or controlling other business software installed on endpoints. The mechanisms that enable all of this can be abused to take control of the endpoint. Once an endpoint is joined to Active Directory, the scope of who controls the endpoint is no longer controlled by the endpoint itself.

But even when a system is not joined to Active Directory, Active Directory may still be used to validate the identity of a user with access to that system. Think of technologies like RADIUS or SSO — Active Directory validates the user for the system, and then the system grants the user access. For the adversary, this means that gaining control of the identity authority (Active Directory) almost always means taking over any system, user, business process, data, etc.

For the adversary, it couldn’t be more clear: no matter what you want to achieve, control of Active Directory will get you there. This makes Active Directory an extraordinarily attractive target for every adversary.

Active Directory Security Issue #2: Common Weakness

There is one common weakness across all Active Directory environments that spells disaster for the enterprise’s security posture: Windows and Active Directory make it nearly impossible to effectively and accurately audit permissions. Whether that means permissions on an Active Directory object, or local administrator rights on a computer, or even effective rights granted to a security group, Windows and Active Directory are not designed to answer questions like, “How many users have administrator rights on this computer?”

⁴ https://www.slideshare.net/harmj0y/derbycon-the-unintended-risks-of-trusting-active-directory

Windows will only report which principals⁵ have a direct “admin rights” relationship to a computer or object. In reality, a computer can have hundreds, thousands, even tens of thousands of administrators thanks to nested security groups.

⁵ https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-principals

This lack of clarity regarding permissions, coupled with the extraordinarily rare usage of endpoint firewalls and the near-universal ubiquity of Active Directory means adversaries can use the same fundamental tactics to attack almost any organization. An adversary can master the techniques for attacking Active Directory once, then use that mastery anywhere.

These weaknesses are so common, reliable, and consistent, that they have enabled offensive tooling that is just as common, reliable, and consistent — offensive security tools like Mimikatz, Responder, and PowerView.

Active Directory Security Issue #3: Detection is Hard, Evasion is Easy

There’s a common phrase in the information security field: “Defenders have to be right every time, but attackers only have to be right once.” This is of course a gross oversimplification of reality, but it rings true when talking about detecting malicious behavior used in the course of an Attack Path. Because adversaries often use built-in, legitimate administrative tools and abuse existing privileges and permissions in Active Directory, it’s very difficult for defenders to tell the difference between “good” admin behavior and “bad” admin behavior.

Consider a help desk user who logs in to dozens, maybe even hundreds of systems every week. This user may use different administrative tools to do their work, may frequently log into systems for the first time, and may perform privileged tasks on the system. Hundreds of logons, multiplied by hundreds of generated events and artifacts — it’s no wonder adversaries can slip under the radar by “living off the land”⁶.

Looking past the easy tactic of slipping under the radar, there is an entire world of defensive evasion techniques. From evading static hash detection by changing a bit of code, to disabling endpoint security solutions⁷ — adversaries have a very wide set of tactics at their disposal to evade detection, no matter how sophisticated that detection capability.

Active Directory Security Issue #4: Deep Persistence Options

Whether working toward short-term or long-term goals, adversaries need to maintain persistence in the network to avoid operational disruption. With low levels of privilege, adversaries are limited on their persistence mechanism options, and are forced to use options which may be easier for defenders to identify. But with high levels of privilege, persistence options become much greater, and can be much harder for defenders to find and eliminate.

The adversary doesn’t need to constrain themselves to “Domain Admins” when installing persistence. Domain Admin means control of every system, and control of a system means control of the kernel. Most defenders today already struggle with detecting commodity-level persistence mechanisms like malicious scheduled tasks, and the vast majority are not equipped or staffed to handle kernel-level persistence mechanisms.

To complicate detection efforts even further, control of Active Directory means control of the operating system on every domain-joined machine, including domain controllers. Because most detection and threat hunting systems rely on information coming back from the operating system, an adversary with control of the operating system itself can defeat some detection and threat hunting efforts with one simple tactic: lying. More specifically, with control of the operating system, the adversary can cause the same pieces of the operating system queried by defenders to report everything is A-OK.

⁶ https://docs.google.com/presentation/d/1UcDGg2NV432tC8qmbCQkcsHc5ANK08XLXRVID2i5fZA/embed?start=false&loop=false&delayms=3000&slide=id.p15
⁷ https://www.zdnet.com/article/ransomware-installs-gigabyte-driver-to-kill-antivirus-products/

Active Directory Security Issue #5: Unlimited Retries

The SpecterOps Red Team has been lucky enough to face some of the best Security Operations Center (SOC), Digital Forensics and Incident Response (DFIR), and threat hunting teams in the world. These are world-class professional defenders who are on the cutting edge of detection and response for adversary Tactics, Techniques and Procedures (TTP). They have to be — they are specifically targeted and attacked every hour of every day.

But no organization has perfect security, and oftentimes we find well-funded SOCs are partly there to make up for other weaknesses in the bigger IT security picture. For the adversary, this means it may be simple to gain initial access into such an organization, but the slightest OPSEC mistake from the attacker, such as writing a well-signatured binary to disk, virtually guarantees getting caught and kicked out. Does that mean the adversary is shut out forever? Of course not.

Every time an adversary regains access into a well-defended network is another opportunity to learn more about the network and Attack Paths mapping — Attack Paths that grow and remain unseen and unmanaged every day. It may only take one or two rounds of Attack Path data collection on the adversary’s part to discover an Attack Path to their objective. While adversaries certainly do not enjoy needing to rebuild phishing, payload hosting, and command and control infrastructure, the juice is worth the squeeze — the adversary gets and uses unlimited retries to attack Active Directory.

Over the past twenty years, Vulnerability Management (VM) has matured into a critical pillar in enterprise IT security. The sheer volume of software vulnerabilities in the 2000s and 2010s necessitated the creation of vulnerability management platforms, and vulnerability management programs to validate the effectiveness of an organization’s patching and secure configuration practices.

Attack Path Management (APM) is a different solution for a different set of problems than Vulnerability Management (VM).

Patches vs. Privileges

Software vulnerabilities have been, are, and will continue to be a big problem. While vendors are getting better at producing software with fewer bugs, they’re never going to produce bug-free code — nor should they be expected to. But new software isn’t the only risk here — old software, or old code that new software is written on top of, can also have exploitable bugs just waiting to be found. For this reason, organizations must be able to react to software vulnerabilities by testing, deploying, and auditing patches, as well as mitigating risks on systems where patches can’t be deployed.

Vulnerability Management (VM) solutions provide specific vulnerability risk using the Common Vulnerability Scoring System (CVSS). While vulnerabilities are an arrow in an adversary’s quiver, they come at a cost. First, each exploit leaves bread crumbs which defenders can find; potentially risking the adversary’s network access, exploit, or both. Second, developing, aggregating, and maintaining an exploit is time consuming for the adversary. Last, the use of exploits to pivot / move through a network is commonly time-consuming.

In contrast, an adversary with mastery of attacking Active Directory can gain privileges and move freely on Attack Paths leaving minimal risk of discovery from defenders, achieving persistence, and gaining the keys to the kingdom. For this reason, adversaries prefer to use exploits only when necessary and default to Attack Paths.

Attack Paths have plagued organizations for decades. SpecterOps has observed several patterns emerge across hundreds of organizations that explain why they have historically been unable to manage Attack Paths:

The Least Privilege Pipe Dream

When people talk about the “Tough exterior and soft interior”, they are often referring to the fact that while the perimeter controls are hardened and given appropriate attention, the situation inside the perimeter is very, very bad (i.e., full of Attack Paths). Most commonly, this is because the organization has lost control over Windows and Active Directory permissions, which have created critical Attack Paths linking every user and computer in the environment into the most highly sensitive systems and highly privileged principals — a group of assets known as Tier Zero in the Tiered Administration model.

Enter Least Privilege¹⁰ — the foundational security control that absolutely no one implements. But it’s not for a lack of trying or any professional shortcoming of the administrators. Least Privilege has historically been out of reach for several reasons. Why? Because the very opaque nature of how privileges are granted in Windows and Active Directory, and how that opaqueness precludes even the most talented administrators from effectively auditing privileges at scale. For an admin to effectively implement least privilege, they must perfectly understand all of the following elements of every privilege that exists in the environment:

Question #1: Is this an abusable privilege or not?

Answer: The answer to #1 is always going to be either, “I don’t know”, “Yes”, or “No”. But with new Attack Path analysis and research coming out all the time, that last “No” almost may as well be “Not Yet”. Answering this question for dozens of privileges across thousands, tens of thousands, even hundreds of thousands of assets requires appropriate, up-to-date tooling — tooling that historically has been unavailable to administrators or simply didn’t exist yet.

Question #2: Who has been granted this privilege?

Answer: The answer to #2 can be very deceiving because of security group nesting. A security group with a privilege is represented by one privilege. But that security group may in reality have dozens, thousands, even hundreds of thousands of principals added to it via security group nesting. Unrolling those group memberships by hand once is enough to make most administrators give up on the whole idea of auditing privileges at all. To make matters worse, users and computers and groups are being added to and removed from groups all the time, so the fruits of that manual group unrolling process quickly become out-dated.

Question #3: Is this privilege required?

Answer: The hardest question of all is #3. Ask any software vendor whether their software really needs local admin rights, and they’ll almost always tell you, “Yes”. Ask any IT admin or business app owner if their service account really needs a particular permission, and they will almost always tell you the same thing. But as many of us know, granting liberal permissions like this is the easy way to ‘Just Make It Work’. Despite this, providing that a particular privilege is not required is actually much easier said than done. Proving you won’t break something by removing a certain privilege is actually very difficult. Not many organizations are going to want to implement a security “fix” that may cripple a business critical application.

This endless loop of non-starters prevents the vast majority of organizations from ever really achieving effective least privilege enforcement. Yes, an organization may achieve least privilege on a particular set of systems or use logical network rules to mitigate privilege abuse. However, the reality is that Attack Paths persist, grow, and go unmanaged — flying in the face of almost every least privilege accomplishment an organization has.

Red Team Assessments: The Wrong Tool for Mitigating Attack Paths

The goal of a red team assessment as defined by SpecterOps¹¹ is to test the detection and response capabilities (people, processes, and technology) of an organization. Red team assessments are not designed to identify Attack Paths within an organization. However, red team assessments are unique in the professional services arena in their ability to expose how the organization’s defenders respond to realistic, threat-representative attacks. There is often an organizational “A-Ha!” moment when the red team report starts making the rounds. For maybe the first time ever, the organization sees from start to finish the exact steps an adversary took to go from no access to total control of the enterprise. They also clearly see areas where the organization’s response didn’t do enough to prevent it.

Then some familiar questions are asked: “On step 2, you used User X’s password to pivot to Computer 5. But if User X didn’t have admin rights there, you wouldn’t have been able to do that, right?” This kind of thinking is very common — that by taking specific pre-emptive action, the organization would have been free of Attack Paths and, therefore, safe. It’s a comforting — and misinformed — thought. Here’s why:

A “small” organization with around 1,000 endpoints will typically have millions, if not billions of Attack Paths. Attempting to remediate the specific Attack Path presented by the red team assessment would be like trying to stop someone driving from Seattle to New York City by removing a one block stretch of road in St. Louis. It has no effect on the driver’s ability to reach their objective and is likely a waste of resources.

The problem is not that the red team assessment provides no value. Red team assessments provide tremendous value by training or validating the detection and response capabilities of an organization. The problem is in trying to use the red team assessment for something it wasn’t designed for: understanding, quantifying, and eliminating or mitigating Attack Paths. This can lead to frustrating outcomes for red team professionals and their customers, where Attack Paths are discovered and executed year after year after year — it can start to feel like chasing your tail.

Sizing the Problem: Attack Paths as the Unknown Unknown

There are at least three types of problems that present risks to organizations:

Known knowns — well-understood problems that the organization can easily determine their exposure to with tools and methodologies. For mature organizations, Patch Management fits in this category, as the organizations know the importance of patching and can measure their effectiveness at patch management.

Known unknowns — well-understood problems that the organization struggles to determine their exposure to. These are problems that the organization acknowledges to present risks, but for whatever reason, can’t measure how well they are protecting themselves from those risks. Many organizations feel this most acutely with “standard” security controls that are actually incredibly difficult to deploy and maintain in the real world — asset management, least privilege, and tiered administration, for example.

Unknown unknowns — the most dangerous type of risk on this list. These are problems that the organization does not know about, and cannot measure how effectively they are protecting themselves from the risks created by those problems. Attack Paths fit in this category for most organizations.

Unknown unknowns are not the fault of the affected organizations — an organization can not be expected to manage a problem they are not aware of and have no way of measuring. And for those organizations that are aware of the problem of Attack Paths, most lack the ability to use accurate and meaningful statistics to measure their exposure from Attack Paths. You can’t manage or make real progress against a problem that you can’t measure. Fortunately, advancements in Attack Path Management can now transition Attack Paths from ‘unknown unknowns’ into ‘known knowns’ for enterprises. To explain this transition, the details of why Attack Paths are currently ‘unknown unknowns’ must be explored in detail to illustrate how Attack Path Management works and the benefits it provides.

¹⁰ https://docs.microsoft.com/en-us/security/compass/privileged-access-strategy
¹¹ https://specterops.io/what-we-do/adversary-simulation

Simply put, the current options for dealing with the risks brought on by Attack Paths fall short because they:

• Don’t or can’t measure the magnitude of the problem.
• Attack the symptoms rather than the problem.
• Ultimately fail to provide practical approaches to resolve risk.

Today, organizations try to deal with Attack Paths in three different ways:

Attack Path Best Practices Are Often Impractical Practices

In theory, there are two particular methodologies an organization can use to very effectively mitigate the risks brought on by Attack Paths: Tiered Administration and Least Privilege. But for the vast majority of organizations, these methodologies are out of reach.

Tiered Administration sounds simple on paper: split your administrators and endpoints into different “tiers”, and only allow principals and systems in the same tier to access one another. Effectively deployed, this promises to eliminate lateral movement between tiers, so that an attacker with control of a lower-tier principal or system cannot pivot to higher tiers.

Least Privilege Access sounds even simpler: only give users and other principals the privileges they need to do their job, and no more privilege than that. But several factors prevent organizations from deploying Tiered Administration or Least Privilege Access:

1. Opaque and confusing privileges make it too difficult to understand effective permissions against any particular system or object. If you can’t easily audit who has access to one system or object, you can’t determine whether a tier-separation violation exists, or whether a user or principal has the least amount of privilege required.
2. Effectively implementing and maintaining Tiered Administration has historically required architectural changes to several fundamental services, including identity and access management, endpoint management, and even network architecture. This is the biggest reason more organizations didn’t deploy Microsoft’s now-deprecated¹² ESAE, also known as Red Forest.
3. There has historically been no way to accurately predict the real benefit that Tiered Administration or Least Privilege Access would have on eliminating Attack Paths. The inability to demonstrate risk reduction has kept Tiered Administration, Least Privilege, and many other “basic” security controls within the realm of impractical best practice at best, and industry buzzwords at worst.

Existing Products for Securing Active Directory

We have seen some products have an effect on Attack Paths, namely those products in the Privileged Access Management (PAM) category. And some other products, like Anti-Virus (AV) and Endpoint Detection and Response (EDR), can have a positive effect on hindering an adversary’s ability to execute a particular step in an Attack Path. And yet, Attack Paths continue to grow, and Red Teams and adversaries continue to execute Attack Paths. At the end of the day, PAM, AV, and EDR have served more as speed bumps, not roadblocks, when an adversary is executing an Attack Path in Active Directory. Why is this?

The biggest and most obvious reason why existing security products do not solve the problem of Attack Paths? They aren’t designed to. Each product within existing categories has been designed, built, and maintained to solve one, or a few specific problems in the information security space. But just as an Attack Path Management solution will not solve the problem of malicious software running on endpoints, EDR solutions will not solve the problem of Attack Paths.

¹² https://docs.microsoft.com/en-us/security/compass/esae-retirement

A Step Forward: Free and Open-Source Software (FOSS) — BloodHound

Learn more

Almost immediately after BloodHound (https://github.com/BloodHoundAD/BloodHound) was released, the FOSS BloodHound creators and many others realized that the potential for the tool was far more compelling on the defensive side than it was on the offensive. Many organizations have used BloodHound to identify and eliminate Attack Paths in their own networks, to varying degrees of success.

But there are several problems with using FOSS BloodHound as an Attack Path Management solution:

1. Building on top of FOSS BloodHound with custom scripts and methodologies requires a full-time commitment and dedication to mastering graph theory concepts, graph database management, the Cypher query language, and an existing expertise in Active Directory security concepts.
2. FOSS BloodHound offers no way to generate meaningful statistics or measurements. This precludes the possibility of tracking progress over time or demonstrating Attack Path reduction before a remediation is made.
3. FOSS BloodHound’s data collection architecture was designed to facilitate offensive security assessments which take place in a discrete span of time. It was not designed for, nor does it support continuous data collection. This means that the data in the database quickly becomes inaccurate and unusable.

While some organizations, including SpecterOps, have had success with deriving defensive value out of FOSS BloodHound, it is neither good enough nor designed to effectively manage Attack Paths on its own.

Attack Path Management is a fundamentally different, unique methodology designed to help organizations understand, empirically quantify impact, and eliminate Attack Path risks. To achieve this goal, Attack Path Management is based on three fundamental pillars:

Attack Path Management Defined and APM’s Foundational Pillars

Attack Path Management is the continuous discovery, mapping, and risk assessment of Active Directory (on-prem and Azure) Attack Path Choke Points. Organizations can use APM to eliminate, mitigate, and manage Attack Paths, finally achieve effective Tiered Administration and Least Privilege, securing Active Directory and significantly reducing the attack surface presented to the adversary. APM does not require fundamental architectural changes, and helps organizations achieve the above benefits without endlessly chasing down misconfigurations, vulnerabilities, and dangerous user behaviors. To achieve these goals, APM is based on three fundamental pillars:

Pillar 1: Continuous, Comprehensive Attack Path Mapping

Continuous Attack Path Mapping

Enterprise networks are not static. Privileged users log on to different systems every day (leaving behind tokens and credentials that can be abused by an adversary), new applications require newly granted permissions, and security group memberships change to accommodate business requirements. These individual changes and events don’t just affect the principals and objects directly involved — they have far-reaching effects in the creation of Attack Paths. Consider for example the Panama Canal. In its simplest form the canal connects two oceans; however, it opens a pathway for distant nations and economies.
Because the connections and behaviors that form Attack Paths are continuously changing, the Attack Paths themselves must also be continuously mapped.

Comprehensive Attack Path Mapping

When continuously mapping Attack Paths, every relationship / connection must be charted. From critical servers like Domain Controllers to individual endpoints, comprehensive enumeration of relationships and connections enables full understanding of the real permissions against any given object, computer, user, etc., and also enables the empirical measurement and impact of any particular connection.

Furthermore, ongoing research produces new techniques for abusing legitimate privileges. Those new techniques must be included in the Attack Path Mapping as well. Often, introducing a simple technique to the Attack Path Map can reveal Attack Paths that were always there, but remained hidden for years or even decades.

Pillar 2: Empirical Impact Assessment of Attack Path Choke Points

There are numerous solutions that will point to a particular configuration and offer a subjective risk assessment of that specific configuration. Equally as unhelpful, it’s very common for consultants to instruct their clients to broadly “do least privilege”. Attack Path Management is different. By continuously and comprehensively mapping all Attack Paths that exist in a directory services environment, Attack Path Management can empirically measure the impact any particular privilege or user behavior has on the overall security posture of the environment. As an example, the driveway in front of your house (specific privilege) doesn’t just connect your house to the street, it connects your house to every other origin that can be traversed by car.

Choke Point Identification

Attack Path Choke Points are identified as those common privileges and user behaviors that, like the driveway to your house, connect the rest of the environment to an asset or collection of assets. For example, any connection into the collection of Tier Zero assets is a Tier Zero Choke Point — a privilege or user behavior the adversary must abuse in order to compromise a Tier Zero asset. No matter where the adversary initially starts or the pathway they take to this point, there is a finite set of connections into Tier Zero that separate the adversary from their objective. Continuous, comprehensive mapping enumerates those Choke Points. But identifying those Choke Points isn’t enough — they must also be prioritized and their individual impacts must be measured to understand the benefit of revoking privileges or forcing privileged users to change their behaviors.

Choke Point Impact Assessment

Attack Path Management must assess and describe (in simple language) the impact any particular Choke Point has. This is done by comprehensively walking the Attack Paths backwards to discover how many users and computers have access and pathways to each Choke Point. One Choke Point may enable 100% of users to access Tier Zero, while another Choke Point only enables 2% of users to access Tier Zero — this makes prioritization and urgency immediately clear.

Pillar 3: Practical, Precise, and Safe Remediation Guidance

The primary objective of Attack Path Management is to help organizations eliminate key Choke Points such that it’s no longer worth the adversary’s effort to try to enumerate or execute Attack Paths in that organization’s network. With this end-goal in mind, it is vital that Attack Path Management produce practical, precise, and safe remediation guidance that organizations can easily implement.

Practical

Attack Paths present a large risk to every organization, but every organization must choose for themselves how much time, money, and political capital to expend in the name of managing Attack Paths. For this reason, Attack Path Management must provide practical remediation guidance that adheres to four criteria:

1. Remediation actions should not require drastic changes to the environment’s directory services architecture
2. Remediation actions should not require the organization to migrate from one directory services platform to another
3. Remediation actions should not require expert-level knowledge to implement
4. Remediations should have expected outcomes, and both the remediation and the expected outcomes should be verifiable

Precise

Any inexact or incomplete guidance runs the risk of not eliminating the intended Attack Path or impacting critical business processes. Due to the complex relationships and connections of the real permissions against any given object, computer, user, etc., Attack Path Management Choke Point remediation guidance must be precise and comprehensive.

Safe

Because Attack Path Management is constrained to privileges and user behaviors, remediation guidance is focused on removing, altering, or otherwise mitigating those privileges and behaviors. Removing privileges can be a particularly anxiety-inducing exercise, as it may be unclear what critical business processes may fail as a result. Each remediation guidance produced by an Attack Path Management solution must include instructions for how to determine whether those privileges are actually required.