Don't Look Up: There Are Sensitive Internal Links in the Clear on GEO Satellites

Introduction

For decades, geostationary (GEO) satellites have been the primary means of delivering reliable high-speed communication to remote sites. GEO links serve a variety of uses including television and Internet Protocol (IP) communication, including Internet access for in-flight WiFi and residential Internet [32,69], as well as backhaul for private internal networks for sensitive remote commercial and military equipment [53,58,59].

There are thousands of GEO network links in operation today, carried by 590 GEO satellites orbiting Earth [68]. Each satellite may carry traffic for dozens of independent networks through an array of on-board transponders, each covering a diameter of thousands of kilometers (at most a third of Earth's surface) [36,54]. GEO IP links are established by leasing time on a transponder and aiming dishes for Earth-based terminals and hubs at that transponder [16]. The ecosystem of equipment to support IP-based GEO links is mature and heterogeneous: at least 10 different vendors sell terminal and hub systems that each use their own proprietary protocol stacks to provide GEO networking [60].

Unfortunately, GEO satellites have been shown to be particularly susceptible to interception attacks [5,[39][40][41]. Consumer-grade satellite dishes and passive terminals are Commercially Available Off-The-Shelf (COTS) for hundreds of US dollars; a network of online enthusiasts publishes open databases of satellite coordinates and transponders [57], and the popularity of satellite television has given rise to high-quality free software for finding and decoding GEO satellite signals [12]. Given that any individual with a clear view of the sky and US$600 can set up their own GEO interception station from Earth, one would expect that GEO satellite links carrying sensitive commercial and government network traffic would use standardized link and/or network layer encryption to prevent eavesdroppers [10,61]. Indeed, encryption has been routinely deployed for the last four decades to protect paid satellite television services from piracy [54]; a succession of satellite content-scrambling algorithms has been subjected to significant real-world scrutiny [11,17,20,25,42,56,70].

Prior work has found sensitive communication in the clear over a select handful of GEO satellites and transponders [5,39,40], particularly in specific segments of the GEO satellite market such as marine [39] and in-flight WiFi [28]. However, these prior studies focused on restricted protocols and use cases of the GEO ecosystem, and provide a limited view into the threat posed by GEO network interception. Indeed, prior work even stated that "generalizations applicable to the entire VSAT industry are difficult if not impossible" because "service operators use a wide range of protocols, many proprietary and undocumented" [39].

Threat Model. In this work, we demonstrate the feasibility of an attacker whose goal is to observe satellite traffic visible from their position by passively scanning as many GEO transmissions from a single vantage point on Earth as possible. This form of widescale interception has previously been assumed to only be feasible with state actor-grade equipment and software [29]. More precisely, we demonstrate that a low-resource attacker, using COTS, low-cost equipment can reliably intercept and decode hundreds of links from a single vantage point.

Our Work.

We undertake what we believe is the most comprehensive study of GEO satellites, transponders, protocol stacks, encryption use, and application domains carried out to date in the open research community. We observe that while content scrambling is standard for satellite TV, it is surprisingly unlikely to be used for private networks using GEO satellite to backhaul IP network traffic from remote areas. Many organizations appear to treat satellite as any other internal link in their private networks. Our study provides concrete evidence that network-layer encryption protocols like IPSec are far from standard on internal networks, unlike on the Internet where TLS is default [44], a finding that has been until now essentially impossible for external researchers to legally measure.

Findings. As a consequence, we observe significant amounts of highly sensitive internal network traffic being broadcast unencrypted to large portions of North America. The severity of our findings suggest that these organizations do not routinely monitor the security of their own satellite communication links. Despite the availability of COTS satellite hardware, scanning and capturing arbitrary GEO network traffic is technically challenging.

Challenges. Capturing traffic across the broad range of GEO satellites and users requires overcoming three challenges: (1) Dish alignment: We require a passive ground station that can be automatically aimed at dozens of satellites with sufficient accuracy and signal quality to ensure correct datastreams [34]. (2) Protocol diversity: Assessing the GEO ecosystem requires understanding a heterogeneous puzzle of satellite protocol layers and proprietary implementation quirks in order to re-assemble data streams into IP packets and accurately parse higher-layer protocols for traffic analysis and attribution [8,14,18,19,19,38]. (3) Link churn: A given transponder may lease service for many different links over time [16,54]. In order to accurately audit traffic flows, we must account for unpredictable user changeover during our scans.

Our contributions. We overcome these challenges to build a universal GEO satellite scanner from low-cost COTS satellite equipment that can scan the sky for visible satellites, scan each for available transponders, then accurately decode IP packets from each transponder. Our technical contributions include:

(1) We introduce a new method to self-align a motorized dish to improve signal quality. Specifically, we could receive IP traffic from 14.3% of all global Ku-band satellites from a single location with high signal quality and low error rate. (2) We developed a general GEO traffic parser that can blindly decode IP packets from seven different protocol stacks that we observed in our scans. Five of these stacks have never been reported in any public research we are aware of.

Using our tool, we then carried out an empirical study of the current state of encryption in the GEO satellite ecosystem.

(3) We collected comprehensive scans across a seven-month period. There is enough stability in transponder usage across a 24-hour time interval that we can reliably scan each of the 411 transponders that were visible from our test location and collect a 3-minute data capture from each over the course of a scan that took approximately 24 hours. (4) Our scanning dataset uncovered a surprising number of private IP networks with cleartext traffic from industry, government, and critical infrastructure. Table 1 summarizes some of the types of traffic we observed and disclosed.

Our findings illustrate ongoing structural disincentives for deploying encryption, even in apparently security-critical use cases. Source code and an up to date full version of this paper [71] can be found at: https://satcom.sysnet.ucsd.edu

Background

We provide a brief background primer on GEO satellite networks, focusing on the aspects most relevant to interception.

GEO Satellites. Satellites can be broadly classified by their orbits. For example, Starlink satellites have a Low Earth Orbit (LEO). In this paper, we focus on geostationary (GEO) satellites. Hundreds of GEO satellites orbit Earth around the equator at a fixed altitude and position relative to Earth. Each GEO satellite can be distinguished by its fixed longitudinal position, called its orbital slot (Figure 1(a) top). With proper coordination to avoid collisions, multiple GEO satellites can "share" an orbital slot by operating closer than 0.1°apart.

For the most part, GEO satellites act as basic repeaters, receiving signals from the ground, and amplifying and repeating them to broadcast them to a larger coverage area. This basic communication path is often referred to as a "bent pipe" (Figure 1(a)).

Communicating with a satellite requires a directional dish antenna that focuses its beam on one satellite in one orbital slot. When transmitting and receiving, satellites must avoid signal interference. Satellites in distant orbital slots can reuse the same frequency channels, but those in nearby orbital slots must use different frequencies.

Transponders. GEO satellites operate multiple simultaneous amplifying relays, called transponders (Figure 1(a)). Each satellite has dozens of transponders covering different frequencies (GHz), polarizations (Horizontal/Vertical), and coverage areas. GEO transponders are distinguished by the spectrum bands that they transmit over: commonly Ku, Ka, or C. We focus on Ku-band, which is traditionally used for television and Internet applications. Satellite transponders can use beam widths of different sizes in order to transmit to different sized regions on the ground; the area covered by a transponder's beam is called its footprint.

From our single vantage point in La Jolla, CA, we observed 411 independent Ku-band transponders.

(b)).

Forward Link Protocols. Each direction between the terminals and hub is an independent link with its own protocols (Figure 1(a)). The link used to broadcast traffic from the hub to the remote terminals is called the forward link (hub-to-terminal). The forward link covers a large area, often a diameter of ∼10,000 kilometers, to send traffic to many remote terminals. The coverage of the reverse link (terminalto-hub) has a comparatively smaller area, just to cover the hub.

Our work intercepts the forward link, so we describe it here. The physical layer protocols in common use today are DVB-S and DVB-S2(X) (Figure 1(c)). DVB-S is a legacy video/audio broadcast protocol that was adapted for use with IP, and DVB-S2(X) is a more modern protocol designed for carrying IP reliably and efficiently.

Different terminal vendors use different link-layer protocols to encapsulate IP packets from frames at the physical layer. Table 2 provides a list of the most popular terminal vendors and their protocols (in the North American market). These include standardized protocols, modified versions of standard protocols, and vendorspecific proprietary protocols. Legacy IP links were designed to operate over terminals that were originally intended primarily for video delivery and thus use MPE encapsulation, while newer IP links operate over newer, more efficient standards like GSE. There is limited public documentation on the proprietary protocols and implementations used by vendors.

Encryption. Over-the-air encryption is supported by most satellite terminal and hub systems, as shown in Poor signal, many protocols North America Table 3: Our methods allow us to scan many more transponders than prior GEO interception papers.

be implemented in terminals at the physical, link, or network layer.

Using the terminals' built-in encryption saves bandwidth because the terminal can do header and payload compression. The DVB-S2(X) physical layer also offers a scrambling mode (for wireless transmission integrity) that can be set in the terminal [22,54].foot_0

Related Work

To our knowledge, our threat model of using low-cost consumergrade satellite equipment to comprehensively survey GEO satellite usage has not been explored before in the academic literature.

On the high-resource end, military and intelligence agencies have the capabilities to passively capture huge swaths of the satellite ecosystem. Indeed, there are several companies who publicly sell proprietary GEO satellite survey systems to government customers at relatively high prices. This high-end equipment has the capability of parsing traffic from many terminal/hub ecosystems. One vendor claims to be able to decrypt traffic for the Hughes ecosystem [63].

On the low-resource end of the attacker spectrum, a handful of academic works studied a similar adversary to us but limited their scope to a subset of protocols and marine and aviation applications. Table 3 compares our study to prior work.

Pavur, Moser, Lenders, and Martinovic [40] collected data from 13 DVB-S transponders in Europe in 2019 using consumer-grade equipment. They found unencrypted consumer Internet traffic and utility infrastructure. They focused only on terminals/hubs using the MPE protocol, as that was the only public decoder that was available at the time. In 2020, Pavur, Moser, Strohmeier, Lenders, and Martinovic [39] analyzed marine Internet access traffic for two transponders from two targeted satellites in Europe. For this work, they built a parser to extract IP traffic from DVB-S2 encapsulated GSE streams, focusing on this protocol stack because it was common in maritime applications. Both works struggled with poor signal quality to decode traffic from different transponders.

In 2022, Baselt, Strohmeier, Pavur, Lenders, and Martinovic [28] performed a more comprehensive study of aviation-related traffic using the GSE protocol in Europe. This work provided the first scanning results on the GEO satellite ecosystem. The authors scanned 18 visible satellites and found 34 transponders that had GSE traffic that they could parse that were related to aviation Internet access.

Lin, Cheng, Luo, and Chen introduced a new machine-learning GSE decoding algorithm in 2023 to overcome the challenge of low signal quality in intercepted GEO satellite feeds [47]. They used a $15,000 high-end dual-axis steerable satellite setup, and evaluated their data capture on data from seven satellites in Asia. Their work is complementary to ours as CLExtract could improve our interception of GSE streams. However, even without their low-signal decoding, our comprehensive scanning was able to capture 196 GSE transponders with high rates of successful traffic interception.

Various other threats have been identified in the satellite communications ecosystem, including terminals being vulnerable to injection attacks [9] and fingerprinting [64].

In contrast to these prior works, we focus on carrying out a comprehensive wide-band, many-satellite, long-duration scan of the Ku-band satellite ecosystem and understanding vendor-specific quirks that allow us to accurately reconstruct internal traffic flows that no prior works have documented.

Achieving low-cost, near-comprehensive scans of GEO satellites comes with considerable challenges. Most prior works struggled with low signal quality, which we believe stems from the difficulty of aligning consumer-grade satellite equipment. We overcame this challenge by developing careful alignment methods that allow us to accurately gather raw data from hundreds of transponders. We describe our methods in Section 4. The second challenge is to blackbox reverse-engineer and parse the diverse collection of protocols at the physical, link, and network layer, and implementation choices made by vendors. We describe our methods in Section 5. Our more comprehensive viewpoint allows us to accurately reconstruct traffic and gain visibility into satellite ecosystems that were not parseable by the toolchains used in prior work.

Dish Alignment and Aiming

Imperfect satellite alignment can result in poor signal quality and signal loss.

Prior to this work, achieving accurate alignment required an expensive dual-axis steerable dish or phased-array steerable antenna [50]. We demonstrate that with hidden alignment data in satellite feeds, even a hobbyist-grade single axis rotor dish can achieve good enough alignment to receive high-quality signal from all visible satellites. There are two components to aligning a singleaxis rotor: vertical (elevation) and horizontal (azimuth) alignment. Vertical alignment is straightforward: any error in elevation will shift the entire elliptical arc above or below the GEO plane. This reduces signal strength uniformly across all satellites. In our experiments a misalignment of just over 1°reduced SNR by more than 5dB, despite using a large 110 cm dish.

Horizontal (azimuth) alignment is significantly harder. The motor's 0°reference must be precisely oriented toward the user's geographic longitude, but magnetic compasses and mobile apps are unreliable in urban environments. The primary limitation of a single-axis rotor is that the dish must sweep across the satellites in the GEO plane along an elliptical arc. Even small azimuth misalignments can lead to partial coverage: satellites near the center of the arc may still lock, but those at the edges are lost (Figure 3). We found manual alignment via compass-based methods to be effectively impossible for our needs.

Instead, we used ground-truth satellite positions to calibrate alignment. Although it is possible to detect a satellite via a spike in signal power, identifying said satellite without access to the owner's proprietary operational parameters is more difficult.

Hidden ground-truth alignment references. We identified two sources of ground truth to calibrate our azimuth alignment: (1) some transponders broadcast satellite-specific metadata such as the orbital position (e.g., 99°W), satellite name (e.g., G16 for Galaxy 16), and transponder ID (e.g., BEAM 0067) within the Network Information Table (NIT) and Service Description Table (SDT) fields of DVB-SI tables [23]; (2) public databases of free-to-air television (e.g., LyngSat [45]) identify known satellite transponders. These anchors span both edge and central positions in the GEO plane, enabling precise alignment across the dish's full motor range.

Evaluation of Alignment. In our capture location, with a manually misaligned dish, we observed that despite strong signal reception from satellites between 129.0°W and 87.1°W (a span of 15°), all satellites east of 87.1°W (10°) failed to lock due to arc misalignment. We identified twelve transponders across eight longitudes ranging from 65.0°W to 129.0°W (see Appendix A) that broadcast recognizable identifiers. After adjusting the horizontal alignment of the motor to agree with the ground truth latitude of the satellites, we gained 10°of visibility, adding 14 new satellites and 110 transponders to our scan.

Raw Data Capture

We automated raw data capture with dvbv5-zap [1]-a Linux tool compatible with our TBS tuner card's Linux driver-to iteratively lock onto transponders from the list obtained above in Section 4.4. For each transponder, the tool needs to capture the raw bits decoded from the DVB-S/S2(X) protocol into a .ts file so our tools can then parse the vendor specific stack to recover IP packets.

However, Linux's DVB-S support was developed for and largely used by satellite television enthusiasts, so it does not naively support recording raw data streams. We modified the tuner card's driver to record a raw transport stream at the DVB-S/S2(X) protocol layer and above instead of an MPEG-TS video/audio stream. MPEG-TS frames are prefixed with a synchronization byte 0x47 [14,15]; when this byte is not observed, the driver assumes it has lost synchronization and discards bytes until the next available 0x47. This approach works for an MPEG-TS video/audio stream temporarily corrupted by noise, but it fails for non-MPEG-TS streams, such as raw DVB-S2(X), which do not use 0x47 for frame synchronization.

To capture raw streams of DVB-S/S2(X) bytes, we modified and recompiled the tuner card's Linux driver to disable this MPEG-TS internal filtering and forward the raw demodulated data directly to the demux0 device. Our modified driver is open source to support future satellite research [71].

In EBSpro, this filtering can be similarly circumvented by enabling the Raw data handling (do not use Internal EBSPro's filter) option before performing a manual capture. In earlier versions (prior to 18.0.0.2 RC), this feature was unavailable.

Ku-Band Satellite Coverage and Scanning Results.

According to the open source satellite database SatBeams, there are 273 GEO satellites operating in the Ku-band [57]. By cross-referencing this data with the coordinates of our receiver, we limit the scope of our data collection to satellites between 55.0°W and 172.0°E. Because our motor was only capable of ±60°of freedom, we further limited our collection to satellites between 57.2°W and 177.2°W.

As shown in Figure 4, our scan successfully captured signals from satellites positioned between 61.0°W and 129.0°W, covering 39 satellites across 25 distinct longitudes. The lack of detected satellites in the western sky is not due to scanning limitations, but rather the sparse customer base over the Pacific Ocean, which leads to fewer active Ku-band satellites in that region. In total, we identified and successfully locked onto 411 Ku-band transponders, each carrying distinct services and traffic data. A detailed analysis of the captured transponder traffic is provided in Section 5.

Apparent transponder counts can be inflated by orbital slot overlap. For instance, at 105°W, we observed what appears to be an unusually high number of transponders. However, closer inspection reveals that multiple satellites share nearby orbital slots (e.g., within 0.1-0.5°separation), causing their transponders to be grouped under a single longitude. Such slot-sharing is common in GEO deployments and reflects coordinated co-location strategies [37,54].

0°3 0°E 60°E 90°E 120°E 150°E 180°W 150°W 120°W 90°W 60°W 30°W Theoretical…scan…range In…range…only…after…reference…alignment Out…of…range In…range,…no…signal In…range,…signal…detected

Transponder Churn

Satellite transponders change over time because of expiring and activating leases. We conducted two full-band scans in August 2024 in February 2025 and compared the results. Figure 5 presents a histogram of transponder changes by longitude between scans.

The results highlight the heterogeneous and dynamic nature of real-world satellite transponder configurations. The high turnover for some satellites suggests that certain operators dynamically lease and reallocate transponder capacity in response to service contracts, demand shifts, or regional coverage strategies [21].

Interestingly, transponder churn does not always correspond with changes in physical-layer parameters. In some cases, the transmission configuration remained constant (same frequency, polarization, symbol rate), yet the protocol content changed entirely. For instance, one transponder on 67.0°W previously carried DVB-S2 → GSE → IP traffic, but was later observed transmitting an unidentified binary data format, indicating a full-service replacement while retaining the same modulation settings. This reinforces the importance of layered traffic inspection, as services cannot be inferred from transmission parameters alone.

These findings demonstrate the need for longitudinal, periodic scanning of satellite systems to maintain visibility into spectrum usage, service rotation, and emergent threats. A static snapshot of satellite spectrum is insufficient; instead, satellite security research requires a continuous and systematic monitoring paradigm.

DVB-S/S2(X)

The public standardized encodings for satellite data are DVB-S, DVB-S2, and DVB-S2X [14,19,22]. The physical-layer decoding for these standards is performed by our tuner card, yielding a raw bytestream. In some cases, there is additional framing that must be parsed in software. For the legacy DVB-S (Digital Video Broadcasting-Satellite) standard, no further processing is required. For the DVB-S2 (DVB-S Second Generation) and DVB-S2X (DVB-S2 Extension) standards, there is a framing-layer encoding which is not handled by our tuner card and must be processed in software. The process of decoding this framing layer is complicated by implementations that deviate from the published standard [22].

In both the standard and our empirical observations, DVB-S2(X) frames consist of a 10-byte Base-Band (BB) header followed by an arbitrary length data field, which together comprise a BB frame. The BB header format is a two-byte Mode Adaptation Type (MATYPE) field, a two-byte User Packet Length (UPL) field, a two-byte Data Field Length (DFL) field, three bytes related to synchronizing decoding of user packets, and a one-byte CRC-8 checksum over the first nine bytes of the header [19].

Because a raw capture may begin in the middle of a DVB-S2 frame, our parser must be able to distinguish the beginning of valid BB headers. The CRC-8 checksum of the first nine bytes helps eliminate many candidate headers, but the short checksum length leads to many false positives. We heuristically eliminate candidates by assuming the UPL and DPL length fields are multiples of 8 bits and 0 < DFL ≤ 58,112 bits, the maximum specified length of the data field [19]. Next, if a candidate BB header passes these checks, we expect that it is followed by DFL bits of data field, some padding, and the next BB header. If the next BB header passes the heuristic checks, we have probably identified a true BB header and continue parsing. If it does not, the header was a false positive; we discard bytes until we heuristically identify another candidate header.

This synchronization approach is fast and reliable. Since our parser discards bytes that do not pass the heuristic checks, we can use the rate of discarded bytes to identify which captures use DVB-S2(X) framing. If our parser discards more than 10% of the capture, that capture is either not DVB-S2(X) or there is too much transmission noise to decode properly. The remaining captures are classified as DVB-S2(X). Of the 346 captures we analyzed, we identified 290 as using DVB-S2(X) framing. Of these, the median rate of discarded bytes was 0.1% and the mean was 0.2%. [39] is designed to parse DVB-S2 satellite traffic for maritime applications. They observed that the MATYPE often had the value 0x4200, so their tool scans for this 16-bit value to find the beginning of DVB-S2 frames. They also observed that the value was occasionally 0x4300, although their code does not scan for it.

CRC-32.

Of the 296 captures with DVB-S2 as the first layer framing, 177 (61%) employ an additional CRC-32 checksum. This checksum is computed over the 80-bit header and the first DFL -32 bits of the data field, and it is located in the final 32 bits of the data field. We reverse engineered the CRC parameters and found that the CRC polynomial is 0x104c11db7 and the initial value is 0x00000000. These parameters are the same as the CRC-32 defined for GSE, except the initial value in that application is 0xffffffff [18]. When available, the presence of this checksum allows us to have even greater confidence that we correctly identify DVB-S2 frame boundaries and retrieve the correct data field contents.

Pavur et al. also observed this checksum, and their GSExtract tool assumes that the last four bytes of the DVB-S2 frame are always a CRC-32 [4], but it discards the value without validating it. This means that their parser may include corrupted bytes, which validating the checksum would have prevented, or excluded valid data bytes in the case where no CRC-32 checksum is present. SYNC Byte Discrepancy. For packetized transport or generic stream input, the SYNC field is meant to be a copy of the User Packet Sync Byte [19]. For MPEG-TS stream input encoded using DVB-S2(X), this value should be 0x47 [15]. In 27 (9%) of the transponders, despite using MPEG-TS user packets, the SYNC field was set to 0xBB. According to the standard, this value is reserved for "user private" signaling [19].

Byte Order Reversal. In some transponders, we observed a swapped byte order within 16-bit words in the data field. We manually identified such captures in order to further decode their data fields. We observe this byte order in 18 out of the 290 DVB-S2 captures (6%).

GSE

Generic Stream Encapsulation (GSE) is a common encapsulation protocol inside DVB-S2 captures [18]. Of the 290 captures with DVB-S2 as the first layer framing, 196 (68%) of them use some variant of GSE. However, these implementations of GSE all deviate from the published standard, complicating GSE parsing.

GSE encapsulates a series of variable-length packets, called protocol data units (PDUs), into a single stream of bytes [18]. GSE supports fragmentation, so a single PDU may be split across multiple GSE packets. Each GSE packet includes a 1-bit start indicator (set if the packet contents are the start of a PDU), a 1-bit end indicator (set if the contents are the end of a PDU), a 2-bit label type, and a 12-bit GSE length. When both the start and end indicators are set, the packet contains the entire PDU and no fragmentation occurred. If there is fragmentation, a 1-byte fragment identifier is used to aid in reassembling the PDU. GSE also includes a 2-byte protocol type for each PDU and a CRC-32 checksum for each fragmented PDU to validate that it was reassembled properly.

Although GSE is common among our DVB-S2 captures, we identify two major variants.

Standard GSE. Of the 290 DVB-S2 captures, 24 (8%) appear to closely follow the published GSE standard [18]. However, one important distinction is that the published CRC-32 parameters do not validate the defragmented PDUs. This meant we were unable to use the checksum to verify that defragmentation was successful, but we could still validate that the reassembled length matched the expected length and avoid improper defragmentation.

Non-standard GSE. Of the 290 DVB-S2 captures, 172 (59%) appear to follow a modified version of the standard which differs in several ways. First, the 12-bit length field includes the first two bytes when calculating the length, while the standard version excludes these, so all length values are off by two. Second, the fragment identifiers follow a different convention than in the standard. Instead of all 8 bits identifying the PDU, only the first 6 bits identify the PDU, and the final 2 bits are a counter representing that fragment's offset in the reassembled PDU. We call this 6/2 fragmentation. Third, GSE streams of this type include the optional DVB-S2 CRC-32 in Section 5.1, while standard GSE streams do not. Fourth, the GSE CRC-32 checksum used to validate reassembled PDUs uses the same parameters as the reverse engineered DVB-S2 CRC-32. This means that we can validate the checksum of non-standard fragmented GSE packets and are confident that our 6/2 fragmentation hypothesis is correct. Fifth, the two-byte protocol type field has a different meaning, which we discuss below. Finally, in 21 cases, it appears that several GSE PDU fragments are not received in the capture. We hypothesize this is due to channel bonding, and since our setup can only monitor a single transponder at a time, we discard any PDUs with missing fragments.

GSExtract [4] appears to decode this non-standard GSE scheme and fails to decode standard GSE. In particular, their code interprets the length field as off-by-2 and discards the last four bytes of DVB-S2 frames (although they do not validate this checksum value). It does not handle defragmentation properly, so the nonstandard 6/2 fragmentation ID, CRC parameters, or missing fragments are irrelevant to their approach.

Protocol type. Each PDU includes a two-byte protocol type. According to the standard, the protocol type either indicates the presence of optional headers as specified by the IANA registry [30] or an EtherType which indicates the type of the PDU (for example, IPv4 or IPv6) [18]. In the non-standard implementation, we observed protocol types between 0x0001 and 0x0008.

Although we do not fully understand what these protocol types mean, it appears that protocol 2 sometimes includes network traffic, protocols 1, 3, 4, 6, and 7 are too short or too repetitive to include interesting data, and protocols 5 and 8 are potentially encrypted.

Although we do not know for certain that these PDUs are encrypted, protocol 5 (and 8) PDUs include 1 predictable byte (17 respectively) followed by a multiple of 16 bytes of high-entropy data. Because these PDU lengths consistently differ by multiples of the AES block cipher size, it is unlikely that the high-entropy contents are simply compressed data. Since we are focused on interpreting network traffic, we focus on protocol type 2.

Unidentified and Proprietary Protocols

Although we successfully identified most of the encapsulation formats from our captured data, there were still a number of examples where we did not fully understand the protocol stack. This includes 13 (4%) of the 346 raw captures which were not identified as DVB-S2 or MPEG-TS, 67 (23%) of the 290 DVB-S2 captures which did not use GSE, and the format of the protocol 2 (network) PDUs in GSE. Some of this may be caused by noisy collection, but in many cases the unknown bytes reflect some as-yet unidentified protocol.

For some protocol layers, we were able to identify unencrypted IP traffic within the unidentified encapsulating protocol using heuristic assumptions. If the entire IP packet appears uninterrupted and unfragmented in the mystery stream, then finding a valid IP header will also recover the IP body of that packet; any bytes not belonging to IP packets are ignored. Although this blind IP header recovery could be applied to any byte stream, we parse MPE and GSE first, since both schemes support IP packet fragmentation [18,24] that would cause naive application of this approach to fail.

To detect IPv4 and IPv6 packets within a stream of bytes of unknown format, we progressively apply heuristic checks for IP headers. For IPv4, the header must have the correct four-bit version, a reasonable length, and a correct 16-bit checksum. IPv6 headers must have the correct four-bit version, a reasonable length, and a common public or private 16-bit IPv6 address prefix as either the source or destination.

False positives are possible with this approach, but for random data we expect it to be less than 0.001%. If there are errors, it is more likely to be because the IP packet bytes are not continuous. That is, we expect to correctly find almost all of the IP headers, and thus the correct number of IP packets, but there may be some errors when recovering the data. Based on our manual analysis of the resulting IP traffic, these errors appear to be uncommon. We ran the IP extractor on the 80 unidentified DVB-S2 and raw capture traffic, and although the bottom decile recognized less than 1.3% of the bytes as belonging to IP packets, the top decile recognized more than 57.2% of unidentified bytes as belonging to IP packets.

We note that GSExtract also extracts IP packets without understanding all surrounding bytes, but it just assumes the IP packet begins at a fixed offset rather than scanning for headers.

Encrypted and Unencrypted Traffic

After obtaining the raw satellite byte streams, we applied our multistage process to determine if and where encryption was present in the protocol stack. Our custom parser attempted to reconstruct protocol headers from the lowest possible layer upward, identifying the highest unencrypted layer for each capture (Figure 6).

When traffic was unencrypted above the IP layer, the parser successfully reconstructed complete IP packets, which we exported as PCAP files for manual inspection in Wireshark. In such cases, transport-and application-layer protocols (e.g., HTTP, SIP, DNS) were visible in plaintext. Conversely, when network-layer encryption was present, only IPsec or TLS headers were recoverable. Manual PCAP analysis was feasible for our dataset size, though the triage process could be automated for larger collections.

For encryption or obfuscation below the IP layer-such as RF scrambling or link-layer compression-we examined protocol flags, payload lengths, and any recoverable fragments of valid IP packets. In partially recoverable cases, we used a custom IP extraction script to reconstruct identifiable headers. In addition, we applied standard tools such as Binwalk to estimate payload entropy and locate unencrypted regions within the raw captures. These steps, combined with iterative reverse engineering of encapsulation layers, allowed us to identify and characterize unencrypted traffic in mixed or proprietary link-layer environments.

Cellular Network Backhaul

In cellular networks, satellite backhaul is common to connect remote cell towers to the core network, transmitting control plane and user data traffic like voice calls, SMS, and Internet traffic [51].

We observed unencrypted cellular backhaul traffic from multiple telecommunications providers with multiple tower connections per provider. Since the relevant protocols are rarely discussed in public security research, we first provide a primer on what each of these protocols does in a cellular network.

Cellular backhaul takes place over the IPv4-based GPRS Tunneling Protocol (GTP), which is commonly used to transport control and user traffic between cell towers over private network links back to the core network (e.g., PGW, SGW, or UPF in 5G) [52].

The traffic we found flowing unencrypted over these links included the following cellular-specific control and data traffic: IP Multimedia System (IMS) is a standardized framework for VoIPbased communications over cellular networks that was introduced in 4G. IMS system traffic includes control plane messages to register phone numbers with the system, and set up/tear down calls, and user data such as VoIP voice calls, GMS SMS messages, and MMS and RCS messages which include photos and videos. IMS relies on SIP (Session Initiation Protocol) for signaling and enabling communication between devices and IMS core network elements. Call audio data is transmitted via RTP (Real-time Transport Protocol). S1-U tunnels raw user Internet data over private networks between a cell tower and the cellular core network. This traffic includes common protocols like DNS, UDP, QUIC, and TLS. S1-C carries control plane traffic with signaling protocols between cell towers (i.e., eNodeBs in the Radio Access Network) and the core network (e.g., the MME). All S1-C traffic is generally carried over SCTP (Stream Control Transmission Protocol) that ensures reliable in-order delivery. Specific S1-C protocols include: S1 Application Protocol (S1AP) is a signaling protocol in 4G networks that facilitates communication between the eNodeB (base station) and the MME (Mobility Management Entity). S1AP messages perform functions such as establishing context about cell phones, reporting protocol errors, paging, carrying encrypted NAS signaling, and releasing UE context from the network. EUTRAN X2 Application Protocol (X2AP) facilitates communication in 4G between eNodeBs, enabling inter-cell coordination, handovers, and mobility management. X2AP messages can update eNodeB configurations, report radio link failures, and acknowledge handover requests.

UTRAN Iub Interface NBAP Signaling (NBAP) is used in 3G to communicate between the NodeB (base station) and the Radio Network Controller (RNC) over the Iub interface. NBAP messages perform functions such as managing radio link removal, reconfiguration, power control, and various radio link measurements. We identified three satellite beams carrying unencrypted T-Mobile traffic, with footprints spanning part of North America. All three transponders use a protocol stack consisting of DVB-S2 at the physical layer, followed by a proprietary encapsulation layer, an IP layer, and a GTP tunnel layer.

The observed network links, unencrypted S1-U/C links, transmitted customer data, including Internet traffic and IMS services such as voice and SMS. The unencrypted traffic included unprotected IMS signaling as well as metadata and content of real user SMS messages, call metadata, browsing history, and unencrypted RTP voice streams. The IMS traffic did have an IPsec layer, but it used a null cipher for encryption. Figure 8 illustrates an anonymized packet we extracted whose SIP MESSAGE method contains a 3GPP 7-bit encoded GSM SMS payload in plaintext, which is impossible to decode without correct parsing on all upper layer protocols.

From a 9-hour recording, we observed 2,711 users' phone numbers from metadata associated with voice calls and messages. We identified the traffic as belonging to T-Mobile based on the MCC & MNC code of users.

The S1-C control traffic we observed over the SCTP (port 36422) was the S1AP protocol. 6.1.2 AT&T Mexico Cellular Backhaul. We observed unencrypted cellular backhaul traffic that included protocol metadata and cellular network signaling protocols, and raw user Internet traffic. For this transponder, we did not observe any unencrypted call or SMS contents, nor any IPsec tunnels that might contain this data.

Our analysis identified one satellite beam carrying unencrypted AT&T Mexico traffic, which could be received in much of North America. The transponder uses DVB-S2X, with byte-reversed encapsulation of IP packets. The traffic was IP packets with no encryption and no IPsec tunnel.

The unencrypted S1-U/C link exposes control and user plane traffic, revealing core network signaling, authentication data, VoLTE/VoIP signaling, and Internet traffic.

The S1-C signaling traffic we observed included UTRAN Iub Interface NBAP signaling, S1AP, and X2AP. This unencrypted SCTP traffic exposes sensitive information, including secret security keys (KeNB), network identity details (e.g., IMSI, PLMN, eNodeB CellID) session identifiers, (e.g., MME-UE-S1AP-ID, eNB-UE-S1AP-ID) and UE security capabilities, posing significant security risks.

The end-user Internet data we observed was standard S1-U IPbased communication, including HTTP, SSL, TCP, ESP, UDP, QUIC, and TLS packets. Many outer IP source addresses correspond to AT&T domains. Additionally, within these GTP tunnels, we identified inner source IP addresses from major Internet companies, including Facebook, Google, etc.

In a 30-minute recording, we observed 710 users' phone numbers and related control and Internet traffic. We identified the tower as belonging to AT&T based on its MCC & MNC codes.

6.2 VoIP Over Satellite 6.2.1 TelMex VoIP on Satellite Backhaul. We observed unencrypted satellite backhaul traffic that included the plaintext contents of user voice calls, and protocol metadata and cellular signaling protocols.

Our analysis identified three satellite beams carrying unencrypted TelMex VoIP traffic, whose satellite footprints cover part of North America. These transponders follow two distinct protocol stacks: one uses DVB-S2 with a proprietary protocol encapsulating IP, while the other two use a standard DVB-S2 with GSE (with 6/2 fragmentation) protocol to encapsulate IP. There was no IPsec tunnel present; data was sent in plain IP packets.

Our analysis confirmed the presence of unencrypted SIP signaling and RTP voice data. SIP signaling data was transmitted in clear text, revealing metadata that included caller/callee identities (phone numbers), SIP server and domain, call session metadata (Call-ID, CSeq numbers), SDP details (e.g., RTP ports, codec ITU-T G.729), and access network identifiers (e.g., IEEE-802.11 WiFi location data).

The captured data includes source IPs linked to TelMex's network, unencrypted RTP sessions corresponding to different calls, and compressed voice packets (ITU-T G.729 codec) We observed 142 voice conversationsfrom a 2-minute, 167 MB, capture.

KPU Telecommunications. KPU Telecommunications is an

Alaskan telecom. We observed unencrypted satellite backhaul traffic carrying plaintext SIP signaling for some endpoints in their VoIP system. This traffic was being carried over a satellite link used by a customer of KPU. This satellite link was a secondary link enabled only while the main link was down. The link operated over a DVB-S2 physical layer, with an unidentified intermediate encapsulation preceding the IP layer. KPU traced the issue to a VPN that unexpectedly terminated at the satellite modem.

6.2.3 WiBo Satellite Links. We identified unencrypted satellite traffic associated with WiBo, the registered brand of Starsatel S.A. de C.V., a Mexican telecommunications provider offering broadband satellite and IP telephony services to remote and rural areas. The observed links used a standard DVB-S2 physical layer with GSE encapsulation (6/2 fragmentation) to carry IP traffic.

Our analysis revealed clear-text SIP signaling and RTP voice traffic within WiBo's network, exposing sensitive user metadata and audio content. SIP packets (e.g., INVITE, ACK, BYE) were transmitted over without encryption, and contained SDP fields revealing caller/callee phone numbers, IP addresses, negotiated codecs, and RTP port assignments. RTP streams carrying G.729 and G.711 audio were also unencrypted, enabling full reconstruction of call audio. While many calls used private-address source and destination IPs indicating internal VoIP traffic, some were routed to public IPs registered to WiBo.

We also observed large volumes of plaintext DNS traffic. DNS responses were sent to IPs owned by WiBo, likely acting as client resolvers. The data also contained upstream queries to public resolvers, such as Google Public DNS (8.8.8.8). DNS queries suggested typical activity from mobile devices, resolving domains like Apple iCloud, Android OS services, TikTok, and Samsung's app store.

Government and Military

We observed unencrypted satellite traffic belonging to government and military for multiple countries.

6.3.1 US Military. We observed both unencrypted (DNS, ICMP, SIP, SNMP) and encrypted (IPSec and TLSv1.2) traffic from sea vessels owned by the US military. One transponder encapsulates IP packets with GSE with the 6/2 fragmentation quirk, and the other has an unknown layer before the IP header. We were able to identify names of the vessels from addresses in the plaintext SIP packets. By investigating the names, we determined they were all formerly privately-owned ships that were now owned by the US.

6.3.2 Mexico Government and Military. We observed unencrypted satellite traffic from multiple organizations within the Mexican including military, law enforcement, and government agencies. These unencrypted links appear to be used to connect remote command centers, surveillance outposts, and mobile units via commercial satellite backhaul.

The two transponders use unencrypted DVB-S2 at the physical layer. One followed this with GSE encapsulation with the 6/2 fragmentation implementation quirk, followed by unencrypted IP. For the other transponder, it has byte-reversed word encoding of an unknown header followed by an IP header (Section 5).

The traffic that we observed includes DNS requests for hostnames and TLS certificates with Distinguished Name (DN) attributes for a variety of internal and external government hostnames and infrastructure. Among the traffic payloads, we observed large amounts of unencrypted HTTP traffic containing JSON and HTML formatted web application responses from internal systems used for infrastructure, logistics, and administrative management, including:

• References to military terminals, regions, and zones.

• Law enforcement asset inventory, personnel records, and traffic monitoring. • Incident reporting, case tracking, and evidence documentation by field personnel and administrative staff, including narcotics activity and public gatherings. • Military asset tracking records for aircraft, sea vessels, armored vehicles, and LIDAR and RADAR. This data included locations, deployments, mission roles, and maintenance logs. • Real-time military object telemetry with precise geolocation, identifiers, and live telemetry.

Corporations

6.4.1 Walmart-Mexico Internal Network Traffic. Walmart is a multinational retail company, with thousands of stores in dozens of countries. An internal inventory management tool allows stock tracking, price updates, and store operation management via real-time data synchronization across store locations, distribution centers, and Walmart's central database.

We identified three satellite beams carrying unencrypted Walmart-Mexico internal system traffic that could be received across North America. Among the three transponders, two use DVB-S2 followed by GSE encapsulation with 6/2 fragmentation carrying IP traffic, while the third uses DVB-S2 followed by byte-reversed encapsulation with an unknown header before an IP header.

Notable internal network traffic includes:

• Logins via unencrypted telnet to their inventory management system, including plaintext credentials, terminal UI text, and invoice summaries. • Inventory records transferred and updated via unencrypted FTP, including UPC and SKU numbers, retail/wholesale/cost numbers, store layouts, and sales data. • Unencrypted internal corporate emails.

• Unencrypted NetBIOS internal computing equipment usage notices, indicating employee activity monitoring.

6.4.2 Grupo Santander Mexico. Grupo Santander is a major multinational financial institution. We identified unencrypted traffic from internal Grupo Santander Mexico networks being transmitted on a satellite transponder using DVB-S2 followed by GSE encapsulation with 6/2 fragmentation carrying IP traffic. The traffic suggests that Grupo Santander Mexico relies on satellite to support connectivity for remote branches, ATMs, and internal infrastructure. The resolved packets' IPs fall within TelMex-assigned blocks. This suggests that traffic is routed over commercial ISP networks before reaching satellite uplinks. We observed traffic including

• TLS and IPsec traffic with certificates with DNs, internal CRLs, and OCSP URLs for internal network PKI. • DNS responses for internal ATM-related domain names.

• Unencrypted LDAP traffic including a segregated AD domain hierarchy dedicated to ATM infrastructure.

6.4.3 Banjército and Banorte. Banjército is a bank affiliated with the Mexican military, and Banorte is a large commercial bank. We identified extensive unencrypted satellite traffic linked to the internal infrastructure of both banks being transmitted on a satellite transponder using DVB-S2 followed by GSE encapsulation with 6/2 fragmentation carrying IP traffic. The destination IP ranges were inside of the internal/private address range used by Banjército. Plaintext traffic included DNS responses for domains tied to financial operations, ATMs and POS terminals, and CLDAP and LDAP authentication.

In-Flight WiFi

One of the common consumer applications of GEO satellite is providing airline passengers and crew with internet access (in-flight WiFi). Unencrypted in-flight WiFi traffic was previously observed in satellite transmissions by Baselt et al. [28], but our IP header parsing gives us deeper insights into the magnitude of this problem.

Among our captures, 40 included the string "inflight" in unencrypted data. 35 of these used DVB-S2 as the first layer, and 2 of these 35 included MPEG-TS as the second layer. 30 of the 35 include IP, 2 involve GSE, and 2 use the byte order reversal discussed in Section 5.1. We were able to associate DNS lookups and hostnames with two in-flight WiFi and entertainment providers, Gogo Inc and Panasonic. Unencrypted metadata from these captures included references to flights on at least ten different airlines.

The data included hostnames for the domains used by captive portals that users are redirected to, hostnames and accesses for flight information used by pilots, as well as DNS lookups, HTTPS and QUIC traffic, and IPsec and Wireguard traffic to and from domains that would be expected from normal end-user consumers. According to our conversations with Panasonic, they told us they rely on the ubiquity of TLS to secure end user applications.

For one in-flight transponder, roughly 40% of the IP packets included RTP traffic containing MPEG audio/video streams. Although the video streams were scrambled, the audio was not, and the audio appeared to belong to news programs, sports games, and more. We suspect that these packets are used to transmit live television to in-flight entertainment seatback systems. Roughly 60% of the IP packets include a proprietary protocol. We reverse engineered this protocol, and it appears to be a system which compresses TCP and UDP traffic to reduce bandwidth. This is consistent with a system which encapsulates passenger traffic, and understanding the proprietary protocol allows us to observe passenger traffic.

We also observe a handful of IP packets which include a partial PEM-encoded RSA private key. Although this exact same partial private key was previously documented by Pavur [28], our system gives us deeper insight into its provenance. Pavur observed the partial key by extracting strings from the raw satellite capture, and he concluded that the remaining bytes were lost due to connection quality issues, positing that a more reliable setup could recover the remaining bytes. With our improved parsing, we conclude that this is not the case. We reliably recover IP packets from this transponder with negligible error rate, indicating that signal quality is not an issue. The partial private key appears in UDP packets transmitted by a specific host IP on a specific port; these UDP packets also contain partial SQL statements and log strings.

Instead of attributing the partial key exposure to poor signal quality, we believe it is more likely that a specific device on the private network used for in-flight Wi-Fi has a bug that leads to the device leaking internal memory to the network. Because of our improved parsing, we are confident that improving the collection will not reveal more bytes of the private key. More advanced cryptanalytic techniques are required to recover the private key. We developed these advanced cryptanalytic methods and successfully recover the full private keys used by this device. We detail our methods in Appendix B.

6.6 Utilities and Infrastructure 6.6.1 Comisión Federal de Electricidad . The Comisión Federal de Electricidad (CFE) is a large electric utility in Mexico with 90,000 workers and 46 million customers. We observed one transponder carrying unencrypted CFE internal communications, whose footprint spans large portions of North America. The transponder uses DVB-S2 followed by GSE encapsulation with 6/2 fragmentation carrying IP traffic. Unencrypted internal traffic included:

• DNS responses for internal domains to and from private IPs.

• Structured JSON responses for customer service and maintenance work orders with locations, urgency levels, and customer names, addresses, account numbers, and tariff types. • Labeled identifiers for power grid provisioning to military zones and government buildings. • Internal reporting and configuration web forms listing administration and substation infrastructure. • Internal maintenance systems for infrastructure failures and asset status, such as mechanical failures and safety hazards.

6.6.2 Other Industrial Applications. Pending ongoing disclosure, a future version of this document will contain further details on other unencrypted infrastructure and industrial data we observed, including utilities, maritime vessels, and offshore oil and gas platforms.

Discussion and Conclusions

Updating Threat Models. There is a clear mismatch between how satellite customers expect data to be secured and how it is secured in practice; the severity of the vulnerabilities we discovered has certainly revised our own threat models for communications. Cell phone traffic is carefully encrypted at the radio layer between phone and tower to protect it against local eavesdroppers; it is shocking to discover that these private conversations were then broadcast to large portions of the continent, and that these security issues were not limited to isolated mistakes. Similarly, there has been a concerted effort over the past decade or two to encrypt web traffic because of widespread concern about government eavesdropping through tapping fiber-optic cables or placing equipment in Internet exchange points; it is also shocking to discover that this traffic may simply be broadcast to a continent-sized satellite footprint.

Impediments to Encryption. The unencrypted traffic we observed results from a failure to encrypt at multiple levels of the satellite network protocol stack. At the satellite link/transport layer, streams using MPEG encoding have the option to use MPEG scrambling; 2/3 of the TV transponders we observed enabled this but only 10% of the non-TV transponders did. Only 20% of satellite transponders using GSE had encryption enabled. At the network layer, organizations can use IPsec to protect their traffic, but only 6% of the hundreds of transponders from which we recovered IP packets consistently encapsulated further layers using IPsec.

And finally, at the application layer, services can encrypt using TLS; remarkably, nearly all the end-user consumer Internet browsing and app traffic we observed used TLS or QUIC, while we observed extensive unencrypted internal traffic for critical infrastructure being broadcast via satellite.

There are a number of factors contributing to this state of affairs.

Network Visibility. The increased deployment of TLS for web traffic is the outcome of a concerted effort by browser vendors and privacy organizations to make HTTPS the default; TLS is wellstudied by academics and the open web is the subject of a constant stream of academic measurement papers stretching back decades.

In contrast, the academic literature on satellite communication security and the security practices of internal networks is relatively scarce. Our work gives us a rare window into the security practices of these internal networks, which appear to be largely open.

Organizations that do have visibility into these networks have been raising alarms for some time. A 2021 US Executive Order [27] and a follow-up memo [62] mandate moving US government infrastructure to a "zero-trust" architecture, which includes encrypting data on all internal networks. A 2022 NSA security advisory about GEO satellite links states: "Most of these links are unencrypted, relying on frequency separation or predictable frequency hopping rather than encryption to separate communications" [49].

Abstraction. Satellite network connectivity may be provided via several layers of service providers; the network providers we spoke to told us that typically customers choose whether to enable encryption, but there may be multiple layers of customer relationships. From our conversations with vendors, no auditing tools exist that allow vendors to audit the security of their own satellite backhaul. Our work has identified multiple unintentional misconfigurations among organizations who had intended to enable encryption.

Economic incentives. We can observe from the popularity of encrypted satellite TV feeds that network operators will, in fact, encrypt streams when there is a clear economic incentive to do so [11,54]. However, it appears that the incentives are aligned in the opposite direction for network traffic: enabling link-layer encryption can require additional license fees to use the crypto subsystem for specific satellite terminals and hubs [21,35].

Efficiency. Enabling encryption can impact efficiency by incurring additional bandwidth overhead costs and also by requiring increased power consumption for limited-resource off-grid terminals relying on solar power. Panasonic told us that enabling encryption could incur a 20-30% capacity loss. In addition, when using IPsec, ESP and IP headers can introduce 20-30 bytes of overhead, which is nontrivial for small-packet applications like VoIP and video calls.

Reliability. For some of the traffic we observed, such as VoIP for emergency services, the lack of encryption is an intentional choice to maximize service reliability. LEO satellite networks are becoming increasingly popular, but may not provide 100% reliability; in contrast, users who are optimizing for maximal reliability may choose unencrypted GEO connections.

Usability. Usability has been a well-known impediment to cryptographic deployments for decades. The systems we observed where encryption had been inadvertently disabled by misconfigurations or software updates had "failed open" in that the network continued to function correctly with no apparent indication to the operators that no encryption was present. Modern public-key infrastructure still requires significant overhead to deploy and maintain up-todate certificates on terminals and ground stations [33,43]. Network providers also described to us how enabling encryption made it impossible to troubleshoot network issues.

Export controls. The documentation and marketing materials for the satellite terminals that we examined included artifacts of US export controls on cryptography, such as listing optional 56-bit key strengths [65]. Export controls have historically resulted in protocols and products being developed with encryption as a separate add-on so that vendors could comply with these regulations. Future Work. We hope that our study inspires future work providing further visibility into satellite communciations as a critical component of our network infrastructure. Clear future directions include scanning other frequency bands such as Ka and C, developing methodologies for different orbits, and refining our parsing stack to account for further proprietary protocols. Further future work could also include reverse-engineering satellite receivers to understand protocol aspects that are not evident in our passive black-box setting. and coding schemes (e.g., 8 Phase Shift Keying (8PSK) or 16 Phase Shift Keying (16APSK)) enable higher spectral efficiency-measured in bits per second per Hz-making wideband transponders essential for delivering high-capacity services such as trunked backhaul, IP-based content delivery, and satellite internet access.

Figure 10 shows the distribution of detected transponder bandwidths. While sub-5 MHz channels are the most common (131 transponders, 34.8%), transponders span a wide range of bandwidth classes. Notably, 73 transponders (19.4%) have bandwidths ≥ 30 MHz, sufficient to support data rates exceeding 100 Mbps under 8PSK modulation.

B Key Recovery

As described in Section 6.5, in the course of our study we observed partial PEM-encoded RSA private keys. To fully understand the severity of this partial exposure, we wanted to determine whether or not enough bytes were leaked to lead to complete compromise of the private key. Although existing cryptanalytic approaches are insufficient to accomplish this, we develop new methods to recover private keys from this amount of private exposure. PEM encoding is a commonly used format for representing cryptographic keys. For a RSA private key represented using ASN.1, integers in the private key are first encoded as big-endian byte arrays, the full DER-encoded byte array is Base64-encoded as printable text, and a "BEGIN RSA PRIVATE KEY" header and corresponding footer are added. Our observations included the suffixes of two PEM-encoded RSA private keys.

In particular, we observed the final 472 and 474 bytes of these encoded keys. Based on the standard order that private key values appear in, Base64-decoding and DER-decoding the partial PEM keys reveal the following values, corresponding to a 2048-bit RSA modulus 𝑛 with prime factors 𝑝 and 𝑞, public exponent 𝑒, and private exponent 𝑑:

• 512 least significant bits of 𝑑 𝑝 = 𝑑 (mod 𝑝 -1)

• all 1024 bits of 𝑑 𝑞 = 𝑑 (mod 𝑞 -1)

• all 1024 bits of 𝑞 inv = 𝑞 -1 (mod 𝑝). Notably, this does not include the public modulus 𝑛 = 𝑝𝑞. Although the public exponent 𝑒 is also missing, it is extremely common in practice that 𝑒 = 65537, so we assume this is the correct value for the remainder of our recovery algorithm.

Heninger and Shacham [31] document how knowledge of (𝑛, 𝑒, 𝑑 𝑞 ) or (𝑛, 𝑞 inv ) reveal all private key values, but because the attacker in our example does not know 𝑛, those attacks do not apply. We are unaware of any other prior work that demonstrates key recovery from (LSB(𝑑 𝑝 ), 𝑑 𝑞 , 𝑞 inv ), so we develop our own. First, the modular equation 𝑒𝑑 𝑞 ≡ 1 (mod 𝑞 -1) implies the existence of 𝑘 𝑞 such that 1 ≤ 𝑘 𝑞 ≤ 𝑒 and 𝑒𝑑 𝑞 -1 = 𝑘 𝑞 (𝑞 -1). Because there are only 2 16 possible values for 𝑘 𝑞 , we try each value until we find a candidate where 𝑞 = (𝑒𝑑 𝑞 -1)/𝑘 𝑞 + 1 is both integer and prime. Typically this is sufficient to uniquely recover 𝑞.

Next, we attempt to recover 𝑝. We will ultimately use Coppersmith's method [46] to find a small solution to a linear equation modulo a divisor of a known integer, but for this to work, we need to first find a bounded multiple of 𝑝. Note that since 𝑞𝑞 inv ≡ 1 (mod 𝑝), then 𝑞𝑞 inv -1 is a multiple of 𝑝, but this 2048-bit value is too large for Coppersmith's method to efficiently succeed. We apply the elliptic curve factorization method to 𝑞𝑞 inv -1 to find and divide out small prime factors from this integer. The running time of this method depends on the size of the smallest factor, so with high probability we are left with a number of small prime factors and a large composite divisor 𝑚 of 𝑞𝑞 inv -1. This divisor is a bounded multiple of 𝑝. In an example run, the multiple 𝑚 of 𝑝 was around 1900 bits, which is small enough for Coppersmith's method to be efficient.

Finally, we use Coppersmith's method to recover 𝑝. We write 𝑑 𝑝 = 𝑑 𝑝,msb 2 𝑡 + 𝑑 𝑝,lsb where 𝑑 𝑝,msb is unknown and 𝑑 𝑝,lsb is known. As before, there exists 𝑘 𝑝 such that 1 ≤ 𝑘 𝑝 ≤ 𝑒 and 𝑒𝑑 𝑝 -1 = 𝑘 𝑝 (𝑝-1). We rewrite this as 𝑒 (2 𝑡 𝑑 𝑝,msb + 𝑑 𝑝,lsb ) -1 + 𝑘 𝑝 ≡ 0 (mod 𝑝). We try all 2 16 possible values for 𝑘 𝑝 , and each guess gives us a linear equation modulo a divisor of 𝑚 with a single 512-bit unknown 𝑑 𝑝,msb . We use Coppersmith's method with a dimension-30 lattice to attempt to solve this equation; if the guess of 𝑘 𝑝 is correct, then Coppersmith's method recovers 𝑑 𝑝 and 𝑝, completing recovery of the RSA private key. This final step is the most expensive part of our attack since it requires 2 16 invocations of Coppersmith's method. However, thanks to our use of factorization to reduce the size of 𝑚, the required dimension of the lattice is quite reasonable, and the overall running time is not prohibitively expensive. This demonstrates that although only parts of the PEM-encoded private keys were exposed in the satellite traffic, enough bytes leaked to enable full recovery. We do not have enough information to know exactly what role these keys have in the in-flight infrastructure, but this cryptanalysis demonstrates that these private keys should be considered to be fully compromised.

C Ku-band GEO satellite stablity analysis

To provide a clear view of transponder activity dynamics, we include a summary table of changes (Table 5) of all detected transponders across two scanning periods: August 2024 and February 2025. In this version of the full document, we are omitting the full list of satellite names and transponder metadata out of an abundance of caution and to prevent easy targeting of sensitive systems while disclosure is ongoing.

The results highlight the dynamic nature of GEO Ku-band transponder usage across different longitudes. While some satellites maintain stable configurations with no observable changes (e.g., 95.0°W, 78.8°W, and 77.0°W), others exhibit significant churn. For example, satellites at 129.0°W and 105.0°W experienced notable turnover, with 8 and 10 transponders disappearing respectively, alongside several newly activated channels. This suggests that some operators dynamically lease transponder capacity for time-bounded services, periodically adjusting activation based on contractual agreements, shifting user demand, or regional service needs.

These findings underscore the heterogeneous and commerciallydriven nature of satellite communications. Transponder availability is not solely a function of hardware capability, but also of operational policy, market fluctuation, and service allocation strategy. The coexistence of both stable and dynamic configurations highlights the value of continuous, longitudinal scanning to understand the evolving landscape of satellite transponder deployment.