How T1574 hijack execution flow hides malicious code inside normal program starts
A SOC lead often first notices T1574 Hijack Execution Flow as a small oddity: a trusted binary starts at an unexpected moment, or it loads a module from a folder nobody expected. The technique lets an adversary run its code through a legitimate program's normal start path, so the activity inherits the trust of that program. In ATT&CK Enterprise 20.0, it sits under the Stealth tactic (TA0005), which MITRE describes as adversaries trying to hide and conceal their actions by appearing as normal behavior. In intrusions, it can appear as a way to keep execution hidden inside processes that defenders already expect to see, so any trusted process that behaves out of pattern deserves a closer look.
T1574 has 12 sub-techniques, and the set differs by platform, so a Linux server, a macOS endpoint and a Windows host will each produce different telemetry and raise different review questions. This page targets Enterprise ATT&CK version 20.0, and detection mappings should name that version because releases can rename, deprecate or revoke techniques. Note that ATT&CK v19 split Defense Evasion into Stealth and a new Defense Impairment tactic, so older internal documents may still use the previous tactic name. Confirm the current sub-technique list for each target platform in the Enterprise STIX bundle before writing any rule.
Before tuning anything, decide which platforms come first and who owns the baseline of expected program paths, signed binaries and loaded modules. Ask the detection team to confirm which telemetry each platform actually provides, since Process Creation, Module Load and File Creation are the data components most often referenced across Stealth techniques, and coverage varies by agent and logging configuration. A useful first check is whether your team can answer, for a sample of trusted processes, where each one normally starts and which modules it normally loads. Where that baseline does not exist, the first deliverable is the baseline itself, not an alert.
Which telemetry reveals T1574 on Linux, macOS and Windows
This table maps each ATT&CK data component to the hijack signal it reveals, the platforms where it applies and the open-source collector that gathers it. Read each row as a question about your own estimate of coverage: if the collector is missing on a host group, the matching signal is blind. Process Creation and Module Load carry most of the weight, with File Creation showing where an altered search path or load location lands on disk.
| Data component | Signal it reveals for T1574 | Platforms and open-source collector |
|---|---|---|
| Process Creation (DC0032) | A process starts from an unexpected path or with an unexpected parent after a library, service binary or search path has been changed | Windows via Sysmon process events; Linux and macOS via auditd execve records; Wazuh for collection and rules |
| Module Load (DC0016) | A DLL or shared object loads from a writable or non-standard directory, or a module loads that does not match the expected publisher or path | Windows via Sysmon image load events; Linux via auditd or Velociraptor artifacts; macOS via endpoint collection where the platform exposes it |
| File Creation (DC0039) | A new library, configuration or service file appears in a directory that normally stays static, often shortly before a process runs from it | Windows via Sysmon file create events; Linux via auditd file watches; Wazuh file integrity monitoring on defined paths |
| Command Execution (DC0064) | Shell or administrative commands that modify environment variables, linker configuration or service settings, used to correlate with the other signals | Linux and macOS via shell history and auditd; Windows via PowerShell logging forwarded to Wazuh; supports correlation rather than standing alone |
| Network Connection Creation (DC0082) | Optional context: a newly loaded or executed component that opens outbound connections soon after it appears | Zeek or Suricata sensors where network visibility exists; treat as supporting evidence only |
| Collector coverage check | Confirm that each host group in scope produces the events above before relying on the detection | Ask your team to verify Sysmon configuration, auditd rules and Wazuh agent status per platform in your own environment |
Detection logic for T1574 that SOC teams can tune
The four detection ideas below cover the places where T1574 Hijack Execution Flow shows up most often: process ancestry, module loading, search-order directories and loader configuration. Each one is written as a Sigma-style rule concept targeting Enterprise ATT&CK version 20.0, so teams can baseline it against their own software estate before alerting.
Unexpected parent-child for trusted binaries
Alert when a signed system binary or a common utility starts from a parent process it has never been seen under in your environment. Hijacked execution often places a trusted binary under an unusual launcher, such as a script host, a user-profile executable or a document viewer. Build the baseline per host role from several weeks of Process Creation telemetry, then tune out known installer and updater chains. Start with the parent image path and signer, not the child name alone, because a renamed binary is a common pattern. Expect false positives from software updates and deployment tools that launch system binaries on purpose.
Module loads from user-writable paths
Flag Module Load events where a process loads a DLL or shared object from a directory that standard users can write to, such as a user profile, a temporary folder or an application data path. This is the core signal for DLL search-order and side-loading patterns under T1574. Tune by listing the approved third-party application directories in your estate and excluding them by hash and signer. Review loads from newly installed applications separately, since a fresh install can look identical to a planted library. Package managers, developer tools and endpoint agents are the usual sources of noise, so confirm each exception with the owning team.
New or modified files in search-order directories
Correlate File Creation events in directories that Windows or Linux loaders consult before system locations with a later Module Load or Process Creation event that uses the same file name. A file written to an application folder and loaded minutes later is a strong pairing. Set the time window and the directory list as tunable values, and suppress paths owned by package managers during scheduled patch windows. Installers, software updates and configuration management tools create large volumes of legitimate files here, so tie the rule to the write source process where your telemetry supports it.
Changes to loader configuration on Linux and macOS
On Linux and macOS, alert on modifications to files that control library loading, such as the dynamic linker preload configuration, library path overrides and launch agent or daemon definitions that point to unusual binaries. Use File Modification or File Creation telemetry with the file integrity baseline from your host agent. Baseline these files on clean builds of each image, and require a change ticket or configuration management run to explain writes. Package installs, kernel updates and configuration management runs produce expected changes, so treat unmatched changes outside those windows as the priority.
How to validate T1574 detections in a lab before production
This sequence proves that each T1574 detection fires on the behaviors it claims to cover, at a known latency, before the rule reaches production. It produces a scored record of true positives, false positives and missed behaviors that a tuning cycle can be measured against.
Agree scope and rules of engagement
The detection engineering lead, the SOC manager and the platform owner agree in writing which hosts in the cyber range stand in for production Linux, macOS and Windows endpoints, which T1574 sub-techniques are in scope, and what the emulation must never touch, such as production identity systems or real business data. Name a single coordinator who can halt the run. The step is done when a signed scope note lists the in-scope sub-techniques, the excluded assets and the stop conditions, and the team confirms that the range is isolated from production networks. Confirm the rules of engagement with your legal and change management owners before any activity begins.
Map planned behaviors to sub-techniques and detections
Build a table that links each planned behavior, described in plain terms, to a T1574 sub-technique ID, the ATT&CK version it targets, the data components it should generate (such as Process Creation, Module Load or File Creation), and the detection rule or analytic expected to fire. Record the expected log source for each row, for example Wazuh alerts, Sysmon events or Velociraptor artifacts. The output is a traceability matrix where every planned behavior has exactly one expected detection and every detection has at least one planned behavior. Rows without a mapped detection become explicit gaps to log in advance, not surprises at the end.
Prepare the range and baseline telemetry
Confirm that the range endpoints forward the telemetry the matrix depends on, and capture a clean baseline before any emulation. The platform engineer checks agent versions, log pipelines into the SIEM or Security Onion, and time synchronization across hosts, because clock drift will distort latency numbers. Record the rule versions under test with their commit identifiers. Take a snapshot of each range host so the environment can be reset to the same state for every re-run. The step is complete when a baseline query shows that expected events are arriving with usable timestamps and that the rule set matches the version written in the test plan.
Run the emulation under observation
A designated operator runs the agreed behaviors one at a time, in the order of the matrix, while a second person watches the SOC console and the logs. Each behavior is logged with a start time, an end time and the host it ran on, so later analysis can match alerts to actions. The operator does not improvise outside the plan, and any deviation is recorded and approved by the coordinator. The step is complete when every planned behavior has a timestamped execution record and the coordinator confirms that the run ended within the agreed stop conditions.
Record which events fired and their latency
For each planned behavior, pull the events and alerts the platform produced and compare them with the execution record. Note whether the expected detection fired, which data component generated the evidence, and the delay between the action and the first alert reaching an analyst queue. Store the results in a structured table so that latency can be compared across runs. Use the same clock source for every measurement. The output is a per-behavior result that shows fired or not fired, the event source and the measured latency, which gives the team an evidence-based view of how quickly T1574 activity becomes visible.
Score outcomes and log gaps
Classify each planned behavior as a true positive when the expected detection fires with correct context, a false positive when an alert fires on benign activity in the same run or on unrelated baseline noise, or a missed behavior when no expected detection fires. Log each gap with a root cause: missing telemetry, a rule logic issue, a threshold problem, an overly narrow platform filter or an unsupported log source. Review the false positives against the baseline to confirm they are caused by the emulation or by ordinary administrative activity. The step closes with a scoring summary and a gap register with owners assigned, so that every missed behavior has a named person and a next action.
Tune rules and re-run the same plan
The detection engineer changes rule logic, thresholds or data sources based on the gap register, records each change against the rule version, and then re-runs the identical plan on the reset range snapshot. Comparing the second run with the first shows whether the tuning closed the gaps without adding new false positives. Keep the earlier results so that the change history is auditable. The step is complete when the re-run produces a scored summary that shows each gap either closed, accepted with a documented risk decision, or escalated. Repeat the cycle whenever ATT&CK releases change the sub-technique set, because mappings must name the version they target.
Preventive controls that limit T1574 hijacks
T1574 works by getting the operating system or an application to load attacker-controlled code in place of a legitimate one. The controls below reduce how often that swap succeeds and how quickly defenders notice when it is attempted. Audit and behavior prevention address the execution path directly, while permission hardening limits where a hijack can be planted in the first place.
Audit (M1047)
The Audit mitigation means enabling the logging that makes hijacks visible: process creation with command lines, module or library loads where the platform supports them, and file creation or modification in search-path and loader directories. Without these records, a swapped DLL, shared object or dylib looks like a normal application start. Confirm in your endpoint product which of these event types it records by default, how long they are retained, and whether they reach your Wazuh or other SIEM pipeline with enough fields to compare file hashes and signers against a baseline.
Behavior prevention on endpoint
Behavior Prevention on Endpoint (M1040) asks the endpoint product to act on suspicious execution patterns rather than only matching known files. For T1574, this includes blocking or quarantining a process that loads a library from an unexpected location or that starts a trusted binary from a writable path. Confirm whether your product can block at load time or only alert, which Linux, macOS and Windows components it covers, and whether a block can be scoped by path, signer or parent process so that legitimate software updates are not disrupted.
Restrict write access to search paths
Restrict File and Directory Permissions (M1022) is a related mitigation rather than a replacement for the two controls above. Limiting write access to directories that the OS or applications search for libraries, along with loader configuration files, removes the easiest place for an attacker to plant a replacement. Review ACLs on application install directories, service folders and PATH-adjacent locations, and confirm that changes to these paths generate audit events so that any permitted write still leaves a trace.
Validate controls in a cyber range
A preventive control is only useful if it fires against a hijack in your environment. In a private cyber range, DeployOpen can help you run benign, controlled library-substitution tests against images that match your production builds, then record whether the Audit events and behavior blocks appear as expected. Ask the team to document which tests were blocked, which were only alerted and which were missed, so that exceptions for legitimate software are approved with evidence rather than assumed.
What SOC teams should do when a T1574 detection fires
When a T1574 detection fires, the first decision is whether the event is a legitimate change or a hijacked load path, and the fastest way to make that call is to rebuild the process lineage and the loaded module path before anyone touches the host. Confirm which parent process started the binary, whether the executable or library was loaded from its expected directory, and whether the path sits in a location that software updates or administrators would not normally use. Then compare the file hash and the code signer against your known-good baseline for that software version. Check your change records, patch management system and software deployment logs for an update, installer or configuration push on the same host within the same window. A matching, signed, change-tracked update usually explains the event, while an unsigned module, a hash that matches no known release, or a load from a user-writable directory does not.
If the evidence does not explain the event, determine scope before containment. Search the same hash, file path and module name across the fleet, since a hijacked search order or DLL side-loading pattern is often repeated on other hosts that share an application image. Containment should be proportionate: isolating a single endpoint through your EDR or network controls is usually the first step, while restoring the original file or disabling the affected service should wait until evidence is preserved. Collect volatile and file-level artifacts with a collector such as Velociraptor, which can gather running process details, loaded modules, file metadata and hashes under a documented hunt or collection, and record the chain of custody. Confirm what your open-source stack retained for these hosts, because a short log retention window can limit how far back scope can be established.
Escalate to incident response as soon as the event cannot be tied to a known-good change, the module or binary is signed by an unknown party or is unsigned in a privileged path, or the same pattern appears on more than one host or in a system that handles regulated data. Your incident response plan should name who can authorize isolation of a production system and who owns evidence handling, so these decisions do not wait for a meeting. Feed confirmed findings back into the detection by tuning the rule to your environment's approved installers and update channels, and record the ATT&CK version and sub-technique the detection targeted so later reviews can trace the mapping.
Rehearsing T1574 detection and response in a private cyber range
On Linux, the range should contain isolated endpoints built from the same distribution and configuration baseline as the production fleet, with an agent forwarding process, file and authentication events to a SIEM such as Wazuh, and network sensors such as Zeek or Suricata watching the range segment. Facilitators schedule injects at a high level: a change to a dynamic loader configuration on a test host, a modified library path set for a single service, and a file written to a writable directory that a privileged process later loads. Good detection means analysts see the file creation and the configuration change within the expected time window, and that a rule tied to Process Creation and Module Load fires with enough context to name the affected binary. Good response means the team scopes the affected hosts, confirms the loaded object against a known-good hash, reverts the configuration and records the timeline.
- Range build: Confirm which agent version, audit rules and log sources are in place on each isolated host before the exercise starts.
- Injects: Keep injects reversible and limited to range hosts, and name each one in the facilitator plan.
- Detection quality: Check that alerts carry the process lineage, the loaded path and the user context, not only a file name.
- Response quality: Measure how quickly the team pivots from the alert to the affected service owner.
- Evidence: Export the SIEM events and case notes so the rehearsal can feed later tuning.
Check that every inject maps to a named ATT&CK version and sub-technique so results can be compared across rehearsals.
On macOS, the range should use managed endpoints enrolled in the same device management and logging configuration as the target fleet, with the endpoint telemetry pipeline forwarding process, module and file events to the SIEM. Because macOS enforces code signing and notarization in ways that vary by version, confirm with your vendor and your own baseline which protections are enabled on the test images before scheduling injects. Facilitators typically schedule a change to a user-level launch configuration on a test device, a substitution of a library in a location an application searches first, and a file dropped into an application bundle that a signed app later loads. Good detection means the team sees the file creation and the module load tied to an unexpected parent process, and the alert identifies the signing state of the loaded code. Good response means containing the device, validating signatures, restoring the bundle from a trusted source and checking other endpoints for the same pattern.
- Device baseline: Record the operating system version and protection settings on each test image.
- Injects: Limit injects to test users and approved application bundles, and keep a restore script ready.
- Detection quality: Look for alerts that show the signing status and the parent process of the loaded module.
- Response quality: Confirm the team can isolate a device through the management console within the agreed window.
- Evidence: Preserve unified log exports and file hashes before any restore action.
Check whether your endpoint agent exposes module load events on the macOS versions in your fleet, because coverage differs by product.
On Windows, the range should include domain-joined endpoints, a domain controller, and a Windows event pipeline using Sysmon or an equivalent sensor forwarding process creation, image load and file creation events into Wazuh or Security Onion. Facilitators schedule injects that mirror search-order and service-loading behavior on test hosts: a benign DLL placed in an application directory that a service loads, a change to a service or scheduled task definition that points to a path outside the normal location, and a registry-based change to an application's load settings. Good detection means analysts correlate a file creation in a writable path with a module load by a privileged or signed process, and the alert names the expected and actual image paths. Good response means the team isolates the host, identifies the hijacked object, verifies its signature and hash, removes the change through an approved change process and reviews whether the same location exists on other hosts.
- Telemetry: Confirm that image load events are enabled in the sensor configuration before the exercise, because they are often off by default.
- Injects: Use test software in an isolated domain, and avoid any change to production group policy.
- Detection quality: Check that the rule compares the expected image path to the observed one and reduces noise from signed vendor updates.
- Response quality: Test whether the team can roll back a service definition without breaking dependent services.
- Evidence: Export Sysmon and SIEM records with timestamps so the sequence can be rebuilt.
Check that your sensor version and configuration match the detection strategies you are testing, and confirm the rule logic against the ATT&CK version you target.
Questions detection engineers ask about T1574
How do I tell a hijack apart from a legitimate software update?
Start with provenance. Check whether the newly written or loaded file is signed by the expected publisher, whether the process that wrote it is a known updater running under the expected account, and whether the file sits in the vendor's install location. Legitimate updates usually arrive through a managed update channel and leave a predictable process lineage. Hijacks tend to show a library or binary written to a writable search path and loaded by a process that does not normally load it. Build an allowlist of approved updaters from your asset inventory, alert on exceptions, and triage those exceptions with the change record in hand. Before you tune alerts, confirm each vendor's documented update mechanism in your own lab so the allowlist matches what your software actually does.
Which T1574 sub-techniques should my team prioritize on each platform?
Prioritize by where your estate is most exposed and where your telemetry is strongest. On Windows, DLL search order and side-loading patterns in user-writable or application directories usually deserve early attention, because they affect many common applications. On Linux, look first at dynamic linker hijacking, since a successful change there can affect many processes at once. On macOS, dylib hijacking in application bundles is the usual starting point. Rank the sub-techniques by asset criticality, then by whether you already collect the data components needed to see them. Confirm the sub-technique list and descriptions on the ATT&CK page for T1574 in the version you target, since sub-techniques can change between releases.
How should detection mappings handle ATT&CK version changes from v18 to v20?
Name the ATT&CK version in every rule's metadata and keep the mapping tied to it. ATT&CK v18, released October 28, 2025, replaced detections in technique pages with detection strategies and analytics and deprecated data sources, so older mappings may reference retired fields. ATT&CK v19, released April 28, 2026, split the Enterprise Defense Evasion tactic into Stealth, which keeps ID TA0005, and Defense Impairment, which has ID TA0112. Any mapping that stored the old tactic needs an update. ATT&CK v20, released October 13, 2026, may rename or revoke items, so diff the STIX bundle for each version against your mappings before you adopt it. Record the version, the diff date and the owner of each change.
Is Module Load telemetry necessary for detecting T1574 on Linux?
It is not strictly required, but it is the strongest signal for library-based hijacks. Module Load (DC0016) records when code is brought into a process, which is where a substituted library shows up. Process Creation (DC0032) and File Creation (DC0039) can still reveal suspicious writes to loader configuration locations or unexpected binaries, but they often miss a library that is loaded from a legitimate path. Confirm with your Linux telemetry stack, whether it is auditd, an EDR agent or another collector, that library load events are captured at a volume your storage can sustain. Test this in your cyber range by planting a benign, clearly labeled library and checking whether each source records it.
How do I measure detection coverage for T1574 sub-techniques?
Track coverage per sub-technique, not per technique, and count a sub-technique as covered only when a detection has been validated. For each sub-technique, record the data components that feed it, the detection logic in words or rule form, the platforms where it applies, and the date of the last successful test. Mark gaps where telemetry is missing, where the detection has never fired in a test, or where it depends on an allowlist nobody has reviewed. Review the matrix after each ATT&CK release and after major changes to your endpoint tooling. Ask your team to state which sub-techniques are validated, which are partially covered and which are unmonitored, so the gap list drives the next sprint.
How do I keep T1574 baselines current as software changes?
Tie baseline review to the events that change your software: patch cycles, new application onboarding, retirements and ATT&CK version updates. Use software inventory diffs to see which binaries, libraries and install paths changed, then update the allowlist of approved updaters with the owner and change ticket attached. Set a recurring review, with a named owner, that checks stale exceptions and removes entries for software no longer deployed. Retest a sample of detections in your cyber range after each significant baseline change, because a tuned rule can silently stop firing after an update. Keep the review record as evidence for your compliance team and your assessors.
How DeployOpen builds T1574 detections and range scenarios
DeployOpen scopes T1574 detection work as a fixed-scope engagement agreed in writing before any engineering starts. For Hijack Execution Flow, the scope should name the platforms in play (Linux, macOS and Windows), the sub-techniques to cover, the telemetry the client already collects, and the open-source stack that will receive it, such as Wazuh, Security Onion, Zeek or Velociraptor. The written scope also fixes the deliverables, which typically include detection logic described in words and mapped to ATT&CK, validation records and a response runbook. Ask for the number of sub-techniques in scope and the data components each analytic depends on, since Process Creation, Module Load and File Creation each need different collection settings. Work runs inside the client's own cloud accounts, data centers or air-gapped networks, so the client keeps custody of logs and rules.
Purple team exercises run in a private cyber range that mirrors the client's endpoint estate and logging pipeline. DeployOpen's engineers and the client's detection staff plan each T1574 scenario in advance, with a stated expected telemetry trail, a defined pass condition and a rollback path. Practical questions to settle early include whether the range can load and unload shared libraries on the test hosts, whether Windows and Linux telemetry arrives within the alert window the SOC expects, and whether analysts can reconstruct the full execution chain from the alert. Every scenario is recorded against a named ATT&CK version, such as v20, so that detection mappings stay traceable when MITRE renames, deprecates or revokes content in later releases. Confirm the exact version and the matching detection strategy identifiers with the client's own ATT&CK tooling before the range is built.
DeployOpen prepares the systems, control descriptions and evidence that a compliance assessment will examine, including detection coverage records, validation results, change history for rules and proof that audit and endpoint prevention settings were in effect during testing. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so the client should confirm early which assessor will review the evidence and which format they expect. Ongoing tuning, retesting after ATT&CK releases and support for new endpoint builds are usually handled through a retainer, while the initial build is a one-time fixed-scope piece. Ask for the retest cadence, the process for rule changes and the owner of each evidence artifact before signing.
