Registry security controls disabled

Threat snapshot

The Windows registry is the control plane for a wide range of security boundaries: network drive isolation, access to the command prompt, UAC token filtering behaviour, and the ability to edit the registry itself. When an attacker gains a foothold and modifies these controls via registry edits, they are not simply changing configuration settings. They are dismantling the boundaries that separate user-level access from administrative access, restrict lateral movement paths, and prevent users from accessing tools that could expose their activity.

The four detection rules in this use case each target a distinct security control that attackers disable via the registry. EnableLinkedConnections removes the network drive isolation imposed by UAC. Disabling registry access prevents administrators and users from inspecting or modifying the registry to investigate or remediate the attack. Disabling the command prompt removes the primary interactive shell available for incident investigation. Local Account Token Filtering disablement allows local administrator accounts to authenticate over the network with full administrative tokens, enabling lateral movement that UAC would otherwise restrict. Together these changes reduce the operational constraints on the attacker while simultaneously increasing the difficulty of detection and response.

At a glance

How this attack works

Each of the four detection rules targets a registry key that controls a specific security boundary. Understanding what each key does and why its modification matters is important for accurate triage.

EnableLinkedConnections registry edit

When UAC is enabled, Windows runs standard user processes and administrator processes in separate security contexts, even for the same logged-in account. This separation means that network drives mapped in the elevated (administrator) context are not visible in the standard user context, and vice versa. The EnableLinkedConnections value bridges this gap:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

EnableLinkedConnections   REG_DWORD   1

Setting this value to 1 causes Windows to mirror network drive connections between the elevated and standard user contexts. Attackers use this to ensure that network shares mapped in their elevated session are also accessible from standard user processes, including tools running in the standard context that might otherwise be unable to reach lateral movement targets. It also simplifies the attacker's operational environment by removing the context isolation that UAC imposes.

Disabling registry access

Windows allows administrators to restrict access to the registry editor via Group Policy or a registry value:

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System

DisableRegistryTools   REG_DWORD   1

Setting DisableRegistryTools to 1 blocks regedit.exe and reg.exe from running for the affected user. An attacker who sets this value on an administrator's account prevents that administrator from inspecting the registry to investigate suspicious entries, from manually reverting attacker-made registry changes, and from using registry-based forensic investigation tools. It is a direct attempt to obstruct incident response and is almost never a legitimate configuration in an enterprise environment outside of locked-down kiosk deployments.

Disable command prompt via registry

The command prompt can be disabled for a user via a registry value that prevents cmd.exe from launching:

HKCU\Software\Policies\Microsoft\Windows\System

DisableCMD   REG_DWORD   1   (disables cmd.exe and batch files)

DisableCMD   REG_DWORD   2   (disables cmd.exe only)

An attacker who sets this value on a targeted user account or on an administrative account they want to obstruct prevents that user from opening a command prompt to investigate suspicious activity, run remediation commands, or access the system interactively via cmd.exe. Like registry disablement, this is an obstruction technique directed at the response team rather than a capability that benefits the attacker operationally. It is a signal that the attacker is aware of or anticipating defensive investigation activity.

Local account token filtering disabled

By default, when a local administrator account authenticates to a remote Windows system over the network, UAC strips the administrative token from the session and provides only a standard user token. This prevents local admin accounts from being used for remote lateral movement via SMB admin shares, WMI, or remote PowerShell, even if the password is known. Disabling this filtering via the registry removes that restriction:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

LocalAccountTokenFilterPolicy   REG_DWORD   1

Setting LocalAccountTokenFilterPolicy to 1 grants local administrator accounts full administrative tokens over network connections. This is the registry change that enables Pass-the-Hash attacks using local admin credentials to traverse the network and access remote administrative shares. It is a well-documented lateral movement enabler and its presence outside a documented administrative configuration is a strong indicator of either attacker activity or a significant security misconfiguration.

Attack chain

The table below maps each stage of a registry security controls disablement attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A law firm with 200 staff runs a standard Windows domain environment. All workstations share a common local administrator account with the same password, a legacy configuration from the firm's earlier infrastructure. A threat actor who compromised a paralegal's account via a phishing email has been operating inside the network for two days using the paralegal's domain credentials.

The paralegal's workstation has local administrator rights on itself. Using those rights, the attacker makes four registry changes: they set LocalAccountTokenFilterPolicy to 1 under the HKLM policy path, set EnableLinkedConnections to 1, and using the paralegal's user context, set DisableRegistryTools and DisableCMD to 1 under the HKCU path for the firm's IT administrator account, which the attacker accessed after harvesting credentials from the paralegal's browser session history.

With LocalAccountTokenFilterPolicy set to 1 and knowing the shared local admin password, the attacker uses a Pass-the-Hash technique to authenticate to 14 other workstations in the firm using the common local admin credential. On each host they access, they copy client documents, billing records, and matter files to a staging directory. The IT administrator, alerted by a user complaint about a slow workstation, attempts to open regedit.exe to investigate, only to find it blocked. They attempt to open a command prompt to run diagnostic commands and find that also blocked.

Why this happens
The LocalAccountTokenFilterPolicy value is not set by default in most Windows environments, meaning it is absent and token filtering is active. But many administrators and security hardening guides add this value deliberately to enable legitimate remote administration scenarios. Once it has been set once for a legitimate purpose, it tends to remain set indefinitely. An attacker who knows this is common in enterprise environments will check for it and set it if absent, confident that it will not be noticed among other administrative registry values. Similarly, disabling the registry editor and command prompt via HKCU-based values requires only standard user rights on the targeted account and generates no visible change to the targeted user's desktop.

Business impact: What can go wrong

Registry security control disablement creates cascading consequences across lateral movement capability, incident response, and operational continuity:

• Lateral movement at scale: LocalAccountTokenFilterPolicy set to 1 in environments using shared local administrator passwords converts a single compromised credential into network-wide access. Every host sharing the same local admin password becomes immediately accessible via SMB without any additional exploitation.
• Investigation obstruction: disabling the registry editor and command prompt on targeted accounts directly impairs the ability of the IT team to investigate, remediate, or even navigate the affected system. Response time increases significantly when the primary interactive investigation tools are unavailable.
• UAC boundary removal: EnableLinkedConnections set to 1 removes the process context isolation that UAC provides for network resources. Tools and scripts running in the standard user context gain access to network paths that should be visible only to the elevated context, widening the potential reach of any code running on the affected host.
• Pass-the-Hash enablement: the combination of LocalAccountTokenFilterPolicy set to 1 and a shared local admin password is the standard setup for a Pass-the-Hash lateral movement campaign. The attacker does not need to crack any passwords. The hash itself, reused across multiple hosts, provides full administrative access.
• Extended dwell time: an attacker who disables investigation tools on administrator accounts can maintain access for longer before detection, since the typical first-response actions of opening regedit.exe or cmd.exe to inspect the system are blocked.
• Compliance failure: LocalAccountTokenFilterPolicy set to 1 in combination with shared local admin passwords is a violation of CIS Control 5 (account management) and PCI DSS Requirement 7 (restrict access to system components). Discovery during an audit constitutes a reportable control failure independent of any active attack.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the registry security control disablement rules can fire reliably, ensure the following are in place:

• Sysmon is deployed on all monitored endpoints with a configuration capturing Event ID 13 (Registry Value Set) for all four registry paths. Critically, the Sysmon configuration must cover both HKLM and HKCU paths. The DisableRegistryTools and DisableCMD rules target HKCU keys, which are user-profile specific. Ensure the Sysmon include rules cover both hive roots.
• Windows Object Access auditing for the registry is enabled to generate Event ID 4657 for HKLM-based modifications, providing an independent kernel-level audit record supplementing the Sysmon event stream.
• Windows Process Creation auditing with command-line logging is enabled, generating Event ID 4688 with the full ProcessCommandLine field. This allows Log360 to identify the specific process and command used to make each registry modification, which is the primary differentiator between legitimate Group Policy updates and attacker-initiated changes.
• Endpoint agents or Windows Event Forwarding are configured to forward Security and Sysmon logs from all monitored endpoints to Log360. The HKCU-based rules fire on endpoint-level telemetry per user profile. Coverage must include all monitored workstations, not only servers or domain controllers.

Note
The DisableRegistryTools and DisableCMD values live in HKCU rather than HKLM. This means they are user-profile specific and require only standard user rights to set on the current user's own profile. An attacker who has obtained credentials for another user account can set these values in that user's HKCU hive without administrator rights. Verify that the Sysmon configuration explicitly includes the HKCU paths for these values, as some Sysmon configurations focus only on HKLM registry monitoring.

Detecting registry security control disablement using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rules

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable all four rules: EnableLinkedConnections Registry Edit, Disabling Registry, Disable Command Prompt via Registry, and Local Account Token Filtering Disabled - Registry. Configure an alert profile for the same.

Step 2: Read the alert

The alert will display the hostname, the account under whose context the registry write occurred, the specific registry path and value name, the value data written, and the process responsible for the write. For HKCU-based alerts, the account field identifies whose profile was modified, which may differ from the account that performed the modification if the attacker is writing to a target account's hive remotely. Review the writing process first: Group Policy service processes are the primary false positive source. Any other process writing to these security control paths warrants investigation.

Investigating an alert

When any registry security control disablement rule fires, an L2 analyst should work through the following steps:

• Identify the specific rule that fired and the security control it covers. Determine which of the four controls has been disabled: network drive isolation, registry access, command prompt access, or local account token filtering. LocalAccountTokenFilterPolicy and EnableLinkedConnections modifications have immediate lateral movement implications and should be escalated more urgently than DisableRegistryTools or DisableCMD, which are primarily investigation obstruction techniques.
• Check whether multiple rules fired on the same host. Query Log360 for all four rule names against the same hostname in the preceding 10 minutes. Multiple rules firing together indicates a scripted disablement campaign. The combination of LocalAccountTokenFilterPolicy plus DisableRegistryTools plus DisableCMD in the same session is a high-confidence indicator of an active attacker preparing for lateral movement while obstructing the response.
• Identify the process responsible for the registry write. Open the Incident Workbench and find the process that made the modification. Determine whether it was a Group Policy update, an interactive session, a remote session, a scheduled task, or a script. Trace the process back to its parent and identify the original execution vector.
• For a LocalAccountTokenFilterPolicy alert specifically, assess the lateral movement risk immediately. Determine whether the environment uses shared local administrator passwords across multiple hosts. If it does, the combination of LocalAccountTokenFilterPolicy set to 1 and a shared local admin credential means every host sharing that password is now accessible via Pass-the-Hash. Notify the incident response team of the potential scope before the investigation is complete.
• Check for lateral movement activity following a LocalAccountTokenFilterPolicy modification. Query Log360 for Event ID 4624 Type 3 (network logon) events from the affected host to other internal hosts in the 30 minutes following the registry change. Successful network logons from the affected host to multiple other hosts in rapid succession indicate the token filtering policy change is already being exploited.
• Verify against documented administrative activity. Check the change management system for any approved configuration change, Group Policy update, or remote administration task that would explain the registry modification. If no ticket exists and the writing process is not the Group Policy engine, treat the modification as confirmed malicious.

Escalation trigger
Escalate immediately to L3 if LocalAccountTokenFilterPolicy has been set to 1 and the environment uses shared local administrator passwords; if both DisableRegistryTools and DisableCMD have been set on an administrator account's HKCU profile; if the registry modification was made via a remote session from an unrecognised source IP; or if network logon events from the affected host to multiple other internal hosts have been observed following the LocalAccountTokenFilterPolicy change.

Responding and remediating

Immediate containment

• Restore all disabled security controls immediately. Delete the EnableLinkedConnections value or set it to 0, delete DisableRegistryTools and DisableCMD from the affected user profiles, and delete LocalAccountTokenFilterPolicy or set it to 0. Restoring LocalAccountTokenFilterPolicy is the highest priority if lateral movement is suspected, as it immediately re-enables UAC token filtering for network connections.
• If LocalAccountTokenFilterPolicy was set to 1 and the environment uses a shared local administrator password, rotate that password immediately across all affected hosts using LAPS or a scripted password reset. A shared local admin password in an environment with LocalAccountTokenFilterPolicy set to 1 represents active Pass-the-Hash risk for every host sharing the credential.
• Isolate the affected host if lateral movement has been confirmed or if the registry modifications were made via a remote session from an unrecognised source IP. Isolate before restoration if the attacker session may still be active.

Forensic preservation

• Export the Sysmon operational log and Windows Security event log from the affected host covering the full period from the first registry modification alert. These logs contain the process context for each change and any network logon events generated after LocalAccountTokenFilterPolicy was modified.
• Document the modified state of all four registry values and the timestamps at which each was modified. This information is required for the incident record and for assessing how long each security control was disabled before detection and restoration.
• If DisableRegistryTools and DisableCMD were set on an administrator account's profile, check whether the targeted administrator attempted to use those tools during the disabled period. Event ID 4688 entries for failed regedit.exe or cmd.exe launches would be present if they attempted to open these tools while they were blocked.

Eradication and recovery

• Scan all other endpoints in the environment for the same registry modifications. Query Log360 for all four rule names across all agents in the preceding 24 hours. Additionally run a targeted scan of all managed hosts to check the current state of LocalAccountTokenFilterPolicy and EnableLinkedConnections values.
• If LocalAccountTokenFilterPolicy was exploited for lateral movement, conduct a full review of network logon events (Event ID 4624 Type 3) across all domain hosts in the period following the modification. Identify every host the attacker accessed and treat the credentials used as compromised.
• Enforce the correct values for these registry keys via Group Policy rather than relying on local registry state. Group Policy-managed values are restored at each refresh cycle and take precedence over local changes. This is the most resilient remediation for three of the four controls.

False positive guidance

The four registry values covered by these rules have narrow legitimate use cases. False positives are uncommon but occur in the following scenarios:

• Group Policy configuration: EnableLinkedConnections and LocalAccountTokenFilterPolicy are sometimes set deliberately via Group Policy to support remote administration workflows or shared drive access patterns. If either value is Group Policy managed in your environment, the registry write will come from the Group Policy service process and will apply consistently across all hosts in the relevant OU. Verify the writing process and the Group Policy Object responsible for the setting. If the value is intentional, document it as an accepted configuration with a security exception, noting the lateral movement risk associated with LocalAccountTokenFilterPolicy.
• Kiosk and locked-down workstation deployments: DisableRegistryTools and DisableCMD are legitimately used in kiosk, public terminal, and shared workstation deployments to prevent users from accessing system tools. These values will be set by a configuration management tool on specific, documented host types. Verify the host is in the documented kiosk inventory and the modification was made by the expected configuration management process.
• Remote administration tooling: some remote management platforms set LocalAccountTokenFilterPolicy as part of their configuration to enable their agents to connect to managed hosts via local admin credentials. Verify the product, verify that the value is set only on hosts where the product is deployed, and document it as an accepted exception if the product requires it. Review whether the product can be configured to use domain accounts instead, which would not require this registry change.
• Parental control and user restriction software: consumer-grade parental control software and some enterprise endpoint management tools set DisableCMD to restrict what users can run on managed endpoints. These will appear as modifications by the management agent process on endpoints documented as having user restrictions applied.

Key differentiator
Legitimate modifications to these registry values are made by the Group Policy service or a documented configuration management agent, apply consistently across multiple hosts on a schedule, and can be attributed to a specific policy or management tool. An attacker-initiated modification will be made by PowerShell, reg.exe, or an unrecognised process, will appear on a single host or a small group of targeted hosts, will occur outside any documented policy deployment, and in the case of DisableRegistryTools and DisableCMD will typically target an administrator account profile rather than a standard user profile.

Hardening and prevention

The following controls reduce the risk of registry security control disablement in your environment:

• Deploy Windows LAPS on all endpoints to eliminate shared local administrator passwords. LAPS assigns a unique, automatically rotated password to each host's local administrator account, removing the condition that makes LocalAccountTokenFilterPolicy disablement particularly dangerous at scale.
• Manage EnableLinkedConnections and LocalAccountTokenFilterPolicy exclusively via Group Policy rather than local registry settings. Group Policy-managed values are authoritative, are restored automatically at each refresh, and any local override is immediately visible as a deviation from the policy-applied state.
• Apply registry ACLs to restrict write access to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to SYSTEM and the Group Policy service account only. Removing interactive administrator write access to this key prevents an attacker with local admin rights from modifying LocalAccountTokenFilterPolicy and EnableLinkedConnections interactively.
• Deploy Sysmon with explicit monitoring of all four registry paths, including the HKCU paths for DisableRegistryTools and DisableCMD. Ensure the Sysmon configuration covers both HKLM and HKCU hive roots, as some configurations focus exclusively on HKLM.
• Enforce a policy that LocalAccountTokenFilterPolicy must not be set to 1 in the environment unless a specific, documented administrative requirement has been approved. Include this value in periodic configuration audits and remediate any unapproved instances as a standing hygiene control.
• Include all four registry paths in your configuration management baseline with expected values documented. Any deviation from the baseline detected during a scheduled configuration scan should generate a remediation ticket independent of real-time monitoring.