Auditing Windows Autologon: The Cleartext Password Hiding in Your Registry

Windows Autologon stores the account password in cleartext under the LSA registry key. Here is how attackers loot it, why it survives reimaging, and how to audit for it.

Automatic logon is one of those "temporary" convenience settings that quietly becomes permanent. A kiosk, a lab machine, a digital-signage box, or a build agent needs to boot straight to a desktop without someone typing a password — so an admin enables Autologon and moves on. What most admins never realize is where that password ends up: written into the registry in cleartext, readable by any process running as that user, and often left behind long after the reason for it is gone.

Where the password lives

The Winlogon subsystem reads its automatic-logon configuration from a single registry key:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
  AutoAdminLogon   = "1"
  DefaultUserName  = "kioskadmin"
  DefaultDomainName= "WORKGROUP"
  DefaultPassword  = "SuperSecret123!"     <-- cleartext

When AutoAdminLogon is 1 and a DefaultPassword value is present, the password sits there in plain text. There is nothing subtle about it — reg query from any account with read access to the hive returns it verbatim:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword

This is MITRE ATT&CK T1552.002 — Unsecured Credentials: Credentials in Registry, and it is a first-stop enumeration target for almost every post-exploitation toolkit. Mimikatz, LaZagne, and Seatbelt all check it by name.

Why "but it's an LSA secret" is a false comfort

There is a supported way to store the Autologon password more safely: the SysInternals Autologon tool writes it into the LSA secret DefaultPassword instead of the plaintext registry value. That is genuinely better — the value lands under HKLM\SECURITY\Policy\Secrets, which only SYSTEM can read. But do not mistake this for encryption at rest against a determined attacker:

LSA secrets are recoverable. Any process running as SYSTEM — or an attacker who has dumped the SAM/SECURITY hives offline — can decrypt them. The password is obfuscated, not protected by a key you hold.
Both locations coexist. Enabling Autologon through the GUI or a script often writes the plaintext registry value even when an LSA secret already exists, leaving two copies.
It survives reimaging via golden images. If a build engineer bakes Autologon into a master image, every machine deployed from it ships with the same cleartext credential — a single leaked value now unlocks the entire fleet.

Treat any Autologon password as already compromised. The only real fix is to remove it or scope the account to zero blast radius.

The attacker's path

The reason this finding matters so much is the account it usually protects. Autologon is almost always configured for a local administrator or a domain service account — because the machine is doing something privileged automatically. So the sequence is short and brutal:

Attacker lands on the box with any user-level foothold.
Reads DefaultPassword (or decrypts the LSA secret if running as SYSTEM).
Now holds valid credentials for a privileged account — frequently reused across other machines.
Pivots laterally with legitimate authentication that blends into normal logon telemetry.

No exploit, no malware signature, no memory corruption. Just a value that should never have been written.

How to audit it

A proper audit checks three things, not one. Presence of the plaintext value, presence of the LSA secret, and the privilege level of the account being auto-logged-on. Here is a quick manual check:

# Is automatic logon enabled and is a plaintext password present?
$wl = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
$p  = Get-ItemProperty -Path $wl -ErrorAction SilentlyContinue
if ($p.AutoAdminLogon -eq "1") {
  "AutoAdminLogon ENABLED for user: $($p.DefaultUserName)"
  if ($p.DefaultPassword) { "  !! DefaultPassword present in CLEARTEXT" }
}

Then confirm whether DefaultUserName is a member of Administrators — a cleartext password for a standard user is bad, for a local admin it is a fleet-wide incident waiting to happen.

Remediation

Remove Autologon entirely where it is no longer needed. Set AutoAdminLogon to 0 and delete the DefaultPassword value.
If you must keep it, use a dedicated non-privileged local account scoped only to the kiosk task, never a domain or admin account, and never one reused elsewhere.
Never bake Autologon into a golden image. Configure it per-device post-deployment with a unique password.
Purge the plaintext value even if you switch to the LSA-secret method — the two do not overwrite each other.

Where WinSentinel fits

WinSentinel's credential-exposure audit checks the Winlogon key on every scan — surfacing an enabled Autologon, flagging the plaintext DefaultPassword if present, and escalating the finding's severity when the target account is a local administrator. It is one of the 33 modules that run in full on the free single-machine tier: on the box you install it on, you get the complete credential-hygiene sweep, no limits, no upsell.

Where an organization graduates to Pro is scale. When you are running 50 kiosks and 200 laptops, the question is not "does this one machine have a cleartext Autologon password" but "which of my 250 endpoints do, and did a new one appear this week?" Pro's central node rolls those per-machine findings into a fleet-wide view, tracks drift so a re-enabled Autologon on a reimaged kiosk trips an alert, and maps the exposure into compliance reporting. Same audit, every machine, answered from one place.

Cleartext credentials in the registry are a decades-old class of finding, and they persist precisely because they are invisible until someone goes looking. Make the looking automatic.