| REC-0001 |
Gather Spacecraft Design Information |
Threat actors seek a coherent picture of the spacecraft and its supporting ecosystem to reduce uncertainty and plan follow-on actions. Useful design information spans avionics architecture, command and data handling, comms and RF chains, power and thermal control, flight dynamics constraints, payload-to-bus interfaces, redundancy schemes, and ground segment dependencies. Artifacts often include ICDs, block diagrams, SBOMs and toolchains, test procedures, AIT travelers, change logs, and “as-built” versus “as-flown” deltas. Adversaries combine open sources (papers, patents, theses, conference slides, procurement documents, FCC/ITU filings, marketing sheets) with gray sources (leaked RFP appendices, vendor manuals, employee resumes, social posts) to infer single points of failure, unsafe modes, or poorly defended pathways between space, ground, and supply chain. The output of this activity is not merely a document set but a working mental model and, often, a lab replica that enables rehearsal, timing studies, and failure-mode exploration. |
|
REC-0001.01 |
Software Design |
Adversaries target knowledge of flight and ground software to identify exploitable seams and to build high-fidelity emulators for rehearsal. Valuable details include RTOS selection and version, process layout, inter-process messaging patterns, memory maps and linker scripts, fault-detection/isolation/recovery logic, mode management and safing behavior, command handlers and table services, bootloaders, patch/update mechanisms, crypto libraries, device drivers, and test harnesses. Artifacts may be source code, binaries with symbols, stripped images with recognizable patterns, configuration tables, and SBOMs that reveal vulnerable dependencies. With these, a threat actor can reverse engineer command parsing, locate debug hooks, craft inputs that bypass FDIR, or time payload and bus interactions to produce cascading effects. Supply-chain access to vendors of COTS components, open-source communities, or integrators can be used to insert weaknesses or to harvest build metadata. Even partial disclosures, such as a unit test name, an assert message, or a legacy API, shrink the search space for exploitation. |
|
REC-0001.02 |
Firmware |
Firmware intelligence covers microcontroller images, programmable logic bitstreams, boot ROM behavior, peripheral configuration blobs, and anti-rollback or secure-boot settings for devices on the bus. Knowing device types, versions, and footprints enables inference of default passwords, debug interfaces (JTAG, SWD, UART), timing tolerances, and error handling under brownout or thermal stress. A threat actor may obtain firmware from vendor reference packages, public evaluation boards, leaked manufacturing files, over-the-air update images, or crash dumps. Correlating that with board layouts, harness drawings, or part markings helps map trust boundaries and locate choke points like power controllers, bus bridges, and watchdog supervisors. Attack goals include: preparing malicious but apparently valid updates, exploiting unsigned or weakly verified images, forcing downgrades, or manipulating configuration fuses to weaken later defenses. Even when cryptographic verification is present, knowledge of recovery modes, boot-pin strapping, or maintenance commands can offer alternate paths. |
|
REC-0001.03 |
Cryptographic Algorithms |
Adversaries look for the complete crypto picture: algorithms and modes, key types and lifecycles, authentication schemes, counter or time-tag handling, anti-replay windows, link-layer protections, and any differences between uplink and downlink policy. With algorithm and key details, a threat actor can craft valid telecommands, masquerade as a trusted endpoint, or degrade availability through replay and desynchronization. Sources include interface specifications, ground software logs, test vectors, configuration files, contractor laptops, and payload-specific ICDs that reuse bus-level credentials. Particular risk arises when command links rely on authentication without confidentiality; once an adversary acquires the necessary keys or counters, they can issue legitimate-looking commands outside official channels. Programs should assume that partial disclosures, MAC length, counter reset rules, or key rotation cadence, aid exploitation. |
|
REC-0001.04 |
Data Bus |
Bus intelligence focuses on which protocols are used (e.g., MIL-STD-1553, SpaceWire, etc.), controller roles, addressing, timings, arbitration, redundancy management, and the location of critical endpoints on each segment. Knowing the bus controller, remote terminal addresses, message identifiers, and schedule tables allows an adversary to craft frames that collide with or supersede legitimate traffic, to starve health monitoring, or to trigger latent behaviors in payload or power systems. Additional details such as line voltages, termination, connector types, harness pinouts, and EMC constraints inform feasibility of injection and disruption techniques. Attackers assemble this picture from ICDs, vendor datasheets, AIT procedures, harness drawings, lab photos, and academic or trade publications that reveal typical configurations. Enumeration of bridges and gateways is especially valuable because they concentrate trust across fault-containment regions and between payload and bus. |
|
REC-0001.05 |
Thermal Control System |
Adversaries seek a working map of the thermal architecture and its operating envelopes to anticipate stress points and plan timing for other techniques. Valuable details include passive elements (MLI, coatings, radiators, heat pipes/straps, louvers) and active control (survival and control heaters, thermostats, pumped loops), plus sensor placement, setpoints, deadbands, heater priority tables, and autonomy rules that protect critical hardware during eclipses and anomalies. Artifacts often come from thermal math models (TMMs), TVAC test reports, heater maps and harness drawings, command mnemonics, and on-orbit thermal balance procedures. When correlated with attitude constraints, payload duty cycles, and power budgets, this information lets a threat actor infer when components run close to limits, how safing responds to off-nominal gradients, and where power-thermal couplings can be exploited. Even small fragments, such as louver hysteresis or a heater override used for decontamination, can reveal opportunities to mask heating signatures or provoke nuisance safing. |
|
REC-0001.06 |
Maneuver & Control |
Threat actors collect details of the guidance, navigation, and control (GNC) stack to predict vehicle response and identify leverage points during station-keeping, momentum management, and anomaly recovery. Useful specifics include propulsion type and layout (monoprop/biprop/electric; thruster locations, minimum impulse bit, plume keep-out zones), reaction wheels/CMGs and desaturation logic, control laws and gains, estimator design (e.g., EKF), timing and synchronization, detumble/safe-mode behaviors, and the full sensor suite (star trackers, sun sensors, gyros/IMUs, GNSS). Artifacts include AOCS/AOCS ICDs, maneuver procedures, delta-v budgets, ephemeris products, scheduler tables, and wheel management timelines. Knowing when and how attitude holds, acquisition sequences, or wheel unloads occur helps an adversary choose windows where injected commands or bus perturbations have outsized effect, or where sensor blinding and spoofing are most disruptive. |
|
REC-0001.07 |
Payload |
Adversaries pursue a clear picture of payload type, operating modes, command set, and data paths to and from the bus and ground. High-value details include vendor and model, operating constraints (thermal, pointing, contamination), mode transition logic, timing of calibrations, safety inhibits and interlocks, firmware/software update paths, data formatting and compression, and any crypto posture differences between payload links and the main command link. Payload ICDs often reveal addresses, message identifiers, and gateway locations where payload traffic bridges to the C&DH or data-handling networks, creating potential pivot points. Knowledge of duty cycles and scheduler entries enables timing attacks that coincide with high-power or high-rate operations to stress power/thermal margins or saturate storage and downlink. Even partial information, calibration script names, test vectors, or engineering telemetry mnemonics, can shrink the search space for reverse engineering. |
|
REC-0001.08 |
Power |
Reconnaissance of the electrical power system (EPS) focuses on generation, storage, distribution, and autonomy. Useful details include solar array topology and SADA behavior, MPPT algorithms, array string voltages, eclipse depth assumptions, battery chemistry and configuration, BMS charge/discharge limits and thermal dependencies, PCDU architecture, load-shed priorities, latching current limiters, and survival power rules. Artifacts surface in EPS ICDs, acceptance test data, TVAC power margin reports, anomaly response procedures, and vendor manuals. Correlating these with attitude plans and payload schedules lets a threat actor infer when state-of-charge runs tight, which loads are shed first, and how fast recovery proceeds after a brownout or safing entry. Knowledge of housekeeping telemetry formats and rate caps helps identify blind spots where abusive load patterns or command sequences may evade detection. |
|
REC-0001.09 |
Fault Management |
Fault management (FDIR/autonomy/safing) materials are a prime reconnaissance target because they encode how the spacecraft detects, classifies, and responds to off-nominal states. Adversaries seek trigger thresholds and persistence timers, voting logic, inhibit and recovery ladders, safe-mode entry/exit criteria, command authority in safed states, watchdog/reset behavior, and any differences between flight and maintenance builds. Artifacts include fault trees, FMEAs, autonomy rule tables, safing flowcharts, and anomaly response playbooks. With these, a threat actor can craft inputs that remain just below detection thresholds, stack benign-looking events to cross safing boundaries at tactically chosen times, or exploit recovery windows when authentication, visibility, or redundancy is reduced. Knowledge of what telemetry is suppressed or rate-limited during safing further aids concealment. |
| REC-0002 |
Gather Spacecraft Descriptors |
Threat actors compile a concise but highly actionable dossier of “who/what/where/when” attributes about the spacecraft and mission. Descriptors include identity elements (mission name, NORAD catalog number, COSPAR international designator, call signs), mission class and operator, country of registry, launch vehicle and date, orbit regime and typical ephemerides, and any publicly filed regulatory artifacts (e.g., ITU/FCC filings). They also harvest operational descriptors such as ground network affiliations, common pass windows by latitude band, and staffing patterns implied by press, social media, and schedules. Even when each item is benign, the aggregate picture enables precise timing (e.g., during beta-angle peaks, eclipse seasons, or planned maintenance), realistic social-engineering pretexts, and better targeting of ground or cloud resources that support the mission. |
|
REC-0002.01 |
Identifiers |
Adversaries enumerate and correlate all identifiers that uniquely tag the vehicle throughout its lifecycle and across systems. Examples include NORAD/Satellite Catalog numbers, COSPAR designators, mission acronyms, spacecraft serials and bus IDs, regulatory call signs, network addresses used by mission services, and any constellation slot or plane tags. These identifiers allow cross-reference across public catalogs, tracking services, regulatory filings, and operator materials, shrinking search spaces for pass prediction, link acquisition, and vendor ecosystem discovery. Seemingly minor clues, like a configuration filename embedding a serial number or an operator using the same short name across environments, can expose test assets or internal tools. Rideshare and hosted-payload contexts introduce additional ambiguity that an attacker can exploit to mask activity or misattribute traffic. |
|
REC-0002.02 |
Organization |
Threat actors map the human and institutional terrain surrounding the mission to find leverage for phishing, credential theft, invoice fraud, or supply-chain compromise. Targeted details include the owner/operator, prime and subcontractors (bus, payload, ground, launch), key facilities and labs, cloud/SaaS providers, organizational charts, distribution lists, and role/responsibility boundaries for operations, security, and engineering. The objective is to identify who can approve access, who can move money, who holds admin roles on ground and cloud systems, and which vendors maintain remote access for support. Understanding decision chains also reveals when changes control boards meet, when ops handovers occur, and where a single compromised account could bridge enclaves. |
|
REC-0002.03 |
Operations |
Adversaries collect high-level operational descriptors to predict when the mission will be busy, distracted, or temporarily less instrumented. Useful items include CONOPS overviews, daily/weekly activity rhythms, ground pass schedules, DSN or commercial network windows, calibration and maintenance timelines, planned wheel unloads or thruster burns, conjunction-assessment cycles, and anomaly response playbooks at the level of “who acts when.” For constellations, they seek plane/slot assignments, phasing and drift strategies, crosslink usage, and failover rules between vehicles. These descriptors enable time-targeted campaigns, e.g., sending malicious but syntactically valid commands near handovers, exploiting reduced telemetry during safing, or saturating links during high-rate downlinks. |
| REC-0003 |
Gather Spacecraft Communications Information |
Threat actors assemble a detailed picture of the mission’s RF and networking posture across TT&C and payload links. Useful elements include frequency bands and allocations, emission designators, modulation/coding, data rates, polarization sense, Doppler profiles, timing and ranging schemes, link budgets, and expected Eb/N0 margins. They also seek antenna characteristics, beacon structures, and whether transponders are bent-pipe or regenerative. On the ground, they track station locations, apertures, auto-track behavior, front-end filters/LNAs, and handover rules, plus whether services traverse SLE, SDN, or commercial cloud backbones. Even small details, polarization sense, roll-off factors, or beacon cadence, shrink the search space for interception, spoofing, or denial. The outcome is a lab-replicable demod/decode chain and a calendar of advantageous windows. |
|
REC-0003.01 |
Communications Equipment |
Adversaries inventory space and ground RF equipment to infer capabilities, limits, and attack surfaces. On the spacecraft, they seek antenna type and geometry, placement and boresight constraints, polarization, RF front-end chains, transponder type, translation factors, gain control, saturation points, and protective features. On the ground, they collect dish size/aperture efficiency, feed/polarizer configuration, tracking modes, diversity sites, and backend modem settings. Beacon frequency/structure, telemetry signal type, symbol rates, and framing reveal demodulator parameters and help an actor build compatible SDR pipelines. Knowledge of power budgets and AGC behavior enables strategies to push hardware into non-linear regimes, causing self-inflicted denial or intermodulation. Equipment location and mounting inform visibility and interference opportunities. |
|
REC-0003.02 |
Commanding Details |
Threat actors study how commands are formed, authorized, scheduled, and delivered. High-value details include the telecommand protocol (e.g., CCSDS TC), framing and CRC/MAC fields, authentication scheme (keys, counters, anti-replay windows), command dictionary/database formats, critical-command interlocks and enable codes, rate and size limits, timetag handling, command queue semantics, and the roles of scripts or procedures that batch actions. They also collect rules governing “valid commanding periods”: line-of-sight windows, station handovers, maintenance modes, safing states, timeouts, and when rapid-response commanding is permitted. With this, an adversary can craft syntactically valid traffic, time injections to coincide with reduced monitoring, or induce desynchronization (e.g., counter resets, stale timetags). |
|
REC-0003.03 |
Mission-Specific Channel Scanning |
Beyond TT&C, many missions expose additional RF or network surfaces: high-rate payload downlinks (e.g., X/Ka-band), user terminals, inter-satellite crosslinks, and hosted-payload channels that may be operated by different organizations. Adversaries scan spectrum and public telemetry repositories for these mission-specific channels, characterizing carrier plans, burst structures, access schemes (TDMA/FDMA/CDMA), addressing, and gateway locations. For commercial services, they enumerate forward/return links, user terminal waveforms, and provisioning backends that could be impersonated or jammed selectively. In hosted-payload or rideshare contexts, differences in configuration control and key management present opportunities for pivoting between enclaves. |
|
REC-0003.04 |
Valid Credentials |
Adversaries seek any credential that would let them authenticate as a legitimate actor in space, ground, or supporting cloud networks. Targets include TT&C authentication keys and counters, link-encryption keys, PN codes or spreading sequences, modem and gateway accounts, mission control mission control user and service accounts, station control credentials, VPN and identity-provider tokens, SLE/CSP service credentials, maintenance backdoor accounts, and automation secrets embedded in scripts or CI/CD pipelines. Acquisition paths include spear-phishing, supply-chain compromise, credential reuse across dev/test/ops, logs and core dumps, misconfigured repositories, contractor laptops, and improperly sanitized training data. Because some missions authenticate uplink without encrypting it, possession of valid keys or counters may be sufficient to issue accepted commands from outside official channels. |
| REC-0004 |
Gather Launch Information |
Adversaries collect structured launch intelligence to forecast when and how mission assets will transition through their most time-compressed, change-prone phase. Useful elements include the launch date/time windows, launch site and range operator, participating organizations (launch provider, integrator, range safety, telemetry networks), vehicle family and configuration, fairing type, and upper-stage restart profiles. This picture enables realistic social-engineering pretexts, supply-chain targeting of contractors, and identification of auxiliary systems (range instrumentation, TLM/FTS links) that may be less hardened than the spacecraft itself. Knowledge of ascent comms (bands, beacons, ground stations), early-orbit operations (LEOP) procedures, and handovers to mission control further informs when authentication, staffing, or telemetry margins may be tight. |
|
REC-0004.01 |
Flight Termination |
Threat actors may attempt to learn how the launch vehicle’s flight termination capability is architected and governed, command-destruct versus autonomous flight termination (AFTS), authority chains, cryptographic protections, arming interlocks, inhibit ladders, telemetry indicators, and range rules for safe-flight criteria. While FTS is a range safety function, its interfaces (command links, keys, timing sources, decision logic) can reveal design patterns, dependencies, and potential misconfigurations across the broader launch ecosystem. Knowledge of test modes, simulation harnesses, and pre-launch checks could inform social-engineering or availability-degrading actions against range or contractor systems during critical windows. |
| REC-0006 |
Gather FSW Development Information |
Adversaries collect a cradle-to-operations view of how flight software is built, tested, signed, and released. Useful artifacts include architecture docs, source trees and SBOMs, compiler/linker toolchains and flags, RTOS and middleware versions, build scripts, CI/CD pipelines, code-signing workflows, defect trackers, and release notes that describe “as-built” vs. “as-flown” deltas. They also seek integration environments, emulators/SIL, flatsats/iron birds, hardware-in-the-loop rigs, and the autonomy/FDIR logic that governs mode transitions and patch acceptance. With this knowledge, a threat actor can identify weak crypto or provenance controls on update paths, predict error-handling behavior, and craft inputs that slip past unit/integration tests. Even small disclosures (e.g., a linker script, an assert string, or a sanitized crash dump) shrink the search space for exploitation. |
|
REC-0006.01 |
Development Environment |
Threat actors enumerate the exact environment used to produce flight builds: IDEs and plugins, cross-compilers and SDKs, container images/VMs, environment variables, path conventions, build systems, static libraries, and private package registries. They correlate repository layouts (mono- vs multi-repo), branch and review policies, protected branches/tags, and CI orchestrators to find where policy gaps allow unreviewed code or tool updates. Secrets embedded in configs (tokens, service accounts), permissive compiler/linker flags, or disabled hardening options are especially valuable. Knowledge of debug/diagnostic builds, symbol servers, and crash-dump handling lets an adversary reconstruct higher-fidelity testbeds or derive function boundaries in stripped images. |
|
REC-0006.02 |
Security Testing Tools |
Adversaries study how you test to learn what you don’t test. They inventory static analyzers and coding standards (MISRA/C, CERT, CWE rulesets), dynamic tools (address/UB sanitizers, valgrind-class tools), fuzzers targeted at command parsers and protocols (e.g., CCSDS TC/TM, payload formats), property-based tests, mutation testing, coverage thresholds, and formal methods applied to mode logic or crypto. They also examine HIL setups, fault-injection frameworks, timing/jitter tests, and regression suites that gate release. Gaps, such as minimal negative testing on rare modes, weak corpus diversity, or untested rate/size limits, inform exploit design and the timing of inputs to evade FDIR or saturate queues. |
| REC-0007 |
Monitor for Safe-Mode Indicators |
Adversaries watch for telltale signs that the spacecraft has entered a safed or survival configuration, typically sun-pointing or torque-limited attitude, reduced payload activity, conservative power/thermal setpoints, and low-rate engineering downlink. Indicators include specific mode bits or beacon fields, changes in modulation/coding and cadence, distinctive event packets (e.g., wheel unload aborts, brownout recovery), elevated heater duty, altered load-shed states, and operator behaviors such as emergency DSN requests, longer ground passes, or public anomaly notices. This reconnaissance helps time later actions to coincide with periods of reduced bandwidth, altered monitoring, or maintenance command availability. It may also reveal how safing affects authentication (e.g., whether rapid-response paths or recovery consoles differ from nominal). |
| REC-0008 |
Gather Supply Chain Information |
Threat actors map the end-to-end pathway by which hardware, software, data, and people move from design through AIT, launch, and on-orbit sustainment. They catalog manufacturers and lots, test and calibration houses, logistics routes and waypoints, integrator touchpoints, key certificates and tooling, update and key-loading procedures, and who holds custody at each handoff. They correlate this with procurement artifacts, SBOMs, BOMs, and service contracts to locate where trust is assumed rather than verified. Particular attention falls on exceptions, engineering builds, rework tickets, advance replacements, depot repairs, and urgent field updates, because controls are frequently relaxed there. The result is a prioritized list of choke points (board fabrication, FPGA bitstream signing, image repositories, CI/CD runners, cloud artifact stores, freight forwarders) where compromise yields outsized effect. |
|
REC-0008.01 |
Hardware Recon |
Adversaries seek insight into component sources, screening levels, test histories, and configuration states to prepare pre-delivery manipulation of boards and modules. High-value details include ASIC/FPGA part numbers and stepping, security fuses and life-cycle states, JTAG/SWD access policies, secure-boot and anti-rollback configuration, golden bitstream handling, board layouts and test points, conformal coat practices, and acceptance test procedures with allowable tolerances. Knowledge of substitute/alternate parts, counterfeit screening thresholds, and waiver histories reveals where counterfeit insertion or parametric “near-miss” parts might evade detection. For programmable logic, attackers target synthesis/place-and-route toolchains, IP core versions, and bitstream encryption keys to enable hardware Trojans or debug backdoors that survive functional test. Logistics artifacts (packing lists, RMA workflows, depot addresses) expose moments when custody is thin and tamper opportunities expand. |
|
REC-0008.02 |
Software Recon |
Threat actors enumerate the software factory: where source lives, how dependencies are pulled, how artifacts are built, signed, stored, and promoted to flight. They inventory repos and access models, CI/CD orchestrators, build containers and base images, package registries, signing services/HSMs, update channels, and the policies that gate promotion (tests, reviews, attestations). With this, an adversary can plan dependency confusion or typosquatting attacks, modify build scripts, poison cached artifacts, or swap binaries at distribution edges (mirrors, CDN, ground station staging). |
|
REC-0008.04 |
Business Relationships |
Threat actors map contractual and operational relationships to identify the weakest well-connected node. They enumerate primes and subs (bus, payload, ground, launch), managed service providers, ground-network operators, cloud/SaaS tenants, testing and calibration labs, logistics and customs brokers, and warranty/repair depots, plus who holds remote access, who moves money, and who approves changes. Public artifacts (press releases, procurement records, org charts, job postings, conference bios) and technical traces (email MX/DMARC, shared SSO/IdP providers, cross-domain service accounts) reveal trust bridges between enclaves. Shipment paths and integration schedules expose when and where hardware and sensitive data concentrate. Understanding these ties enables tailored phishing, invoice fraud, credential reuse, and supply-chain insertion timed to integration milestones. |
| REC-0009 |
Gather Mission Information |
Adversaries compile a CONOPS-level portrait of the mission to predict priorities, constraints, and operational rhythms. They harvest stated needs, goals, and performance measures; enumerate key elements/instruments and their duty cycles; and extract mode logic, operational constraints (pointing, keep-outs, contamination, thermal/power margins), and contingency concepts. They mine the scientific and engineering basis, papers, algorithms, calibration methods, to anticipate data value, processing chains, and where integrity or availability attacks would have maximal effect. They correlate physical and support environments (ground networks, cloud pipelines, data distribution partners, user communities) and public schedules (campaigns, calibrations, maneuvers) to identify periods of elevated workload or reduced margin. The aim is not merely understanding but timing: choosing moments when authentication might be relaxed, monitoring is saturated, or rapid-response authority is invoked. |
| IA-0001 |
Compromise Supply Chain |
Adversaries achieve first execution before the spacecraft ever flies by inserting malicious code, data, or configuration during manufacturing, integration, or delivery. Targets include software sources and dependencies, build systems and compilers, firmware/bitstreams for MCUs and FPGAs, configuration tables, test vectors, and off-the-shelf avionics. Inserted artifacts are designed to appear legitimate, propagate through normal processes, and activate under routine procedures or specific modes (e.g., safing, maintenance). Common insertion points align with where trust is assumed, vendor updates, mirrors and registries, CI/CD runners, programming stations, and “golden image” repositories. The result is pre-positioned access that blends with baseline behavior, often with delayed or conditional triggers and strong deniability. |
|
IA-0001.01 |
Software Dependencies & Development Tools |
This technique targets what developers import and the tools that transform source into flight binaries. Methods include dependency confusion and typosquatting, poisoned container/base images, malicious IDE plugins, and compromised compilers, linkers, or build runners that subtly alter output. Because flight and ground stacks frequently reuse open-source RTOS components, crypto libraries, protocol parsers, and build scripts, an upstream change can deterministically reproduce a backdoor downstream. Attackers also seed private mirrors or caches so “trust-on-first-use” locks in tainted packages, or abuse CI secrets and environment variables to pivot further. Effects range from inserting covert handlers into command parsers, to weakening integrity checks in update paths, to embedding telemetry beacons that exfiltrate build metadata helpful for later stages. |
|
IA-0001.02 |
Software Supply Chain |
Here the manipulation targets software delivered to flight or ground systems: altering source before build, swapping signed binaries at distribution edges, subverting update metadata, or using stolen signing keys to issue malicious patches. Space-specific vectors include mission control applications, schedulers, gateway services, flight tables and configuration packages, and firmware loads during I&T or LEOP. Adversaries craft payloads that pass superficial validation, trigger under particular operating modes, or reintroduce known weaknesses through version rollback. “Data payloads” such as malformed tables, ephemerides, or calibration products can double as exploits when parsers are permissive. The objective is to ride the normal promotion pipeline so the implant arrives pre-trusted and executes as part of routine operations. |
| IA-0007 |
Compromise Ground System |
Compromising the ground segment gives an adversary the most direct path to first execution against a spacecraft. Ground systems encompass operator workstations and mission control mission control software, scheduling/orchestration services, front-end processors and modems, antenna control, key-loading tools and HSMs, data gateways (SLE/CSP), identity providers, and cloud-hosted mission services. Once inside, a threat actor can prepare on-orbit updates, craft and queue valid telecommands, replay captured traffic within acceptance windows, or manipulate authentication material and counters to pass checks. The same foothold enables deep reconnaissance: enumerating mission networks and enclaves, discovering which satellites are operated from a site, mapping logical topology between MOC and stations, identifying in-band “birds” reachable from a given aperture, and learning pass plans, dictionaries, and automation hooks. From there, initial access to the spacecraft is a matter of timing and presentation, injecting commands, procedures, or update packages that align with expected operations so the first execution event appears indistinguishable from normal activity. |
|
IA-0007.01 |
Compromise On-Orbit Update |
Adversaries may target the pipeline that produces and transmits updates to an on-orbit vehicle. Manipulation points include source repositories and configuration tables, build and packaging steps that generate images or differential patches, staging areas on ground servers, update metadata (versions, counters, manifests), and the transmission process itself. Spacecraft updates span flight software patches, FPGA bitstreams, bootloader or device firmware loads, and operational data products such as command tables, ephemerides, and calibration files, each with distinct formats, framing, and acceptance rules. An attacker positioned in the ground system can substitute or modify an artifact, alter its timing and timetags to match pass windows, and queue it through the same procedures operators use for nominal maintenance. Activation can be immediate or deferred: implants may lie dormant until a specific mode, safing entry, or table index is referenced. |
| PER-0002 |
Backdoor |
A backdoor is a covert access path that bypasses normal authentication, authorization, or operational checks so the attacker can reenter the system on demand. Backdoors may be preexisting (undocumented service modes, maintenance accounts, debug features) or introduced by the adversary during development, integration, or on-orbit updates. Triggers range from “magic” opcodes and timetags to specific geometry/time conditions, counters, or data patterns embedded in routine traffic. The access they provide varies from expanded command sets and relaxed rate/size limits to alternate communications profiles and hidden file/parameter interfaces. Well-crafted backdoors blend with nominal behavior, appearing as ordinary operations while quietly accepting instructions that other paths would reject, thereby sustaining the attacker’s foothold across passes, resets, and operator handovers. |
|
PER-0002.02 |
Software Backdoor |
Software backdoors are code paths intentionally crafted or later inserted to provide privileged functionality on cue. In flight contexts, they appear as hidden command handlers, alternate authentication checks, special user/role constructs, or procedure/script hooks that accept nonpublic inputs. They can be embedded in flight applications, separation kernels or drivers, gateway processors that translate bus/payload traffic, or update/loader utilities that handle tables and images. SDR configurations offer another avenue: non-public waveforms, subcarriers, or framing profiles that, when selected, expose a private command channel. Activation is often conditional, specific timetags, geometry, message sequences, or file names, to keep the feature dormant during routine testing and operations. Once present, the backdoor provides a repeatable way to execute commands or modify state without traversing the standard control surfaces, sustaining the adversary’s access over time. |
| PER-0005 |
Credentialed Persistence |
Threat actors may acquire or leverage valid credentials to maintain persistent access to a spacecraft or its supporting command and control (C2) systems. These credentials may include system service accounts, user accounts, maintenance access credentials, cryptographic keys, or other authentication mechanisms that enable continued entry without triggering access alarms. By operating with legitimate credentials, adversaries can sustain access over extended periods, evade detection, and facilitate follow-on tactics such as command execution, data exfiltration, or lateral movement. Credentialed persistence is particularly effective in environments lacking strong credential lifecycle management, segmentation, or monitoring allowing threat actors to exploit trusted pathways while remaining embedded in mission operations. |
| DE-0009 |
Camouflage, Concealment, and Decoys (CCD) |
The adversary exploits the physical and operational environment to reduce detectability or to mislead observers. Tactics include signature management (minimizing RF/optical/thermal/RCS), controlled emissions timing, deliberate power-down/dormancy, geometry choices that hide within clutter or eclipse, and the deployment of decoys that generate convincing tracks. CCD can also leverage naturally noisy conditions, debris-rich regions, auroral radio noise, solar storms, to mask proximity operations or to provide plausible alternate explanations for anomalies. The unifying theme is environmental manipulation: shape what external sensors perceive so surveillance and attribution lag, misclassify, or look elsewhere. |
|
DE-0009.05 |
Corruption or Overload of Ground-Based SDA Systems |
The adversary targets terrestrial space-domain awareness pipelines, sensor networks, tracking centers, catalogs, and their data flows, to blind or confuse broad-area monitoring. Paths include compromising or spoofing observational feeds (radar/optical returns, TLE updates, ephemeris exchanges), injecting falsified or time-shifted tracks, tampering with fusion/association parameters, and saturating ingestion and alerting with noisy or adversarial inputs. Where SDA employs AI/ML for detection and correlation, the attacker can degrade models by flooding them with ambiguous scenes or crafted features that increase false positives/negatives and consume analyst cycles. Unlike onboard deception, this approach skews the external decision-support picture across many assets at once, delaying detection of real maneuvers and providing cover for concurrent operations. |
| DE-0011 |
Credentialed Evasion |
Threat actors may leverage valid credentials to conduct unauthorized actions against a spacecraft or related system in a way that conceals their presence and evades detection. By using trusted authentication mechanisms attackers can blend in with legitimate operations and avoid triggering access control alarms or anomaly detection systems. This technique enables evasion by appearing authorized, allowing adversaries to issue commands, access sensitive subsystems, or move laterally within spacecraft or constellation architectures without exploiting software vulnerabilities. When credential use is poorly segmented or monitored, this form of access can be used to maintain stealthy persistence or facilitate other tactics under the guise of legitimate activity. |
| LM-0007 |
Credentialed Traversal |
Movement is achieved by reusing legitimate credentials and keys to cross boundaries that rely on trust rather than strict isolation. Using operator or service accounts, maintenance logins, station certificates, or spacecraft-recognized crypto, the adversary invokes gateways that bridge domains, C&DH to payload, crosslink routers to onboard networks, or constellation management planes to individual vehicles. Because the traversal occurs through approved interfaces (file services, table loaders, remote procedure calls, crosslink tasking), actions appear as routine operations while reaching progressively more privileged subsystems or neighboring spacecraft. Where roles and scopes are broad or reused, the same credential opens multiple enclaves, turning authorization itself into the lateral path. |
| EXF-0007 |
Compromised Ground System |
The adversary resides in mission ground infrastructure and uses its trusted position to siphon data at scale. With access to operator workstations, mission control servers, baseband/modem chains, telemetry processing pipelines, or archive databases, the attacker can mirror real-time streams, scrape recorder playbacks, export payload products, and harvest procedure logs and command histories. Because exfiltration rides normal paths, file staging areas, data distribution services, cloud relays, or cross-site links, it blends with routine dissemination. Compromise of scheduling tools and pass plans also lets the actor time captures to high-value downlinks and automate bulk extraction without touching the spacecraft. |
| EXF-0008 |
Compromised Developer Site |
By breaching development or integration environments (at the mission owner, contractor, or partner), the adversary gains access to source code, test vectors, telemetry captures, build artifacts, documentation, and configuration data, material that is often more complete than flight archives. Beyond theft of intellectual property, the attacker can embed telemetry taps, extended logging, or data “export” features into test harnesses, simulators, or flight builds so that, once fielded, the system produces extra observables or forwards content to non-mission endpoints. This activity typically occurs pre-launch during software production and ATLO, positioning exfiltration mechanisms to activate later in flight. |
| EXF-0009 |
Compromised Partner Site |
The adversary leverages third-party infrastructure connected to the mission, commercial ground stations, relay networks, operations service providers, data processing partners, to capture or relay mission data outside official channels. From these footholds, the attacker can mirror TT&C and payload feeds, scrape shared repositories, and man-in-the-middle cross-organization links (e.g., between partner stations and the primary MOC). Because partner environments vary in segmentation and monitoring, exfiltration can affect multiple missions or operators simultaneously, with stolen data exiting through the partner’s routine distribution mechanisms. |