On-Board Process Injection is detected by spotting unexpected code, tasks or commands running inside an embedded or onboard system. Monitor process trees, firmware integrity, task creation and configuration changes, and compare them with a known-good baseline. Alert on unauthorised debug access, unusual memory writes and changes that persist across reboots.
How to tell process injection from ordinary embedded-system activity
Detection starts with establishing what “normal” looks like for the onboard environment. On-board process injection usually leaves a mismatch between the expected firmware, task graph, and runtime behaviour, so the key question is whether new code paths, commands, or scheduled work appear without a legitimate maintenance or update event.
That means comparing live behaviour against a known-good baseline, not just watching for malware-style signatures. In embedded and onboard systems, the useful signals are often structural: a task that was not part of the approved image, a command sequence that should not exist in that operating mode, or a configuration change that alters execution flow in a way the baseline never shows.
Signals that matter more than a single indicator
Process trees are useful because injected logic often creates relationships that do not fit the normal startup chain. Unexpected parent-child relationships, strange helper processes, and commands executed from locations or contexts that are not part of the approved workload are all strong clues. Memory-write events also matter, especially when they touch code regions that should remain static after boot or deploy.
Firmware integrity checks add a second layer of confidence. If the runtime image, boot components, or persistent configuration diverge from the trusted reference, then the issue is no longer just a transient anomaly. Persistence across reboot is especially important, because injected logic that survives restart usually indicates either tampering with a durable component or a mechanism that reinstates itself from trusted startup paths.
Changes to task creation, device configuration, and debug settings often show up before overt compromise becomes visible. If an attacker or rogue maintenance tool can enable debug access, alter task scheduling, or rewrite control settings, the environment may remain functional while quietly executing unapproved logic.
Building detection around trusted baselines and access boundaries
The most reliable approach is to baseline both the static and dynamic state of the system. Static state includes firmware hashes, configuration files, signed components, and expected boot artifacts. Dynamic state includes process ancestry, memory activity, task scheduling, and the set of commands normally issued during operating conditions. A detection program is strongest when it can tell the difference between authorised change and unauthorised drift.
For onboard systems that support remote maintenance, the access boundary matters as much as the code boundary. If an operator or service path can issue commands that modify runtime behaviour, then every privileged action should be traceable to an approved workflow. For broader guidance on hardening access and command integrity in these environments, see the Space and Satellite Cybersecurity Guide.
Detection should also account for EDR-like blind spots in constrained or specialised environments. When tooling cannot inspect every layer directly, the answer is not to trust the absence of alerts. It is to verify state from multiple angles: image integrity, task inventory, debug controls, configuration diffs, and any telemetry that reveals when code execution has changed in ways the platform should not permit. The EDR Evasion and Defence Guide is useful for understanding how hidden execution can defeat narrow monitoring assumptions.
Risk and Threat Considerations
On-board process injection is dangerous because it can blend into legitimate device activity while subverting control logic, telemetry, or safety functions. The main risk is not just code execution, but durable control over a system that operators assume is still running trusted software.
Failure mechanism: An attacker or malicious tool abuses update paths, debug access, task scheduling, or memory modification to introduce execution that survives normal operational checks and, in some cases, reboot.
Impact: The system may continue to appear healthy while executing unapproved commands, falsifying behaviour, or undermining onboard safety and integrity controls, which can delay detection and complicate recovery.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Detecting injected execution maps directly to process injection behavior. |
| Recommendation — Correlate process ancestry and memory-write anomalies to process injection detection. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Baseline drift and unauthorized config changes are central to spotting onboard tampering. |
| Recommendation — Baseline firmware and configuration states and alert on unauthorized deviations. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Firmware and code integrity checks are core to detecting persistent onboard injection. |
| AU-12 — Audit Record Generation | Process-tree and command auditing depend on complete event generation. | |
| CM-5 — Access Restrictions for Change | Unauthorized debug or configuration changes are a key detection signal here. | |
| Recommendation — Verify software and firmware integrity before trusting onboard execution state. Generate audit records for task creation, debug access, and configuration changes. Restrict who can alter onboard configuration and debug settings. | ||
Practitioner Guidance
What to verify: Confirm that your baseline includes firmware hashes, signed boot artifacts, expected process ancestry, normal task schedules, and known maintenance states. If you cannot distinguish approved change from injected behaviour, your detection will be too noisy to trust.
Decision rule: Treat persistent changes, debug enablement, or unexpected memory writes as higher priority than a one-off anomalous process, because durable tampering usually creates broader compromise than a transient runtime artefact.
What practitioners underestimate: Onboard environments often fail quietly when only runtime telemetry is watched. You need both behaviour checks and integrity checks, otherwise an injected component can stay invisible while still steering the system.
Practitioner takeaway: The best detection strategy is to combine behavioural anomalies with integrity verification, because process injection in onboard systems is most dangerous when it changes execution without obviously changing the system’s outward state.
Related resources from NHI Mgmt Group
- How should security teams detect and contain FormBook infections that use process hollowing and code injection to hide in legitimate processes?
- How can security teams detect process injection?
- Why are NHIs a critical concern for security teams?
- What steps should security teams take to prevent Shadow AI risks?