Security teams can detect Process hijacking by looking for a process that changes behaviour, loads unexpected modules, or inherits suspicious handles from another process. Monitor parent-child process chains, memory modifications, and privilege changes, and alert on legitimate processes spawning command shells, scripting engines, or network connections they do not normally create.
What process hijacking detection is really looking for
Process hijacking detection is about spotting when a trusted process stops behaving like itself. The clearest signals are unexpected module loads, abnormal memory writes, suspicious handle inheritance, and a legitimate process beginning to launch shells, script interpreters, or outbound network connections that are not part of its normal job.
That means the question is not only “did a process start?”, but “did its execution path, memory state, or privilege context change in a way that the process owner did not intend?” In practice, defenders should compare observed behaviour against the process’s baseline on that host, in that role, and at that point in its lifecycle.
Useful telemetry includes process creation, image load events, handle access patterns, memory protection changes, child-process spawning, and token or privilege adjustments. Correlating those signals is more reliable than any single indicator, because many hijacking techniques try to look like ordinary parent-child activity until the execution environment is altered.
Behavioural patterns that separate hijacking from normal admin activity
Process hijacking often appears as a legitimate binary performing actions that belong to a different toolchain. A service host that suddenly opens a command shell, a browser helper that launches scripting, or an update process that creates a remote connection can all be red flags when they break the host’s normal behaviour profile.
Watch for mismatches between the original image and the actions it performs after launch. Unexpected DLLs, abnormal memory modifications, thread injection, suspended-process tampering, and odd parent-child chains all matter because they suggest the process is being used as a carrier rather than acting on its own.
Process telemetry is strongest when you can tie it to context: signed-but-unexpected binaries, rare command-line arguments, unusual timing, or a process that inherits access it should not normally need. That context helps separate hijacking from legitimate automation, especially in environments where administrative tools and scripting are already common.
How to tune detections without drowning in false positives
A good detection strategy starts with a small set of high-confidence behaviours and then adds context. Generic alerts on any child process or any module load will be noisy; alerts become more useful when they focus on trusted processes that should rarely spawn shells, write into another process, or open network sessions outside their expected purpose.
Baseline by process name, image path, signer, parent process, host role, and user context. A process that is normal on one system may be suspicious on another, so detections need to reflect how the endpoint is actually used rather than how the vendor documentation describes it in isolation.
If you operate EDR telemetry, make sure the rule set can surface process injection, hollowing, or tampering behaviours as part of the same investigative queue. NHIMG’s EDR Evasion and Defence Guide is useful here because the same techniques that evade detection often overlap with the mechanics defenders need to observe.
Risk and Threat Considerations
Process hijacking is dangerous because it turns a trusted process into an execution foothold. Once an attacker can ride inside a legitimate process, they can hide malicious activity inside normal telemetry, borrow the process’s privileges, and make incident triage harder by blending in with expected system behaviour.
Failure mechanism: The hijack usually succeeds when defenders monitor only process starts and miss later changes such as memory patching, module replacement, handle abuse, or privilege escalation inside an already-running process.
Impact: The result can be stealthier command execution, credential or token exposure, lateral movement, and a much narrower response window because the compromised process may still appear legitimate at a glance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Process hijacking detection depends on spotting injection and process tampering behaviors. |
| T1055.012 — Process Hollowing | Hollowing is a common process-hijack pattern that changes a legitimate process after launch. | |
| T1055.013 — Process Doppelgänging | Doppelgänging is a stealthy process-hijack technique that abuses trusted process execution. | |
| Recommendation — Map tampering telemetry to T1055 and alert on memory writes or thread manipulation in trusted processes. Correlate suspended-start and image-replacement events to T1055.012. Hunt for anomalous image execution and transaction-based process creation linked to T1055.013. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and environments are monitored to find anomalies, indicators of compromise and other potentially adverse events | Behavioural process monitoring is an anomaly-detection problem within continuous monitoring. |
| DE.CM-03 — Personnel, devices, software, systems and facilities are monitored to find anomalous activity | Process hijacking is detected by identifying anomalous software and system activity. | |
| DE.AE-01 — Anomalous activity is detected and analyzed | The core task is to detect and analyze unusual process behavior after compromise. | |
| Recommendation — Instrument endpoint telemetry to detect abnormal process behaviour and suspicious execution chains. Correlate process, module-load, and privilege-change telemetry to surface anomalies. Analyze suspicious process deviations as candidate compromise rather than isolated alerts. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Process hijacking detection relies on endpoint logs for process, module, and privilege events. |
| Recommendation — Centralize and review process and module telemetry for suspicious execution changes. | ||
Practitioner Guidance
What to verify: Validate detections against the process’s normal parent, child, module, and network behaviour on that specific host class. If a process only looks suspicious in isolation but repeatedly behaves that way by design, tune the rule around context instead of raw process creation.
What to measure: Track how often alerts are driven by post-launch behaviour rather than launch events alone. The more your detections rely on module-load anomalies, memory changes, and unexpected privilege transitions, the more likely they are to catch real hijacking attempts.
Practitioner takeaway: Process hijacking detection works best when teams treat the process as a living execution context, not a one-time event. Baselines, memory-aware telemetry, and behaviour correlation matter more than simple parent-child matching.