T1574.010: Services File Permissions Weakness
Adversaries may execute their own malicious payloads by hijacking the binaries used by services. Adversaries may use flaws in the permissions of Windows services to replace the binary that is executed upon service start. These service processes may automatically execute specific binaries as part of their functionality or to perform other actions. If the permissions on the file system directory containing a target binary, or permissions on the binary itself are improperly set, then the target binary may be overwritten with another binary using user-level permissions and executed by the original process. If the original process and thread are running under a higher permissions level, then the replaced binary will also execute under higher-level permissions, which could include SYSTEM.
Adversaries may use this technique to replace legitimate binaries with malicious ones as a means of executing code at a higher permissions level. If the executing process is set to run at a specific time or during a certain event (e.g., system bootup) then this technique can also be used for persistence.
Analyst context for executives and security teams
Services File Permissions Weakness matters because a normal Windows user may be able to replace a service binary if file or directory permissions are too permissive. When that service starts, the replacement can run with the service’s higher privileges, potentially including SYSTEM. For leaders, this is a configuration hygiene issue that can turn a low-privilege foothold into privileged execution or recurring persistence at boot or service start.
Executive priority
Prioritize this as a Windows privilege-escalation and persistence control gap: it is often decided by basic asset configuration, account privilege discipline, and audit evidence rather than a single security tool. Executives should ask whether service binary permissions are inventoried, reviewed after software deployment, and monitored for unauthorized change, especially on servers where privileged services support business-critical operations.
Technical view
This is a Windows sub-technique of Hijack Execution Flow focused on service binary replacement through weak file or directory ACLs. SOC, IR, and detection engineering teams should validate coverage for suspicious modification or replacement of binaries used by Windows services, followed by service execution under a higher-privileged context. Because the official object provides no detection text, use the related DET0436 detection strategy as the ATT&CK-supported direction, and test locally against service configuration, file permission state, service start events, and process execution lineage.
Likely telemetry
- Windows service configuration inventory, including service executable paths
- File and directory ACL data for service binary locations
- File creation, overwrite, rename, or modification events for service executables and their parent directories
- Windows service start, stop, creation, or configuration change events
- Process execution telemetry showing service-spawned binaries and execution account context
Detection direction
- Validate that detections correlate service binary path changes or file replacement with subsequent service execution, rather than relying only on process names.
- Prioritize monitoring where service binaries or parent directories are writable by non-administrative users or broadly scoped groups.
- Tune for legitimate software updates, patching, and administrative maintenance that may replace service binaries to reduce false positives.
- Confirm that collection includes both configuration state and event telemetry; file modification alone may not show privilege context, and service execution alone may not reveal the prior permission weakness.
- Use the relationship to DET0436 as the ATT&CK-supported detection-strategy reference, but require local validation because the official detection field is not provided.
Mitigation priorities
- Enforce least privilege and disciplined user account management so ordinary users cannot modify service binaries or service directories.
- Audit Windows service file paths and ACLs on a recurring basis, with special attention to services running with elevated privileges.
- Keep User Account Control enabled and properly configured as a supporting control against unauthorized elevated changes.
- Include service permission checks in build standards, software deployment validation, vulnerability/configuration management, and compliance evidence collection.
- During incident response, review recently modified service binaries and weak ACLs as potential persistence or privilege-escalation evidence.
Analyst notes and limits
This technique is Windows-specific in the supplied ATT&CK object and is part of the broader Hijack Execution Flow technique. MITRE also links BlackEnergy as software that uses this behavior, but that relationship should be treated as threat-context enrichment, not evidence of activity in any environment.
The official ATT&CK detection section is not provided, and the related DET0436 strategy details are not included in the supplied fields. Practical coverage depends on local Windows audit policy, endpoint telemetry, service inventory quality, and the organization’s ability to review ACLs at scale.
Services File Permissions Weakness
Adversaries may execute their own malicious payloads by hijacking the binaries used by services. Adversaries may use flaws in the permissions of Windows services to replace the binary that is executed upon service start. These service processes may automatically execute specific binaries as part of their functionality or to perform other actions. If the permissions on the file system directory containing a target binary, or permissions on the binary itself are improperly set, then the target binary may be overwritten with another binary using user-level permissions and executed by the original process. If the original process and thread are running under a higher permissions level, then the replaced binary will also execute under higher-level permissions, which could include SYSTEM.
Adversaries may use this technique to replace legitimate binaries with malicious ones as a means of executing code at a higher permissions level. If the executing process is set to run at a specific time or during a certain event (e.g., system bootup) then this technique can also be used for persistence.
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 | T1574 | Hijack Execution Flow | This object subtechnique of Hijack Execution Flow. |
| Enterprise | T1044 | File System Permissions Weakness | File System Permissions Weakness revoked by this object. |
Groups, software, and campaigns
S0089: BlackEnergy
BlackEnergy is a malware toolkit that has been used by both criminal and APT actors. It dates back to at least 2007 and was originally designed to create botnets for use in conducting Distributed Denial of Service (DDoS) attacks, but its use has evolved to support various plug-ins. It is well known for being used during the confrontation between Georgia and Russia in 2008, as well as in targeting Ukrainian institutions. Variants include BlackEnergy 2 and BlackEnergy 3. [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 | 41590b56120f… |
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]
mitre-attack T1574.010Open 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.