safemode.space
← All techniques
EX-0010.03
ST0004Execution
sub-technique

Rootkit

Parent: EX-0010

Description

A rootkit hides the presence and activity of other malicious components by interposing on the mechanisms that report system state. On spacecraft this can occur within flight software processes, at OS kernel level, inside separation kernels/hypervisors, or down in system firmware where drivers and initialization routines run. Techniques include API and syscall hooking, patching message queues and inter-process communication paths, altering task lists and scheduler views, filtering telemetry packets and event logs, and rewriting sensor or health values before they are recorded or downlinked. Rootkits may also hook command handlers and gateways so certain opcodes, timetags, or sources are silently accepted or ignored while external observers see normal acknowledgments. Because many missions rely on deterministic procedures and limited observability, even small alterations to reporting can make malicious actions appear as plausible mode transitions or benign anomalies. Persistence often pairs with the concealment layer, with the rootkit reinjecting companions after resets or rebuilds by monitoring for specific files, tables, or image loads and modifying them on the fly.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(f)
    addresses
    high
    derived

    Integrity protection on flight-software processes, OS components and FSW frameworks resists rootkit installation; signed code, runtime integrity verification and measured-boot mechanisms are manufacturer-side controls.

  • craAnnex I, Part I, (2)(l)
    addresses
    moderate
    derived

    Manufacturer logging/monitoring obligation requires recording of relevant internal activity — the visibility that surfaces inconsistencies between system-state reports and authoritative sources, the principal observable signature of rootkit presence.

  • eu-space-actArt. 83(1)
    addresses
    high
    direct

    Rootkits hide system state by altering reporting paths; 83(1)'s continuous monitoring obligation, especially with the segregated security-monitoring subsystem in 83(3), is the discipline that detects rootkit-influenced telemetry.

  • eu-space-actArt. 88(1)
    addresses
    moderate
    direct

    Regular tests under 88(1) — including out-of-band integrity attestation and offline image verification — surface rootkit-induced discrepancies that runtime telemetry alone hides.

  • eu-space-actArt. 88(3)
    addresses
    moderate
    direct

    Rootkit testing (primary: Art. 88(1)) cascades to 88(3) — out-of-band attestation testing in TLPT cadence is the operator discipline that surfaces rootkit persistence.

  • nis2Art. 21(2)(b)
    addresses
    high
    derived

    Rootkits subvert the very mechanisms incident-handling depends on (telemetry, event logs, scheduler views, sensor reports); Art. 21(2)(b)'s incident-handling capability must include integrity-of-monitoring controls and out-of-band attestation that survive in-host concealment.

  • nis2Art. 21(2)(e)
    addresses
    high
    direct

    Separation-kernel/hypervisor integrity, syscall-hooking detection, and firmware-driver assurance are squarely Art. 21(2)(e)'s network-and-information-systems development/maintenance + vulnerability-handling obligation — including disclosed weaknesses in any of those layers.

  • nis2Art. 21(2)(h)
    addresses
    moderate
    inferred

    Art. 21(2)(h) crypto policy does not interdict an in-host rootkit that hooks live calls and rewrites values; the operative control is operating-system and kernel integrity with runtime attestation. Addresses (domain relevance).

  • nis2-implAnnex 3.2.1
    addresses
    moderate
    derived

    Monitoring-and-logging procedures must surface anomalous system-state reporting and detect tampering with telemetry pipelines, which is the principal observable signature of rootkit presence.

  • nis2-implAnnex 6.4.1
    addresses
    moderate
    derived

    Change-management procedures govern modifications to flight-software processes, OS components and FSW frameworks; rootkit installation requires subverting that change pipeline.

  • nis2-implAnnex 6.9.1
    addresses
    high
    derived

    A rootkit is malicious software that interposes on system-state reporting; the malware-protection obligations require the entity to implement detection or prevention measures appropriate to the asset.

ENISA controls

  • ENISA-STL-2025-03-sD.25-i10
    addresses
    high

    Integrity-checking mechanisms detect rootkit-induced kernel hooks, syscall patches, and modified message queues by comparing against signed baselines.

  • ENISA-STL-2025-03-sD.29-i02
    mitigates
    high

    On-board IDS/IPS monitoring mission-critical components surfaces rootkit telemetry-filtering and command-handler-hooking activity even when system reports look healthy.

  • ENISA-STL-2025-03-sD.29-i05
    addresses
    high

    Mission cyber-actor-actions detection function is positioned to surface rootkit concealment of malicious actions at the on-board layer.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, EX-0010.03 (SPARTA v3.2).

Built 2026-07-25 from 216 techniques, 334 regulation articles, 125 ENISA controls, 2,610 framework controls, and 90 countermeasures.