Today, threat actors are using a variety of methods to target organizations. While ransomware, phishing, botnets and other malware steal the headlines, Active Directory (AD) remains a major vector of abuse.
More specifically, hackers use Attack Paths in AD, which are chains of abusable privileges and user behaviors linking users and computers that attackers use to steal sensitive data or launch malware attacks. They’re present in virtually all business networks and have frustrated defenders for decades (whether they’ve known it or not).
I’ve studied Attack Paths in detail over the last several years. As attacks evolve, defending against Attack Paths requires a new approach. In this article, I’ll explore Attack Paths in more detail and talk about how security pros can work to eliminate these threats.
Also see: 5 Cloud Security Trends in 2022
The Secret Scourge of Microsoft Active Directory
In 2009 Microsoft Research described Attack Paths as “Identity snowball attacks [that] leverage the users logged in to a first compromised host to launch additional attacks with those users’ privileges on other hosts.”
Identity-based Attack Paths (which is what I’ll focus on here) are especially problematic in Microsft AD and Azure AD, since these platforms provide high rewards to attackers with relatively low risk. But here, I’ll focus on Microsoft AD, these concepts also apply to other identity and access management systems like those in Google Suite and AWS.
Existing defensive literature on Attack Paths is often too academic to be practical, and the practical tools that do exist focus on Attack Paths from the attacker perspective. While approaches like Tiered Administration and Least Privilege can reduce these risks in theory, they’re almost never implemented correctly (if at all) for a variety of reasons.
Defending against Attack Path abuse requires continuous discovery, mapping, and risk assessment of AD Attack Path choke points (both on-prem and in AD). This approach can eliminate, mitigate, and manage Attack Paths, and significantly reduces the attack surface presented to the adversary by AD.
This protective approach should not require fundamental architectural changes, or force defenders to work through endless lists of misconfigurations, vulnerabilities, and dangerous user behaviors. In my experience, successfully defending AD from Attack Paths requires three primary steps:
1) Real-Time Mapping
The first step to stopping Attack Paths is knowing how many of them exist – at all times.
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.
One-time measurements of Attack Paths or measurements at intervals are not good enough. Mapping needs to include all possible systems and users, from Domain Controllers to individual endpoints. As new research finds new techniques for abusing user privileges, these techniques need to be added to the Attack Path Map so it remains comprehensive.
Also see: Secure Access Service Edge: Big Benefits, Big Challenges
2) Identifying and Prioritizing Attack Path Choke Points
Shutting down all the Attack Paths in an environment isn’t possible – there are simply too many of them (and not all of them can be shut down).
A better solution is to focus on “choke points” that lead to high value (or Tier Zero) assets like Domain Controllers. For example, if an organization has ten connections to their Tier Zero assets, then any Attack Path to those assets must go through one of those connections, no matter where it starts. Finding these choke points reduces the scope of what defenders need to focus on, turning it into a more manageable process.
There are plenty of solutions that give AD misconfigurations a subjective “risk assessment” value. This may or may not be useful, depending on how the solution provider assesses risk. A better approach is to measure risk objectively, based on the number of computers and users that have access to each choke point.
For example, if one choke point enables 100% of users to access Tier Zero, while another choke point only enables 2% of users to access Tier Zero, then it’s very clear what defenders should fix first.
Also see: 5 Ways Social Media Impacts Cybersecurity
3) Actionable Remediation Guidance
Attack Paths present a large risk to every organization, but every organization must choose for themselves how much time, money, and political capital to spend on managing them. Removing user permissions or trying to change user behaviors can easily have unintended consequences (such as breaking backwards compatibility by turning off NTLM authentication) that interfere with legitimate business processes.
AD admins are reluctant to rock the boat without a clear benefit. If guidance is unclear or involves too much work, then defenders will likely play it safe and not change anything. Because of this, remediation guidance must meet several criteria to ensure they are practical, precise, and safe. These criteria include:
- Not requiring drastic changes to the environment’s directory services architecture.
- Not requiring the organization to migrate to a new directory services platform.
- Not requiring expert-level knowledge.
- Providing expected outcomes, with both the remediation and the expected outcomes being verifiable.
- Including instructions for how to determine if privileges are required.
Being able to identify specific Attack Path choke points, assess the risk of each one objectively, resolve issues quickly, and measure how an organization’s overall risk changes over time can dramatically improve and simplify AD security for organizations.
As this space develops and new solutions come to market to help streamline this process, organizations will be able to streamline the management of Attack Paths to help mitigate serious threats and misconfigurations.
Also see: Tech Predictions for 2022: Cloud, Data, Cybersecurity, AI and More
About the Author:
Andy Robbins, Technical Architect and Co-Founder, SpecterOps