Hardening Windows Logon: Account Policy, LSASS Protection, and the Credential-Theft Surface

Almost no serious intrusion ends on the machine it started on. The first box is a foothold; the prize is everything that foothold can reach. And the currency that buys it is not a fresh exploit — it is credentials. An attacker who lands as a local user, then harvests a cached domain hash or a logged-on admin’s token, doesn’t need a second zero-day to move laterally. They authenticate, like a real user, to the next machine. The Windows logon and authentication stack is where that theft is either easy or hard, and it is one of the least-audited surfaces on a typical machine because nothing about it shows up in a vulnerability scan. Patch level has no opinion on whether your LSASS process is protected or your account lockout policy exists.

This is the credential-theft surface: the set of configuration choices that decide whether one compromised box stays one box, or becomes the whole network. Here is each piece, why it matters, and how to read it on the machine in front of you.

1. Account Policy: The Door Brute Force Knocks On

Before an attacker steals a credential, they often try to guess one — against RDP, against SMB, against a local admin account that ships with a predictable name. Two policies decide whether that guessing is cheap or expensive: account lockout and password policy. A machine with no lockout threshold is an unlimited guessing range; an attacker can throw millions of passwords at it and the only cost is time.

# Account lockout + password policy, as currently enforced:
net accounts

# The full local security policy, exported for review:
secedit /export /cfg $env:TEMP\secpol.cfg
Select-String -Path $env:TEMP\secpol.cfg -Pattern 'Lockout|Password|MinimumPasswordLength'

Read four numbers. LockoutThreshold should be set (a handful of bad attempts, not zero, which means “never lock”). LockoutDuration and the reset window should be long enough to make online guessing pointless. MinimumPasswordLength belongs in the 14+ range for any account a human types. The single most common finding here is a lockout threshold of 0 — the default on a fresh standalone install — which quietly converts every network-reachable logon into an offline-speed online attack. Setting it is one line and closes an entire technique.

2. Cached Credentials and the LSASS Vault

Once an attacker has code execution, the target shifts from guessing a password to stealing one that is already in memory. The Local Security Authority Subsystem Service — lsass.exe — is where Windows keeps authentication secrets for logged-on sessions: hashes, Kerberos tickets, sometimes more. The entire Mimikatz family exists to read that process. Three settings shrink what is there to steal and how easily it can be read.

• LSA Protection (RunAsPPL) — runs LSASS as a protected process so an ordinary admin-level handle cannot read its memory. It is off by default on most installs and is one registry value to enable. This alone defeats the most common credential-dumping path.
• Cached logon count — Windows caches domain credentials so you can log in when the domain controller is unreachable. Convenient for laptops, and exactly what an attacker scrapes from a machine that hasn’t talked to the DC. Lowering CachedLogonsCount (often to 1 or 2) limits the haul.
• WDigest — a legacy protocol that, when enabled, stores cleartext passwords in LSASS. It should be explicitly disabled; on older or upgraded machines it sometimes is not.

# Is LSASS running protected (RunAsPPL = 1)?
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name RunAsPPL -EA SilentlyContinue

# WDigest must NOT store cleartext (UseLogonCredential should be 0 or absent):
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential -EA SilentlyContinue

# How many domain logons are cached on this box:
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' -Name CachedLogonsCount -EA SilentlyContinue

On machines that support it, Credential Guard goes further, using virtualization-based security to isolate those secrets from the OS entirely — the strongest available answer, and worth confirming on hardware that can run it.

3. NTLM and the Downgrade Problem

Even with LSASS locked down, the protocol a machine will accept for authentication matters. NTLM — especially NTLMv1 and the LM hash before it — is weak by modern standards and is the basis for relay and pass-the-hash attacks. The relevant control, LmCompatibilityLevel, decides whether the machine will still speak those legacy dialects. Set too low, the machine happily downgrades to a protocol an attacker can break or relay.

# LM/NTLM compatibility - 5 = send NTLMv2 only, refuse LM & NTLMv1:
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -EA SilentlyContinue

The goal is to refuse LM and NTLMv1 outright (level 5 where the environment allows it) and, ideally, restrict outbound NTLM so a coerced authentication can’t be relayed to a juicier target. This is the configuration that turns “poison a name-resolution request, relay the hash, own the file server” from a one-step move into a dead end.

Auditing All of This for Free

None of these are exotic checks — they are registry values and policy settings — but there are enough of them, scattered across the registry and the local security policy, that doing it by hand every time is how it quietly stops getting done. This is precisely the mechanical sweep a posture audit is for. On the machine in front of you, the full credential-theft surface — account policy, LSA protection, WDigest, cached logons, NTLM level, Credential Guard — reads in seconds, at full depth, free:

# Audit the logon/authentication surface (and everything else) - full depth:
winsentinel --audit

# Capture it as a baseline you can diff against next month:
winsentinel --audit --format json --out logon-baseline.json

# Remediate the weak settings that don't belong:
winsentinel --fix-it

This is the gap a vulnerability scanner can’t see. “Is the software patched?” and “will this machine hand its cached hashes to whoever lands on it?” are different questions. A fully patched box with LSA Protection off, WDigest storing cleartext, and a lockout threshold of zero is a textbook lateral-movement launch pad — and a clean CVE report says nothing about it. Configuration state is what an attacker actually exploits once they’re in, and configuration state is exactly what an audit reads.

Where It Becomes an Org Problem

On a single machine, this is complete. Every check above — account policy, LSASS protection, NTLM level, cached credentials — runs free and at full depth on the box you own; there is no “upgrade for the real checks.” The problem changes shape at scale. The danger to an organization is not one laptop with WDigest enabled; it is that you cannot see which machines drifted. One legacy GPO, one imaging template built before LSA Protection was a habit, one app that flipped UseLogonCredential back on — and the cleartext-credential weakness now lives on an unknown subset of your fleet. From any single box, that’s invisible.

That is the boundary where fleet orchestration earns its keep. WinSentinel Pro runs the same logon-hardening audit — identical depth to the free single-machine scan; Pro does not unlock extra checks — via an agent on each endpoint, reporting into a central node. What it adds is the org-level answer: a fleet rollup that says “31 of your 200 machines have LSA Protection disabled” in one view instead of 200 separate scans; drift alerts when a rollout re-enables WDigest or drops a lockout policy across the fleet; and compliance evidence that your endpoints’ credential posture held steady over an audit window. Single-machine hardening is free and total. The “which of my machines is one phish away from handing over domain creds?” question, answered as one report, is the org problem Pro exists to solve.

The Takeaway

Lateral movement is a credential problem wearing a network costume. An attacker spreads by authenticating, and they authenticate with secrets they either guessed or stole — from a machine that let them guess forever, cached more than it needed, kept its LSASS readable, or still spoke a broken protocol. Close those: set a real lockout threshold, enable LSA Protection, disable WDigest, trim cached logons, and refuse legacy NTLM. Each one removes a rung from the ladder an intruder climbs after the first box falls — and the first box will fall eventually; the question is whether it becomes the last.

# See your credential-theft surface right now, then shrink it:
winsentinel --audit
winsentinel --fix-it

The intrusion you can survive is the one that stays where it started. Hardening logon is how you make sure the foothold is the finish line, not the on-ramp.