Process hijacking

Process hijacking is an attack technique where malware or an intruder takes over an existing process to run malicious code under a trusted context. This can hide activity, inherit permissions and bypass application controls. Defenders watch for unexpected memory changes, code injection, strange child processes and privilege abuse in sensitive services.

How process hijacking works

Process hijacking is a takeover technique, not a new application feature or a standalone malware family. Attackers abuse an already running process so their code executes inside a trusted runtime, which can make malicious activity look like normal application behaviour and reduce the chance of immediate blocking.

The core advantage is context. A hijacked process may already have valid permissions, established network trust, loaded libraries, and expected telemetry patterns. That means the attacker often gains a cleaner execution path than they would through a fresh malicious process, especially in environments that allow broad parent-child process relationships or weak runtime integrity checks.

Why process hijacking is effective

Process hijacking works because defenders and controls frequently trust stable processes more than newly spawned ones. When code is injected into, replaced within, or run through an existing process, the activity can inherit the process’s identity, privilege level, session state, and sometimes its access to internal services or local resources.

That makes the technique useful for evasion and privilege abuse. It can help malware blend into ordinary admin tooling, browser processes, service hosts, or other sensitive binaries. It also creates ambiguity for detection logic that relies too heavily on process name, parent process, or signed binary reputation instead of runtime behaviour.

Common takeover patterns and detection clues

Process hijacking can involve classic code injection, process replacement, runtime library abuse, or manipulation of how a legitimate process starts child tasks. The exact method matters less than the security consequence: the attacker is no longer forcing execution through an obviously malicious new process tree.

Defenders usually look for mismatches between expected behaviour and observed runtime state. Useful clues include unusual memory writes, suspicious module loads, abnormal command lines, unexpected child processes, access to protected memory regions, and privilege use that does not fit the service or application’s normal purpose.

These checks are most effective when paired with process lineage, memory inspection, and application allowlisting. MITRE ATT&CK Enterprise Matrix is the most useful external reference for mapping the technique to attacker behaviour, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control catalogue for monitoring, integrity, and access enforcement.

Security implications for organisations

Process hijacking is dangerous because it can turn a trusted process into a covert execution platform. Once that happens, the attacker may be able to reach sensitive APIs, local secrets, internal data, or administrative functions without tripping controls that focus only on initial launch events.

The impact is often broader than one host. If the hijacked process is a service, a management agent, or a process that handles credentials, the compromise can expose sessions, tokens, keys, or downstream access paths. NIST Cybersecurity Framework 2.0 is useful for organising this as a detect-and-respond problem, and NIST SP 800-207 Zero Trust Architecture reinforces the need to verify trust continuously rather than assuming a running process remains benign.

Risk and Threat Considerations

Process hijacking matters because it converts a legitimate execution context into an attack surface. That can hide malware from process-based controls, undermine application trust decisions, and let an intruder reuse permissions that were never meant for hostile code.

Failure mechanism: The attacker gains control of an existing process through injection, replacement, or runtime manipulation, then uses that process’s trusted context to execute actions that appear normal to the host or monitoring stack.

Impact: The compromise can enable stealthy persistence, privilege abuse, access to protected resources, and lateral movement through services that are harder to scrutinise than a newly created malicious process.

Practitioner Guidance

Why practitioners should care: Treat process trust as runtime trust, not just binary trust. A signed or expected executable is not automatically safe if its memory, modules, or child-process behaviour has changed in ways the application never needs.

What to watch for: Focus on memory tampering, abnormal parent-child chains, unexpected command-line arguments, injected modules, and service processes that make network or file-system calls outside their normal role. MITRE ATT&CK Enterprise and NIST SP 800-53 Rev 5 both support this kind of behaviour-based detection.

Practitioner takeaway: The most reliable defence is to combine process integrity monitoring with least privilege and tight runtime observation, so trust in the process does not become trust for the attacker.

Related resources from NHI Mgmt Group

• Hijacking a privileged process
• Why do NHI programmes need stronger process ownership than many human identity programmes?
• How can security teams reduce the risk of session hijacking in SaaS environments?
• Why does MFA not stop session hijacking?