Finding the Fleet: What SNMP Finds in the Satellite Ground Segment that HTTP Misses

By Adrian Cheek, Senior Cybercrime Researcher

Ask an internet-wide scanning index how many satellite mission-control systems are exposed and you can get the answer 1,776. All but 18 of those results turn out to be the same static web page, replicated across cloud edge nodes in every region on earth.

The productive question asks which devices report the vendor’s string in their own SNMP system description, whereas the web query asks which pages carry that string in their title. That question returns 437. Every one of those is a distinct address, on a distinct national telecom network, reporting a distinct serial number, answering on the port assigned to the management protocol.

Same infrastructure, same vendors, same collection day, yet the difference is roughly three orders of magnitude, and nothing about the first number looks wrong on its face.

Passive measurement has become the default way to estimate how much satellite infrastructure is exposed on the internet. Most of it is done over HTTP. An analyst queries a vendor name, counts the results, and publishes the number. This article shows that the method, applied without validation, surfaces mostly the wrong things, and sets out what a validated approach finds instead.

Queried over HTTP, satellite vendor names predominantly return marketing sites, cloud-hosted demonstrations, and replicated web assets rather than deployed equipment. These are counted in the thousands. Queried over SNMP, the same infrastructure returns a very different picture: 437 Hughes VSAT terminals on national telecom networks across 15 countries, a small number of carrier modems, and several network management servers running operating systems that stopped receiving security updates between five and eight years ago. This last item is the one that should concern this community most.

The gap between those two pictures is the point of the article. It is a predictable consequence of how modern infrastructure is hosted, not sampling noise. The practical lesson for anyone who consumes exposure reports is that a passive-discovery result is a hypothesis, not yet a count. The sections below give four checks that separate the real fleet from the noise. Satellite systems serve as the worked example because they contain one population that fails every check and one that passes all four.

Key Findings About the Satellite Ground and User Segment

• A passive discovery result is a hypothesis, not a count. Over 11 HTTP queries, more than 5,000 returned records yielded nine genuine devices. One satellite mission-control product returned 1,776 results by page title, of which all but 18 shared a single identical response body served from cloud object storage. The count was inflated by nearly three orders of magnitude, and every unit was misclassified.
• SNMP surfaces deployed equipment where HTTP surfaces web assets. A confirmed-banner anchor returned 437 Hughes multimedia VSAT terminals, each on a distinct address, across 13 networks, 28 organizations, and 15 countries in West Africa, the Middle East, South Asia, and Latin America. No hyperscale cloud appears anywhere in the set.
• Observed exposure concentrates in the user segment rather than the carrier segment, an asymmetry that holds at two orders of magnitude. Carrier trunking modems return single-digit counts worldwide, because they live in teleports behind management networks.
• Five satellite network management servers are passively discoverable on end-of-life operating systems. Two run an enterprise Linux release that lost support in March 2017; three run the following major release, unsupported since November 2020. In the most significant known attack on a satellite system, the attacker had to exploit a misconfigured VPN appliance to reach this same architectural layer, from which fleet-wide management commands could be issued. These servers answer on the public internet.
• Queries cannot be built from vendor documentation. Each of five vendors places its identifying information in a different SNMP field, and no convention is predictable from a spec sheet. Anchors built from documentation failed repeatedly, and several failed silently, returning zero results in a way indistinguishable from genuine absence. Every anchor that worked was taken from a confirmed banner on a known instance, which is why the provenance of an anchor carries more weight than the precision of the query built on it.

Discovery Does Not Equal Counting

The core mistake in most passive exposure work is treating a returned banner as a device. A banner is only a claim that something at an address responded to a probe with text matching a query. Whether that text represents a deployed piece of equipment is a separate question, and it has to be asked separately.

The work therefore has two stages: discovery generates candidates, and validation decides which candidates are real. When the second stage is skipped, the count inherits every artifact the internet’s hosting layer produces, including replicated assets, cloud demos, laboratory instances, and honeypots. The resulting number can be wrong by three orders of magnitude, and nothing about it looks wrong on its face.

Four Questions that Separate Signal from Noise

These are evidence-quality checks. They are not specific to satellite systems. Each one asks whether a result deserves to be believed, and each applies to any passive measurement, including industrial control, medical devices, and enterprise appliances. That is why the framework outlives the case study.

• Replication: Is the same content repeated across many addresses? Count the distinct response bodies. Where one body dominates the result set, the finding represents a single artifact served from many places. It does not represent many deployments.
• Identity variance: Is the field that should be unique actually unique? A hardcoded product string will be identical across a fleet, which is expected. A per-device serial will not. Where the identity field fails to vary with the count, the count is inflated.
• Network context: Does the hosting make sense? Deployed field equipment sits on operator and enterprise networks. A satellite modem answering from a hyperscale cloud region is a demonstration, a laboratory, or a honeypot. It is not a modem in the field.
• Service plausibility: Does the service context make sense? Equipment answers on its own service ports. A vendor interface responding on a port conventionally assigned to an unrelated service is a virtual machine in costume.

A fifth question underlies all four, and it is the one that most often goes unasked: where did the anchor come from? A query built from a vendor spec sheet is a guess about what the banner will say. A query built from an observed instance is evidence. Guessing from documentation failed repeatedly in this work, and it failed silently, returning nothing in a way that cannot be distinguished from genuine absence.

What SNMP Reveals

SNMP is a management protocol. Where it is reachable, it returns a device’s own description of itself: a system-description string, a system name, a contact, and a location. For network equipment, these fields are more reliable than an HTTP page, because they are set by the device firmware and not by whatever web content happens to sit at the same address.

NSA guidance recommends disabling SNMP v1 and v2 because they leak this information. That leakage is what makes a genuine fleet measurable.

437 Terminals, and the Basis for the Number

A confirmed anchor, taken from the system-description string that a known Hughes multimedia VSAT terminal reports, returns 437 records. Every one is on port 161, and every one is a distinct address. Three independent anchors converge on exactly the same 437: the description string, a system-contact filter, and a bare match on the same text. Convergence at a precise number is the first good sign, because it indicates that the anchor is tight around a population that genuinely exists.

The four checks then apply as follows:

• Replication: All 437 report the identical description, “Hughes Network Systems Multimedia VSAT.” This is expected behavior for a hardcoded product string and is not a concern.
• Identity variance: The system-name field holds 437 distinct values across 437 records, one serial or site identifier per device. The field that should vary does vary. This is the strongest available evidence that these are individual physical units.
• Network context: The addresses resolve to national and regional telecom operators across West Africa, the Middle East, South Asia, and Latin America: 13 networks, 28 organizations, and 15 countries. No hyperscale cloud appears anywhere in the set.
• Service plausibility: All answer on 161, the SNMP service port, and many also answer on web-management ports. This is consistent with deployed remote terminals.

The population passes every check, and it passes each one in the correct direction. It is uniform where uniformity is expected and varied where variety is expected. That directional consistency is what distinguishes a real fleet from a replicated artifact. Roughly half the fleet, 222 of 437, answers over SNMP v2 against explicit guidance to disable it, which is itself an exposure finding. One further detail is quietly telling. Every terminal reports the factory-default location string unchanged. Guidance advises against descriptive device naming precisely to frustrate identification, and here the vendor default has become the identifier.

The Finding that Matters to this Community

The same SNMP approach, applied across carrier vendors, returns almost nothing. Single-digit counts of trunking modems appear worldwide. These counts should be read as a lower bound with unknown recall, since the carrier anchors are weaker than the Hughes anchor. The architectural explanation is straightforward: carrier modems sit in teleports, behind management networks, away from the open internet.

Exposure is concentrated in the consumer and enterprise user segment. That inverts where the sector tends to direct its concern, and it independently confirms a point the academic literature has already made, that the user segment is the under-examined part of the ground picture.

The carrier ground segment is not clean, because the modems were never the interesting target. Five network management servers are passively discoverable. Management servers are the control plane, the systems that operate remote terminals across an entire satellite network. Their operating systems, read directly from their own description strings, break down as follows.

• Two run an enterprise Linux release whose kernel was built in 2013. That release reached end-of-life in March 2017, roughly eight years without security updates.
• Three run the following major release, with kernels dated 2016 to 2019. That release reached end-of-life in November 2020, roughly five years without security updates.

The management layer is the same architectural component that public analysis identifies as the suspected entry point for the most significant known attack on a satellite system. Finding it exposed, on operating systems abandoned half a decade ago, is the most actionable item in this study.

The finding must be stated at its true weight. This is five machines, not a population. The defensible claim is that a small number of management servers are passively discoverable on end-of-life operating systems. Five is enough to matter to the operators concerned and enough to justify a look by everyone else. It is not a census.

Five Vendors, Five Conventions

Each vendor places its identifying information in a different field, and none of it can be predicted from product documentation. This is the part of SNMP-based detection most easily gotten wrong.

The reusable rule follows directly. Satellite discovery queries cannot be built from vendor documentation. They must be anchored on a confirmed banner from a known instance. Every anchor in this work that was built from a spec sheet failed, and several failed silently, which is the dangerous case, because zero results read identically to genuine absence.

A related trap is the substring collision. A model prefix such as a hyphenated product code matches organizational naming conventions on unrelated equipment, so a query built on it returns routers and Linux hosts whose names merely contain the string. Precision is never the difficulty. The anchor matches exactly what it was told to match, which is why the anchor’s provenance carries the whole weight.

What HTTP Returns Instead

The contrast carries the argument. Run the same vendor names over HTTP and the numbers grow while the signal disappears. One satellite mission-control product returned 1,776 results by page title. All but 18 shared a single identical response body served from cloud object storage, a single static web asset replicated across hyperscale edge nodes in every region. An analyst trusting the title would not suspect it. The count is inflated by nearly three orders of magnitude, and every unit is misclassified. The obvious fix, anchoring on an application-specific asset string in place of the generic title, returns a strict subset of the same replicated set and does not help.

A satellite modem vendor’s HTTP results told the same story in miniature: a marketing tool hosted in a cloud region, alongside a handful of genuine device interfaces running on cloud VMs answering on ports conventionally assigned to unrelated services. Across 11 HTTP queries, more than 5,000 records yielded roughly nine genuine devices.

A Control Hiding in the HTTP Data

Those few genuine device interfaces are the framework operating as designed. HTTP correctly identified five embedded device interfaces, which is five of the roughly nine genuine devices returned across the 11 HTTP queries; the balance are devices of other types surfaced by the remaining queries. These five are distinct from the five network management servers described earlier, which were surfaced over SNMP and are counted in the fleet. The HTTP-derived interfaces are excluded from the deployment population because their hosting environment and service context indicate demonstration or laboratory instances rather than operational field equipment. Discovery succeeded and validation correctly rejected. That is the two-stage argument demonstrated inside the data. Finding a banner generated a hypothesis, and the checks resolved it.

The lesson is not that HTTP is a poor protocol. Within this dataset, HTTP-derived discovery predominantly surfaced web applications and supporting infrastructure, whereas SNMP-derived discovery predominantly surfaced deployed equipment. The reason lies in the validation checks, which separate operational reality from everything that resembles it.

The Two Pictures, Side by Side

The rows are the stages. Discovery returns both columns; validation is what separates them.

The same infrastructure, the same vendors, and the same collection day. The difference lies entirely in how the question was asked and whether the answer was validated.

Takeaways for Security Teams in the Space Industry

There are two takeaways, and they point in different directions.

The first concerns your own estate. SNMP over the public internet is the exposure that surfaced a real fleet in this study, much of it running v2 against explicit guidance, and for the operators concerned it surfaced management servers on operating systems abandoned years ago. Any practitioner running VSAT or ground infrastructure should answer two questions internally, before an external party answers them first: what of ours responds to SNMP from the public internet, and what operating systems are our management servers running?

The second concerns the reports you consume. When a vendor or researcher provides a count of exposed satellite systems, the useful response is to ask how the count was validated. Was the same content replicated across those addresses? Did the identity field vary? Did the hosting make sense? Did the service context make sense?

A number that has not survived those questions is a hypothesis in the costume of a finding, and this study exists because the difference between the two can be several thousand-fold, and because 1,776 and nine are both answers to the same question.

Why This Generalizes

Passive measurement is widely used to estimate exposure in operational technology, healthcare, and industrial control as well as satellite communications. This study shows that the method can fail in ways practitioners do not routinely check for, and it offers a framework for detecting that failure.

The specific contamination mechanisms are architecture-dependent. Object-store replication requires a particular kind of web application and will not appear where devices expose fixed protocol banners, so the failure modes do not transfer wholesale. What transfers is the obligation to ask, for any ecosystem, which architecture-specific contamination could inflate this count, whether the result survives the checks, and where the anchor came from.

The scoping obligation transfers with it, and on this evidence it is the more consequential of the two. Protocol choice determines which architectural layer a query can reach. Against the same vendors on the same collection day, HTTP reached web applications and SNMP reached deployed equipment. A study must confirm that the protocol it uses can observe the population it claims to be measuring, because a query aimed at the wrong layer still returns a confident number.

The lasting idea outlasts the checks themselves. Discovery generates hypotheses. It does not generate populations. Passive-measurement practice often treats a found banner as sufficient evidence of a deployed system. It is not sufficient. Validation is the stage where populations are established, and it is easily skipped.

Responsible-Disclosure Posture

All collection for this study was passive. No host was contacted directly, no credential was attempted, and no interface was accessed. The findings describe an exposure surface. They are not a target list, and the write-up is deliberately shaped so that they cannot become one.

• No device serials, site identifiers, or system-name values appear, for any device.
• No operator is named, at any level of the dataset.
• For the management servers, only operating-system age is given. No countries and no per-country breakdown appear. Five control-plane servers identified by role, in identifiable jurisdictions, are precisely what must not be published.
• For carrier modems, no country attribution is given, and no analytic weight is placed on their geographic concentration, which the small counts cannot support.
• For the user-segment fleet, only regional and network-class distribution is given, and individual organizations are withheld.

The aggregate is more sensitive than any single record, because the contribution of this work is the classification and validation, the step that turns scattered banners into a coherent picture. That a record was already visible is not an adequate defense of the aggregate, and the disclosure posture above reflects that.

Limitations

• Every figure is a point-in-time observation. A passive index reflects crawl coverage, not ground truth, and it moves. Devices documented in earlier work were already gone by this collection. Absence of a banner is not the absence of a device.
• The carrier-vendor counts are small enough that a single unindexed device shifts the ratio. The user-segment and carrier asymmetry holds at two orders of magnitude. The precise carrier figures are not.
• Some anchors, particularly for the smaller carrier populations, are weaker than the Hughes anchor and should be read as lower bounds with unknown recall. Given the five-conventions finding, a silent zero cannot be assumed to mean absence.
• Collection was single-source and English-language. Other indices and other language coverage were not consulted.