Somewhere in your environment right now, there’s a service account with domain admin privileges that was created for a migration three years ago and never disabled. There’s a shared root password that six people know and nobody has changed since the last person who knew it left the company. There’s a developer with production database access who hasn’t touched production in eight months but still has the credentials in their password manager.

These are privileged accounts. And they’re the reason most breaches escalate from “initial foothold” to “catastrophic data loss.” Attackers don’t break in with admin credentials — they break in with whatever they can get, then hunt for privilege. The path from compromised help-desk account to domain admin is well-worn, well-documented, and often shockingly short.

The TLDR

Privileged access management (PAM) is the set of controls that govern who can use powerful accounts, when, how, and under what oversight. Privileged accounts — domain admins, root accounts, service accounts, database admins, cloud IAM owners — can modify security configurations, access all data, and cover their tracks. MITRE ATT&CK is essentially a catalog of what attackers do once they have privileged access. PAM controls include credential vaulting (secrets stored in a vault, checked out when needed), just-in-time (JIT) access (privileges granted temporarily and automatically revoked), session recording (every keystroke logged), and standing privilege removal (nobody has permanent admin access). NIST SP 800-53 AC-6 (Least Privilege) and CISA’s guidance on privileged access are the baselines.

The Reality

The numbers paint a grim picture. Privileged credential misuse is involved in a massive percentage of breaches. Verizon’s Data Breach Investigations Report consistently shows credential-based attacks as the leading initial access vector, and privilege escalation as a near-universal step in multi-stage breaches.

The problem isn’t that organizations don’t know privileged accounts are dangerous. The problem is that privileged access is operationally necessary, and the path of least resistance is to give people (and services) more access than they need and leave it that way. Admin accounts accumulate. Service account passwords get embedded in scripts and configuration files. Shared credentials get emailed around. “Temporary” elevated access becomes permanent because there’s no automated mechanism to revoke it.

And then there’s the service account problem. Service accounts — non-human identities used by applications, scripts, and automation — often outnumber human accounts in enterprise environments. They run with elevated privileges because the application “needs” them. They use static passwords because the application “can’t handle” rotation. They’re excluded from MFA policies because they’re “not interactive.” They are, without exaggeration, the most dangerous accounts in most organizations, and they receive the least scrutiny.

How It Works

What Makes an Account “Privileged”

Privilege isn’t just about the “Administrator” or “root” label. Any account that can perform actions with outsized security impact is privileged:

Credential Vaulting

The foundational PAM control is getting privileged credentials out of people’s heads, off sticky notes, and out of config files, and into a dedicated, audited, access-controlled vault.

A credential vault (CyberArk, HashiCorp Vault, BeyondTrust, Delinea, Azure Key Vault) stores privileged credentials centrally. When an admin needs to use a privileged account, they check the credential out from the vault. The vault logs who checked it out, when, and for how long. When they’re done, the credential is checked back in and automatically rotated — the password changes so even if the admin wrote it down, it’s no longer valid.

This is the “break the glass” model for everyday admin work. Nobody memorizes root passwords. Nobody stores them in shared spreadsheets. The vault is the single source of truth, and it enforces policies: approval workflows, time-limited checkouts, automatic rotation after each use.

For service accounts, the vault provides credentials to applications via API. The application requests the current credential from the vault at runtime rather than storing it in a config file. If the vault rotates the credential, the application gets the new one automatically. No more “we can’t rotate because we don’t know what will break.”

Just-in-Time (JIT) Access

The gold standard in PAM is eliminating standing privileges entirely. Instead of granting someone permanent admin access, you grant them zero-standing privileges and the ability to request elevation when they need it.

JIT access works like this:

  1. An admin needs to perform a privileged operation.
  2. They request elevated access through the PAM system, specifying what they need and why.
  3. The request is approved (automatically based on policy, or manually by a manager).
  4. The PAM system grants the elevated privilege for a defined time window (30 minutes, 2 hours, whatever the policy dictates).
  5. When the window expires, the privilege is automatically revoked. No human needs to remember to remove it.

Azure AD Privileged Identity Management (PIM), CyberArk’s JIT capabilities, and AWS IAM Identity Center’s temporary elevated access all implement this pattern. The result: even if an attacker compromises an admin’s account, that account has no elevated privileges unless the attacker also navigates the JIT approval process.

Session Recording and Monitoring

If you’re granting someone the ability to take actions that could destroy your environment, you should be watching. Privileged session management records terminal sessions, RDP sessions, and database queries performed under privileged accounts.

This isn’t about distrust — it’s about accountability and forensics. When something goes wrong in production, session recordings tell you exactly what happened, who did it, and when. They also serve as a deterrent: people behave differently when they know the tape is rolling.

NIST SP 800-53 AU-14 (Session Audit) specifically calls for session recording of privileged activities. Modern PAM tools can also inject real-time monitoring — flagging dangerous commands (like DROP TABLE or rm -rf /) before they execute.

Separation of Admin and Daily-Use Accounts

This one is simple but consistently violated: people who need admin access should have two accounts. Their daily-use account for email, browsing, and documents has standard privileges. Their admin account is used only for administrative tasks and is subject to PAM controls, MFA, and session recording.

The reason is attack surface. Your daily-use account opens emails, clicks links, browses the web — all activities that expose it to phishing, malware, and credential theft. If that account is also a domain admin, a single phishing email is a domain compromise. Separate accounts mean the admin account is never exposed to those attack vectors.

Microsoft calls this the tiered administration model. Tier 0 accounts (domain admins) should only be used on Tier 0 systems (domain controllers). They should never log into workstations, never browse the web, never open email. The credential should never touch a system where it could be harvested.

How It Gets Exploited

Credential Harvesting

Once an attacker has a foothold on a machine, they harvest credentials from memory, disk, and network traffic. Tools like Mimikatz extract plaintext passwords and hash values from Windows LSASS memory — MITRE ATT&CK T1003.001 (OS Credential Dumping: LSASS Memory). If an admin has logged into that machine, their credentials are in memory, waiting to be harvested. This is why admin credentials should never touch standard workstations.

Kerberoasting (T1558.003) is another classic: the attacker requests Kerberos service tickets for service accounts, then cracks the tickets offline to recover the service account passwords. Service accounts with weak passwords fall in minutes.

Lateral Movement via Service Accounts

Service accounts are the superhighway for lateral movement. They often have access to multiple systems, they don’t trigger MFA, their passwords rarely change, and they’re not monitored with the same scrutiny as human accounts. An attacker who compromises one service account credential can often traverse the entire environment. MITRE ATT&CK T1021 (Remote Services) documents the techniques.

Admin Account Persistence

Once attackers have admin access, they create persistence: new admin accounts (T1136), scheduled tasks, modified group policies, backdoor services. If your PAM controls don’t detect the creation of new privileged accounts or modifications to privileged groups, the attacker can maintain access indefinitely — surviving password resets, system rebuilds, and incident response actions.

Pass-the-Hash and Pass-the-Ticket

Windows authentication protocols (NTLM, Kerberos) use hashes and tickets that can be captured and reused without knowing the plaintext password. Pass-the-Hash (T1550.002) reuses NTLM hashes. Pass-the-Ticket (T1550.003) reuses Kerberos tickets. Golden Ticket attacks (T1558.001) forge Kerberos tickets using the krbtgt account hash, granting unrestricted domain access for as long as the hash remains valid.

What You Can Do

Inventory every privileged account. You can’t protect what you don’t know about. Discover all admin accounts, service accounts, and shared credentials. Every one. This is the unsexy first step that makes everything else possible.

Vault privileged credentials. No human should know a production admin password by heart. No config file should contain a hardcoded service account credential. Get them into a vault, rotate them regularly, and audit every checkout.

Implement JIT access. Eliminate standing privileges wherever possible. Admin access should be requested, justified, time-limited, and automatically revoked. This single control dramatically reduces the window for credential-based attacks.

Separate admin and daily-use accounts. Your domain admin account should never open an email or browse a website. Two accounts. Different machines. No exceptions.

Monitor privileged sessions. Record them. Alert on dangerous commands. Review anomalous activity. If someone is running Mimikatz on a domain controller at 3 AM, you need to know about it before they finish.

Audit service accounts ruthlessly. What does each one do? What permissions does it actually need versus what it has? When was the password last rotated? Is it in a vault? If you can’t answer these questions for every service account, you have work to do.

Sources & Further Reading