safemode.space
← All techniques
DE-0007
ST0006Defense Evasion

Evasion via Rootkit

Description

A rootkit hides malicious activity by interposing on reporting paths after the system has booted. In flight contexts this includes patching flight software APIs, kernel syscalls, message queues, and telemetry publishers so task lists, counters, health channels, and event severities are falsified before downlink. Command handlers can be hooked to suppress evidence of certain opcodes or sources; recorder catalogs and file listings can be rewritten on the fly; and housekeeping can be biased to show nominal temperatures, currents, or voltages while actions proceed. The defining feature is runtime concealment: the observability surfaces operators rely on are altered to present a curated, benign narrative.

Mappings

EU regulation articles

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

    A rootkit patches flight-software APIs, kernel syscalls, and message queues — the canonical case of unauthorized modification of programs (2)(f) addresses, including the corruption-reporting requirement.

  • craAnnex I, Part I, (2)(k)
    addresses
    moderate
    inferred

    CRA Annex I (2)(k) is domain-relevant but does not mitigate DE-0007: a rootkit's harm is concealment of activity, not an incident-impact availability loss. The operative controls are runtime and kernel integrity with tamper-resistant observability. Addresses.

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

    Rootkits invalidate the (2)(l) record-and-monitor obligation by tampering with reporting paths after boot; product design must consider tamper-resistant logging and out-of-band attestation.

  • craAnnex I, Part II, (3)
    addresses
    high
    direct

    Rootkit evasion (primary mapping: Annex I, Part I, (2)(k)) cascades to (3)'s regular-tests obligation — exploitation-mitigation mechanisms (signed code, control-flow integrity) require ongoing validation through fuzzing and integrity-attestation tests.

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

    Rootkits defeat the reporting paths 83(1)'s continuous-monitoring depends on; the segregated security-monitoring subsystem under 83(3) is the architectural counter — out-of-band attestation that survives rootkit interception.

  • eu-space-actArt. 84(2)
    addresses
    high
    direct

    Rootkits patch FSW APIs, kernel syscalls, and message queues — directly attacking the integrity properties of the network-and-information-system per 84(2)'s Annex VII point 5.1.

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

    Rootkit detection requires offline integrity attestation, image hashing, and kernel-introspection testing — within 88(1)'s testing programme scope.

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

    Rootkit detection (primary: Art. 88(1)) cascades to 88(3) — TLPT 3-yearly cadence is exactly the offensive-testing discipline that surfaces persistent rootkits between security audits.

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

    Runtime concealment subverts the very mechanisms incident-handling depends on; Art. 21(2)(b)'s capability must include integrity-of-monitoring controls and out-of-band attestation that survive in-host hooks on telemetry, queues, and event paths.

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

    Kernel-syscall integrity, separation-kernel hardening, and FSW-API tamper detection are squarely Art. 21(2)(e)'s network-and-information-systems development/maintenance + vulnerability-handling obligation.

  • nis2-implAnnex 3.2.1
    addresses
    high
    derived

    Monitoring-and-logging procedures must surface inconsistencies between system-state reports and authoritative sources (resource consumption, watchdog timing, redundant telemetry), which are the observable signatures rootkits attempt to hide.

  • nis2-implAnnex 6.9.1
    addresses
    high
    derived

    Rootkit-based evasion is malicious software interposing on reporting paths; the malware-protection obligation requires detection-or-prevention measures appropriate to the asset.

ENISA controls

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

    Integrity checking on flight software detects rootkit-installed API/syscall hooks and patched message queues that bias telemetry before downlink.

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

    On-board IDS/IPS surfaces rootkit activity (hooked command handlers, falsified events) that masks malicious actions.

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

    Mission cyber-actor-actions detection function is positioned exactly to surface rootkit-induced runtime concealment of malicious actions.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, DE-0007 (SPARTA v3.2).

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