Three Windows Controls That Make Credential Theft Harder

Credential theft in Windows is not new. Neither is lsass.exe. Neither is the uncomfortable truth that one good credential grab can turn “we have an endpoint alert” into “why is that account touching the backup server overnight?”

Tools such as Mimikatz made LSASS credential theft famous because they made an old idea very usable. Get enough local access, read or dump the wrong process memory, harvest useful secrets, and the attacker gets to stop guessing passwords like it is still 2007.

Windows has improved. Defenders have better controls. Attackers have adapted. Everyone is still arguing about admin rights.

This post is about three hardening controls that are reasonably approachable, produce real security value, and work well together against common Mimikatz-style credential dumping paths:

1. remove unnecessary Debug programs assignments and SeDebugPrivilege
2. run LSASS with Local Security Authority protection
3. enable memory integrity, also known as Hypervisor-protected Code Integrity (HVCI), where the estate can support it

Two of these are explicitly in ASD’s Essential Eight maturity model: memory integrity and Local Security Authority protection. Removing unnecessary debug privilege is the less celebrated sibling in this post. It is still useful. Not every good control needs a committee-approved poster.

What LSASS attacks need

LSASS is not just another process with a mildly ominous all-caps name. The Local Security Authority validates sign-ins, enforces local security policy, and manages credential material that attackers would very much like to borrow permanently.

A common credential dumping workflow needs some combination of:

• useful local privilege
• access to LSASS memory or a dump of it
• a way to inject, load or use code at the right trust level
• weak enough kernel and process protections that the attempt survives contact with Windows

That matters because the three controls below interfere with different parts of the workflow. One removes a very convenient privilege. One directly protects LSASS from standard read and injection attempts. One makes kernel-assisted bypass work harder, especially when drivers are involved.

None of them make credential theft impossible. Security marketing departments do enjoy a silver bullet. Windows attackers enjoy finding out it was made of PowerPoint.

1. Remove debug privilege where it is not needed

The Debug programs user right maps to SeDebugPrivilege. Microsoft describes it as the right to attach a debugger to any process or to the kernel. That is useful for real debugging work. It is also extremely useful when malware wants broad process access and the operator would prefer LSASS not to be treated like a buffet.

The default conversation often stops at “admins are admins anyway”. That is not a reason to spray powerful rights around more widely. It is a reason to restrict local administration as well.

Removing unnecessary debug privilege helps in two ways:

• it reduces the easy path to process-memory access for users and groups that never needed debugging rights
• it reduces a privilege that can be abused well beyond LSASS by malware interested in other protected or sensitive processes

It is not a complete defence once an attacker has strong enough local control. A sufficiently privileged attacker may still alter policy, use another access path, or move down into kernel territory. The point is to stop handing out a handy credential-dumping tool and calling it operational convenience.

Implement it

Use policy for the assignment:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Debug programs

Review the assigned groups, identify why each one is there, and remove anything that is not a deliberate debugging requirement. If a production exception is unavoidable, make it scoped, time-bound and boring enough to survive an audit.

For a quick local check of the current token:

whoami /priv | Select-String -Pattern "SeDebugPrivilege|Debug"

For a representative endpoint check of the exported local user-right assignment:

$exportPath = Join-Path $env:TEMP "user-rights.inf"

secedit /export /cfg $exportPath /areas USER_RIGHTS | Out-Null
Select-String -Path $exportPath -Pattern "^SeDebugPrivilege"

That tells you what landed locally. Your GPO or endpoint management evidence should still be the source of truth for fleet rollout.

2. Make LSASS a protected process

Local Security Authority protection runs LSASS as a protected process. Microsoft’s LSA protection guidance says the feature prevents non-protected processes from reading LSASS memory and injecting code into it.

That is why this is the most directly relevant control in the set. If the attacker brought a standard credential dumping workflow that expects ordinary admin-flavoured access to LSASS, LSA protection is where that plan should start making sad noises.

ASD calls for Local Security Authority protection functionality in the Essential Eight maturity model. Windows 11 has also improved default behaviour on eligible new enterprise-joined installations, but enterprise hardening should be verified, not assumed because the laptop was purchased this financial year.

There are two operational details worth taking seriously:

• test LSA plug-ins and drivers before broad enablement, including password filters, smart card components and cryptographic plug-ins
• prefer the UEFI lock option where your rollback and support model can handle it, because it makes casual remote disablement harder

Microsoft documents Code Integrity audit events for plug-ins and drivers that would fail under protected LSASS. That is your warning light. Use it before turning a workstation ring into a mystery sign-in incident.

Implement it

For Windows 11 22H2 and later, the Local Group Policy path is:

Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process

For domain rollout across supported Windows versions, Microsoft also documents using Group Policy Preferences to set the RunAsPPL registry value under:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

The option matters:

• RunAsPPL = 1 enables LSA protection with UEFI lock
• RunAsPPL = 2 enables it without UEFI lock on Windows 11 22H2 and later

Check the configured value:

Get-ItemProperty `
  -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
  -Name "RunAsPPL" `
  -ErrorAction SilentlyContinue

Check the Code Integrity operational log during audit and rollout:

Get-WinEvent `
  -LogName "Microsoft-Windows-CodeIntegrity/Operational" `
  -MaxEvents 200 |
  Where-Object Id -in 3033, 3063, 3065, 3066 |
  Select-Object TimeCreated, Id, ProviderName, Message

LSA protection will not save a host that is already losing at the kernel layer. It does, however, remove a lot of ordinary LSASS abuse that was relying on “local admin means process memory is fair game”.

3. Turn on memory integrity where compatible

Memory integrity is Microsoft’s VBS-backed kernel code integrity control. You will also see it called HVCI. ASD’s Essential Eight FAQ calls out that naming overlap, which is helpful because Windows hardening already has enough labels to make a naming committee blush.

This control is not LSASS-only. That is part of its value.

Microsoft’s memory integrity guidance describes it as a VBS feature that hardens Windows by running kernel-mode code integrity in an isolated environment and restricting kernel memory allocations that could be used to compromise the system.

For credential dumping, that matters when the bypass path tries to get clever:

• malicious kernel code is less welcome
• driver-assisted attacks have a harder environment to work in
• attempts to bypass process protections through kernel tampering face a stronger control stack

It also helps with malware that is not currently obsessed with LSASS. Kernel-level compromise is bad for many reasons. “At least it did not dump credentials first” is not a reassuring post-incident finding.

Implement it

For managed endpoints, start with Intune settings or Group Policy and pilot on hardware and application rings that actually represent the estate.

The Group Policy path is:

Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security

Under Virtualization Based Protection of Code Integrity, select the memory integrity option that matches your support model. Microsoft warns that incompatible applications or hardware drivers can malfunction, and rare cases can include boot failure. That is not a reason to avoid the control forever. It is a reason to run compatibility testing before announcing success in a slide deck.

Verify the local VBS and Device Guard state:

Get-CimInstance `
  -ClassName Win32_DeviceGuard `
  -Namespace "root\Microsoft\Windows\DeviceGuard" |
  Select-Object VirtualizationBasedSecurityStatus,
    SecurityServicesConfigured,
    SecurityServicesRunning

Use that with your endpoint management reporting and driver compatibility findings. One green lab machine is not fleet assurance.

The stack is the win

Each control changes the attack differently:

Control	What it changes
Remove unnecessary SeDebugPrivilege	Reduces easy process-memory access and removes a powerful privilege from users and groups that do not need it
LSA protection / PPL	Directly blocks many standard LSASS memory read and code injection attempts
Memory integrity / HVCI	Hardens kernel code integrity and raises the cost of driver-assisted or kernel-assisted bypass work

Together, they are a strong quick-win baseline against commodity and many intermediate credential dumping workflows. They do not erase the need for patching, EDR, application control, logging, privileged access hygiene or incident response. They also do not excuse persistent local admin sprawl because a dashboard says HVCI is enabled.

In a healthcare or hybrid enterprise environment, I would keep the rollout practical:

• start with privileged workstations and representative endpoint rings
• restrict local administrator access instead of treating it as an emotional support permission
• monitor LSASS access and dump attempts
• monitor suspicious and vulnerable driver loads
• watch Code Integrity, VBS, memory integrity and LSA protection events
• record the rollback path before locking firmware-backed settings

Credential Guard is the next conversation

Credential Guard deserves its own planning discussion. Microsoft’s Credential Guard overview describes it as using virtualization-based security to isolate secrets so only privileged system software can access them.

That is important because memory integrity protects kernel integrity, while Credential Guard more directly changes where valuable credential material lives and how it is exposed. It is a stronger credential-theft control for this problem space. It can also carry more compatibility and operational considerations, particularly around authentication behaviour, platform support and legacy dependencies.

So yes, consider it. Especially for privileged workstations and higher-risk endpoints. Just do not pretend it is the same size change as removing a careless debug privilege assignment.

The short version

If you want three controls that produce Windows credential-theft value without beginning with the most difficult control in the room:

1. remove unnecessary Debug programs assignments
2. enable LSA protection for LSASS
3. enable memory integrity where drivers and applications can support it

LSA protection is the most LSASS-specific prevention control here. Debug privilege removal strips away an easy abuse path. Memory integrity strengthens the ground under both of them by making kernel compromise and driver-based bypass work less comfortable.

Attackers do not need defenders to be perfect. They need defenders to leave enough cheap paths open.

Close a few.

• MadDogWarner