Attack path types
From the perspective of a defender, there are three types of attack paths:
- Ones that can be fixed in minutes
- Ones that take days or weeks to resolve, and
- Ones that can’t be fixed without significant structural changes or breaking critical software.
Here’s some background to help understand why they break down into those categories.
Identity attack paths are the adversary’s favorite target for lateral movement and privilege escalation. They allow an adversary with initial access to go from a low-privileged user to a high-value target or full takeover of the environment by exploiting misconfigurations and user behaviors within a directory service like Active Directory or Azure Active Directory. These paths are numerous and exploiting any single attack path is difficult for defenders to detect, as attackers often use legitimate tools and credentials and their activities thus appear identical to normal user activity.
Defenders will want to eliminate as many attack paths as possible, but some are easier than others to fix. From our experience, these Identity Attack Paths can be grouped into three main categories:
Quick fix
A decent percentage of attack paths in the average enterprise AD environment can be fixed in minutes simply by changing configurations.
For example, one of my favorite attack paths to fix is non-Domain Admins with ownership rights over Domain Controllers. This attack path is a common byproduct of automation accounts that join systems to the domain. It can also happen when someone promotes a computer to a Domain Controller (DC). Promoting a system to a Domain Controller does not change the security owner of the object in Active Directory. Therefore, “Bob” could have created a server in the directory and sometime later that system is promoted into a DC – now Bob owns a DC. Anyone that can get access to Bob now has a path to compromise a DC.
Here’s why this is my favorite attack path: your internal business applications don’t typically use the “owner” relationship to function. That means that unlike other ACL rights like “GenericWrite,” you can be confident that changing the owner of an object to the Domain Admins group should not cause unforeseen issues within the environment. This can be done by finding each Domain Controller object in Active Directory Users and Computers, right-clicking it and selecting “Properties,” then “Security,” then “Advanced,” then “Change” and changing ownership to the Domain Admins group.
There are examples of this that are quite obvious once you see them. A couple weeks ago I found a “WIFIAuth” user object that had full control over the entire domain. No enterprise system is going to need such a gross overuse of privilege to function and is another obvious misconfiguration that can be remediated immediately.
Some of these remediations can have dramatic results, removing thousands of attack paths with just a few hours of work.
Moderate fix
The next category is attack paths that take days or weeks of work to fix.
These might require additional research by the analyst team, a more complicated remediation process, require changes in behavior, or make it more difficult for other business users to do their job. Fixing these might involve weighing the risks of the attack path versus the side effects of the remediation or doing more work to make sure the remediation has as little impact as possible. Here’s a couple examples:
A service account with GenericWrite over a Domain Controller. To answer how this should be remediated you need to understand what the service is doing and how often this is occurring. This can typically be answered by using Windows Event Logs. For most actions exercising an Access Control Entry (ACE) right in Active Directory, a corresponding Windows Event log will be generated. Before remediating the issue, it’s important to collect these logs and see if that service is using that right. If not, removing that right will remove that path from the adversary. However, if the service is in use, then it should be reviewed to see if it should, in fact, be run on a Domain Controller. Perhaps it can be segmented in some way (for example, by only using Tier Zero accounts on Tier Zero systems).
Another example is Domain Administrators (DA) logging in to servers or workstations with their DA credentials. DA credentials should be limited to use within Domain Controllers or other Tier Zero systems. Admins should have other credentials for modifying servers or workstations. This fix may take some time as it involves changing user behavior and a GPO will have to be pushed to the environment to create a new group for “Workstation Admins” and “Server Admins” for access on both respectively (Domain Admins have access this access by default, which is why they’re commonly used in this way). Abusing DA logins is an extremely common way to abuse the domain, so while the fix may take some adjustment, the security payoff is worth it.
Won’t fix
The final category is attack paths that probably won’t be fixed. Fixing these paths usually requires such a significant amount of change to fix that other mitigating controls may be preferable.
For example, consider on-premises Microsoft Exchange. Exchange has a history of requiring a ton of privileges, which basically made a compromise of Exchange equal to compromise of AD itself. While this has gotten better over the years and Microsoft explains how to reduce these permissions, Exchange Server can only be completely segmented by introducing a split permission model. The work here can be very tedious, break other integrations, and cause issues when reaching out to support. For this reason, many of our customers choose not to fully implement split permissions but pursue one of the following:
- Introduce a DENY ACE on Tier Zero accounts blocking this access
- Use this finding to fast-track their transition to Office 365
- Deploy compensating monitoring controls around these specific accounts
Any of the three are valid approaches as security is a risk management process.
Active Directory Administration Cookbook:
