Beyond the vault: Zero standing privilege defeats more than password attacks

Part 2 of 3 in our Rethinking Privileged Access series. Start with Part 1: The password was never the only problem.

In Part 1, we drew the line between the vault-and-checkout model of legacy PAM and the session-and-Activities model of modern PAM with Netwrix Privilege Secure (NPS). One protects the password; the other eliminates the standing privilege behind it. That framing is a good starting point, but it understates the case. In Windows and Active Directory, the password is just the seed. Everything an attacker uses to move laterally is derived from it or issued because of it: an NTLM hash, a Kerberos ticket, a cached logon, a certificate, a DPAPI blob. A PAM tool that protects only the password protects one link in a much longer chain.

This is where the real difference between legacy PAM and modern PAM shows up. Vaulting hides the password, but it doesn't touch anything downstream of it. NPS removes standing privilege by rotating, disabling, or deleting accounts the moment a session ends. That interrupts several of those downstream attack paths, because most of them depend on a privileged account existing, in a usable state, for longer than it needs to. NPS doesn't, however, prevent AD threats like Kerberoasting outright. Other Netwrix products, such as Netwrix Threat Prevention, can help by detecting suspicious authentication activity.

The credential surface nobody vaults

Here's what's attackable in a Windows/AD environment beyond the plaintext password:

• NTLM hashes: usable directly via Pass-the-Hash, no cracking required.
• Kerberos tickets (TGT/TGS): stealable and replayable via Pass-the-Ticket, and forgeable via Golden and Silver Tickets if the krbtgt key or a service account's key is compromised.
• Kerberoastable/AS-REP roastable material: any domain user can request a service ticket for an SPN-bearing account, or an AS-REP for a pre-auth-disabled one, and crack it offline.
• Cached domain credentials (MSCACHEv2): sitting in the local SECURITY hive of any machine a user has logged into.
• Certificates and msDS-KeyCredentialLinkExpand entries: abusable through AD CS template misconfiguration or Shadow Credential attacks, authenticating as a user without ever touching their password.
• LAPS/gMSA managed passwords: protected only by the ACL on the attribute that stores them.
• DPAPI-protected secrets: decryptable if an attacker derives the user's master key or steals the domain DPAPI backup key.

None of these require the plaintext password, and all of them grant something close to it.

Why standing privilege is the common thread

Almost every item on that list is powerful only because the account behind it holds real privilege right now, and stays that way indefinitely. A legacy PAM setup, with a vaulted, rotated, injected password sitting on top of a permanent Domain Admin membership, still leaves an NTLM hash worth stealing, a TGS worth roasting, and a cached logon worth cracking between checkouts.

The NPS account models (requestor, managed, and ephemeral, covered in full in Part 1) attack that shared root cause directly. Managed accounts are disabled and rotated again the moment a session ends, ephemeral accounts are deleted outright, and even requestor accounts carry elevated group membership only for the session's duration.

Because privilege has a start and end time instead of existing forever, most of the attacks above lose their target the instant the session closes. NPS doesn't need to detect the attack because there's nothing left worth attacking.

Mapping the attacks to what NPS changes

With NPS, a compromised account carries limited privilege, which caps the damage it can do.

Two features that widen the effect further

Two of the non-account Activities in NPS, both introduced in Part 1, are worth calling out again here because they extend this same logic past credentials:

• RDP enable/disable. Most servers leave RDP listening permanently. NPS can turn it on only for the duration of a session and off immediately after. That removes a large, constantly available piece of attack surface that has nothing to do with which credential an attacker holds.
• Protection mode. Scanning Windows and Linux resources for unapproved local accounts catches a different failure mode: an insider (or an attacker who has already gotten in) quietly creating a standing account for later use. NPS applies the same "don't let unmanaged privilege accumulate" philosophy to accounts it didn't create.

What this doesn't replace

NPS is effective against attacks that depend on a privileged account persisting in a usable state, which covers a surprising amount of the Windows credential-attack catalog. But it doesn't touch attacks that operate independently of any single account's real-time status: a Golden Ticket forged from a stolen krbtgt key, AD CS template abuse, a Shadow Credential written to an attribute, or theft of the domain-wide DPAPI backup key. Those need their own hygiene (krbtgt rotation discipline, certificate template review, attribute-write monitoring, backup-key protection) regardless of how disciplined the session and Activity model is.

The takeaway

Legacy PAM vaults a password and protects one artifact. Eliminating standing privilege shrinks the value of almost everything downstream of that password: hashes, tickets, cached logons, and managed-account attributes. Those artifacts are only worth stealing if the privilege behind them is still there when the attacker goes to use it. NPS won't stop every credential-based attack in Active Directory, but it can close off far more of that attack surface than "protect the password" ever could.

Up next in this series

Everything above assumes accounts run fully on the NPS account models. Part 3 covers Bring Your Own Vault (BYOV): how NPS layers this same session-based protection on top of a vault you're already running (a legacy PAM vault, CyberArk, BeyondTrust, HashiCorp Vault, or LAPS), so you can start reducing this exposure without migrating everything at once.