The Security Principle Every Attacker Needs to Follow

Earlier this year, I was tasked with developing a follow-on course for our renowned Adversary Tactics: Red Team Operations course. The new course needed to cover the advanced tradecraft we perform on engagements and teach students how to navigate highly secure environments.

I decided to focus on “Identity-Driven Offensive Tradecraft”, which ultimately became the course name. In this post, I will explain what I mean by that and why it is so central to attack paths and red team operations. I will also answer the question “What turns a path into an attack path?” and discuss the principle behind the framework we teach in our new IDOT course: the Clean Source Principle.

This will be a less technical post than my usual, but it’s important to understand the theory behind the practice.

Access Control Fundamentals

Every modern technological ecosystem has a mechanism, or a set of mechanisms, that govern access to resources. These mechanisms must be able to perform the following most fundamental tasks:

• Identification: Recognizing a principal (e.g., matching a username or email address to an account)
• Authentication: Verifying the identity of the principal (e.g., verifying that the client is in possession of the principal’s password)
• Authorization: Determining whether the principal is permitted to perform an action on a resource in the current state

In practice, identification is part of the authentication process, but most literature recognizes them as different processes.

I’m intentionally leaving out Accounting, as it is less relevant to the main point of this post.

Authentication

Authentication can be performed locally by the system or delegated to another system, such as Active Directory or an Identity Provider (IdP), either on-premises (e.g., Active Directory Federation Services — AD FS) or in the cloud (e.g., Entra ID or Okta).

When authentication is delegated to another system, an authentication protocol is usually utilized to ensure credentials are exchanged securely. On-premises, this is typically done via Kerberos or NTLM, which avoids sending raw credential material to the authentication server or the resource server. In the cloud and with third-party software, it is typically done via SAML or OIDC, which rely on signed tokens.

Authorization

Authorization essentially boils down to a set of access control rules that apply to the principal or the resource and are enforced by the system’s Identity and Access Management (IAM) components. In Windows, the Security Reference Monitor (SRM) performs this service. These rules are comprised of variations of the following elements:

• Subject: The principal that seeks access
• Action: What the rule allows/denies the subject to do
• Object: The resource that the subject can/cannot perform the action on
• Conditions: Additional requirements that must be met in the current state of the subject or the resource (e.g., time or location restrictions)
• Decision: Allow or Deny

For example, the following rules depict a policy that grants the Domain Admins group Full Control access to the Production DB Server and the Global Admins role Full Control access to the Storage Account if access is initiated from a compliant device with multi-factor authentication (MFA).

What is Identity-Driven Offensive Tradecraft?

Identity-driven offensive tradecraft is Tactics, Techniques, and Procedures (TTPs) motivated by, centered around, and strategically guided by the abuse of identity and access management. This focus on identity as the key vector for achieving offensive goals defines this approach.

Attackers ultimately seek to impact the target environment, steal data, or, in the case of red teamers, demonstrate their ability to do so. Virtually all attack paths require navigating the access control mechanisms, primarily in one of the following ways:

• Credential abuse or similar TTPs that lead to user impersonation
• Access policy/ACL modification or configuration changes to allow access
• Exploitation or manipulation of components with permitted access to the attacker’s ultimate objective or in support of performing one of the above

That is why most threat actors seek to gain “Enterprise Identity Dominance,” e.g., Domain Admin in Active Directory or Global Admin in Entra ID. Once they gain such dominance, they can control or impersonate principals with access to their ultimate objectives. Such privileged access potentially enables rapid lateral movement for a smash-and-grab operation, allows installing hard-to-find persistence for long-term operations, and often hinders incident response efforts because relatively few people in the organization have such privileged access, making containment and eradication more complex.

Going back to the previous example, we can fill in the gaps and depict a very simple attack path that demonstrates how an attacker could abuse the access policy:

The attacker gains initial access to a Domain Admin’s workstation and abuses their credentials/session to gain Full Control access to the Production DB Server. At that point, the attacker can also gain access to the Entra ID Privileged Access Workstation, a compliant device with a Global Admin logged in with MFA, and gain Full Control access to the Storage Account.

Every Attack Path is Identity-Driven

Many readers are familiar with what I have discussed so far, so what’s my point? I argue that every single edge in BloodHound (and I would even go as far as arguing that every attack path in general) is identity-driven. Therefore, attackers must equip themselves with as much identity-driven tradecraft as possible to abuse those edges and navigate complex hybrid environments (did I mention that we have a new course dedicated to that?).

Executing attack paths that BloodHound identified is relatively straightforward and there are a plethora of resources that explain how to do that in detail, but how does one discover and abuse new attack paths? What do you do when BloodHound doesn’t find a path to your objectives? I’ve been asked these questions countless times. To answer those questions, let’s go back to the previous example. What’s wrong with the access policy depicted in the diagram above? There’s nothing wrong with Domain Admins being allowed to add users to a domain group or with a Global Admin having access to a storage account. These are expected behaviors. So, what turns a path into an attack path?

What’s Wrong Here?

We established that there’s nothing wrong with Domain Admins being permitted to add users to a domain group or with a Global Admin having access to a storage account. We can also assume that the DA User and the GA User are supposed to have the privileged access they do and that the PAW Admins group is supposed to have admin access to the Privileged Access Workstation (PAW), as the name suggests.

Let’s go back to the beginning and discuss the remaining edges. The fact that the DA User has a session on a compromised workstation, presumably a normal workstation instead of a PAW, violates security best practices.

What about the remaining edges? The diagram is a bit ambiguous to help me make a point. The fact that the GA User has a session on the PAW can mean one of two things:

• The session is an interactive Windows session, which leads to the conclusion that the GA User is a synced domain account. Assigning the Global Admin role to a synced account violates security best practices, making the Has Role edge the problem.
• The session is a browser session and the GA User is an Entra ID cloud-only account. In this case, the GA User shouldn’t establish a session on a domain-joined workstation, making the Has Session edge the problem.

Why is it Wrong?

Those edges violate security best practices because of the Clean Source Principle, which dictates that, “all security dependencies must be as trustworthy as the object being secured.” I believe the term “trustworthy” is used rather than “secure” because:

• The principle applies not only to processes and technology but also to people
• It alludes to the Trusted Computing Base (TCB) concept

In my opinion, the Clean Source Principle is the most important yet least-known security principle. Microsoft, to their credit, used it as the guiding principle for the good old Enhanced Security Admin Environment (ESAE) architecture, which introduced concepts like the “Tiering Model”, “Tier Zero”, and the “Red Forest”. The ESAE model is now deprecated, but its successor, the Enterprise Access Model, still follows the Clean Source Principle.

Dissecting the Clean Source Principle

All security dependencies must be as trustworthy as the object being secured.

What is a Security Dependency?

If one resource’s security relies on another’s security, then it is a security dependency. Conversely, controlling a security dependency may allow controlling resources that depend on it. I emphasized the word “may” because some attack techniques have multiple prerequisites, so controlling a single security dependency may be insufficient for controlling a resource that depends on it.

Defining “Control”

In our context, “control” is a relationship that can contribute to compromising the target resource or impacting its operability. I say “contribute to compromising or impacting” rather than “compromise or impact” because we often need to abuse more than one security dependency to fully compromise or impact the target. For example, if MFA is enforced on an account, we must control both authentication factor mechanisms to gain control of the account.

Therefore, we can conclude that a set of one or multiple security dependencies can control a resource that depends on it.

Transitivity

Security dependency and control relationships are transitive, meaning that if A controls B and B controls C, then A also controls C through transitivity. The following diagram depicts a more concrete example:

The User Workstation controls the Domain Admin account because it has a session established on it. The Domain Admin account is an admin to the Member Server. Through transitivity, the User Workstation can control the Member Server.

Making an Attack Path

Given the definitions above, we can now circle back to attack paths. I define attack paths as a chain of control relationships with at least one violation of the Clean Source Principle. Some may refer to the violations or their abuse as “attack vectors”. Going back to the previous example, we can observe the following:

The Admin To relationship is not a Clean Source Principle violation, while the Has Session relationship is. The graph does not represent an attack path without the Has Session relationship.

It becomes an attack path only when an attack vector or a Clean Source Principle violation is introduced.

Notable Vectors

The Has Session relationship is the bread and butter of the Credential Shuffle, but there are several other examples, some more common than others:

• Hypervisor to VM: The hypervisor (and anyone in control of the hypervisor) can control any VM running on it
• EDR to Host: The EDR (and anyone in control of it) can control the host it’s installed on
• Workstation through Jumpbox to Server: My all-time favorite, the workstation from which a user establishes a session to a jumpbox/bastion host can control the session and transitively control the target server

I want to highlight the last example. Jumpboxes/bastion hosts are a relic from the network segmentation days and are an inadequate solution for mitigating identity-driven offensive tradecraft. This anti-pattern is commonly replaced by Privileged Account and Session Management (PASM) solutions that often fail to solve the problem. The session/journey to the jumpbox/bastion host or the equivalent PASM solution must be established from a PAW.

Thought Exercises

I often get pushback for saying that a Clean Source Principle violation is what makes an attack path. I’ll share a couple of thought exercises that often help make the point.

Unauthenticated Remote Code Execution

Imagine a server running a service vulnerable to a good old remote code execution vulnerability that can be triggered unauthenticated. The service runs as NT AUTHORITYSYSTEM, allowing everyone to take over the host and then compromise any logged-on user or any resource hosted on the server.

There is evidently an attack path here because an attacker can ultimately control the logged-on user or the hosted resource. Where is the Clean Source Violation? The Vulnerable Service is less trustworthy than the Privileged User or the Resource. Therefore, the Vulnerable Service should not be running as NT AUTHORITYSYSTEM on the Server (or at all!), or the Privileged User should not log onto the Server, and the Resource should not be hosted on it.

Can Domain Users be Domain Admins?

Consider the extreme scenario of adding the Domain Users group to the Domain Admins group. Is it inherently wrong? Does it necessarily violate the Clean Source Principle? Is it always an attack path?

In practice, of course, the answer to all these questions is “yes!”.

In theory, though, imagine a contrived scenario in which an organization chooses to make this change. Can they do it without violating the Clean Source Principle? Yes, as long as Domain Users remain as trustworthy as Domain Admins. All domain users would have to log on only to hardened PAWs, avoid accessing the internet, etc. Unless the organization’s sole purpose is to run Active Directory, everyone will fail to perform their duties and achieve anything in such an environment.

Change My Mind

We will hold a webinar about this topic in September, so I encourage you to sharpen your pitchforks, join the debate, and take your best shot at proving me wrong.

Conclusion and Practical Applications

The Clean Source Principle dictates that all security dependencies must be as trustworthy as the object being secured, and every attack path must contain at least one attack vector that abuses a violation of this principle to navigate identity and access management.

In my next post, I will show how attackers can follow the Clean Source Principle to discover known and unknown attack paths using a framework that we teach in our new Adversary Tactics: Identity-Driven Offensive Tradecraft course.

Until then, I encourage you to think in terms of security dependency, control, trustworthiness, and clean source. Every time you discover an attack path, ask yourself the following questions:

• Does the edge represent control?
• What are the security dependencies that allow such control?
• Is the source node as trustworthy as the destination node?
• Where are the Clean Source violations?

---

The Security Principle Every Attacker Needs to Follow was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.