T1574: Hijack Execution Flow
Adversaries may execute their own malicious payloads by hijacking the way operating systems run programs. Hijacking execution flow can be for the purposes of persistence, since this hijacked execution may reoccur over time. Adversaries may also use these mechanisms to elevate privileges or evade defenses, such as application control or other restrictions on execution.
There are many ways an adversary may hijack the flow of execution, including by manipulating how the operating system locates programs to be executed. How the operating system locates libraries to be used by a program can also be intercepted. Locations where the operating system looks for programs/resources, such as file directories and in the case of Windows the Registry, could also be poisoned to include malicious payloads.
Analyst context for executives and security teams
Hijack Execution Flow matters because it turns normal operating-system behavior—how programs, libraries, paths, environment variables, services, and registry settings are resolved—into a way to run attacker-controlled code. For leaders, the risk is not just malware execution; it is that trusted applications or services may become the launch point, complicating application control, persistence review, privilege boundaries, and incident scoping across Windows, Linux, and macOS.
Executive priority
Prioritize this as a control-assurance issue: are critical endpoints and servers configured so ordinary users or compromised processes cannot alter executable paths, libraries, service definitions, registry locations, or writable directories used by trusted software? This technique family is relevant to operational resilience because it can support persistence, privilege escalation, and defense evasion. It also creates audit evidence needs around least privilege, secure software deployment, update hygiene, and endpoint behavior prevention.
Technical view
ATT&CK provides no standalone detection text for T1574, so defenders should validate coverage through the related detection strategy DET0218 and the listed sub-techniques. Practical validation should span Windows, Linux, and macOS execution paths: DLL and dylib loading behavior, dynamic linker environment variables, PATH search order, unquoted or weak service paths, writable installer or service binaries, sensitive registry permissions, and .NET-related hijack points such as COR_PROFILER and AppDomainManager. SOC and IR teams should focus on whether a trusted process loaded or executed code from an unexpected, user-writable, recently modified, or policy-inconsistent location.
Likely telemetry
- Process creation events with command line, parent process, executable path, user, integrity/elevation context, and hash where available
- File creation, modification, replacement, and permission-change events for executable files, DLLs, shared objects, dylibs, installer directories, service directories, and application search paths
- Library/module load telemetry showing process, module path, signature or trust status, and load location
- Windows Registry change telemetry for service configuration and other execution-related keys, especially HKLM\SYSTEM\CurrentControlSet\Services where applicable
- Environment variable and configuration change evidence for PATH, LD_PRELOAD, DYLD_INSERT_LIBRARIES, COR_PROFILER, and related runtime loading controls where collected
Detection direction
- Map detections to the sub-techniques rather than treating T1574 as a single analytic; DLL side-loading, path interception, service permission weakness, dynamic linker hijacking, and .NET hijacks produce different evidence.
- Baseline legitimate software update, installer, developer, and administrative activity to reduce false positives when files, libraries, or service settings change in trusted locations.
- Prioritize alerts where trusted or elevated processes execute code from user-writable directories, unexpected search-order locations, recently modified paths, or unsigned/untrusted libraries, subject to local policy.
- Validate visibility on macOS and Linux as well as Windows; ATT&CK lists all three platforms, but many organizations over-focus on Windows DLL and service cases.
- Use DET0218 as the ATT&CK-linked detection strategy reference, but confirm local sensors actually collect module loads, registry changes, permission changes, and environment variable evidence needed for the relevant sub-techniques.
Mitigation priorities
- Start with least privilege and user account management so users and routine processes cannot write to locations used for privileged execution.
- Restrict file, directory, and registry permissions on service paths, installer paths, application directories, library locations, and sensitive execution configuration.
- Apply execution prevention and endpoint behavior prevention to reduce unauthorized code execution and suspicious process behavior, while testing for business-process exceptions.
- Restrict library loading and promote safe library loading practices in supported environments.
- Use application developer guidance and secure SDLC practices so internally developed or packaged applications do not rely on unsafe search paths, weak linking, or ambiguous executable resolution.
Analyst notes and limits
This is a broad parent technique with many sub-techniques across Windows, Linux, and macOS. Its defensive value comes from combining configuration assurance with behavior monitoring: who can modify execution locations, what code is actually loaded, and whether trusted processes are resolving dependencies from expected paths. The strongest local assessment is a control test against representative business applications, services, installers, and developer-managed systems.
The official object does not provide detection guidance, and the relationship descriptions are mitigation- and sub-technique-focused. This take therefore avoids claiming specific detection coverage or exploitation prevalence. Local platform mix, endpoint sensor capabilities, application architecture, and permissions model are required to determine actual exposure and monitoring quality.
Hijack Execution Flow
Adversaries may execute their own malicious payloads by hijacking the way operating systems run programs. Hijacking execution flow can be for the purposes of persistence, since this hijacked execution may reoccur over time. Adversaries may also use these mechanisms to elevate privileges or evade defenses, such as application control or other restrictions on execution.
There are many ways an adversary may hijack the flow of execution, including by manipulating how the operating system locates programs to be executed. How the operating system locates libraries to be used by a program can also be intercepted. Locations where the operating system looks for programs/resources, such as file directories and in the case of Windows the Registry, could also be poisoned to include malicious payloads.
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.010 | Services File Permissions Weakness Sub-technique | Services File Permissions Weakness subtechnique of this object. |
| Enterprise | T1574.013 | KernelCallbackTable Sub-technique | KernelCallbackTable subtechnique of this object. |
| Enterprise | T1574.007 | Path Interception by PATH Environment Variable Sub-technique | Path Interception by PATH Environment Variable subtechnique of this object. |
| Enterprise | T1574.005 | Executable Installer File Permissions Weakness Sub-technique | Executable Installer File Permissions Weakness subtechnique of this object. |
| Enterprise | T1574.002 | DLL Side-Loading Sub-technique | DLL Side-Loading subtechnique of this object. |
| Enterprise | T1574.009 | Path Interception by Unquoted Path Sub-technique | Path Interception by Unquoted Path subtechnique of this object. |
| Enterprise | T1574.004 | Dylib Hijacking Sub-technique | Dylib Hijacking subtechnique of this object. |
| Enterprise | T1574.006 | Dynamic Linker Hijacking Sub-technique | Dynamic Linker Hijacking subtechnique of this object. |
| Enterprise | T1574.014 | AppDomainManager Sub-technique | AppDomainManager subtechnique of this object. |
| Enterprise | T1574.001 | DLL Sub-technique | DLL subtechnique of this object. |
| Enterprise | T1574.008 | Path Interception by Search Order Hijacking Sub-technique | Path Interception by Search Order Hijacking subtechnique of this object. |
| Enterprise | T1574.011 | Services Registry Permissions Weakness Sub-technique | Services Registry Permissions Weakness subtechnique of this object. |
| Enterprise | T1574.012 | COR_PROFILER Sub-technique | COR_PROFILER subtechnique of this object. |
Groups, software, and campaigns
S1111: DarkGate
DarkGate first emerged in 2018 and has evolved into an initial access and data gathering tool associated with various criminal cyber operations. Written in Delphi and named "DarkGate" by its author, DarkGate is associated with credential theft, cryptomining, cryptotheft, and pre-ransomware actions.[1] DarkGate use increased significantly starting in 2022 and is under active development by its author, who provides it as a Malware-as-a-Service offering.[2]
S0567: Dtrack
S9024: SPAWNCHIMERA
SPAWNCHIMERA is a backdoor that supports command and control and can inject malicious components into native processes.[1][2][3] SPAWNCHIMERA It incorporates capabilities from multiple tools within the SPAWN malware family, including SPAWNANT, SPAWNMOLE, and SPAWNSNAIL.[4][2][3] SPAWNCHIMERA was first reported in April 2024.[2] SPAWNCHIMERA has been observed in activity attributed to People's Republic of China (PRC) state-sponsored threat actors, including UNC5221..[4][5][2][6]
S0444: ShimRat
ShimRat has been used by the suspected China-based adversary Mofang in campaigns targeting multiple countries and sectors including government, military, critical infrastructure, automobile, and weapons development. The name "ShimRat" comes from the malware's extensive use of Windows Application Shimming to maintain persistence. [1]
S1130: Raspberry Robin
Raspberry Robin is initial access malware first identified in September 2021, and active through early 2024. The malware is notable for spreading via infected USB devices containing a malicious LNK object that, on execution, retrieves remote hosted payloads for installation. Raspberry Robin has been widely used against various industries and geographies, and as a precursor to information stealer, ransomware, and other payloads such as SocGholish, Cobalt Strike, IcedID, and Bumblebee.[1][2][3] The DLL componenet in the Raspberry Robin infection chain is also referred to as "Roshtyak."[4] The name "Raspberry Robin" is used to refer to both the malware as well as the threat actor associated with its use, although the Raspberry Robin operators are also tracked as Storm-0856 by some vendors.[5]
S0354: Denis
S1147: Nightdoor
S1105: COATHANGER
COATHANGER is a remote access tool (RAT) targeting FortiGate networking appliances. First used in 2023 in targeted intrusions against military and government entities in the Netherlands along with other victims, COATHANGER was disclosed in early 2024, with a high confidence assessment linking this malware to a state-sponsored entity in the People's Republic of China. COATHANGER is delivered after gaining access to a FortiGate device, with in-the-wild observations linked to exploitation of CVE-2022-42475. The name COATHANGER is based on a unique string in the malware used to encrypt configuration files on disk: “She took his coat and hung it up”.[1]
S1018: Saint Bot
Saint Bot is a .NET downloader that has been used by Saint Bear since at least March 2021.[1][2]
C0036: Pikabot Distribution February 2024
Pikabot was distributed in Pikabot Distribution February 2024 using malicious emails with embedded links leading to malicious ZIP archives requiring user interaction for follow-on infection. The version of Pikabot distributed featured significant changes over the 2023 variant, including reduced code complexity and simplified obfuscation mechanisms.[1][2]
C0017: C0017
C0017 was an APT41 campaign conducted between May 2021 and February 2022 that successfully compromised at least six U.S. state government networks through the exploitation of vulnerable Internet facing web applications. During C0017, APT41 was quick to adapt and use publicly-disclosed as well as zero-day vulnerabilities for initial access, and in at least two cases re-compromised victims following remediation efforts. The goals of C0017 are unknown, however APT41 was observed exfiltrating Personal Identifiable Information (PII).[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 | b693e5d763e4… |
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 T1574Open 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.