Attackers use On-Board Process Injection to insert malicious code or data into a running onboard process so it acts under trusted system context. That can alter telemetry, suppress alarms, or redirect control logic without changing the process name. Defenders should monitor process integrity, memory protection, and abnormal inter-process behaviour on the spacecraft.
How attackers turn an onboard process into a trusted execution path
On-Board Process Injection works because the target process is already trusted by the spacecraft or payload software stack. Once malicious code or data is placed into that running process, the attacker can shape behaviour from inside the trust boundary instead of trying to break it from outside. That is why this technique is used to modify telemetry, suppress alarms, or steer control logic while keeping the process itself looking legitimate.
A useful way to think about the technique is that the attacker is not always trying to replace software, they are trying to borrow its authority. If the onboard process already has access to command handling, telemetry generation, fault management, or other privileged functions, injection lets the attacker influence those functions indirectly and often more quietly than a visible binary replacement would.
That makes process boundaries, memory integrity, and runtime behaviour the real security targets. In practice, defenders need to understand which onboard processes are trusted for safety-critical actions, which ones can influence downstream subsystems, and which monitoring signals would change if code inside that process were altered.
What the attacker gains once injection succeeds
The main advantage is control without obvious change. A successful injection can change what the process reports, what it suppresses, or how it sequences internal logic, while leaving the process name, service identity, and normal operational flow intact. That can be enough to hide faults, distort situational awareness, or prevent safety responses from triggering when they should.
In a space environment, the impact is amplified because onboard software often has to operate autonomously and tolerate intermittent connectivity. If the attacker can influence the process that mediates telemetry or control, the attacker may be able to create a false picture for operators on the ground and delay intervention until the effect has already propagated.
Injection also changes the defender’s detection problem. Traditional integrity checks that focus only on file hashes or process names can miss runtime tampering if the process image on disk is unchanged. The better indicator is whether the process is behaving inconsistently with its expected memory state, call patterns, or message flow.
Why spacecraft and embedded systems are especially exposed
Onboard systems often run with tight resource constraints, long maintenance intervals, and limited recovery options. That gives the attacker more value from a single foothold because the affected process may remain in place for a long time and may not be easily restarted or reimaged. A compromise in one process can also cascade if that process brokers input to other subsystems.
The risk is highest where a process has both trust and reach, for example when it touches command execution, telemetry downlink, fault handling, or mode switching. If the attacker can inject at that layer, the compromise is no longer just a local code issue, it becomes an operational integrity issue for the spacecraft.
For background on adjacent spacecraft attack paths and defensive priorities, see Space and Satellite Cybersecurity Guide. For a broader view of how attackers abuse trusted software context and access paths, The State of NHI & AI Agent Breach Report 2026 is a useful companion reference, even though the attack surface here is embedded rather than enterprise identity infrastructure.
Risk and Threat Considerations
Injection into an onboard process is dangerous because it attacks the integrity of the control plane, not just the availability of a single application. An adversary who can alter trusted runtime behaviour may be able to suppress alarms, falsify telemetry, or influence control decisions without tripping the most obvious static checks.
Failure mechanism: The attacker exploits a process that already holds operational trust, then modifies its runtime memory, inputs, or inter-process interactions so the altered process keeps operating with legitimate authority while behaving differently.
Impact: Operators may see normal process status while the spacecraft is making unsafe or misleading decisions, which can delay response, mask compromise, or produce incorrect control actions at mission-critical moments.
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, NIST CSF 2.0 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 | Directly covers injecting code into running processes to alter trusted execution. |
| Recommendation — Hunt for process injection telemetry and memory tampering around trusted onboard processes. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Process injection is a malware technique that malware defenses and detection must address. |
| Recommendation — Deploy malware defenses that detect in-memory tampering and abnormal process behaviour. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest | Process injection can alter mission data and telemetry integrity within protected systems. |
| DE.CM-01 — Monitoring for Anomalies and Events | Detecting injected behaviour requires continuous monitoring of process and runtime anomalies. | |
| Recommendation — Protect mission-critical data flows from unauthorized modification or redirection. Monitor onboard processes for memory, behaviour, and inter-process anomalies. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Runtime injection is best detected through active monitoring of process integrity and behaviour. |
| Recommendation — Monitor system and process behaviour for signs of runtime tampering. | ||
Practitioner Guidance
What to verify: Confirm which onboard processes are allowed to originate telemetry, accept commands, or influence fault management, then validate that those processes cannot be modified at runtime without detection. The practical question is not only whether the binary is signed, but whether the executing process can be impersonated or altered after launch.
What to prioritise: Focus first on processes with the widest operational blast radius, especially those that bridge safety logic and communications. If a process can change what operators see or what the spacecraft does in response to faults, it deserves stronger integrity monitoring than ordinary application code.
Practitioner takeaway: Treat process integrity as an operational safety control, because once an attacker can shape a trusted onboard process from the inside, the hardest problem is no longer initial access, it is proving that the control logic you are observing is still the one you deployed.
Related resources from NHI Mgmt Group
- What breaks when attackers use MSBuild and APC injection inside a trusted Windows process?
- Why do attackers use shellcode and injection techniques to run code inside another process?
- How do attackers use process injection?
- What is the difference between prompt injection risk and identity abuse in agents?