Microsoft Windows SMB Registry : Autologon Enabled (Nessus 10412): How to Disable Autologon and Remove DefaultPassword

Microsoft Windows SMB Registry : Autologon Enabled (Nessus plugin 10412) means Windows is configured to sign an account in automatically at startup, usually with that account’s password stored in cleartext in the DefaultPassword registry value. Fix it under HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon: set AutoAdminLogon to 0, delete DefaultPassword, then change the exposed password.

Below: what plugin 10412 reads, how to check a host without printing the password, fixes for single hosts, Group Policy and kiosks that genuinely need autologon, and how to prove the fix on rescan.

What the scanner is actually detecting

“SMB Registry” in the title tells you how the check works: Nessus logs in over SMB with the scan credentials and reads the remote registry. An unauthenticated scan never produces this finding. Tenable’s description is that an intruder can log in to the host as DefaultUserName with the password DefaultPassword, and its published solution is to delete the AutoAdminLogon and DefaultPassword values under the Winlogon key.

The values involved all live in HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon:

• AutoAdminLogon (string): 1 turns automatic logon on.
• DefaultUserName and DefaultDomainName: the account to sign in. Windows also rewrites DefaultUserName as a “last logged-on user” marker, so its presence alone means nothing.
• DefaultPassword (string): the password, in plain text.
• AutoLogonCount (DWORD, optional): the number of automatic logons left. When it reaches zero, Windows deletes AutoLogonCount and DefaultPassword and sets AutoAdminLogon to 0.

Nessus compliance audits check the same setting under the CIS name “MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended)” and the DISA STIG rule “Automatic logons must be disabled”.

Real-world risk

There are two separate problems. First, anyone with physical or console access to the machine gets a signed-in session as that account, including whatever network access it has. Second, the password sits in the registry in cleartext. Microsoft’s own documentation warns about both and adds that the key storing the password can be read remotely by the Authenticated Users group. Local privilege escalation tooling checks this value as a matter of routine, so assume anyone who has landed on the host can read it.

The CVSS vector is local, and this is not remote code execution. How much it matters depends almost entirely on the account. A local standard user on a physically secured kiosk is a modest risk. A local administrator, a domain account, or an imaging or deployment account whose password is reused on other machines turns one exposed registry value into a lateral movement credential. Check which case you have before you set the priority. Removing stored credentials like this one belongs in any Windows Server hardening checklist.

How to confirm it on the host

Avoid reg query … /v DefaultPassword: it prints the password to the screen, to transcripts and to any remote management logs. This PowerShell check reports whether the value exists without showing it:

$k = Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon'
[pscustomobject]@{
    AutoAdminLogon     = $k.AutoAdminLogon
    DefaultUserName    = $k.DefaultUserName
    DefaultDomainName  = $k.DefaultDomainName
    DefaultPasswordSet = [bool]$k.DefaultPassword
    AutoLogonCount     = $k.AutoLogonCount
}

AutoAdminLogon = 1 with DefaultPasswordSet = True is the finding exactly as Nessus sees it. AutoAdminLogon = 1 with no DefaultPassword usually means the password is held as an LSA secret (the Sysinternals Autologon method): Winlogon looks for that secret first and falls back to the registry value. Then check how privileged the account is:

net localgroup Administrators

How to fix it

Single host: registry

From an elevated prompt:

reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon" /v AutoAdminLogon /t REG_SZ /d 0 /f
reg delete "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon" /v DefaultPassword /f
reg delete "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon" /v AutoLogonCount /f

The last command fails harmlessly if AutoLogonCount does not exist. Delete only these values. The Winlogon key also holds Shell, Userinit and other values that Windows needs to sign anyone in, so never delete the key itself, and leave DefaultUserName alone. If the host was set up with Sysinternals Autologon, run Autologon.exe and click Disable as well.

Rotate the exposed password

This step is not optional. The password was readable for as long as the value existed, so treat it as disclosed. For a local account:

net user <account> *

For a domain account (ActiveDirectory module):

Set-ADAccountPassword -Identity <account> -Reset -NewPassword (Read-Host -AsSecureString "New password")

If the same password was used on other machines or service accounts, those need rotating too.

Domain-joined hosts: Group Policy

1. Install the MSS-legacy ADMX/ADML template from the Microsoft Security Compliance Toolkit. The path does not exist without it.
2. Set Computer Configuration > Policies > Administrative Templates > MSS (Legacy) > MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended) to Disabled.
3. That policy only controls AutoAdminLogon. To remove the cleartext value, add a Group Policy Preferences registry item: Computer Configuration > Preferences > Windows Settings > Registry, action Delete, hive HKEY_LOCAL_MACHINE, key path SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon, value name DefaultPassword.

On Intune-managed devices, deploy the reg commands above as a script that runs as SYSTEM.

Kiosks and signage that really need autologon

If the device must come back signed in after a power cut, keep autologon but get the password out of cleartext:

• Assigned Access: an AutoLogonAccount entry makes Windows create and manage a local standard user that signs in automatically, so you do not store a password you chose.
• Sysinternals Autologon: stores the password as an LSA secret instead of the Winlogon value. Use a dedicated local standard account, never an administrator or domain account. It also accepts autologon user domain password on the command line, but a password passed that way can end up in process creation logs and deployment scripts.

Microsoft’s Sysinternals page is explicit that an administrator can easily retrieve and decrypt the LSA secret, so this reduces exposure to non-admin users, not to an attacker with admin rights. For how Windows protects credentials held by LSA more broadly, see LSASS protection with RunAsPPL and Credential Guard. Autologon is still enabled either way, so if plugin 10412 keeps reporting these devices, record them as a documented exception with physical security as the compensating control.

How to verify the fix and rescan

Run the confirmation check again: AutoAdminLogon should be 0 and DefaultPasswordSet should be False. A direct query should return an error:

reg query "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon" /v DefaultPassword
ERROR: The system was unable to find the specified registry key or value.

To check many hosts without pulling passwords across the network:

Invoke-Command -ComputerName (Get-Content .hosts.txt) -ScriptBlock {
    $k = Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon'
    [pscustomobject]@{
        AutoAdminLogon     = $k.AutoAdminLogon
        DefaultPasswordSet = [bool]$k.DefaultPassword
    }
} | Select-Object PSComputerName, AutoAdminLogon, DefaultPasswordSet

No reboot is needed for the scanner to see the change. Rerun a credentialed Nessus scan and confirm two things: plugin 10412 is gone, and plugin 19506 (Nessus Scan Information) shows credentialed checks succeeded. A failed login also makes 10412 disappear, which proves nothing.

What can break and how to roll back

• Kiosks, digital signage, lab machines and test VMs stop at the sign-in screen after a restart.
• Applications that run in the user’s interactive session rather than as a service do not start until someone signs in.
• Scheduled tasks set to “Run only when user is logged on” stop running unattended.

Do not roll back by restoring the old values. A reg export of the Winlogon key taken before the change contains the cleartext password, so delete any such backup file. If a device genuinely needs autologon again, re-enable it with Assigned Access or Sysinternals Autologon using the new password. For one-off maintenance on a device that still has autologon, holding Shift while Windows starts skips the automatic logon unless IgnoreShiftOverride is set to 1.

Common false positive reasons

True false positives are rare. The usual disputes:

• “AutoAdminLogon is already 0.” A leftover DefaultPassword is still a readable cleartext credential. Tenable’s solution asks for both values to be removed.
• Only DefaultUserName is set. That is normal. An old version of the plugin once flagged hosts where DefaultPassword was empty and AutoAdminLogon was 0; Tenable fixed that, so update the plugin feed if you see it.
• The password is an LSA secret. The cleartext exposure is gone, but autologon is still on. Treat it as an accepted exception, not a scanner error.
• The finding comes back after the fix. Something is rewriting the values: an unattend.xml AutoLogon block in the image (Microsoft’s unattend documentation says to make sure AutoLogon is disabled on computers delivered to customers), a vendor kiosk installer, or a GPO or GPP registry item. Run gpresult /h report.html to find the policy.
• Stale results. The report predates the change or the host was offline during the rescan.

FAQ

Can someone exploit this remotely?

Not directly: the CVSS vector is local. But the cleartext password can be read by anyone with a foothold on the host, and Microsoft notes the key is remotely readable by Authenticated Users, so the credential can travel.

Does Sysinternals Autologon make the finding go away?

It removes the cleartext DefaultPassword, which is the most serious part. Administrators can still decrypt the LSA secret and autologon is still enabled, so the scanner may keep reporting the host. Document it as an exception.

Do I need to reboot?

No. The scanner reads the registry. A session that autologon already started stays signed in until someone logs it off or the machine restarts.

Should I delete DefaultUserName too?

No. It is not a secret, and Windows rewrites it as the last logged-on user anyway.

Tracking this finding across many hosts

Autologon leftovers tend to cluster on images, kiosks and lab machines, so they show up as one finding on many hosts. SITEY, a self-hosted vulnerability management platform, imports Nessus results when you upload a .nessus export (it does not pull them automatically). Its AI can write host-specific remediation scripts that run only after human approval, deployed by SITEY agents on Windows endpoints. Per-finding retest works for Nessus findings, so it can then confirm that plugin 10412 has closed.

Sources

• Tenable: Microsoft Windows SMB Registry : Autologon Enabled (plugin 10412)
• Microsoft Learn: Configure Windows to automate logon
• Microsoft Learn: Autologon (Sysinternals)
• Microsoft Learn: MSGina.dll Features (automatic logon registry values)
• Tenable: CIS audit item, MSS: (AutoAdminLogon) Enable Automatic Logon