Chapter 19: Privileged Access Management: Protecting the Keys to the Kingdom

"There are only two types of companies: those that have been hacked, and those that will be." — Robert Mueller, FBI Director, 2012

Overview

The breach that turns a bad week into a catastrophe almost never begins with an administrator account. It begins with a help-desk technician, or a developer's laptop, or a service account that a vendor set up in 2019 and nobody has thought about since. The attacker lands there — through a phished password, a reused credential, a vulnerable web app — and finds, to their delight, that the foothold they stole is already a local administrator, or can reach a server where a domain administrator logged in last Tuesday and left their credentials cached in memory. From that machine the attacker harvests the admin's credential, replays it to the next server, and within hours holds the single account that controls the entire Windows domain. The bank is no longer dealing with a compromised laptop. It is dealing with an adversary who can read every file, reset every password, disable every defense, and deploy ransomware to every endpoint at once.

This is the path nearly every major intrusion travels, and it is the path this chapter is built to close. The accounts that grant administrative power — domain admins, root, cloud root, the database sa account, the vault that holds every other password — are the keys to the kingdom. An attacker who reaches them has won; a defender who protects them has survived even after the perimeter, the endpoint, and the user have all failed. That is exactly the asymmetry from Chapter 1 stated at its sharpest: the attacker needs to compromise one privileged credential, while you must protect every path to every one of them. Privileged Access Management — PAM — is the discipline of changing that math.

You already know how to decide who should have access (the authorization models of Chapter 17) and how to govern identities at scale (the lifecycle and reviews of Chapter 18). This chapter is about the small, dangerous set of accounts where getting it wrong ends the game — and about the specific controls that make those accounts hard to steal, hard to misuse, and impossible to use invisibly.

In this chapter, you will learn to:

• Explain why privileged accounts are the target attackers want most, and trace the escalation from foothold to domain admin step by step.
• Inventory the privileged accounts you actually have (always more than you think) and vault their credentials with automatic rotation.
• Implement just-in-time access so administrators hold power only for the minutes they need it, behind an approval workflow.
• Apply tiered administration and privileged access workstations to break the credential-theft paths that lead to total compromise.
• Record privileged sessions and write detections that catch privileged-account abuse in your logs.

Learning Paths

Privileged access sits at the intersection of architecture, operations, and audit, so every track has a stake — but they read it differently.

🏗️ Security Engineer: This is a core chapter for you. §19.2 (vaulting/rotation), §19.3 (JIT), and §19.4 (tiering and PAWs) are designs you will build and defend. The tiering model in Figure 19.1 is the architecture that prevents the worst day of your career. 🛡️ SOC Analyst: Focus on §19.5 (session recording) and §19.6 (detecting abuse). Privileged-account misuse is the highest-severity alert you will ever triage; learn what it looks like in telemetry before you see it for real. 📋 GRC: PAM is where many audit findings and regulatory expectations land (least privilege, separation of duties, accountability for shared accounts). §19.1 and the Project Checkpoint give you the policy and control language. 📜 Certification Prep: Privileged access, JIT, vaulting, and the tiered model appear on Security+ and CISSP. Every reserved term in this chapter is exam-relevant; the key-takeaways.md file maps them.

19.1 Why admins are the target

Start with the attacker's point of view, because PAM is only legible once you see what it denies them.

An attacker who breaks into an organization rarely lands where they want to be. The phished user is a teller, not a domain admin. The vulnerable web server runs as a low-privilege service account. The compromised laptop belongs to someone in marketing. None of these, by themselves, is a disaster — and that is precisely the gap a mature defense lives in. The attacker's entire post-compromise effort is a campaign to convert some access into privileged access, because privileged access is what makes the objectives — mass data theft, ransomware deployment, persistent control — actually achievable.

A privileged account is any account whose permissions exceed those of an ordinary user in a way that could compromise the confidentiality, integrity, or availability of systems if misused: it can administer other accounts, change security settings, read or alter data broadly, or control infrastructure. The obvious examples are the named ones — Windows domain administrators, Linux root, the AWS root user and high-privilege IAM roles, the database administrator. But the category is much wider than the obvious, and underestimating its size is the first mistake teams make. Privileged accounts include local administrator accounts on every workstation and server; the built-in Administrator and sa accounts; backup operators (who can read everything, by design); accounts that can modify Group Policy (and therefore push code to every machine); hypervisor and storage-array admins; the identity provider's own admins; the service accounts that run applications and scheduled tasks with elevated rights (a non-human account we introduce here and treat fully in Chapter 20); and — the one people forget until it is too late — the accounts that administer the security tools themselves, including the PAM system.

🚪 Threshold Concept: Privilege is not a property of a person; it is a property of an account and a moment. The same human is a low-privilege user when reading email and a domain admin when running a console — and the attacker does not need the human, only the account, and only for the moment it holds power. Once you see privilege as something accounts hold temporarily rather than something people are, the entire design of PAM — vault it, time-box it, record it, tier it — follows naturally. This reframing is the hinge of the chapter.

How a foothold becomes domain admin

To defend the path, you must be able to walk it. Here is the canonical escalation in a Windows Active Directory environment — the architecture Meridian runs — told as the sequence of moves an attacker makes after gaining a single low-privilege foothold. We describe it as a defender must understand it, not as a recipe; every step names the control that breaks it, which is the whole reason we are tracing it.

1. Initial foothold. The attacker controls one ordinary workstation — say, via a phished credential that survived because that user was not yet on phishing-resistant MFA (Chapter 16). They have a normal user's rights and nothing more.

2. Local privilege escalation. They exploit an unpatched local vulnerability, or abuse a misconfiguration, to become a local administrator on that one machine. Often they do not even need an exploit: far too many organizations make every user a local admin on their own laptop "for convenience," handing this step over for free.

3. Credential harvesting. As local admin, the attacker reads secrets out of the machine: cached credentials, tokens, password hashes from memory (the LSASS process), and — crucially — the hashes or tickets of any other account that has logged on to this machine recently. If a help-desk technician used a powerful account to fix this laptop last week, that powerful account's credential material may still be harvestable here.

4. Lateral movement. Armed with a harvested credential, the attacker authenticates to another machine — not by cracking the password, but by replaying the stolen hash or ticket directly (the "pass-the-hash" and "pass-the-ticket" techniques). They do not need to know the password; they reuse the proof of it. Now they control a second machine, and they harvest its logged-on credentials, and they move again.

5. Escalation to domain admin. This loop — land, harvest, move — continues until the attacker harvests a credential belonging to a highly privileged account: a domain administrator, or an account that can reach the domain controllers. The moment they hold a domain admin credential, they own Active Directory, and through it every domain-joined system in the bank.

6. Domain dominance and objectives. With domain admin, the attacker can create accounts, disable logging, push a malicious Group Policy to every endpoint, extract the entire password database (the NTDS.dit file from a domain controller), and deploy ransomware fleet-wide in a single action. This is the difference between "an incident" and "the bank made the national news."

🛡️ Defender's Lens: Notice that steps 3 and 4 depend entirely on a privileged credential being present where the attacker can reach it. If the domain admin had never logged on to that workstation — because tiering (§19.4) forbids it — there would be nothing to harvest. If the powerful credential were checked out from a vault for ten minutes and then rotated (§19.2, §19.3) — the harvested hash would already be dead by the time the attacker replayed it. If the admin used a dedicated, locked-down workstation (§19.4) that ordinary malware never touches, the credential would never be exposed in the first place. Every PAM control in this chapter is aimed at one of the rungs on this ladder. PAM is, fundamentally, the practice of making sure the attacker who lands on rung 1 can never reach rung 5.

This is also Theme 2 (the asymmetry) and Theme 4 (defense in depth) fused into one picture. The attacker needs the chain to complete once; the defender needs to break it at every rung, on the assumption that the earlier rungs have already failed — that the user was phished, that the laptop was compromised. PAM is what you build for the world where those assumptions are true, which is the real world.

What "the keys to the kingdom" are actually worth

It is worth being concrete about the blast radius, because it is what justifies the cost and friction PAM imposes. At Meridian, a single domain admin compromise would expose the file shares holding loan documents and PII, the path to the core-banking environment, the M365 tenant, and the backups — and would let the attacker disable the very monitoring that might catch them. The Cardholder Data Environment (CDE) that PCI-DSS requires Meridian to protect lives behind exactly these accounts. This is why every serious framework treats privileged access as a top-tier control: the CIS Controls devote Control 5 (Account Management) and Control 6 (Access Control Management) to it; NIST SP 800-53 dedicates the entire Access Control (AC) family to least privilege, separation of duties, and least functionality; and bank regulators (FFIEC, in Meridian's case) examine privileged access directly. Privileged access is the one place where a single control failure is reliably fatal — which is exactly why it gets its own discipline, its own tools, and this chapter.

🔄 Check Your Understanding: 1. An attacker phishes a marketing employee with no special permissions. Explain, in terms of the escalation ladder, why this is still potentially the first step toward total domain compromise — and name the one condition that most directly enables step 3 (credential harvesting). 2. Why is "every user is a local admin on their own laptop, for convenience" such a dangerous default? Which rung of the ladder does it hand to the attacker for free?

Answers

1. Even a no-privilege foothold lets the attacker attempt local privilege escalation (rung 2) and then harvest any credentials present on the machine (rung 3); from there, lateral movement and escalation can follow. The condition that most directly enables harvesting is a more-privileged account having logged on to (and left credential material on) a machine the attacker can reach — which tiering is designed to prevent. 2. It eliminates rung 2 entirely: the attacker who lands as that user is already a local administrator, free to harvest credentials immediately, with no exploit required. Removing local-admin rights from ordinary users is one of the highest-value, lowest-cost hardening steps available.

19.2 Vaulting and rotation: ending the shared, standing secret

The most common state of privileged credentials in an immature organization is the worst possible one: a handful of powerful passwords, known to many people, that never change. The domain admin password is in a spreadsheet. The local administrator password is the same on every workstation (a default that, once one machine is compromised, hands the attacker every other machine for free). The database sa password was set during installation in 2018 and is now embedded in four applications, a runbook, and the memory of three people who have since left. Each of these is a standing, shared secret — and standing, shared secrets are the fuel of the escalation ladder in §19.1.

Credential vaulting is the practice of storing privileged credentials in a secured, access-controlled, audited repository — a vault — rather than in people's heads, spreadsheets, scripts, or sticky notes, and brokering access to them so that no human needs to know a privileged password to use it. The vault becomes the single, defensible home for the keys to the kingdom. A privileged user who needs to administer a server does not type a memorized password; they authenticate to the PAM system (with their own identity and strong MFA), request access to the target, and the vault either injects the credential into the session on their behalf or releases it for a tightly bounded window. The human may never see the actual password at all.

Vaulting buys you several things at once, and they map directly onto the ladder:

• No more shared knowledge. Because the vault brokers access, you can give twelve administrators the ability to use the domain admin account without twelve people knowing its password. When one of them leaves, you revoke their vault access; you do not have to change a password that twelve people memorized (and may have written down).
• Accountability for shared accounts. A built-in Administrator account is shared by definition. Without a vault, when it does something destructive, the audit log says "Administrator did it" and you cannot tell which human was behind the keyboard — a separation-of-duties and non-repudiation failure that auditors flag and that §19.5 closes. The vault records which individual checked out the account, when, and for what stated reason, restoring individual accountability to a shared credential.
• A single point to monitor and control. All privileged access now funnels through one system you can watch, alert on, and put approval workflows in front of (§19.3).

The other half of the control is password rotation: automatically changing privileged credentials on a schedule and, ideally, after every use, so that any credential an attacker manages to capture has the shortest possible useful life. Rotation is what turns a stolen secret into a dead secret. If the local administrator password on every workstation is unique and rotated every 24 hours by an automated system, then the credential an attacker harvests in §19.1's rung 3 may already be invalid before they can replay it in rung 4 — and even if it is still live, it works on one machine, not all of them.

Two rotation patterns matter:

• Scheduled rotation changes credentials at a fixed cadence (e.g., every 30 days, or every 24 hours for the highest-risk accounts). This bounds the lifetime of any credential silently stolen and sitting unused.
• One-time / check-in rotation changes the credential immediately after a session ends (the user "checks it back in," and the vault rotates it before the next checkout). This is the gold standard for the most powerful accounts: a credential exposed during a session is worthless the moment the session closes, because it has already been changed.

🔗 Connection: Microsoft's LAPS (Local Administrator Password Solution), which you met in the Windows-hardening discussion of Chapter 11, is a focused, free implementation of exactly this idea for local administrator accounts: it sets a unique, random local admin password on every machine and rotates it on a schedule, storing it where authorized staff can retrieve it. LAPS alone kills the single most abused lateral-movement path — the shared local admin password — and is the cheapest large win in this entire chapter. A full PAM platform generalizes LAPS's pattern to domain accounts, service accounts, network devices, databases, and cloud, with brokering and session control layered on top.

A worked example: vaulting and rotation in practice

Picture Meridian's domain admin account before and after. Before: the password is Meridian$Admin2023, it is in a password manager shared by the four-person infrastructure team and a runbook in SharePoint, and it was last changed eleven months ago when an admin left. After vaulting and check-in rotation:

Privileged session (illustrative, Tier 3):
1. Sam authenticates to the PAM portal with her own account + FIDO2 key.
2. Sam requests "domain-admin on DC role" -> policy check passes (she is authorized).
3. Vault opens an RDP/console session to the jump host as the domain admin account;
   the actual password is INJECTED, never shown to Sam.
4. Sam does her work (12 minutes). The session is recorded (see 19.5).
5. Sam ends the session ("checks in").
6. Vault IMMEDIATELY rotates the domain admin password to a new 40-char random value
   that no human knows or has seen.

Net effect on the 19.1 ladder:
- Nothing for an attacker to find in a spreadsheet (no standing shared secret).
- If credential material leaked during the 12-minute window, it is dead at minute 13.
- The audit log says "SAM checked out domain-admin 14:02-14:14 for change CHG-4471",
  not the anonymous "Administrator did something."

The friction is real — Sam can no longer just paste a memorized password — and managing that friction is the central adoption challenge of PAM (we return to it in §19.3 and the case study). But weigh it against what it buys: the bank's most dangerous credential is now unknown to every human, changes after every use, and cannot be used at all without an authenticated request that lands in a log.

⚠️ Common Pitfall: Vaulting the credentials but leaving a break-glass copy in a way that quietly defeats the whole control. A break-glass account (sometimes "emergency access account") is a highly privileged account reserved for emergencies — when the PAM system, the identity provider, or MFA itself is down and you must still be able to get in. You genuinely need one or two of these; locking yourself out of your own domain during an outage is a real and serious risk. But teams routinely undermine PAM by storing the break-glass password in the same spreadsheet they were trying to retire, or by exempting it from rotation and monitoring "because it's the emergency account." The discipline: store break-glass credentials offline in a sealed, physically secured location (a safe), make them long and random, alert loudly on any use (a break-glass login should page the SOC instantly — its use is always either a genuine emergency or an attack), and test and rotate them on a schedule. The break-glass account is a deliberate, monitored exception — not a backdoor.

🔄 Check Your Understanding: 1. Explain how check-in rotation (rotating a credential immediately after each session) defeats the credential-harvesting rung of the escalation ladder even if the attacker successfully captures the credential during a session. 2. Why does a unique local administrator password per machine (e.g., via LAPS) matter even more than a strong one, when defending against lateral movement?

Answers

1. The harvested credential is rotated to a new value the instant the session ends, so by the time the attacker attempts to replay it, it is no longer valid — its useful lifetime is reduced to the length of the session, and a quietly captured-but-unused credential is dead almost immediately. 2. Strength resists cracking, but lateral movement via pass-the-hash does not require cracking — it replays the credential directly. A shared password (even a strong one) means compromising one machine yields a credential that works on all of them; a unique password per machine confines a harvested credential to the single box it came from, breaking the "move to the next machine with the same key" loop.

19.3 Just-in-time access and approval workflows

Vaulting and rotation fix how a privileged credential is stored and how long it lives. Just-in-time access attacks a deeper problem: the existence of standing privilege at all.

In most organizations, privileged access is standing — an administrator's account is a member of the Domain Admins group every minute of every day, whether they are actively administering something or asleep at home. That account is a permanently armed weapon. If it is compromised at 3 a.m. on a Sunday — when no legitimate admin work is happening — it is just as powerful as it is at 3 p.m. on a Tuesday. Standing privilege means the attacker's window is always open.

Just-in-time (JIT) access grants privileged rights only for the limited time they are actually needed, and removes them automatically afterward — so that, by default, no one holds standing privileged access at all. Instead of being a permanent member of Domain Admins, an administrator is an eligible member: they can request to activate the role, and when the request is approved, they receive the privilege for a bounded window (say, one hour), after which it is automatically revoked. The default state of every powerful account is off. Privilege becomes something you switch on for a task and that switches itself off, not a standing condition.

The security payoff is large and direct: it collapses the attack window. If domain admin rights exist for, on average, two hours per administrator per week instead of 168 hours per week, you have removed roughly 99% of the time during which a compromise of that account would yield active domain admin power. An attacker who steals the account at a random moment now almost always steals an account that currently has no elevated rights and would have to also defeat the activation workflow — with its MFA, its approval, and its alerting — to get them.

JIT typically combines several elements:

• Eligibility instead of membership. Users are made eligible for privileged roles rather than permanent members. Microsoft Entra Privileged Identity Management (PIM) is the best-known cloud implementation; equivalents exist for on-prem AD and for cloud IAM.
• Time-bound activation. When activated, the role is granted for a fixed maximum duration and then automatically removed. No human has to remember to "take the access away" — the failure mode of manual deprovisioning that Chapter 18 warned about is engineered out.
• An approval workflow. High-risk activations require a second person's approval before the privilege is granted. This is separation of duties (Chapter 17) applied to the act of becoming privileged: the requester cannot unilaterally arm themselves.
• Justification and ticket binding. The requester must state why (often tying the request to a change ticket), which both creates an audit trail and adds friction to illegitimate use.

🔗 Connection: JIT is least privilege (the principle from Chapter 3, applied to access in Chapter 17) extended into the time dimension. Chapter 17 asked "what is the minimum set of permissions this role needs?" JIT adds "...and for the minimum length of time?" Standing privilege violates least privilege not in scope but in duration — the admin has more access than they need most of the time, because they need it only some of the time. JIT closes that gap. It is also the first concrete step toward the per-session, continuously-verified access of zero-trust architecture, which we build in Chapter 32.

The approval workflow as a control

The approval step deserves attention because it is where JIT becomes a genuine barrier rather than a speed bump. A well-designed privileged-access request flows like this:

Privileged access request flow (illustrative):

  [Requester] --requests "domain-admin role, 60 min, CHG-4471"-->  [PAM/PIM]
                                                                      |
                                          policy check: eligible? MFA passed?
                                                                      |
                          +-------------------------------------------+
                          |                                           |
                   low-risk role                              high-risk role
                          |                                           |
                  auto-grant, time-boxed                     route to APPROVER
                  (logged + alerted)                                  |
                                                        approver reviews who/why/when
                                                                      |
                                                  approve -> grant 60 min, log, alert SOC
                                                  deny    -> log, no access

Figure 19.2 — A just-in-time privileged-access workflow. Low-risk activations are auto-granted but logged and time-boxed; high-risk activations require human approval (separation of duties). Every path produces a record, and every grant is bounded in time.

The design choices in this flow are all defensive. Routing high-risk roles to an approver means a single compromised account cannot self-elevate to the most dangerous privileges. Binding the request to a change ticket means an analyst reviewing logs later can ask "was there a legitimate change happening at this time?" — and an activation with no corresponding business reason becomes a high-fidelity alert (§19.6). Time-boxing means the privilege evaporates on its own. And requiring MFA at activation time — not just at login — means that even an attacker with a valid session must clear a phishing-resistant factor at the exact moment they try to become powerful.

⚠️ Common Pitfall: Setting JIT activation windows so long, and approvals so rubber-stamped, that "just-in-time" becomes "just-in-name." If every admin activates domain admin for the maximum eight hours at the start of every shift and the approver clicks "approve" on everything without looking, you have reintroduced standing access with extra steps. Keep windows tight (right-size them to real tasks — often 1–4 hours, not 8), make approvers accountable for what they approve, and watch for the activation patterns that signal the control has decayed into theater. The metric to track is average privileged-hours granted per week; if it is not dramatically lower than standing access would be, your JIT is cosmetic.

📟 War Story: A constructed but representative incident. At a mid-size firm, an attacker compromised a senior administrator's account through a token-theft attack that bypassed the login MFA. With standing domain admin, that would have been game over within minutes. But the firm had deployed JIT: the stolen account was merely eligible for domain admin, not a member. When the attacker tried to activate the role, the activation demanded a fresh FIDO2 tap the attacker could not produce, and generated an "off-hours domain-admin activation request" alert that woke the on-call analyst. The attacker never got the privilege; the firm got a two-minute head start and a clean signal. The lesson: JIT does not just shrink the window — it converts the attacker's most important move into a noisy, blockable event.

🔄 Check Your Understanding: 1. In one sentence, how does JIT access reduce risk without changing what permissions a privileged role contains? 2. Why is requiring MFA at the moment of privilege activation — not only at initial login — a meaningful additional control against session/token theft?

Answers

1. By granting the privilege only for a short, bounded window and removing it automatically, JIT shrinks the time during which a compromise of the account yields active privileged power — collapsing the attacker's window even though the role's permission set is unchanged. 2. Because an attacker who steals an existing authenticated session or token has bypassed the login check; demanding a fresh phishing-resistant factor at activation forces them to defeat MFA again at the precise moment they attempt to become privileged — a step a token thief usually cannot complete.

19.4 Tiering and privileged access workstations

Vaulting, rotation, and JIT make privileged credentials harder to steal and shorter-lived. Tiered administration attacks the problem from the other direction: it redesigns the environment so that even a stolen high-privilege credential cannot be harvested from a low-trust place — closing rung 3 of the escalation ladder by architecture rather than by hoping the credential is gone.

The core insight is brutally simple. In §19.1, the attacker escalated by harvesting a privileged credential from a machine they had already compromised. That only worked because a privileged credential had been exposed on that machine — because the admin who manages domain controllers also used that same account to log into ordinary workstations, or because the same account administers both the CEO's laptop and the domain. The credential is only as protected as the least protected place it is ever used. A domain admin credential typed into a malware-ridden laptop is a compromised domain admin credential, no matter how strong the password or how good the vault.

Tiering breaks this by partitioning administrative identities and the systems they manage into tiers by sensitivity, and forbidding credentials from one tier from ever being exposed on a lower tier. Microsoft's classic model (originally "Active Directory tier model," now folded into its Enterprise Access Model) uses three tiers:

              ┌─────────────────────────────────────────────────────────┐
   TIER 0     │  Identity & control plane: domain controllers, AD,       │
  (control)   │  the PAM vault, PKI, the identity provider, anything      │
              │  that can control everything else.                        │
              │  Admins: Tier-0 only. Logon: ONLY to Tier-0 systems,      │
              │  from a Tier-0 PAW.                                        │
              └───────────────▲─────────────────────────────────────────┘
                              │  no credential crosses downward
              ┌───────────────┴─────────────────────────────────────────┐
   TIER 1     │  Servers & applications: the core-banking app servers,    │
  (servers)   │  databases, business apps, member servers.                │
              │  Admins: Tier-1 only. Logon: ONLY to Tier-1 systems.      │
              └───────────────▲─────────────────────────────────────────┘
                              │  no credential crosses downward
              ┌───────────────┴─────────────────────────────────────────┐
   TIER 2     │  Workstations & devices: user laptops, help-desk-managed  │
  (endpoints) │  endpoints — the highest-volume, highest-exposure tier.   │
              │  Admins: Tier-2 only (help desk). Logon: workstations.    │
              └─────────────────────────────────────────────────────────┘

   RULE: A higher-tier credential is NEVER used to log on to a lower tier.
         A Tier-0 admin never types Tier-0 creds on a Tier-2 laptop.

Figure 19.1 — The administrative tiering model. Each tier administers only its own systems, and credentials never flow downward. Because a Tier-0 (domain) credential is never exposed on a Tier-2 (workstation) — where ordinary malware and phished users live — the §19.1 escalation from a compromised workstation to domain admin has no credential to harvest. Tiering severs the ladder by architecture.

Read the model through the attacker's eyes and its power is obvious. The attacker in §19.1 compromised a Tier 2 workstation. In a tiered environment, no Tier 0 or Tier 1 credential has ever been used on that workstation, so there is nothing privileged to harvest there. The attacker can become local admin of that laptop all day; they will find only Tier 2 credentials, which administer other laptops — bad, but bounded, and nowhere near the domain. To reach Tier 0, the attacker would have to compromise a Tier 0 system or a Tier 0 admin's dedicated workstation directly, and those are few, hardened, and heavily watched. Tiering converts "compromise any laptop → own the domain" into "compromise any laptop → own that laptop," which is the entire game.

The discipline tiering requires is real: a person who is both a domain admin and needs to use a normal laptop for email must have two separate accounts — an ordinary Tier 2 account for daily work (email, browsing) and a distinct Tier 0 account used only from a dedicated machine to administer Tier 0. They never log into their email laptop with the Tier 0 account, and they never check email or browse the web from the Tier 0 machine. Enforcing this requires logon restrictions (configured so that Tier 0 accounts are denied the right to log on to Tier 1 and Tier 2 systems at the operating-system level, not merely by policy and good intentions) and the next control: dedicated workstations.

Privileged access workstations

A privileged access workstation (PAW) is a dedicated, hardened, single-purpose computer used only to perform privileged administration — never for email, web browsing, or general productivity. It is the clean room from which you handle the keys to the kingdom.

The reasoning, again, traces the ladder. The most common way any machine gets compromised is through the things ordinary users do on it: opening email attachments, clicking links, browsing the web, running downloaded software. Those are precisely the activities that deliver the malware that harvests credentials. A PAW removes that entire attack surface from the machine where privileged credentials are used: it cannot browse the general internet, cannot read email, runs a strictly allowlisted set of applications (Chapter 11's application allowlisting), is fully patched and hardened, and is locked down so tightly that the usual delivery vectors simply are not present. The admin uses an ordinary workstation for ordinary work and switches to the PAW — a separate physical machine, or a strongly isolated virtual one — only to administer sensitive systems.

PAWs and tiering are complementary: tiering says which credentials may be used where, and the PAW is the hardened where for the most sensitive tiers. A Tier 0 admin uses a Tier 0 PAW; the domain admin credential is only ever exposed on a machine that ordinary malware cannot reach because the machine cannot do the ordinary things that let malware in.

🔗 Connection: Tiering and PAWs are defense in depth (Theme 4, and the principle from Chapter 3) applied to administration: even if vaulting, rotation, and JIT all fail and an attacker captures a live privileged credential, the architecture ensures that credential was never sitting on a machine the attacker could reach. And even if the attacker compromises a PAW, the PAW administers only its own tier — the blast radius is bounded by the tier boundary. No single control is trusted to hold; each assumes the others may fail. This is the same layered logic that will reappear, generalized to every resource and request, in the zero-trust architecture of Chapter 32.

⚠️ Common Pitfall: "Soft" tiering that exists on a slide but not in the operating system. If your tiering is merely a policy ("admins are asked not to use domain accounts on laptops") with no technical enforcement, it will be violated — by a rushed admin during an outage, by a help-desk tech taking a shortcut, by anyone under pressure. The control only works when it is enforced: logon-restriction policies that actively deny Tier 0 accounts the ability to authenticate to lower-tier machines, authentication policies/silos that bind privileged accounts to their PAWs, and monitoring that alerts when a Tier 0 credential appears on a Tier 2 system (which should be impossible, and is therefore a high-fidelity sign that either the control broke or an attack is underway — §19.6). Tiering you cannot enforce is tiering you do not have.

🔄 Check Your Understanding: 1. Explain, using the escalation ladder from §19.1, why a tiered model with enforced logon restrictions prevents a compromised user laptop from leading to domain admin — even if the attacker becomes local admin of that laptop and harvests every credential on it. 2. Why must a privileged access workstation be forbidden from reading email and browsing the web? What attack surface does that restriction remove, and how does it relate to credential harvesting?

Answers

1. In a tiered model, Tier 0/Tier 1 (privileged) credentials are never used on Tier 2 workstations, so a compromised laptop has no privileged credential to harvest — the attacker finds only Tier 2 credentials, which administer other workstations but cannot reach the domain. The downward-flow rule, enforced by logon restrictions, removes the very thing rung 3 depends on. 2. Email and web browsing are the most common malware-delivery vectors; forbidding them removes that attack surface from the machine where privileged credentials are used, so the malware that would harvest those credentials never has a way onto the PAW in the first place. The credential is exposed only on a machine the usual delivery mechanisms cannot reach.

19.5 Session recording and monitoring

The controls so far make privileged credentials hard to steal and hard to use. Session recording and monitoring addresses what happens during the privileged sessions that do legitimately occur — and the ones an attacker manages to obtain anyway. It is the control that makes privileged activity accountable and visible, and it is the bridge from prevention to detection.

Session recording (also called session monitoring) is the capture of a detailed, tamper-resistant record of what is done during a privileged session — the commands typed, the screens shown, the actions taken — so that privileged activity can be reviewed, audited, and investigated. When a PAM system brokers a privileged session (as in §19.2), it sits in the path of that session and can record it: keystroke logs for command-line sessions, video-like screen capture for graphical ones, and a structured event log of what was accessed. The recording is stored where the user being recorded cannot alter or delete it.

Session recording serves three distinct purposes, and it is worth separating them because they justify the control to different audiences:

• Accountability and deterrence. When administrators know their privileged sessions are recorded, illegitimate or careless actions become far less likely — the same reason a bank vault has cameras. Combined with the vaulting from §19.2, it fully solves the shared-account accountability problem: not only do you know which human checked out the Administrator account, you have a complete record of what they did with it.
• Audit and compliance. Regulators and auditors (for Meridian: PCI-DSS, SOX, FFIEC) increasingly expect that privileged actions on sensitive systems are logged and reviewable. Session recording produces exactly the evidence an audit demands: a reviewable trail of administrative access to in-scope systems.
• Incident response and forensics. When an account is compromised, the session recording is the difference between "we think the attacker may have accessed the CDE" and "here is exactly what they ran, what they touched, and when." This is the input to the forensic timeline you will build in incident response — which is precisely why Chapter 24 lists privileged session data among the first things a responder pulls.

🔗 Connection: Session recording is the privileged-access feeding tube into the security-operations machinery you build in Part V. The recordings and the access logs become high-value sources for the SIEM (Chapter 21), the detections of §19.6 below, and — when an incident occurs — the response and forensics of Chapter 24. A privileged session record is one of the highest-fidelity pieces of evidence a defender can have, because privileged actions are exactly the ones an attacker most wants to take and most wants to hide.

Beyond passive recording, mature deployments add real-time session monitoring: live alerting (or even an analyst watching) when a privileged session does something dangerous — running credential-dumping tools, touching the domain controller's password database, disabling logging — with the ability to terminate the session automatically or on command. This turns the recording from a forensic artifact (useful after the fact) into a detective and even corrective control (useful during the attack).

⚖️ Authorization & Ethics: Session recording captures what employees do, and that raises legitimate privacy and legal considerations — especially across jurisdictions with strong worker-privacy protections. Handle it correctly and transparently: record privileged sessions (administrative access to sensitive systems), not general employee activity; disclose the monitoring clearly in policy and at logon so it is no surprise; scope it to the legitimate purpose (protecting the keys to the kingdom and meeting audit obligations), not to surveilling people; and protect the recordings themselves, which contain sensitive actions and sometimes sensitive data, with strict access control. Monitoring privileged access is a well-established and defensible practice — but it must be done deliberately, disclosed, and bounded, not deployed as ambient surveillance.

🔄 Check Your Understanding: 1. Vaulting (§19.2) tells you which human used a shared account. What does session recording add on top of that, and why does the combination fully resolve the shared-account accountability problem auditors raise? 2. Give one way real-time session monitoring is a stronger control than recording alone, in terms of where it sits on the prevent/detect/respond spectrum.

Answers

1. Vaulting attributes the checkout to an individual (who and when); session recording adds what they actually did during the session. Together they convert a shared, anonymous credential into a fully attributable and reviewable action — exactly the individual accountability and auditability that separation-of-duties and non-repudiation requirements demand. 2. Recording alone is detective/forensic — useful after the fact. Real-time monitoring with the ability to alert on or terminate a dangerous session is detective and corrective: it can interrupt the attack while it is happening, not merely document it afterward.

19.6 Detecting privilege abuse

Every control in this chapter assumes the others may fail — that is Theme 4, and it is why detection is the final, non-negotiable layer. Detecting privilege abuse means building the telemetry and the rules that catch a privileged account being misused, whether by an external attacker who reached it, a malicious insider, or an administrator making a dangerous mistake. Even with vaulting, JIT, tiering, PAWs, and recording, you must assume that someday a privileged account will be misused, and you must be able to see it.

Privileged-account abuse has a crucial property that works in the defender's favor: privileged actions are, by definition, rare and significant. A teller's normal day generates thousands of routine events; a domain admin should generate a small, predictable set of privileged actions tied to known changes. That low baseline is a gift — it means deviations stand out sharply, and the detections you write can be high-fidelity rather than drowning in noise. The goal is to alert on the anomalous use of privilege, and the richest detections come from the very controls you have built.

Here are the highest-value privileged-access detections, expressed as the behaviors that should generate alerts:

• Privileged logon from the wrong place. A Tier 0 credential authenticating to a Tier 2 workstation (§19.4) should be impossible under enforced tiering. If you see it, either your control broke or an attacker is moving — either way it is a top-severity alert. (Windows Event ID 4624/4672 with a Tier 0 account on a non-PAW host.)
• Privileged access outside the PAM system. All legitimate privileged access now flows through the vault and JIT. A privileged logon that did not originate from a vault-brokered session is, by construction, suspicious — someone is using a credential the way an attacker would, bypassing the controls. Correlating "privileged logons" against "vault checkout records" and alerting on the difference is one of the most powerful detections PAM enables.
• Off-hours or no-ticket privileged activation. A JIT activation (§19.3) with no corresponding change ticket, or at 3 a.m. on a Sunday with no on-call work scheduled, is a high-fidelity signal — the war story in §19.3 turned exactly this into a save.
• New member added to a privileged group. Direct addition of an account to Domain Admins, Enterprise Admins, or an equivalent (Windows Event ID 4728/4732/4756) — especially outside the JIT workflow — is a classic escalation indicator and should always alert.
• Credential-theft tradecraft on a privileged host. Access to the LSASS process memory, suspicious use of administrative tools on a domain controller, or attempts to read the AD password database (NTDS.dit) are the technical signatures of rungs 3 and 6 of the ladder. Real-time session monitoring (§19.5) and endpoint detection (Chapter 11's EDR) are where these surface.
• Break-glass account use. Any authentication by the emergency account (§19.2) should page the SOC immediately and unconditionally — its use is always either a genuine emergency or an attack, and there is no benign third option that does not warrant a look.

A worked detection, written as the kind of rule you would deploy, makes the pattern concrete:

Detection: privileged logon NOT brokered by the PAM vault (illustrative)

  WHEN  an authentication event occurs
   AND  the account is a member of a privileged group (Tier 0/Tier 1)
   AND  there is NO matching vault checkout record within +/- 2 minutes
  THEN  raise SEVERITY=CRITICAL alert "Out-of-band privileged logon"
        enrich with: account, source host, target host, time
        auto-action: notify on-call IR; consider isolating source host

  Why it works: after PAM, the ONLY legitimate way to use a privileged
  credential is through the vault. Any privileged logon without a
  checkout is, by design, an anomaly worth a human's immediate attention.

Figure 19.3 — A high-fidelity privileged-access detection. Because PAM makes vault-brokered access the only legitimate path, any privileged authentication lacking a corresponding checkout record is anomalous by construction — turning the control itself into a detection.

This is the deepest payoff of PAM and the reason it belongs as much to the SOC as to the engineers: by forcing all privileged access through a narrow, instrumented path, you do not merely make privilege harder to steal — you make its misuse loud. Before PAM, a domain admin logon is just one more event in an ocean. After PAM, a domain admin logon that did not come through the vault is a flare. The controls and the detections reinforce each other: the tighter you constrain the legitimate path, the more sharply illegitimate use stands out.

🛡️ Defender's Lens: The single most valuable habit this chapter can leave you with is to baseline your privileged accounts and alert on deviation. Know which accounts are privileged (the inventory you build in the Project Checkpoint), know where and when they should be used (vault-brokered, ticketed, in-hours, from PAWs), and treat every departure from that baseline as a serious signal. Privileged-account anomalies are the highest-severity, highest-fidelity alerts in your environment — they sit at the top of rung 5, the rung that decides whether an incident is survivable. Tune them carefully, route them to your most experienced analysts, and never let them blend into the noise.

🔄 Check Your Understanding: 1. Why does routing all privileged access through a vault and JIT workflow improve detection, not just prevention? Give the specific anomaly this makes detectable. 2. Why are privileged-account detections generally higher-fidelity (fewer false positives relative to their severity) than detections on ordinary user activity?

Answers

1. Once the vault is the only legitimate path to privileged access, any privileged logon that lacks a matching vault-checkout record is anomalous by construction — so "out-of-band privileged logon" becomes a clean, high-confidence detection that simply did not exist before the control narrowed the legitimate path. 2. Privileged actions are rare and significant against a low, predictable baseline, so genuine deviations stand out sharply; ordinary user activity is high-volume and varied, making anomalies harder to separate from normal behavior. The same scarcity that makes privileged accounts dangerous makes their misuse easier to spot.

Project Checkpoint

Two deliverables grow this chapter, as in every chapter: a section of Meridian's security program and an increment to the bluekit toolkit.

Program increment — the PAM standard (Meridian's domain-admin lockdown). The near-miss that opened this book proved Meridian's identity controls could hold; the access reviews of Chapter 18 revealed how sprawling its privileged footprint had become. This chapter's contribution is Meridian's Privileged Access Management Standard, and the first project under it is the domain-admin lockdown — the work that ends the §19.1 escalation path inside the bank. The standard specifies: (1) a privileged-account inventory — every domain admin, local admin, service account, database admin, and security-tool admin, with an owner and a justification; (2) vaulting and rotation for all of them, starting with LAPS for every workstation and server local-admin account and vault-brokered, check-in-rotated access for domain admins; (3) JIT activation with approval for Tier 0 and Tier 1 roles, so Meridian holds no standing domain admin access; (4) tiering and PAWs — a Tier 0/1/2 model with enforced logon restrictions and dedicated PAWs for Tier 0 administration; (5) session recording of all privileged sessions on in-scope (including CDE) systems; (6) detections for out-of-band privileged logons, off-hours/no-ticket activations, privileged-group changes, and break-glass use; and (7) two break-glass accounts, stored offline, alerting on any use. This is the single highest-leverage section of Meridian's whole program: it is the control set that decides whether a future foothold becomes a contained incident or a front-page breach. (It sets up the secrets and machine-identity work of Chapter 20, and it is the control whose telemetry the incident-response process of Chapter 24 will most depend on.)

bluekit increment — pam.py. We add the toolkit's privileged-access module: one function to triage a privileged-account inventory and one to compute a just-in-time access window. As always, the code is illustrative and hand-traced — the expected output is in a comment, and nothing was executed during authoring.

# bluekit/pam.py  — Chapter 19 increment
"""Privileged Access Management helpers: inventory triage and JIT windows.

privileged_inventory() flags privileged accounts whose hygiene is risky;
jit_window() computes the time-boxed grant for a just-in-time access request.
Illustrative only; hand-traced. Service-account secrets are handled fully in Ch.20.
"""
from datetime import datetime, timedelta

# Max JIT grant (minutes) by tier — tighter for more sensitive tiers.
MAX_MINUTES = {0: 60, 1: 120, 2: 240}


def privileged_inventory(accounts):
    """Return (name, risk_flags) for accounts needing attention. Highest risk first."""
    out = []
    for a in accounts:
        flags = []
        if not a.get("vaulted"):
            flags.append("NOT_VAULTED")
        if a.get("standing"):
            flags.append("STANDING_ACCESS")     # should be JIT-eligible, not a member
        if a.get("shared"):
            flags.append("SHARED_NO_RECORDING") if not a.get("recorded") else None
        if a.get("last_rotated_days", 999) > 90:
            flags.append("STALE_CREDENTIAL")
        flags = [f for f in flags if f]
        if flags:
            out.append((a["name"], flags))
    return sorted(out, key=lambda t: len(t[1]), reverse=True)


def jit_window(req, now=None):
    """Time-box a JIT request to its tier's max; deny if approval is missing."""
    now = now or datetime(2026, 6, 14, 14, 0)          # fixed for a stable trace
    tier = req["tier"]
    if tier <= 1 and not req.get("approved"):
        return {"granted": False, "reason": "approval required for Tier 0/1"}
    minutes = min(req.get("minutes", 60), MAX_MINUTES[tier])
    return {"granted": True, "start": now,
            "end": now + timedelta(minutes=minutes), "minutes": minutes}


if __name__ == "__main__":
    inv = [
        {"name": "DOMAIN\\admin",  "vaulted": False, "standing": True,
         "shared": True, "recorded": False, "last_rotated_days": 330},
        {"name": "svc-backup",     "vaulted": True,  "standing": True,
         "last_rotated_days": 400},
        {"name": "help-desk-adm",  "vaulted": True,  "standing": False,
         "last_rotated_days": 10},
    ]
    for name, flags in privileged_inventory(inv):
        print(f"{name:14s} {','.join(flags)}")
    print("---")
    print(jit_window({"tier": 0, "minutes": 240, "approved": False}))
    print(jit_window({"tier": 0, "minutes": 240, "approved": True}))

# Expected output:
# DOMAIN\admin   NOT_VAULTED,STANDING_ACCESS,SHARED_NO_RECORDING,STALE_CREDENTIAL
# svc-backup     STANDING_ACCESS,STALE_CREDENTIAL
# ---
# {'granted': False, 'reason': 'approval required for Tier 0/1'}
# {'granted': True, 'start': datetime.datetime(2026, 6, 14, 14, 0), 'end': datetime.datetime(2026, 6, 14, 15, 0), 'minutes': 60}

Trace the two functions and notice how they encode the chapter. privileged_inventory ranks the domain admin account at the top because it carries four hygiene failures at once — not vaulted, standing, shared without recording, and stale — exactly the §19.1 profile that turns a foothold into a catastrophe; svc-backup is flagged for standing access and a 400-day-old credential, a textbook Chapter 20 problem. jit_window denies the Tier 0 request that lacks approval (separation of duties, §19.3) and, when approved, clamps the requested 240 minutes down to the Tier 0 maximum of 60 (time-boxing, §19.3) — the tool refuses to grant more privilege, for longer, than the standard allows. You have written, in thirty lines, the logic that decides who holds the keys to the kingdom and for how long.

Summary

This chapter is reference-grade below; reread it before an exam or before designing a privileged-access program.

• Privileged accounts are the prize. A privileged account can administer other accounts, change security settings, or control infrastructure — domain admins, root, cloud root, DBAs, backup operators, local admins on every machine, service accounts, and the admins of the security tools themselves. The category is always larger than it first appears.
• The escalation ladder: foothold → local privilege escalation → credential harvesting → lateral movement (pass-the-hash/ticket) → domain admin → domain dominance. The attacker needs the chain to complete once; the defender breaks it at every rung, assuming earlier rungs have failed. PAM is the discipline of severing this ladder.
• Credential vaulting stores privileged secrets in an audited vault and brokers access so humans need not know a password to use it — solving shared-account accountability. Password rotation (scheduled, and ideally check-in rotation after every session) shortens the useful life of any stolen credential to near zero. LAPS is the cheapest large win: unique, rotated local-admin passwords kill the shared-local-admin lateral-movement path.
• Just-in-time (JIT) access grants privilege only for a bounded window and removes it automatically, so no standing privileged access exists by default. It collapses the attack window from always-on to minutes, and an approval workflow (separation of duties + MFA at activation + ticket binding) turns the attacker's key move into a noisy, blockable event.
• Tiered administration partitions admins and systems into tiers (0 control plane / 1 servers / 2 workstations) and forbids higher-tier credentials from being exposed on lower tiers, severing rung 3 by architecture. Privileged access workstations (PAWs) are dedicated, hardened machines used only for administration — no email, no web — removing the malware-delivery surface from where privileged credentials are used. Both must be enforced (logon restrictions), not merely policy.
• Session recording/monitoring captures a tamper-resistant record of privileged sessions for accountability, audit, and forensics; real-time monitoring can alert on or terminate a dangerous session. Disclose it, scope it to privileged access, and protect the recordings.
• Detecting privilege abuse exploits the low, predictable baseline of privileged activity. Highest-value detections: out-of-band (non-vault) privileged logon; Tier 0 credential on a Tier 2 host; off-hours/no-ticket JIT activation; new privileged-group member; LSASS/NTDS.dit access; break-glass use (always page). Forcing privilege through a narrow instrumented path makes its misuse loud.
• Break-glass accounts are deliberate, monitored emergency exceptions — offline, sealed, long/random, alerting on every use. Needed, but never a backdoor.

Spaced Review

Retrieval practice from earlier chapters, so the concepts resurface at expanding intervals. Answer before scrolling.

1. (Ch.18) In identity governance, what is an orphaned account, and why is an orphaned account that happens to be privileged a far more urgent finding than an orphaned ordinary account? Connect it to this chapter's escalation ladder.
2. (Ch.18) What is an access review (access certification), and how does the inventory-and-review discipline from Chapter 18 feed directly into building the privileged-account inventory in this chapter's Project Checkpoint?
3. (Ch.11) Chapter 11 introduced application allowlisting and host hardening. Explain how both are essential to making a privileged access workstation actually trustworthy.
4. (Ch.11) Why does removing local administrator rights from ordinary users' workstations (a Chapter 11 hardening step) directly defend against rung 2 of the §19.1 escalation ladder?

What's Next

You have now locked down the human privileged accounts — the domain admins and the administrators who hold the keys deliberately. But the most numerous privileged identities in a modern environment are not human at all: the service accounts we only introduced here, the API keys, the certificates, and the workload identities that let one machine authenticate to another, often with broad rights and credentials hard-coded in scripts and config files where they never rotate and anyone can find them. Chapter 20 takes on secrets and machine identity directly — secrets vaults and dynamic secrets, certificate lifecycle at scale, and finding the leaked credentials already sitting in your code — extending the vaulting and rotation discipline you built here to the non-human accounts that now outnumber your people many times over.