Privileged Access Management (PAM)

What it is

Privileged Access Management is the security discipline focused on the small set of accounts that can do the most damage if abused. These accounts are different from ordinary user accounts in a few specific ways: they have elevated permissions, they often act on behalf of systems rather than individual people, and they bypass many of the controls that protect normal access.

The account types that fall under PAM include:

• Domain administrators. Accounts that control Active Directory, group policy, and the entire authentication infrastructure of a Windows environment. A compromised domain admin account is, for most organisations, game over.
• Root and superuser accounts on Linux and Unix systems. Including the root user itself, sudo-capable users, and accounts with broad system permissions.
• Cloud root and master accounts. AWS root user, Azure global administrator, GCP organisation owner. These accounts can do anything to the entire cloud environment, including delete it.
• Database administrators. SQL Server sa, Oracle SYS, MongoDB root. Direct access to the data the organisation depends on.
• Service accounts. Non-human identities used by applications, scripts, and automated processes. They typically have broad permissions, do not have MFA, and rarely rotate their credentials.
• Application administrators. Salesforce admin, Workday admin, ServiceNow admin, GitHub organisation owner, and similar. Each SaaS platform has its own privileged tier.
• RPA service accounts. Robotic process automation accounts that automate business processes often need access across many systems and tend to accumulate broad permissions over time.
• Network device admins. Firewall, switch, router, and load balancer accounts that control how traffic flows.
• Security tooling accounts. SIEM admin, EDR console admin, vulnerability scanner admin. Often treated less rigorously than they should be, given that they can disable other security controls.

Each of these account types is a high-value target because compromising one of them dramatically reduces the work the attacker has to do to achieve their objective.

Why it matters

Privileged accounts appear in every serious attack. The kill chains for the major ransomware families, the data breaches that produce regulatory action, and the espionage operations that hit headlines all pass through privileged access at some point.

The pattern is consistent. The attacker gains an initial foothold through phishing, stealer logs, an exploited vulnerability, or social engineering. From there, they pivot toward privileged accounts. Once they reach a domain administrator, a cloud root, or a database admin, the rest of the operation (data exfiltration, ransomware deployment, persistence) becomes straightforward.

A few specific consequences of inadequate PAM:

The blast radius is unbounded. A normal user account that gets compromised affects the data and systems that user can access. A domain admin that gets compromised affects everything in the directory.

Privileged accounts often have weak protection. The shared admin password is in a spreadsheet. The root password has not changed in five years. The service account is using a 2017 hash. Privileged accounts paradoxically receive less rigorous identity protection than executive accounts in many organisations.

Detection is harder. Privileged accounts do many things by design. Distinguishing legitimate admin work from malicious admin work requires context and baselining that ordinary monitoring lacks.

Remediation after compromise is expensive. Cleaning up after a domain admin compromise typically involves rebuilding portions of the environment, rotating thousands of credentials, and assuming persistent compromise of any system the account touched. Most organisations are not prepared for the scale of work this represents.

The Maersk NotPetya incident in 2017 is the canonical illustration. The attackers obtained a single domain admin credential, propagated through the network using legitimate Windows administration tools, and destroyed roughly 49,000 endpoints in hours. The recovery cost was estimated at $300 million. The pattern has repeated across every major ransomware incident since.

How attackers exploit it

Modern attackers move through environments using techniques specifically designed to find and abuse privileged credentials. The MITRE ATT&CK framework documents dozens of relevant techniques, but the patterns reduce to a small set of recurring motifs.

Credential harvesting on compromised endpoints. Once an attacker has any foothold, they look for cached credentials, password files, browser-stored secrets, and configuration files containing service account credentials. Tools like Mimikatz, Impacket's secretsdump, and various living-off-the-land utilities extract these from a compromised Windows endpoint in seconds.

Service account abuse. Service account passwords are often stored in scripts, configuration files, scheduled tasks, and source control. Attackers know this. A newly compromised file server commonly contains references to multiple service accounts the attacker can then use across the environment.

Kerberoasting. A Windows-specific technique that requests service tickets for accounts with service principal names, then cracks the resulting tickets offline to recover passwords. Service accounts with weak passwords fall to kerberoasting routinely.

Pass-the-hash and pass-the-ticket. Reusing credential material extracted from one system to authenticate to another, without ever knowing the underlying password. These techniques work against environments without explicit credential isolation between systems.

Privilege escalation through over-privileged accounts. A user who is a local admin on their laptop becomes a domain admin if they log into a server where a domain admin's session is cached. Lateral movement through these patterns is often invisible to traditional monitoring.

Cloud privilege escalation. Cloud environments have their own escalation patterns: assuming roles with broader permissions, abusing IAM trust relationships, exploiting misconfigured service principals. The Capital One breach in 2019 used cloud privilege escalation to access data that the directly compromised account could not have reached.

Phishing and social engineering targeting administrators. IT staff and administrators are themselves targets, and the attacker who compromises an admin account skips most of the lateral movement work.

What PAM tools actually do

The PAM market is mature, with several established vendors: CyberArk, BeyondTrust, Delinea (formerly Thycotic and Centrify), HashiCorp Boundary, Saviynt, and a growing set of cloud-native challengers. They differ in detail, but the core functionality is similar.

Credential vaulting. Privileged credentials are stored in a hardened, encrypted repository rather than scattered across spreadsheets, scripts, and admin documentation. Users and applications retrieve credentials through the PAM platform when they need them.

Automatic password rotation. The PAM tool periodically (often after every use) changes the password on the target system and updates its vault. The credential the attacker stole yesterday no longer works today.

Session brokering. Instead of giving the user a password, the PAM tool initiates a session on behalf of the user. The user never sees the actual credential. The session is recorded and audited.

Session recording. Every privileged session is recorded for forensic and compliance purposes. Some tools also flag suspicious commands in real time.

Just-in-time (JIT) access. Privileges are granted for a specific task and revoked when the task is finished. Standing privileged access becomes the exception rather than the rule.

Approval workflows. Sensitive privileged actions require approval from a colleague, a manager, or a security team member before execution. The approval requirement adds friction by design.

Multi-factor authentication enforcement. PAM platforms typically enforce MFA on every privileged session, often with stricter requirements than the rest of the environment.

Secret management for applications. Modern PAM and adjacent secret management tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) provide programmatic interfaces for applications to retrieve credentials at runtime, eliminating the hardcoded password problem.

A well-implemented PAM deployment removes most of the credential harvesting opportunities attackers depend on. Mimikatz cannot extract a password that is rotated automatically every hour. Pass-the-hash is harder when sessions are brokered through a PAM gateway. Kerberoasting is much less productive when service account passwords are long and rotate.

How to detect privileged credential abuse

Even with PAM in place, monitoring matters. The signals worth tracking:

• Privileged authentication anomalies. A domain admin authenticating from a new endpoint, an unusual location, or at an unusual hour. A service account authenticating interactively when it should only run as a service.
• Credential access patterns. PAM platforms log every credential checkout. Unexpected checkouts (a user accessing credentials they have never touched, a sudden surge in checkouts from one user) are high-fidelity signals.
• Privileged action anomalies. Group changes, GPO modifications, federation changes, IAM policy changes. These are the actions attackers take after they have privileged access.
• Service account behaviour changes. Service accounts that suddenly access different resources, run different commands, or operate from different IPs warrant attention.
• Stealer log monitoring for admin credentials. Privileged credentials sometimes show up in stealer logs from infected admin endpoints. Daily monitoring catches these before attackers can use them.

The Active Directory environment in particular has a rich set of detection opportunities through Windows event logs, but most organisations do not configure logging adequately to catch the relevant patterns. Event 4624 with logon type 9 (NewCredentials), event 4672 (special privileges assigned), and event 4688 (process creation) are starting points.

How to remediate after privileged credential compromise

If a privileged account compromise is confirmed:

1. Assume any system the account touched is compromised. This is the conservative default and the realistic one in most cases.
2. Rotate the credential immediately. Including in the PAM vault, in any scripts that referenced it, and in any application that uses it.
3. Invalidate sessions. Domain controllers, cloud platforms, and applications all need session invalidation. Kerberos tickets, OAuth tokens, SAML sessions all have to be revoked.
4. Reset the krbtgt password twice in Active Directory environments. The double-reset invalidates any forged Kerberos tickets the attacker may have created.
5. Audit all changes the account made. Group memberships, GPO modifications, scheduled tasks, services created, federation changes. Each can be a persistence mechanism.
6. Hunt for lateral movement. Where else did the attacker go? Did they create additional accounts? Did they install backdoors? Did they exfiltrate data?
7. Plan for the broader recovery. Major privileged credential compromises sometimes require rebuilding the directory, re-imaging endpoints, and rotating thousands of credentials.

The cost and time of remediation scale steeply with the elapsed time before detection. A privileged compromise caught within hours typically resolves with rotation and monitoring. A privileged compromise caught after weeks of dwell time often requires a partial environment rebuild.

Best practices

• Tier your administrative model. Tier 0 (domain admins, cloud roots, identity providers), Tier 1 (server admins), Tier 2 (workstation admins) each get their own dedicated accounts and dedicated workstations. A Tier 0 admin never logs into a Tier 2 system from a Tier 0 account.
• Use dedicated privileged access workstations (PAWs). Hardened endpoints used only for administrative work, with no internet access, no email, and tight control over what runs on them. The Microsoft secured workstation guidance details this approach.
• Enforce JIT access for sensitive privileges. Standing membership in domain admin or global admin groups is the configuration to avoid. Time-limited elevation for specific tasks is the alternative.
• Implement strong MFA on all privileged accounts. Phishing-resistant factors (FIDO2, smartcards) for the highest tier.
• Monitor for privileged credentials in stealer logs and breach data. A leaked admin credential is an emergency, and external monitoring catches what internal controls cannot.
• Inventory and rotate service account credentials. Document every service account, identify owners, and rotate on a defined schedule. Eliminate orphaned and unused service accounts.
• Avoid shared admin accounts where possible. Each privileged action should map to a specific human. PAM tools enable this even when the underlying system requires a single shared account.
• Practice privileged credential incident response. Tabletop exercises that walk through a domain admin compromise reveal gaps in playbooks long before a real incident does.

What PAM does not solve

PAM is powerful but bounded. Several risks fall outside its scope:

• Application vulnerabilities that bypass authentication entirely. A SQL injection that reads the database directly does not need a database admin account.
• Insider abuse by legitimate privileged users. PAM logs the activity, but stopping a determined administrator who has decided to abuse their access is harder. Separation of duties and approval workflows help, but a single insider with the right combination of permissions can still cause significant damage.
• Compromise of the PAM platform itself. PAM is high-value infrastructure. The platform requires its own protection, and several real incidents have involved attackers compromising the PAM platform to extract every credential it managed.
• Identity provider compromise upstream. If an attacker compromises Active Directory, Okta, Entra ID, or another identity provider at the root, every PAM control downstream is moot.
• Hardcoded credentials in code, configurations, and infrastructure-as-code repositories. PAM helps if the credentials are managed through it. Credentials that bypass PAM stay vulnerable to source code leakage.

PAM is a foundational control. It reduces the privileged credential attack surface substantially. It is not a substitute for the rest of the security programme.