On-Board Process Injection

What On-Board Process Injection Does

On-board process injection is a stealth technique, not just a code-loading trick. By placing malicious code inside a legitimate running process, attackers inherit the trust, network position, and telemetry profile of software that already belongs on the system.

This makes the technique useful for concealment, command manipulation, and state theft. It is often chosen when the attacker wants their activity to blend into normal operational behaviour rather than stand out as a separate executable or service.

Why It Is Dangerous in Embedded or Onboard Environments

Onboard systems usually have tight resource constraints, specialised software stacks, and a high trust in long-running control processes. In that environment, process injection can be especially disruptive because a compromised process may already be handling commands, telemetry, device control, or safety-related logic.

Once code runs inside the trusted process boundary, defenders may lose clean separation between legitimate activity and hostile action. That can let an attacker alter outputs, suppress alerts, or intercept sensitive runtime state without needing a visibly new process.

How It Is Detected and Confirmed

Detection usually depends on correlating process behaviour rather than looking for a single signature. Sudden memory changes, unexpected modules, thread anomalies, unsigned or unapproved code loading, and mismatches between process identity and behaviour are all useful indicators.

Investigation should also ask whether the process is doing things it was never designed to do, such as spawning unusual child activity, writing into another process, or showing unstable memory regions. EDR evasion and defence guidance is relevant here because injection techniques often overlap with sensor blinding, telemetry gaps, and other anti-detection tradecraft.

Where possible, defenders should compare live process behaviour with a known-good baseline and confirm whether the suspicious code path appeared before or after a compromise event. Post-incident review matters because injected code can leave behind very little in the file system while still altering runtime state.

Defensive Controls and Hardening Priorities

The strongest controls reduce both the chance of injection and the value of successful injection. That means hardening memory protections, limiting who can load code into a process, tightening privilege boundaries, and reducing the number of processes that have access to sensitive commands or secrets.

Operationally, NIST Cybersecurity Framework 2.0 is useful for structuring the detect, protect, and respond work around this threat, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control catalogue for integrity monitoring, code integrity, auditing, and access restriction. For onboard systems that run in connected environments, NCSC UK Advice and Guidance remains a practical source for operational hardening and monitoring advice.

Risk and Threat Considerations

Process injection is dangerous because it lets an attacker hide inside software that defenders already trust. That can turn a single compromised process into a durable foothold for command tampering, data theft, or monitoring suppression.

Failure mechanism: The attacker gains execution inside a legitimate process, then uses that context to evade process-level controls, manipulate runtime state, or reuse the process’s own trust relationships.

Impact: Security tools may see the wrong picture, operators may miss malicious action, and critical onboard functions may continue operating with corrupted inputs, outputs, or telemetry.

Practitioner Guidance

What to watch for: Treat unexplained memory writes, suspicious code sections, and process behaviour that no longer matches its normal role as investigation triggers rather than isolated anomalies. On onboard platforms, it is especially important to distinguish genuine application activity from injected logic that is riding inside the same process.

Practitioner takeaway: The key question is not just whether a process is running, but whether it is still running its own code.

Related resources from NHI Mgmt Group

• What breaks when attackers use MSBuild and APC injection inside a trusted Windows process?
• How should security teams implement prompt injection defenses for browser agents that process untrusted web content?
• What are the signs that LodaRAT is attempting process injection or persistence on a host?
• How should security teams validate EDR coverage against advanced process injection techniques?