One variant of BlackEnergy locates existing driver services that have been disabled and drops its driver component into one of those service's paths, replacing the legitimate executable. The malware then sets the hijacked service to start automatically to establish persistence.1
Services File Permissions Weakness T1574.010
- Platform
- Windows
- Version
- 2.0
- Created
- 12 March 2020
- Last modified
- 12 May 2026
- Contributors
- Stefan Kanthak; Travis Smith, Tripwire
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.
Services File Permissions Weakness MITRE reference T1574.010
1 software entry is documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
All 1 software entries for this technique
Offense vs defense T1574.010
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Services File Permissions Weakness detection strategy DET0436
MITRE names one behaviour worth catching for this technique and breaks it into 1 analytic, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection Strategy for Hijack Execution Flow through Services File Permissions Weakness.
AN1211 · Windows
Modification or replacement of service executables due to weak file or directory permissions. Defender observes file writes to service binary paths, unexpected modifications of executables associated with registered services, and subsequent service execution of attacker-supplied binaries under elevated permissions.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | WinEventLog:Sysmon | EventCode=1 |
| File CreationDC0039 | WinEventLog:Sysmon | EventCode=11 |
| File MetadataDC0059 | WinEventLog:Sysmon | EventCode=15 |
| Service CreationDC0060 | WinEventLog:System | EventCode=7045 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| MonitoredServices | List of critical services and their expected executable paths for integrity checking. |
| HashBaseline | Baseline hashes of legitimate service executables for tamper detection. |
| TimeWindow | Correlation interval between file modification of service executables and service execution. |
| PrivilegedAccounts | Accounts allowed to legitimately modify service executables. |
The Sysinternals tool Autoruns checks the registry and file system for known identify persistence mechanisms. It will output any tools identified, including built-in or added-on Microsoft functionality and third party software. Many of these locations are known by adversaries and used to obtain Persistence. Running Autoruns periodically in an environment makes it possible to collect and monitor its output for differences, which may include the removal or addition of persistent tools. Depending on the persistence mechanism and location, legitimate software may be more likely to make changes than an adversary tool. Thus, this analytic may result in significant noise in a highly dynamic environment. While Autoruns is a convenient method to scan for programs using persistence mechanisms its scanning nature does not conform well to streaming based analytics. This analytic could be replaced with one that draws from sensors that collect registry and file information if streaming analytics are desired.
D3FEND techniques
The defensive countermeasure this analytic implements, in MITRE’s D3FEND ontology.
| ID | Name |
|---|---|
| D3-SICA | System Init Config Analysis |
Adversaries may modify the binary file for an existing service to achieve Persistence while potentially evading defenses. If a newly created or modified runs as a service, it may indicate APT activity. However, services are frequently installed by legitimate software. A well-tuned baseline is essential to differentiating between benign and malicious service modifications.
D3FEND techniques
The defensive countermeasure this analytic implements, in MITRE’s D3FEND ontology.
| ID | Name |
|---|---|
| D3-SBV | Service Binary Verification |
Data model references
The CAR data model objects, actions and fields the logic reads. Map these to your own schema before implementing.
| Object | Action | Field |
|---|---|---|
| file | create | file_path |
| file | create | image_path |
| process | create | image_path |
| process | create | parent_exe |
Implementations
Pseudocode is the canonical logic; the rest are CAR’s translations into vendor query languages.
Look for events where a file was created and then later run as a service. In these cases, a new service has been created or the binary has been modified. Many programs, such as msiexec.exe, do these behaviors legitimately and can be used to help validate legitimate service creations/modifications.
legitimate_installers = ["C:\windows\system32\msiexec.exe", "C:\windows\syswow64\msiexec.exe", ...] file_change = search File:Create,Modify process = search Process:Create service_process = filter processes where (parent_exe == "services.exe") modified_service = join (search, filter) where ( file_change.time < service_process.time and file_change.file_path == service_process.image_path ) modified_service = filter modified_service where (modified_service.file_change.image_path not in legitimate_installers) output modified_service
Use auditing tools capable of detecting file system permissions abuse opportunities on systems within an enterprise and correct them. Toolkits like the PowerSploit framework contain PowerUp modules that can be used to explore systems for service file system permissions weaknesses.
Turn off UAC's privilege elevation for standard users [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]to automatically deny elevation requests, add: "ConsentPromptBehaviorUser"=dword:00000000. Consider enabling installer detection for all users by adding: "EnableInstallerDetection"=dword:00000001. This will prompt for a password for installation and also log the attempt. To disable installer detection, instead add: "EnableInstallerDetection"=dword:00000000. This may prevent potential elevation of privileges through exploitation during the process of UAC detecting the installer, but will allow the installation process to continue without being logged.
Limit privileges of user accounts and groups so that only authorized administrators can interact with service changes and service binary target path locations. Deny execution from user directories such as file download directories and temp directories where able.