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

Operating System

Parent: EX-0009

Description

At the OS layer the attacker targets primitives that schedule work and mediate hardware. Maintenance builds may expose shells or management consoles; misconfigurations around these interfaces can provide paths to command interpreters or privileged syscalls. Exploitation yields kernel-mode execution, arbitrary memory read/write, or control of scheduling and address spaces, letting the actor tamper with FSW processes, intercept command paths, or manipulate storage and bus drivers beneath application checks. The technique leverages generic OS weaknesses adapted to the spacecraft’s particular build, turning low-level control into mission-facing effects that appear to originate from legitimate processes.

Mappings

EU regulation articles

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

    Limited attack surfaces obligation requires manufacturers to remove or disable maintenance shells, management consoles and unused kernel primitives in production firmware — exactly the OS-level surface this technique targets.

  • craAnnex I, Part II, (1)
    addresses
    moderate
    derived

    Component identification covers OS-layer components (kernels, schedulers, device drivers); the manufacturer's vulnerability inventory must include these primitives.

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

    Address-and-remediate obligations cover OS-level defects, including misconfigurations around maintenance interfaces.

  • craAnnex I, Part II, (5)
    addresses
    moderate
    direct

    Zero-day or undocumented-vulnerability exploitation (primary mappings: Part II, (1)+(2)) increases the importance of (5)'s CVD policy as the inbound channel for unknown-vuln reports from researchers and partners.

  • craAnnex I, Part II, (8)
    addresses
    moderate
    direct

    Zero-day exploitation (primary mapping: Part II, (2) remediate) cascades to (8) — once a fix is developed for an undisclosed vulnerability, dissemination without delay is the operational obligation.

  • eu-space-actArt. 76(5)
    addresses
    moderate
    direct

    OS-layer vulnerabilities (primary: Art. 78(1)) need ISMS-level tracking and risk treatment per 76(5).

  • eu-space-actArt. 76(6)
    addresses
    moderate
    direct

    OS-layer testing efficacy (primary: Art. 88(1)) is reviewed under the effectiveness-assessment policy 76(6) requires.

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

    OS-layer exploitation depends on kernel/driver vulnerabilities — 78(1)(c)'s identify-cybersecurity-vulnerabilities obligation extends to the operating-system stack of mission systems.

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

    OS-level testing (kernel fuzzing, syscall fuzzing, privilege boundary validation) is part of the testing programme 88(1) requires.

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

    OS-layer testing (primary: Art. 88(1)) cascades to 88(3) — TLPT 3-yearly cadence covers kernel-and-driver attack surfaces.

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

    EX-0009.02 exploits operating-system weaknesses and exposed management consoles for kernel-level execution; NIS2 21(2)(e) security in development and maintenance including vulnerability handling governs this risk.

  • nis2Art. 21(2)(i)
    addresses
    moderate
    direct

    Maintenance shells, management consoles, and privileged syscall paths are access-controlled functions; Art. 21(2)(i)'s access-control + asset-management obligation governs which roles can reach them and under what conditions.

  • nis2-implAnnex 6.10.1
    addresses
    high
    derived

    Vulnerability-handling obligations cover OS-level defects (kernel issues, scheduler primitives, IPC vulnerabilities) and require the entity to monitor, evaluate impact and apply remediation through documented channels.

  • nis2-implAnnex 6.3.1
    addresses
    high
    derived

    OS-layer attack surface (maintenance shells, management consoles, kernel parameters) is governed by configuration-management obligations: the entity must establish, document, implement and monitor configurations to keep these primitives off and constrained.

  • nis2-implAnnex 6.6.1
    addresses
    high
    derived

    Security-patch management procedures bound how quickly OS-layer fixes are validated, packaged and deployed to flight or ground systems running the affected kernels.

ENISA controls

  • ENISA-STL-2025-03-sD.21-i01
    mitigates
    moderate

    Configuration management with the principle of least functionality removes maintenance shells and management consoles from the flight build.

  • ENISA-STL-2025-03-sD.21-i03
    addresses
    moderate

    Secure development lifecycle principles cover OS configuration hardening, removal of management consoles in flight builds, and least-privilege syscall wrappers.

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

    Vulnerability management identifies, validates, and tracks OS-level defects including those potentially inherited from external sources, the catalog EX-0009.02 leverages.

  • ENISA-STL-2025-03-sD.25-i06
    mitigates
    high

    OS software updates with regression testing close kernel-level defects exposed in maintenance builds before they reach EX-0009.02 exploitation.

Cross-reference controls

SPARTA countermeasures

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

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