Security Feature Disabled in Safe-Mode

Monitors the status of critical security features (e.g., COMSEC) to detect if they are disabled during safe-mode operations. The security feature would need to be determined by engineer, but COMSEC is an example. An example of how to build pattern for COMSEC, [x-opencti-security-feature:feature = 'encryption' AND x-opencti-security-feature:status = 'disabled' AND x-opencti-spacecraft-status:mode = 'safe-mode']

STIX Pattern

[x-opencti-spacecraft-status:mode = 'safe-mode' AND x-opencti-security-feature:status = 'disabled']

SPARTA TTPs

ID Name Description
EX-0011 Exploit Reduced Protections During Safe-Mode The adversary times on-board actions to the period when the vehicle is in safe-mode and operating with altered guardrails. In many designs, safe-mode enables contingency command dictionaries, activates alternate receivers or antennas, reduces data rates, and prioritizes survival behaviors (sun-pointing, thermal/power conservation). Authentication checks, anti-replay windows, rate/size limits, and interlocks may differ from nominal; counters can be reset, timetag screening relaxed, or maintenance procedures made available for recovery. Ground cadence also changes, longer passes, emergency scheduling, atypical station selection, creating predictable windows for interaction. Using knowledge of these patterns, an attacker issues maintenance-looking loads, recovery scripts, parameter edits, or boot/patch sequences that the spacecraft is primed to accept while safed. Because responses (telemetry beacons, acknowledgments, mode bits) resemble normal anomaly recovery, the first execution event blends with expected behavior, allowing unauthorized reconfiguration, software modification, or state manipulation to occur under the cover of fault response.