T1574.011: Services Registry Permissions Weakness
Adversaries may execute their own malicious payloads by hijacking the Registry entries used by services. Flaws in the permissions for Registry keys related to services can allow adversaries to redirect the originally specified executable to one they control, launching their own code when a service starts. Windows stores local service configuration information in the Registry under HKLM\SYSTEM\CurrentControlSet\Services. The information stored under a service's Registry keys can be manipulated to modify a service's execution parameters through tools such as the service controller, sc.exe, PowerShell, or Reg. Access to Registry keys is controlled through access control lists and user permissions. [1][2]
If the permissions for users and groups are not properly set and allow access to the Registry keys for a service, adversaries may change the service's binPath/ImagePath to point to a different executable under their control. When the service starts or is restarted, the adversary-controlled program will execute, allowing the adversary to establish persistence and/or privilege escalation to the account context the service is set to execute under (local/domain account, SYSTEM, LocalService, or NetworkService).
Adversaries may also alter other Registry keys in the service’s Registry tree. For example, the FailureCommand key may be changed so that the service is executed in an elevated context anytime the service fails or is intentionally corrupted.[3][4]
The Performance key contains the name of a driver service's performance DLL and the names of several exported functions in the DLL.[5] If the Performance key is not already present and if an adversary-controlled user has the Create Subkey permission, adversaries may create the Performance key in the service’s Registry tree to point to a malicious DLL.[6]
Adversaries may also add the Parameters key, which can reference malicious drivers file paths. This technique has been identified to be a method of abuse by configuring DLL file paths within the Parameters key of a given services registry configuration. By placing and configuring the Parameters key to reference a malicious DLL, adversaries can ensure that their code is loaded persistently whenever the associated service or library is invoked.
For example, the registry path[7] HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters[8][9] contains the AutodiaDLL value, which specifies the DLL to be loaded for autodial funcitionality. An adversary could set the AutodiaDLL to point to a hijacked or malicious DLL:
"AutodialDLL"="c:\temp\foo.dll"
This ensures persistence, as it causes the DLL (in this case, foo.dll) to be loaded each time the Winsock 2 library is invoked.
Analyst context for executives and security teams
This Windows technique matters because weak permissions on service-related Registry keys can let an attacker change how a service starts and cause attacker-controlled code to run when the service is started, restarted, fails, or loads related service DLLs. For leaders, the issue is less about a single Registry value and more about whether Windows service configuration is governed tightly enough to prevent quiet execution-flow hijacking in privileged service contexts.
Executive priority
Prioritize this as a Windows hardening and assurance question: do critical endpoints and servers have defensible Registry permissions under HKLM\SYSTEM\CurrentControlSet\Services, and can the organization prove when service execution parameters change? The business risk is that misconfigured service Registry permissions can create durable execution opportunities and potential privilege escalation paths, affecting incident containment, audit evidence, and operational resilience on Windows systems.
Technical view
Validate service Registry permissions and monitoring around HKLM\SYSTEM\CurrentControlSet\Services. Focus on changes to service execution parameters such as ImagePath/binPath, FailureCommand, Performance key DLL references, and Parameters-based DLL paths such as AutodialDLL where applicable. ATT&CK does not provide official detection text for this object, but the related DET0427 detection strategy indicates this behavior should be treated as a detectable hijack-execution-flow pattern. SOC and IR teams should correlate Registry modifications with service starts/restarts/failures and execution by service accounts such as SYSTEM, LocalService, NetworkService, or configured local/domain accounts.
Likely telemetry
- Windows Registry auditing or endpoint telemetry for HKLM\SYSTEM\CurrentControlSet\Services key/value creation and modification
- Registry ACL and permission inventory for service Registry keys
- Service configuration change evidence, including ImagePath/binPath and recovery configuration changes
- Process execution telemetry for sc.exe, PowerShell, Reg, and service-launched executables
- Service start, restart, and failure events correlated with newly changed Registry values
Detection direction
- Baseline expected service Registry permissions and alert on non-administrative write or create-subkey rights on sensitive service keys.
- Monitor for changes to ImagePath/binPath, FailureCommand, Performance, and Parameters values that point to unusual or newly created executable, driver, or DLL paths.
- Correlate Registry changes with subsequent service starts, restarts, failures, or library invocation to separate suspicious execution flow changes from normal administration.
- Tune for legitimate software installation, driver updates, and administrative service maintenance, which may create false positives if context is missing.
- Check for blind spots where Registry auditing is disabled, endpoint telemetry does not capture value-level changes, or service account process lineage is not retained.
Mitigation priorities
- Implement M1024: restrict Registry permissions on sensitive service keys so only authorized users and processes can modify service configuration.
- Regularly review and correct ACLs under HKLM\SYSTEM\CurrentControlSet\Services, especially for services running with elevated accounts.
- Limit and monitor use of tools capable of modifying service Registry configuration, including service controller utilities, PowerShell, and Reg.
- Use configuration management or compliance checks to detect drift in service Registry permissions and execution parameters.
- During incident response, inspect modified service Registry trees and referenced binaries/DLLs before restarting services or hosts.
Analyst notes and limits
This take is based on ATT&CK T1574.011 in enterprise-attack, Windows platform, with tactics listed as stealth and execution. The official description also states the behavior can support persistence and/or privilege escalation depending on the service account context. Relationship context includes mitigation M1024, detection strategy DET0427, revoked predecessor T1058, parent technique T1574 Hijack Execution Flow, and campaign C0006 using this technique.
ATT&CK provides no official detection procedure for this object in the supplied fields, and the related detection strategy details are not included beyond its name. Local validation is required to determine which Windows services are exposed by weak Registry permissions, which telemetry is collected, and which service configuration changes are legitimate in the environment.
Services Registry Permissions Weakness
Adversaries may execute their own malicious payloads by hijacking the Registry entries used by services. Flaws in the permissions for Registry keys related to services can allow adversaries to redirect the originally specified executable to one they control, launching their own code when a service starts. Windows stores local service configuration information in the Registry under HKLM\SYSTEM\CurrentControlSet\Services. The information stored under a service's Registry keys can be manipulated to modify a service's execution parameters through tools such as the service controller, sc.exe, PowerShell, or Reg. Access to Registry keys is controlled through access control lists and user permissions. [1][2]
If the permissions for users and groups are not properly set and allow access to the Registry keys for a service, adversaries may change the service's binPath/ImagePath to point to a different executable under their control. When the service starts or is restarted, the adversary-controlled program will execute, allowing the adversary to establish persistence and/or privilege escalation to the account context the service is set to execute under (local/domain account, SYSTEM, LocalService, or NetworkService).
Adversaries may also alter other Registry keys in the service’s Registry tree. For example, the FailureCommand key may be changed so that the service is executed in an elevated context anytime the service fails or is intentionally corrupted.[3][4]
The Performance key contains the name of a driver service's performance DLL and the names of several exported functions in the DLL.[5] If the Performance key is not already present and if an adversary-controlled user has the Create Subkey permission, adversaries may create the Performance key in the service’s Registry tree to point to a malicious DLL.[6]
Adversaries may also add the Parameters key, which can reference malicious drivers file paths. This technique has been identified to be a method of abuse by configuring DLL file paths within the Parameters key of a given services registry configuration. By placing and configuring the Parameters key to reference a malicious DLL, adversaries can ensure that their code is loaded persistently whenever the associated service or library is invoked.
For example, the registry path[7] HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters[8][9] contains the AutodiaDLL value, which specifies the DLL to be loaded for autodial funcitionality. An adversary could set the AutodiaDLL to point to a hijacked or malicious DLL:
"AutodialDLL"="c:\temp\foo.dll"
This ensures persistence, as it causes the DLL (in this case, foo.dll) to be loaded each time the Winsock 2 library is invoked.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1058 | Service Registry Permissions Weakness | Service Registry Permissions Weakness revoked by this object. |
| Enterprise | T1574 | Hijack Execution Flow | This object subtechnique of Hijack Execution Flow. |
Groups, software, and campaigns
C0006: Operation Honeybee
Operation Honeybee was a campaign that targeted humanitarian aid and inter-Korean affairs organizations from at least late 2017 through early 2018. Operation Honeybee initially targeted South Korea, but expanded to include Vietnam, Singapore, Japan, Indonesia, Argentina, and Canada. Security researchers assessed the threat actors were likely Korean speakers based on metadata used in both lure documents and executables, and named the campaign "Honeybee" after the author name discovered in malicious Word documents.[1]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 96a033fc6688… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Registry Key Security
Microsoft. (2018, May 31). Registry Key Security and Access Rights. Retrieved March 16, 2017.
Open source URL -
[2]
malware_hides_service
Lawrence Abrams. (2004, September 10). How Malware hides and is installed as a Service. Retrieved August 30, 2021.
Open source URL -
[3]
Kansa Service related collectors
Hull, D.. (2014, May 3). Kansa: Service related collectors and analysis. Retrieved October 10, 2019.
Open source URL -
[4]
Tweet Registry Perms Weakness
@r0wdy_. (2017, November 30). Service Recovery Parameters. Retrieved September 12, 2024.
Open source URL -
[5]
microsoft_services_registry_tree
Microsoft. (2021, August 5). HKLM\SYSTEM\CurrentControlSet\Services Registry Tree. Retrieved August 25, 2021.
Open source URL -
[6]
insecure_reg_perms
Clément Labro. (2020, November 12). Windows RpcEptMapper Service Insecure Registry Permissions EoP. Retrieved August 25, 2021.
Open source URL -
[7]
MDSec
MDSec. (n.d.). Autodial(DLL)ing Your Way. Retrieved September 25, 2025.
Open source URL -
[8]
hexacorn
hexacorn. (2015, January 13). Beyond good ol’ Run key, Part 24. Retrieved September 25, 2025.
Open source URL -
[9]
gendigital
Threat Research Team. (2022, March 22). Operation Dragon Castling: APT group targeting betting companies. Retrieved September 25, 2025.
Open source URL -
[10]
mitre-attack T1574.011Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.