When the shield becomes the sword: How misconfigured PAM bridges the tiering model

In the world of identity security, few tools promise as much peace of mind as Privileged Access Management (PAM). It is often referred to as the "vault" that locks away your kingdom's keys. However, in Microsoft Incident Response – the Detection and Response Team (DART) engagements, we frequently encounter a paradox: the tool used to secure Tier 0 often becomes a quick path for threat actors to compromise it.

In a recent DART engagement, a threat actor moved from a compromised helpdesk workstation to full domain compromise in under four hours. They didn't use a zero-day. They used the organization's PAM server. 

We have seen this story play out in real-time. An organization invests heavily in Active Directory (AD) Tiering and a premium PAM solution. They feel secure. Yet, during an incident, we trace the threat actor’s path and find they didn't burn a zero-day or crack a complex algorithm. They simply walked across a bridge the organization built themselves: a PAM server positioned in Tier 1 that held the keys to Tier 0. 

This isn't a failure of the product; it's a failure of positioning. This post shares what DART sees on the front lines, why "intermediaries" are the most critical link in your chain, and how to deploy PAM without rolling out a red carpet for threat actors.

The foundation: A quick refresher on tiering model and PAM, PIM, and PAW concepts

Before we dive into the threat actor’s tactics and techniques, let’s revisit the ground rules and define a few key concepts. The Active Directory Tiering Model is built on a simple premise: prevent credential theft propagation; ensuring that credentials with administrative access to higher-tier systems are never exposed on lower-tier systems where a threat actor may already have a foothold. 

• Tier 0 is your control plane: Domain Controllers, PKI, and the identities that manage your authentication plane. 

• Tier 1 houses your application servers and data. 

• Tier 2 is the high-risk environment: user workstations and devices exposed to the internet. 

The golden rule of tiering is strictly one-way: higher tier admins must never expose their credentials to lower tier systems, and lower tiers must never have management access to higher tiers. The core purpose of this separation is to ensure that a compromised workstation cannot yield Domain Admin credentials. However, operational tools that bridge these tiers often inadvertently break this definitional boundary. 

PAM (Privileged Access Management): Solutions designed to securely vault credentials and broker administrative sessions, ensuring access to critical systems is monitored and controlled. 

PIM (Privileged Identity Management): Tools that manage the lifecycle of elevated roles, typically by enforcing time-bound, Just-In-Time (JIT) access to eliminate standing privileges. 

PAW (Privileged Access Workstation): Highly hardened, dedicated devices used exclusively for sensitive administrative tasks, physically or logically isolating tier admins from high-risk activities like email and web browsing. 

Figure 1: Administration with dedicated tiered accounts

The front-line reality: the shared intermediary trap

Imagine this scenario: A threat actor compromises a standard workstation (Tier 2) through a phishing email. Their goal is the Domain Controller (Tier 0). In a properly tiered environment, this path is blocked; there are no credentials on the workstation to steal, and no direct privilege escalation route to the Domain Controller. 

But then the threat actor finds an intermediary system. 

In many environments, we see a single PAM session host used by everyone. The Tier 1 admins use it to manage application servers, and the Tier 0 admins use it to manage Domain Controllers. This convergence creates a "Shared" or "Dirty" Intermediary. 

The attack path

1. The foothold: The threat actor compromises a standard Tier 2 workstation. 
2. The escalation: The threat actor moves laterally and escalates privileges by exploiting common lower-tier misconfigurations (such as Helpdesk scenarios or exposed privileged service accounts) to compromise a Tier 1 administrator account who has full control over the Tier 1 PAM Host. 
3. The pivot: Because the PAM Session Host resides in Tier 1, the threat actor uses those compromised Tier 1 admin rights to seamlessly gain full control of the underlying operating system of the PAM host itself. 
4. The compromise: The threat actor simply waits for a Tier 0 admin to initiate a session. Because the threat actor already has full administrative control over the underlying server, it is a given that they can extract the Tier 0 credentials the moment that session begins. 
   Note: A threat actor at this stage does not need to exploit any weakness in the PAM software itself. Because the session host logically resides within the Tier 1 boundary, any identity or system with administrative rights over that tier holds ultimate authority over the host. This administrative control provides the means to modify the host's configuration, bypass security agents, and disable runtime protections before a privileged session ever begins. Once this foundational control is established, credential material processed by the operating system for outbound privileged sessions becomes accessible. This is not a PAM product failure; it is an architectural placement failure 
5. Game over: The threat actor replays those credentials to take over the Domain Controller. 

Here is how that compromise looks architecturally: 

Figure 2: Single PAM host architecture

The core concept: PAM is an intermediary

To understand why the scenario above happens, we have to look at how Microsoft defines Privileged Access Intermediaries. 

As detailed in our Privileged access intermediaries guidance, an intermediary is any system that stands between a user and a target resource. This includes VPNs, Jump Servers, and PAM solutions. 

The Golden Rule of intermediaries

The security assurance of the target is only as good as the security assurance of the intermediary. 

If you manage a Tier 0 asset (like a Domain Controller) through a PAM server, that PAM server becomes a Tier 0 asset. If that PAM server allows logins from Tier 1 users or is reachable from Tier 2 workstations, you have effectively downgraded your Domain Controllers to the security level of a workstation. 

You cannot have a "Tier 1" server managing "Tier 0" assets. The math simply doesn't work. Each type of intermediary serves a different role, so the security controls won’t be identical. However, some basics apply to all of them, like quickly patching appliances, firmware, operating systems, and applications. 

Figure 3: Security impact of different PAM approaches

Third-party PIM/PAM solutions are often deployed on-premises or as a Virtual Machine (VM) in an Infrastructure as a Service (IaaS) environment and are usually reachable only from internal (intranet) systems. Even if they aren’t exposed to the internet, one stolen credential could let a threat actor reach them through VPN or other remote access methods. 

The hidden risk: the "master key" service account

The attack path above assumes a threat actor waits for a human administrator to arrive. But there is a second, more direct risk and it doesn’t require patience at all. It’s not just about where users log in; it’s about the power the software holds. 

Consider the Password Reset scenario. A key feature of PAM is automatically rotating Domain Admin passwords, so human admins never need to know them; credentials are simply injected into the session. However, to perform this action, the PAM Service Account itself requires massive privileges (typically Domain Admin or equivalent) to reset those target passwords. 

Here is the trap: If your PAM Core or Vault resides in Tier 1 (or is treated as such) but manages Tier 0 credentials, you have effectively granted Domain Admin rights to a Tier 1 asset. 

A threat actor doesn't even need to wait for a human administrator to log in. If they compromise the underlying server where the PAM service runs, they can extract the Service Account’s credentials. Since this account has the power to reset Domain Admin passwords, the threat actor instantly elevates to Tier 0; no session required, no waiting, no noise. 

This reinforces the golden rule: If a Service Account manages Tier 0, the system it runs on is Tier 0. The two attack vectors: hijacking a session and stealing the service account. Both stem from the same root cause: architectural misplacement. Fix the placement, and you eliminate both. 

Practical checklist: are you exposed?

In DART engagements, we use this checklist to rapidly assess if a PAM deployment is a security asset or a liability. Use this to validate your own environment: 

• The intermediary check: Does any server used to manage Domain Controllers allow inbound RDP, SMB or other management connections from standard workstations or Tier 1 servers? (If yes, you are bridged). 
• The identity check: Do you use the same "Admin" account to log into the PAM portal for both Tier 0 and Tier 1 tasks? (If yes, you are exposing credentials). 
• The reachability check: Can your PAM Vault/Core be reached from the general user network? (It should only be reachable from management zones). 
• The isolation check: Are your Tier 0 Session Hosts logically and technically treated as Tier 0 assets? 

What good looks like: The tiered PAM architecture

How do we fix this? We don't throw away PAM; we align it with the Enterprise Access Model. 

In DART, we advocate for a tiered PAM deployment. This doesn't necessarily mean buying three different PAM vaults. It means strictly segregating the session hosts and the control plane. 

The architecture of isolation

1. Tier 0 Control Plane: The core of your PAM (the Vault, the Policy Manager) holds the keys to the kingdom. Therefore, it must be treated as Tier 0. It should only be manageable by Tier 0 admins from Tier 0 workstations. 
2. Segregated Session Hosts: You must have separate session host infrastructure for each tier. 

• • Tier 1 Session Host: Accessible from Tier 1, manages Tier 1. Blocked from talking to Domain Controllers. 
  • Tier 0 Session Host: Accessible only from Tier 0 PAWs, manages Tier 0. Totally isolated from the rest of the network. 

This diagram illustrates a PAM deployment that respects the tiering model:

Figure 4: Separate PAM host architecture

For a deeper dive into reconciling these paradigms, review Intermediaries in Securing Privileged Administration and Microsoft's guide on Partitioning Administrative Privileges. 

FAQ: Clearing the confusion

Q: Does PAM always belong in Tier 0?  

A: If the PAM system manages Tier 0 credentials or provides access to Tier 0 assets, yes. The components that touch Tier 0 (Vault, Brokers, Session Hosts) must be secured at Tier 0 standards. 

Q: Can we use a single "hardened" session host for all tiers to save costs?  

A: In DART's experience, no. "Hardening" is often a configuration state that drifts or is bypassed by zero-days. Architecture beats configuration. If you bridge the network tiers, a compromised Tier 1 admin account is all a threat actor needs to gain OS-level control of that host and from there, access to Tier 0 sessions is a matter of patience, not sophistication. 

Q: If we have PAM, do we still need the Tiering Model?  

A: Absolutely. PAM doesn’t replace Tiering; when implemented correctly, it adds another layer of security and/or governance. Tiering keeps credentials and admin access separated, so threat actors can’t easily move sideways or reuse stolen hashes. PAM provides workflow, rotation, and audit trails.  

Q: What is the most common mistake you see?  

A: We frequently see organizations approach PAM as a "magic stick", believing it secures everything about credential hygiene. Yet, because they assume the tool secures itself, they treat this critical infrastructure as just another Tier-1 asset. It gets patched like a standard file server and monitored like a print server, rather than being hardened and isolated as a Tier-0 component. This mindset doesn't secure the environment; it creates a fragile bridge that threat actors can easily cross. 

Q: Our PAM vendor says their session host is hardened out of the box. Why is this still a risk? 

A: PAM vendors are right that a well-configured session host with Credential Guard enabled, application control enforced, and remote management restricted is considerably harder to exploit than a stock Windows Server. Some vendors use Kerberos constrained delegation with S4U2Proxy, meaning the machine account rather than the Domain Admin’s actual credentials authenticates to the target, which limits direct credential exposure. These are meaningful controls and we don’t dismiss them. However, application-layer hardening is defeated by OS-layer control. If the PAM host is domain-joined and sits in a Tier 1 OU, a Tier 1 Domain Admin has Group Policy, software deployment rights, and Active Directory machine account control over that host. They can push a GPO to disable Credential Guard, deploy a driver via software distribution, or alter the machine’s configuration before the next reboot, all using entirely legitimate AD administration tools. The vendor’s hardening is irrelevant once the threat actor controls the tier the machine lives in. This is precisely why tier placement is not a PAM configuration decision; it is an Active Directory architecture decision. 

Q: We’re cloud-first and use Entra ID. Does AD Tiering still apply to us? 

A: The specific tier labels change, but the principle does not. Microsoft’s Enterprise Access Model is the cloud-era evolution of AD Tiering, built around the same core concept: Control Plane (equivalent to Tier 0), Management Plane (Tier 1), and User Access / Data Plane (Tier 2). In an Entra ID environment, your Control Plane includes Global Administrators, Privileged Role Administrators, and the Conditional Access policies that govern them. A PAM or PIM solution managing those identities must be treated with the same isolation discipline. Hybrid environments, where on-premises AD and Entra ID are synchronized, carry the additional risk that a compromise of either plane can propagate to the other through synchronization. If anything, hybrid environments make strict intermediary placement more critical, not less. 

Conclusion

PAM is a powerful tool in the defender’s arsenal; but like any powerful tool, its effectiveness depends entirely on how it is positioned. The threat actors we encounter in DART engagements don’t look for the most sophisticated path to Domain Admin. They look for the most trusted one. A PAM server in the wrong tier isn’t a hardened barrier; it’s a trusted bridge with a gold-plated sign. 

By aligning your PAM deployment with the principles of Privileged Access Administration, treating session hosts and service accounts as the tier of the assets they manage, not the zone they physically sit in, you close the bridge before a threat actor finds it. 

Build your architecture like a threat actor will find it. Because they will. 

Stay secure, stay tiered.