Unattended System Login Detection

Threat snapshot

Windows Auto Admin Logon is a built-in mechanism that allows a system to log in automatically to a specified user account on startup, bypassing the credential prompt entirely. It was designed for kiosk deployments, unattended workstations, and lab environments where interactive login is operationally inconvenient. In those contexts it is a legitimate feature. In every other context, it is a significant security control failure.

When an attacker or a malicious insider enables Auto Admin Logon via the Windows registry, they are doing two things simultaneously: establishing a persistence mechanism that survives reboots and guarantees access to a logged-in session on next startup, and storing plaintext or weakly encoded credentials in the registry where they can be retrieved by any process with read access to that key. The two detection rules in this use case target both the activation of the feature itself and the credential storage that enables it. Together they provide early warning of an identity and access threat that, if undetected, leaves a standing door open into the affected system.

At a glance:

How this attack works

Auto Admin Logon is controlled through registry values stored under the Winlogon key:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
AutoAdminLogon   REG_SZ    1
DefaultUserName   REG_SZ   <username>
DefaultPassword   REG_SZ   <password in plaintext>
DefaultDomainName   REG_SZ   <domain> (optional)

Setting AutoAdminLogon to 1 enables the feature. Adding DefaultUserName and DefaultPassword provides the credentials that Windows will use to authenticate automatically at next boot. The password is stored as a plaintext REG_SZ value — it is not hashed, encrypted, or protected by the Windows credential store. Any process running with sufficient privileges to read HKLM can retrieve it directly.

In an attack context, an adversary who has already gained a foothold on a system through phishing, exploitation, or lateral movement may enable Auto Admin Logon to ensure persistent, no-interaction access survives a reboot. If the host is rebooted as part of a patch cycle, a power event, or a user-initiated restart, the attacker's chosen account is automatically logged in without any credential prompt. The session is live and accessible without any further action on the attacker's part.

The second dimension of risk is credential exposure. The DefaultPassword value stores the logon credential in the registry in plaintext. If the attacker configures Auto Admin Logon using a domain account or if the system is later accessed by another party who reads the registry those credentials are available in cleartext for immediate reuse in lateral movement, privilege escalation, or further persistence across the environment.

Attack chain

Real-world scenario

A mid-sized professional services firm runs a mix of on-premises workstations and remote desktops. A threat actor who gained access to the environment three days earlier via a phishing email has been operating under a compromised standard user account. Using a local privilege escalation exploit, they have elevated to local administrator on one of the firm's internal workstations.

Rather than maintaining an active connection that could be severed by a network change or a session timeout, the attacker writes three registry values to the Winlogon key: AutoAdminLogon set to 1, DefaultUserName set to the local administrator account name, and DefaultPassword set to the administrator's plaintext password. The changes take less than two seconds. No user sees anything. No alert fires on the endpoint.

Two days later, the workstation is rebooted as part of the firm's monthly patch cycle. The machine comes back up, automatically logs into the administrator account, and the attacker's previously deployed remote access tool, which is configured to start on user login, re-establishes its C2 connection without any further action. The attacker now has a persistent, administrative session on the workstation with credentials stored in plaintext in the registry — credentials that turn out to be reused across several other internal systems.

Why this happens

Enabling Auto Admin Logon requires only registry write access to a HKLM key. It uses no special APIs, drops no files, and leaves no entry in the Windows application event log. It will not be flagged by antivirus. It will not appear in a review of scheduled tasks, startup folder entries, or running services. Without registry modification monitoring tied to the specific Winlogon key values that control this feature, the configuration change is invisible until the next reboot — at which point the session is already live.

Business impact: What can go wrong

Unattended system login enabled via registry carries compounding identity and access risks:

• Persistent access without authentication: Auto Admin Logon guarantees an attacker a logged-in session on every reboot, bypassing the authentication control that would otherwise require credential re-entry. Patch cycles, power events, and legitimate restarts all become opportunities for re-entry rather than disruption.
• Plaintext credential exposure: DefaultPassword is stored as a plaintext REG_SZ value readable by any process with HKLM read access. Those credentials are available for immediate reuse in lateral movement, cloud service authentication, VPN access, and privilege escalation across any system where the password is shared.
• Lateral movement amplification: if the configured auto-logon account is a domain account — or if the password is reused across other systems — a single registry modification creates a credential harvest that propagates far beyond the original compromised host.
• Detection evasion: because Auto Admin Logon uses built-in Windows functionality and legitimate registry keys, it does not trigger file-based AV, behaviour-based EDR rules focused on process execution, or network-based detection. It is specifically a registry-layer persistence technique that evades most non-registry monitoring controls.
• Compliance failure: storage of plaintext credentials in the registry is a direct violation of password storage requirements under PCI DSS Requirement 8, NIST SP 800-63B, and ISO 27001 Annex A.9. Discovery of this configuration during an audit or post-incident review constitutes a reportable control failure.
• Extended dwell time: because the persistence mechanism is silent and survives reboots, an attacker who configures Auto Admin Logon may maintain access for weeks or months without generating further detection signals, dramatically extending dwell time and the scope of data accessible during the intrusion.

Indicators of compromise and detection signals

The following signals should be collected and correlated to detect unattended login

Prerequisites for detection using Log360

Before Log360 can detect unattended login configuration, the following must be in place:

Detecting with Log360

Step 1: Enable the Rules

Navigate to Log360 > Security > Manage Rules > Rule Library. Search for Auto Admin Logon and enable both rules:

• Auto Admin Logon Enabled via Registry: monitors for Sysmon Event ID 13 or Windows Security Event ID 4657 where the target registry path is the Winlogon key and the value name is AutoAdminLogon with a data value of 1.
• DefaultUser And Password Added in Registry: monitors for registry write events where DefaultUserName and DefaultPassword values are set under the Winlogon key. The password write is the higher-severity signal and should be configured to alert immediately upon detection.

Create alert profile with both rules to notify the SOC queue immediately. Because these two rules target a two-step configuration sequence, consider creating a correlation rule that raises severity to Critical if both rules fire on the same host within a 10-minute window.

Step 2: Tune the Rules

Before going live, review the following:

• Scope: Do not exclude servers - Auto Admin Logon configuration on a server is higher risk than on a workstation because servers are more likely to host domain accounts and to be accessible remotely.
• Kiosk and lab exclusions: if your environment includes documented kiosk or unattended workstation deployments where Auto Admin Logon is legitimately configured, add those specific hostnames to an exclusion list with documented justification and a review date. Do not exclude by OU or IP range - be specific.

Step 3: Read the Alert

When alert is triggered, it surfaces the following fields. Review them in sequence:

Investigating an alert

When either Auto Admin Logon rule fires, follow these steps to determine whether the configuration represents a genuine threat:

• Open the Incident Workbench from the alert panel. Load the process tree for the affected host and the session window in which the registry write occurred. Identify the process that made the write, its parent process, and the full command line. Determine whether the write was made interactively, via a script, or via a remote session.
• Identify the configured account. From the DefaultUserName and DefaultDomainName registry values in the alert detail, determine which account has been set for auto-logon. Query Log360 for all recent activity by this account across the environment. If it is a domain account, check for recent logons from unusual hosts or IP addresses.
• Check Windows Security Event ID 4624 logon events for the affected host in the period following the registry modification. Look for a Type 2 (interactive) logon at or after a system boot time. If such a logon has already occurred, the auto-logon mechanism has already activated.
• Verify whether the registry modification was an authorised administrative action. Check your change management system for an approved change ticket. If the host is a documented kiosk or unattended workstation with Auto Admin Logon legitimately configured, verify the change was made by the account and tooling documented as responsible for that host's configuration.
• Assess the credential risk. If DefaultPassword was written, the account's plaintext password is currently stored in the registry. Regardless of whether the configuration was malicious or accidental, this credential must be treated as compromised. Initiate a mandatory password reset for the configured account immediately, before concluding the investigation.

Escalation trigger

Escalate immediately to L3 if any of the following are observed: both rules fired on the same host within a 10-minute window; the configured DefaultUserName is a domain account rather than a local account; the registry write was performed by a non-administrative user account; a Type 2 interactive logon at boot time has already occurred on the affected host following the registry modification; or the same Winlogon configuration pattern appears across multiple hosts, which indicates a scripted deployment of the persistence mechanism.

Responding and remediating

Immediate containment

• Treat the DefaultPassword credential as fully compromised regardless of investigation outcome. Initiate a mandatory, immediate password reset for the account named in DefaultUserName. If the account is a domain account, reset it at the domain level and audit all systems where that credential may have been cached or reused.
• If the registry write was performed remotely via a live attacker session, isolate the affected host from the network using EDR host isolation before performing remediation. Removing the registry values while an active attacker session is open does not end the intrusion.

Forensic preservation

• Export the Windows Security event log and Sysmon operational log from the affected host before remediation. These logs contain the registry write events, the process context of the modification, and any subsequent logon events that confirm whether Auto Admin Logon has already activated.
• Capture the current state of the HKLM Winlogon key before removing the Auto Admin Logon values. Document all values present, their data, and the timestamps recorded by the registry. This information is required for the incident record and for any forensic timeline reconstruction.
• Review the host's Windows Security event log for Event ID 4624 Type 2 logons since the time of the registry modification. Document whether and when Auto Admin Logon activated, which provides the window during which the attacker may have had an active session.

Eradication and recovery

• Audit all other endpoints in the environment for the same Winlogon configuration. Query Log360 for the same registry modification pattern across all agents, or run a remote PowerShell scan: Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' | Select AutoAdminLogon, DefaultUserName, DefaultDomainName across all managed hosts.
• Review all persistence mechanisms on the affected host — scheduled tasks, registry Run keys, startup folder entries, and services — for additional attacker-placed persistence that may have been installed in the same session as the Auto Admin Logon configuration.
• If the account configured for auto-logon was a domain account, conduct a full audit of that account's activity across the environment for the preceding 72 hours. Identify all hosts where the account has authenticated, all resources accessed, and all changes made under that account's security context.

False positive guidance

Auto Admin Logon is a legitimate Windows feature with specific valid use cases. The following scenarios commonly produce false positive alerts:

Key differentiator

Any write to the DefaultPassword value under the Winlogon key is high risk regardless of context. Even on documented kiosk systems, the existence of DefaultPassword means a plaintext credential is stored in the registry. The False Positive scenarios above apply to the AutoAdminLogon enablement signal. They do not reduce the risk of DefaultPassword. If DefaultPassword is written to the Winlogon key on any host, including a documented kiosk, treat the credential as exposed and initiate a password review for the configured account.

Hardening and prevention

The following controls reduce the risk of unattended login configuration being used as a persistence or credential exposure technique:

• Restrict write access to the Winlogon registry key. By default, local administrators can write to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. Apply a registry ACL that restricts write access to SYSTEM and designated configuration management service accounts only, removing write access from interactive administrator sessions where operationally feasible.
• Deploy Sysmon with explicit registry monitoring for the Winlogon key path on all endpoints. This is the single most effective preventive-detective control for this technique. Ensure the Sysmon configuration targets all three high-risk value names: AutoAdminLogon, DefaultPassword, and DefaultUserName.
• Include the Winlogon key in your configuration management baseline as an explicitly monitored value. Any deviation from the baseline state — whether AutoAdminLogon is set to 0 or the key contains no DefaultPassword — should generate an alert from your configuration management tooling independently of the Log360 rule.
• Enforce a policy prohibiting the use of Auto Admin Logon with domain accounts. If Auto Admin Logon is required for a legitimate use case, require the use of a dedicated, non-privileged local account with a strong, unique password that is not reused elsewhere in the environment.
• Enable Windows LAPS (Local Administrator Password Solution) on all endpoints. LAPS manages and rotates local administrator passwords automatically, preventing the password reuse scenarios that make DefaultPassword exposure particularly damaging when the configured account is a shared local admin account.
• Implement privileged access workstations (PAWs) and tiered administration models that prevent domain administrator credentials from ever being used on — or stored in the registry of — standard workstations, limiting the blast radius of a DefaultPassword exposure.
• Conduct periodic, automated scans for Auto Admin Logon configuration across all managed endpoints using your RMM or configuration management tooling. A monthly scan that checks for AutoAdminLogon = 1 or the presence of a DefaultPassword value provides a detective control independent of real-time monitoring.