Satellite Penetration Testing | Satellite Security

Overview

Penetration testing satellite systems requires a fundamentally different approach from traditional network or application pentesting. The attack surface spans four distinct segments (space, ground, user, link), involves radio frequency (RF) communication subject to strict legal regulation, and encompasses hardware, firmware, software, and protocol-level vulnerabilities. The consequences of unauthorized testing can range from federal criminal charges (Computer Fraud and Abuse Act, FCC violations) to physical damage to multi-million-dollar space assets.

This page presents a structured methodology for satellite penetration testing, covering each phase from scoping and legal authorization through OSINT reconnaissance, passive and active RF analysis, ground segment testing, and reporting. All techniques described assume proper authorization and legal compliance — satellite pentesting without explicit written authorization is illegal in virtually every jurisdiction.

For the tools referenced throughout this page, see the Tools & Resources page. For the attack vectors and threat landscape that inform these tests, see the Attack Vectors page.

Methodology Overview

Satellite penetration testing follows a phased approach that progresses from entirely passive techniques (OSINT, passive RF monitoring) to increasingly active techniques (ground segment exploitation, RF injection) as authorization scope permits. This graduated approach manages legal risk and ensures that passive intelligence informs active testing.

flowchart TD
    A["Phase 1<br/>Scoping & Legal"] --> B["Phase 2<br/>OSINT & Recon"]
    B --> C["Phase 3<br/>Passive RF Analysis"]
    C --> D["Phase 4<br/>Ground Segment Testing"]
    D --> E["Phase 5<br/>Active RF Testing"]
    E --> F["Phase 6<br/>Reporting"]

    A1["Define scope across segments<br/>Obtain legal authorization<br/>Establish Rules of Engagement"] --> A
    B1["TLE data, Shodan/Censys<br/>Frequency databases<br/>OSINT on operators"] --> B
    C1["SDR monitoring<br/>Signal identification<br/>Protocol analysis"] --> C
    D1["VSAT terminal testing<br/>Ground station networks<br/>TT&C interface assessment"] --> D
    E1["GPS spoofing tests<br/>Uplink injection concepts<br/>Replay attacks"] --> E
    F1["Risk scoring<br/>Impact assessment<br/>Remediation priorities"] --> F

    style A fill:#e74c3c,color:#fff
    style B fill:#f39c12,color:#fff
    style C fill:#3498db,color:#fff
    style D fill:#2ecc71,color:#fff
    style E fill:#9b59b6,color:#fff
    style F fill:#1abc9c,color:#fff

Phase 1 — Scoping and Legal Considerations

Satellite penetration testing scoping is substantially more complex than traditional IT pentesting because the system spans multiple technical domains, multiple jurisdictions, and multiple regulatory regimes. Getting the scope and legal authorization wrong can result in federal criminal charges, FCC enforcement actions, and international treaty violations.

Defining Scope Across Segments

A satellite pentest scope must explicitly define which segments are in scope and what testing activities are authorized for each:

Segment	In-Scope Activities (Typical)	Usually Excluded	Authorization Required From
Space Segment	Firmware analysis of identical ground units, protocol analysis	Direct interaction with on-orbit spacecraft	Spacecraft operator, program office
Ground Segment	Network pentesting, web app testing, VSAT terminal testing	Disruption of operational TT&C systems	Ground station operator, network owner
User Segment	Terminal hardware hacking, firmware extraction, app testing	Customer-owned terminals without consent	Terminal manufacturer, service provider
Link Segment	Passive RF monitoring, authorized active RF testing	Unauthorized transmission on licensed frequencies	FCC (or national regulator), satellite operator

Regulatory Requirements

Satellite pentesting involves regulatory requirements that traditional IT pentesters rarely encounter:

FCC Regulations (United States):

FCC Part 25: Governs satellite communications. Any transmission on licensed satellite frequencies requires FCC authorization. Even “testing” transmissions without authorization violate federal law.
FCC Part 97: Amateur radio regulations. Some satellite security researchers use amateur radio satellites for authorized experimentation, but Part 97 prohibits encryption and commercial use.
FCC Part 15: Unlicensed devices. SDR receivers operate under Part 15 (receive-only is generally unrestricted), but any intentional transmission must comply with applicable rules.
Communications Act Section 705: Prohibits unauthorized interception and divulgation of satellite communications content. Passive monitoring of unencrypted signals for security research occupies a legal gray area — consult legal counsel.

ITU Regulations:

ITU Radio Regulations Article 15 prohibits harmful interference to any radio service. Active RF testing that interferes with satellite communications violates international treaty obligations.
National administrations enforce ITU regulations domestically. In the U.S., the FCC enforces spectrum regulations; in the UK, Ofcom; in the EU, national regulatory authorities under the EECC framework.

Additional Legal Frameworks:

Computer Fraud and Abuse Act (CFAA): Applies to unauthorized access to satellite ground systems and management platforms. Written authorization from the system owner is essential.
Wiretap Act / ECPA: May apply to interception of satellite communications, even for security testing purposes.
ITAR: If the satellite system involves ITAR-controlled technology, the pentest team and reports may be subject to export control restrictions.

Rules of Engagement

Satellite pentest Rules of Engagement (RoE) should address scenarios unique to space operations:

Spacecraft safe mode triggers: Define emergency contact procedures if testing causes a spacecraft anomaly.
RF transmission boundaries: Specify exact frequencies, power levels, bandwidths, durations, and geographic boundaries for active RF testing.
Operational windows: Schedule active testing to avoid conflicts with critical satellite operations (station-keeping maneuvers, payload reconfigurations, eclipse periods).
Data handling: Specify handling, storage, and destruction of intercepted satellite communications, particularly for third-party traffic.
Escalation procedures: Define escalation paths for critical vulnerabilities discovered during testing.

Phase 2 — OSINT and Reconnaissance

Satellite OSINT is exceptionally productive because the space industry, by necessity and regulation, publishes substantial technical information about satellite systems. Orbital parameters are publicly tracked, frequency allocations are filed with the ITU, and ground station infrastructure is often discoverable through internet scanning.

Orbital Data and Satellite Tracking

space-track.org:

The U.S. Space Surveillance Network publishes Two-Line Element sets (TLEs) for tracked space objects through space-track.org (requires free registration). TLEs provide orbital parameters that enable prediction of a satellite’s position at any given time.

ISS (ZARYA)
1 25544U 98067A   24045.51458333  .00016717  00000-0  10270-3 0  9002
2 25544  51.6416 247.4627 0006703 130.5360 229.6360 15.49438000 12345

Key intelligence from TLEs:

Orbital inclination and period: Determines ground coverage and revisit times.
NORAD catalog number: Unique identifier for cross-referencing in other databases.
Epoch and decay rate: Indicates whether the satellite is actively maintained (station-keeping).

Tracking tools:

# Install and configure gpredict for satellite tracking
sudo apt install gpredict

# N2YO API for programmatic tracking
curl "https://api.n2yo.com/rest/v1/satellite/positions/25544/41.702/-76.014/0/2/&apiKey=YOUR_KEY"

# celestrak.org for supplementary TLE data
wget "https://celestrak.org/NORAD/elements/gp.php?GROUP=starlink&FORMAT=tle" -O starlink_tles.txt

gpredict provides real-time satellite tracking with pass prediction — essential for timing passive RF monitoring sessions to coincide with satellite passes over your receive location.

Internet-Connected Ground Infrastructure

Shodan and Censys queries for satellite infrastructure:

# Shodan queries
"iDirect" port:443                       # iDirect VSAT terminals
"Hughes" "HT2000" port:80               # Hughes modems
http.title:"Antenna Control" port:80     # Antenna control interfaces
"Satellite" "Ground Station" port:161    # SNMP on ground stations
"ACU" "Antenna" port:502                 # Modbus antenna controllers

# Censys queries
services.http.response.body:"ground station" AND services.port:443
services.banner:"iDirect"

Look for management interfaces exposed to the internet, default/self-signed TLS certificates revealing organizational details, banner information disclosing software versions, and open SNMP communities.

Frequency and Spectrum Databases

ITU BR IFIC (International Frequency Information Circular):

The ITU Radiocommunication Bureau publishes frequency filings for all satellite networks through the BR IFIC database. This includes:

Filed frequency bands for uplink and downlink
Orbital position (for GEO satellites)
Polarization (linear or circular, RHCP/LHCP)
Emission designator (reveals modulation type and bandwidth)
Filing administration (country of registry)

Additional frequency resources:

Resource	Information Available	Access
ITU BR IFIC / SNS Online	Official frequency filings, technical characteristics	Subscription (national administrations)
SatBeams (satbeams.com)	Beam coverage maps, frequency plans, transponder layouts	Free
LyngSat (lyngsat.com)	TV/radio satellite channel frequencies, symbol rates	Free
Gunter’s Space Page	Satellite technical specifications, launch details	Free
FCC IBFS	U.S. satellite license applications with technical exhibits	Free (fcc.gov)
UCS Satellite Database	Open-source database of operational satellites	Free (ucsusa.org)

FCC International Bureau Filing System (IBFS): For FCC-licensed satellites, IBFS contains detailed technical exhibits including exact uplink/downlink frequency ranges, EIRP levels, modulation/coding schemes, ground station coordinates, and beam coverage areas.

Satellite operators are vulnerable to social engineering like any organization. Key OSINT sources include LinkedIn (identify operators and engineers; job postings reveal technology stacks), satellite industry conference presentations (SATELLITE, SpaceCom, MILCOM, SmallSat), academic publications by affiliated researchers, and government procurement records (SAM.gov, FPDS) revealing contractors and technology specifications.

Phase 3 — Passive RF Analysis

Passive RF analysis involves receiving and analyzing satellite signals without transmitting. In most jurisdictions, receiving satellite signals is legal (with exceptions for intentional interception of private communications). Passive analysis provides intelligence about the target satellite’s communication protocols, modulation schemes, and potential vulnerabilities — all without any risk of interference.

SDR Setup for Satellite Monitoring

Recommended hardware for satellite signal reception:

SDR Device	Frequency Range	Bandwidth	Use Case	Approximate Cost
RTL-SDR V4	24 MHz - 1.766 GHz	2.4 MHz	L-band (Iridium, Inmarsat, GPS)	$30
Airspy Mini	24 MHz - 1.8 GHz	6 MHz	L-band with better dynamic range	$100
HackRF One	1 MHz - 6 GHz	20 MHz	Wide frequency coverage, TX capable	$350
LimeSDR Mini 2.0	10 MHz - 3.5 GHz	30.72 MHz	Full-duplex, MIMO capable	$250
Ettus USRP B210	70 MHz - 6 GHz	56 MHz	Professional-grade, MIMO	$2,500
Nooelec SAWbird+	Filtered LNA	N/A	Low-noise amplifier for specific bands	$30

Antenna considerations:

L-band (1-2 GHz): Patch antenna, quadrifilar helix antenna (QFH), or Yagi for Iridium/Inmarsat/GPS
S-band (2-4 GHz): Helical antenna or small dish (60+ cm)
C-band (4-8 GHz): 1.2m+ parabolic dish with C-band LNB
Ku-band (12-18 GHz): 60cm+ offset dish with Ku-band LNB
Ka-band (26-40 GHz): 45cm+ dish with Ka-band LNB (higher precision required)

Signal Identification and Analysis

DVB-S2 signal identification:

DVB-S2 (Digital Video Broadcasting - Satellite, 2nd Generation) is the dominant protocol for satellite TV distribution and increasingly for broadband. Identifying DVB-S2 signals:

# Using SatDump for DVB-S2 signal processing
# Install SatDump
git clone https://github.com/SatDump/SatDump.git
cd SatDump && mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make -j$(nproc) && sudo make install

# Record baseband from RTL-SDR for analysis
rtl_sdr -f 1545000000 -s 2400000 -g 40 capture.bin

# Analyze with inspectrum for visual signal analysis
inspectrum capture.bin

Signal parameter identification:

When you observe a satellite signal, determine the following parameters:

Parameter	How to Determine	Tools
Center frequency	SDR waterfall display, compare to filed frequencies	GQRX, SDR#, SDR++
Bandwidth	Measure -3dB points on spectrum display	GQRX, inspectrum
Modulation	Visual pattern on constellation diagram	GNU Radio, SatDump
Symbol rate	Measure symbol width in time domain	GNU Radio, baudline
Polarization	Rotate antenna feed, measure signal strength	Physical observation
FEC coding	Attempt decode with different coding parameters	SatDump, GNU Radio
Protocol	Match parameters to known standards	Cross-reference databases

VSAT Carrier Identification

VSAT (Very Small Aperture Terminal) networks operate in C-band, Ku-band, or Ka-band. During passive monitoring, look for:

Outbound carriers (hub-to-remote): High-bandwidth, continuous TDM carriers. Often DVB-S2 modulation. These carry data from the hub to remote terminals.
Inbound carriers (remote-to-hub): Lower-bandwidth, bursty TDMA or SCPC carriers. These reveal remote terminal locations and traffic patterns.
ACM (Adaptive Coding and Modulation): DVB-S2X carriers that change modulation and coding based on link conditions. The MODCOD field in the physical layer header is unencrypted and reveals link quality information.

Security-relevant observations from passive VSAT monitoring: Unencrypted management traffic (terminal provisioning, firmware updates), unencrypted user traffic, terminal identification in protocol headers, and network topology information from routing protocols carried over the satellite link.

Phase 4 — Ground Segment Testing

The ground segment is the most accessible attack surface in satellite systems and the most amenable to traditional penetration testing techniques. Ground segment testing can often be conducted without any RF-specific equipment or regulatory concerns.

VSAT Terminal Testing

VSAT terminals are among the most common satellite equipment encountered in penetration testing. They are deployed in large numbers, often in physically accessible locations, and frequently suffer from poor security hygiene.

Default credential testing:

Vendor	Product	Common Default Credentials	Interface
Hughes	HT2000W / HT2500	admin:admin, admin:password	HTTPS (:443)
iDirect	iQ Desktop / Evolution	admin:P@55w0rd!, admin:iDirect	HTTPS (:443)
Newtec	MDM Series	admin:newtec, admin:admin	HTTPS (:443), SSH (:22)
Gilat	SkyEdge II-c	admin:admin	HTTP (:80)
Comtech	CDM-760	admin:password, comtech:comtech	HTTPS (:443), Serial
ViaSat	SurfBeam 2	admin:admin	HTTP (:80)
Kymeta	u8	admin:admin	HTTPS (:443)

Important: These are commonly reported default credentials found in public documentation, security advisories, and vendor manuals. Always verify against current vendor documentation, as defaults change between firmware versions.

Firmware extraction and analysis:

# UART access - identify UART pins on terminal PCB
# Common baud rates for satellite terminals: 9600, 38400, 115200
screen /dev/ttyUSB0 115200

# Once connected, check for shell access
# Many terminals drop to BusyBox or custom Linux shell

# JTAG access for deeper analysis
# Use OpenOCD with appropriate JTAG adapter
openocd -f interface/ftdi/um232h.cfg -f target/arm926ejs.cfg

# Firmware extraction via SPI flash
# Identify flash chip, connect with SPI programmer
flashrom -p ch341a_spi -r firmware_dump.bin

# Firmware analysis with binwalk
binwalk -e firmware_dump.bin
# Look for:
# - Hardcoded credentials in extracted filesystem
# - Private keys / certificates
# - Configuration files with network topology
# - Debug interfaces left enabled

# String analysis for credentials
strings firmware_dump.bin | grep -i -E "password|passwd|secret|key|token"

# Entropy analysis to identify encrypted/compressed sections
binwalk -E firmware_dump.bin

Web interface vulnerabilities:

VSAT terminal web management interfaces commonly suffer from:

Command injection: Many terminals pass user input directly to shell commands for network configuration, ping tests, or diagnostic functions. Test all input fields with standard OS command injection payloads.
Improper authentication: Session tokens that are predictable or do not expire, missing CSRF protection, authentication bypass through direct URL access.
Information disclosure: Debug pages, status pages, or API endpoints that reveal network configuration, neighboring terminal information, or satellite link parameters without authentication.
Insecure firmware updates: Firmware update mechanisms that do not verify digital signatures, allowing an attacker to flash modified firmware.

# Example: Testing VSAT terminal web interface
# Enumerate web interface endpoints
gobuster dir -u https://192.168.1.1 -w /usr/share/wordlists/dirb/common.txt -k

# Test for command injection in diagnostic functions
# Common injection points: ping test, traceroute, DNS lookup
curl -k "https://192.168.1.1/cgi-bin/ping.cgi" \
  -d "target=8.8.8.8;id"

# Check for unauthenticated API endpoints
curl -k "https://192.168.1.1/api/v1/status"
curl -k "https://192.168.1.1/api/v1/config"
curl -k "https://192.168.1.1/cgi-bin/sysinfo"

# Test for directory traversal
curl -k "https://192.168.1.1/cgi-bin/download.cgi?file=../../../etc/passwd"

Ground Station Network Penetration Testing

Ground station networks combine IT and OT components, requiring a hybrid testing approach:

Network architecture reconnaissance:

# Network discovery on ground station network
nmap -sn 10.0.0.0/24                    # Host discovery
nmap -sV -sC -p- 10.0.0.0/24 -oA scan  # Full port/service scan

# Common services found in ground station networks:
# - SNMP (UDP 161) - Antenna controllers, RF equipment
# - Modbus (TCP 502) - SCADA/ICS components
# - HTTP/HTTPS (80/443) - Equipment management interfaces
# - SSH (22) - Linux-based ground station controllers
# - VNC (5900) - Remote access to operator consoles
# - Custom ports - Proprietary TT&C and M&C protocols

# SNMP enumeration of antenna control equipment
snmpwalk -v2c -c public 10.0.0.50 1.3.6.1
# Look for: antenna position, frequency settings, power levels

# Test for default Modbus access to antenna controllers
python3 -c "
from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('10.0.0.100')
client.connect()
# Read holding registers (antenna position, status)
result = client.read_holding_registers(0, 10, unit=1)
print(result.registers)
"

TT&C interface security assessment:

Telemetry, Tracking, and Command (TT&C) interfaces are the most critical components in the ground segment. Testing should assess:

Command authentication: Are commands to the spacecraft authenticated? Can an attacker on the ground network inject unauthorized commands?
Telemetry integrity: Is telemetry data integrity-protected from the ground station to the mission control center? Can an attacker modify telemetry in transit to mask anomalies?
Key management: How are cryptographic keys for command authentication stored and managed? Are they in HSMs or in software?
Network segmentation: Is the TT&C network properly segmented from the enterprise IT network? Can an attacker who compromises an enterprise workstation reach TT&C systems?
Remote access: How do operators access TT&C systems remotely? Are VPN connections properly secured? Is multi-factor authentication enforced?

API Testing for Satellite Management Platforms

Modern satellite operators increasingly use cloud-based platforms and APIs for fleet management, capacity allocation, and service provisioning. Key API endpoints to test include satellite telemetry retrieval, command submission, ground station scheduling, antenna control, and capacity allocation. Apply standard OWASP API Top 10 methodology with particular attention to:

BOLA/IDOR: Change satellite/ground station IDs to access other operators’ resources
Command injection: Command submission endpoints that may pass input to spacecraft command processors
Mass assignment: Adding privileged fields (admin roles, spacecraft access levels) to user update requests
Rate limiting: Absence enables brute force against authentication and resource exhaustion on capacity APIs

Phase 5 — Active RF Testing

Active RF testing involves transmitting radio signals to test satellite system resilience. This phase requires the highest level of authorization and carries the greatest legal risk. Active RF testing must only be performed with explicit written authorization from the satellite operator and any relevant regulatory authority (e.g., FCC experimental license).

GPS Spoofing Test Methodology

GPS spoofing is one of the most impactful and well-documented active RF attacks against satellite-dependent systems. Testing GPS spoofing resilience is increasingly requested by organizations that depend on GPS for timing (financial systems, power grids) or navigation (maritime, aviation, autonomous vehicles).

Test setup (RF-shielded environment or direct cable connection only):

# Hardware: HackRF One + GPS antenna (or direct cable with 60+ dB attenuator)
# Software: GPS-SDR-SIM (https://github.com/osqzss/gps-sdr-sim)

# Download current GPS ephemeris
wget "https://cddis.nasa.gov/archive/gnss/data/daily/2024/brdc/brdc0450.24n.gz"
gunzip brdc0450.24n.gz

# Generate spoofed GPS baseband signal for target location
./gps-sdr-sim -e brdc0450.24n -l 38.8977,-77.0365,100 -b 8 -d 300 -o spoofed_gps.bin

# Transmit via HackRF (IN SHIELDED ENVIRONMENT ONLY)
hackrf_transfer -t spoofed_gps.bin -f 1575420000 -s 2600000 -a 1 -x 20

GPS spoofing test cases:

Test Case	Description	Expected Resilient Behavior
Static position spoof	Spoof GPS to report a different fixed location	Receiver detects jump discontinuity, alerts
Gradual drift	Slowly shift reported position over time	Receiver detects deviation from IMU/other sensors
Time manipulation	Spoof GPS time to a different epoch	Timing system detects discontinuity, falls back to holdover
Selective denial	Spoof specific satellites while leaving others	Receiver detects inconsistent pseudoranges
Meaconing (replay)	Record and replay real GPS signals with delay	Receiver detects timing inconsistency
Power advantage	Transmit spoofed signal at higher power than real GPS	Tests receiver’s ability to detect abnormal signal strength

VSAT Uplink Injection Concepts

VSAT uplink injection attacks exploit the fact that satellite transponders are typically “bent-pipe” — they amplify and retransmit whatever they receive on the uplink frequency, without authentication.

Testing approach (authorized lab environment only):

Characterize the target VSAT protocol (DVB-S2/DVB-RCS2, iDirect, Hughes, etc.) through passive analysis.
Replicate the signal structure in a lab environment using test equipment or SDR.
Assess whether the hub authenticates traffic from remote terminals at the physical layer, MAC layer, or only at higher protocol layers.
Test whether a rogue terminal can inject traffic into the network by mimicking legitimate terminal signaling.

Note: Actual uplink injection against operational satellites is illegal without authorization and can interfere with legitimate communications. Testing should be conducted in a lab environment with a satellite simulator or with explicit operator authorization during a maintenance window.

Replay Attacks

Replay attacks involve capturing legitimate satellite communications and retransmitting them later. Capture signals using hackrf_transfer -r capture.raw -f <freq> -s 20000000 -g 40, then analyze for anti-replay mechanisms: sequence numbers, timestamps, nonces, and session tokens. If the protocol lacks these mechanisms, retransmitting the captured signal may be accepted by the satellite system. This directly tests compliance with CCSDS 352.0 SDLS anti-replay requirements (see Frameworks & Standards).

Phase 6 — Reporting

Satellite penetration test reports require additional context that standard pentest reports do not address. The multi-segment nature of satellite systems, the regulatory environment, and the long lifecycle of space assets all influence how findings should be presented and prioritized.

Satellite-Specific Risk Scoring

Standard CVSS scoring does not adequately capture the risk of satellite-specific vulnerabilities. Augment CVSS with the following satellite-specific factors:

Factor	Low (1)	Medium (2)	High (3)	Critical (4)
Segment Impact	Single terminal	Ground station	Link segment	Space segment
Remediation Difficulty	Software patch	Firmware update (ground)	Protocol change	On-orbit (no fix)
Cascade Potential	Isolated system	Single operator affected	Multiple operators	Cross-sector impact
Regulatory Exposure	Internal policy	Industry standard	National regulation	International treaty
Mission Impact	Degraded performance	Partial service loss	Full service outage	Permanent asset loss

Composite Satellite Risk Score = (CVSS Base Score * 0.4) + (Satellite Factors Average * 0.6)

This weighting reflects that satellite-specific factors (particularly remediation difficulty and cascade potential) often dominate the real-world risk more than traditional CVSS metrics.

Impact Assessment Across Segments

Each finding should be assessed for its potential impact across all satellite system segments, even if the vulnerability exists in only one segment:

graph LR
    V["Vulnerability<br/>(Ground Segment)"] --> I1["Direct Impact<br/>Ground station compromise"]
    I1 --> I2["Cascade Impact<br/>Unauthorized commanding"]
    I2 --> I3["Segment Impact<br/>Spacecraft compromise"]
    I3 --> I4["Mission Impact<br/>Service disruption"]
    I4 --> I5["Cross-Sector Impact<br/>GPS timing loss"]

    style V fill:#e74c3c,color:#fff
    style I1 fill:#e67e22,color:#fff
    style I2 fill:#f39c12,color:#fff
    style I3 fill:#9b59b6,color:#fff
    style I4 fill:#3498db,color:#fff
    style I5 fill:#2c3e50,color:#fff

Remediation Prioritization

Prioritize remediation based on the unique constraints of satellite systems:

Immediate (0-30 days): Vulnerabilities exploitable remotely with no authentication that could lead to unauthorized commanding or service disruption. Ground segment network segmentation fixes.
Short-term (30-90 days): Default credentials on accessible terminals, unencrypted management interfaces, missing authentication on APIs.
Medium-term (90-180 days): Firmware vulnerabilities requiring coordinated update across deployed terminals, protocol-level issues requiring configuration changes.
Long-term (180+ days): Architectural issues requiring ground system redesign, on-orbit vulnerabilities that can only be mitigated (not fixed), standards compliance gaps requiring policy and process changes.
Next mission (design phase): Vulnerabilities in the space segment that cannot be remediated on orbit. Document for incorporation into successor mission design requirements.

Pentest Checklist by Segment

The following comprehensive checklists provide a structured approach to satellite penetration testing for each system segment.

Space Segment Checklist

#	Test Item	Technique	Tools	Risk Level
S1	Flight software analysis (if test unit available)	Static analysis, reverse engineering	Ghidra, IDA Pro, Binary Ninja	Critical
S2	Spacecraft bus protocol security	Protocol analysis of test interfaces	Wireshark, custom parsers	Critical
S3	Command authentication mechanism review	Protocol analysis, documentation review	N/A (design review)	Critical
S4	Telemetry encryption assessment	Passive signal analysis, documentation review	GNU Radio, SatDump	High
S5	Software update mechanism security	Firmware update process analysis	binwalk, firmware-mod-kit	Critical
S6	Redundancy/failover security	Safe mode trigger analysis	N/A (design review)	High
S7	Supply chain component analysis	Hardware inspection, provenance verification	X-ray, decapping (specialized)	High
S8	Side-channel analysis (if hardware available)	Power analysis, EM emanation	ChipWhisperer, oscilloscope	Medium

Ground Segment Checklist

#	Test Item	Technique	Tools	Risk Level
G1	Network segmentation validation	Network scanning, VLAN hopping	nmap, Yersinia	Critical
G2	Ground station authentication	Credential testing, brute force	Hydra, Burp Suite	Critical
G3	TT&C system access controls	Privilege escalation, RBAC testing	Manual testing	Critical
G4	VSAT terminal default credentials	Credential testing against known defaults	Custom scripts, Hydra	High
G5	VSAT terminal firmware analysis	Firmware extraction, reverse engineering	binwalk, Ghidra	High
G6	Web management interface testing	OWASP methodology	Burp Suite, ZAP	High
G7	SCADA/ICS component assessment	Modbus/SNMP testing	Metasploit, nmap scripts	High
G8	Key management infrastructure	HSM configuration review, key storage	Manual review	Critical
G9	Physical security assessment	Site survey, access control testing	Physical pentest tools	Medium
G10	Remote access security	VPN testing, MFA validation	nmap, OpenVPN audit	High
G11	Satellite management API testing	OWASP API Top 10 methodology	Burp Suite, Postman	High
G12	Database security (orbit/telemetry data)	SQL injection, access control testing	sqlmap, manual testing	Medium

User Segment Checklist

#	Test Item	Technique	Tools	Risk Level
U1	Terminal hardware security	JTAG/UART access, debug interface identification	JTAGulator, Bus Pirate	High
U2	Terminal firmware extraction	SPI flash dump, eMMC access	flashrom, ch341a programmer	High
U3	Terminal firmware analysis	Reverse engineering extracted firmware	binwalk, Ghidra, strings	High
U4	Terminal web interface testing	Standard web app pentest	Burp Suite, ZAP	Medium
U5	Terminal default credentials	Test against vendor default lists	Manual, Hydra	Medium
U6	Mobile app security	OWASP Mobile Top 10	MobSF, Frida, objection	Medium
U7	Terminal-to-hub authentication	Protocol analysis	Wireshark, SDR	High
U8	Local network exposure	Test what local network services terminals expose	nmap, netcat	Medium
U9	Secure boot validation	Attempt to boot modified firmware	Hardware tools, JTAG	High
U10	GPS receiver spoofing resilience	GPS spoofing test	HackRF, GPS-SDR-SIM	High

Link Segment Checklist

#	Test Item	Technique	Tools	Risk Level
L1	Encryption presence verification	Passive signal analysis	SDR, GNU Radio	Critical
L2	Protocol identification	Signal analysis, parameter extraction	SatDump, inspectrum	Medium
L3	Anti-replay mechanism assessment	Capture and replay testing (authorized)	HackRF, GNU Radio	High
L4	Key rotation frequency	Documentation review, long-term monitoring	Manual review	Medium
L5	Uplink authentication assessment	Protocol analysis	SDR, custom tools	Critical
L6	Jamming resilience testing	Controlled interference testing (authorized)	Signal generator, SDR	High
L7	Spoofing detection capability	GPS/GNSS spoofing test	HackRF, GPS-SDR-SIM	High
L8	Inter-satellite link security	Design review (if accessible)	N/A (design review)	Medium
L9	Unencrypted data exposure	Passive monitoring for cleartext data	SDR, Wireshark	High
L10	Signal authentication mechanism	Protocol analysis	GNU Radio, custom tools	Critical

Legal and Ethical Considerations Summary

Satellite penetration testing carries legal risks that substantially exceed those of traditional IT pentesting. The following table summarizes the key legal considerations by activity:

Activity	Legal Status (US)	Authorization Required	Regulatory Body
OSINT / public data collection	Legal	None	N/A
Passive RF reception	Generally legal	None (but interception of content may violate ECPA)	FCC
Internet scanning of ground infrastructure	Legal with authorization	Written authorization from system owner	N/A (CFAA)
VSAT terminal hardware hacking (own equipment)	Legal	Ownership	FCC (if transmitting)
VSAT terminal hardware hacking (client equipment)	Legal with authorization	Written authorization	N/A (CFAA)
Active RF transmission (satellite frequencies)	Requires license	FCC experimental license + operator authorization	FCC
GPS spoofing (shielded environment)	Legal gray area	Operator authorization, shielded environment	FCC
GPS spoofing (over-the-air)	Illegal (18 USC 32)	Generally not authorized	FCC, DOJ
Satellite uplink injection	Requires license	FCC license + operator authorization	FCC
Jamming of any kind	Illegal (47 USC 333)	No authorization possible for commercial entities	FCC

Critical reminder: The FCC has imposed fines exceeding $100,000 for unauthorized transmissions on satellite frequencies. GPS jamming and spoofing carry criminal penalties under 18 USC 32. Always consult legal counsel before conducting active RF testing.