The Satellite Is Not the Target. The Vulnerability Lives on the Ground

19:42 UTC. Unusual authentication.

A few minutes later, there is an outbound connection to an unknown host. Then anomalous administrative activity on one of the workstations. Shortly afterward, a network device configuration is changed without anyone having requested it.

This looks like a routine SOC alert. Dozens of them can pass through a SOC during a single shift. Only later does the team notice a detail that changes the context of the incident entirely: the compromised endpoint is connecting to the network through a Starlink terminal.

And this raises a question worth asking every time we talk about "space cybersecurity":

What exactly are we considering an attack on space infrastructure at this point?

Most people, including some cybersecurity professionals, imagine something cinematic: intercepting a satellite signal, jamming a communications channel, or directly interfering with an orbital spacecraft.

For DFIR (Digital Forensics and Incident Response), the starting point is different.

When an analyst investigates an incident, they do not begin by asking, "Was the satellite hacked?" The first step is to reconstruct the chain of events: what was accessible to the threat actor, where did the initial access come from, which services were exposed, could credentials have been compromised, which endpoint became the entry point, what happened after access was obtained, and, critically, what evidence remains in telemetry and logs.

This is the perspective from which space cybersecurity should be approached.

Space infrastructure is not the satellite

There is one basic misconception worth addressing at the outset: space infrastructure ≠ satellite.

A satellite is only one node in a distributed system, where every component has its own attack surface:

satellite -> ground station -> router / firewall -> operator workstation -> cloud infrastructure -> identity / credentials -> third-party software -> developers / supply chain

From a DFIR perspective, this is not simply an architectural question. It determines where we should look for the beginning of a compromise.

A threat actor does not necessarily need to target the most expensive or technically complex component of the system. It is often much easier to find a node that is internet-facing, has not been properly updated, relies on legacy protocols, is poorly monitored, or has excessive privileges.

Such a node becomes particularly valuable when other components in the environment trust it.

For the threat actor, the value may therefore not be in the endpoint itself. The value is in where that endpoint can go next.

What the new research on Starlink hosts found

On August 17, 2026, researchers published an analysis providing a view of the security posture of Starlink-connected hosts compared with the broader internet.

The study analyzed approximately 33,000 Starlink hosts and a comparison dataset of roughly 1.78 million other hosts. The researchers examined, among other things, CVEs from 2020 through 2025, exposed services, TLS configurations, SSH cipher suites, SMBv1 usage, and the geographic distribution of identified issues.

Eastern Europe is particularly notable. The researchers identified a disproportionately high share of insecure protocol usage among Starlink-connected hosts in the region. Similar patterns were observed in parts of Southeast Asia and Latin America.

But there is an important distinction to make here.

The study does not provide evidence that Starlink itself was compromised.

What it does show is that some internet-accessible hosts associated with Starlink have a weaker security posture, including the presence of vulnerable or outdated software, insecure protocols, or exposed services.

That distinction matters.

An exposed host is not necessarily a compromised host. The presence of a CVE is not evidence that the vulnerability was exploited. And an open port, by itself, does not mean that an intrusion has already taken place.

For a security analyst, however, these are still meaningful signals. They indicate where the external attack surface may be broader than it should be.

The formula that matters here

Exposed ≠ compromised. But exposed + vulnerable + trusted = operational risk.

This is where the difference between vulnerability assessment and incident response becomes important.

Individually, none of these factors proves that an incident has occurred. But when an internet-facing host has a vulnerable service, is used as a trusted component, and has access to other parts of the infrastructure, its compromise can have a very different impact.

A hypothetical chain could look like this:

internet exposure -> exploitation of a vulnerable service -> access obtained -> credential theft -> management interface access -> lateral movement -> access to ground infrastructure -> operational disruption

And notice something important: for most of this chain, there is nothing specifically "space-related" about it.

It is the same set of activities an IR analyst might encounter in a corporate environment: initial access, credential theft, privilege escalation, lateral movement, and access to a critical segment.

The difference appears later, in what the threat actor can access and what operational impact that access can create.

What a DFIR analyst would look for if an incident happened tomorrow

If an incident occurred tomorrow in the ground segment of a space system, the investigation would not begin with an attempt to find a "hacker's trace inside the satellite."

The first task would be to reconstruct the timeline.

When did the first suspicious authentication occur? Where did it originate? Does the source IP match the user's or service's normal behavior? Did new administrative sessions appear? Was network equipment configuration modified? Were new accounts created? Were credentials reused across other segments? Did unusual DNS queries or outbound connections appear?

Then comes endpoint telemetry: processes, command lines, persistence mechanisms, configuration changes, access to credential stores, and evidence of lateral movement.

There is also a separate layer: network data. In a distributed infrastructure, network telemetry can reveal relationships between events that look harmless when examined on individual systems.

And there is another problem that becomes particularly important in these environments: time.

If logs from different components are not synchronized, or parts of the telemetry are unavailable, reconstructing the sequence of events becomes significantly harder. Without a reliable timeline, it may be difficult to determine even a basic question: which event represented initial access, and which events were already consequences of the compromise?

This is why, after an incident, a responder has to answer not only what happened, but also:

what can still be trusted?

If a single workstation had administrative access to multiple systems, simply rebuilding that endpoint is not enough after a compromise. Investigators need to determine which credentials were used on it, which systems it could access, and what changes could have been made through its sessions.

That is where blast radius becomes more important than the fact that a single host was compromised.

Viasat: proof that this is not theoretical

On August 18, 2026, AP published a report on new AI technology from Atalanta being used to strengthen the security of Viasat's satellite network following the 2022 attack. The approach focuses on software analysis and identifying vulnerabilities in complex systems.

The Viasat incident itself demonstrates why the ground segment cannot be treated as a secondary part of space infrastructure.

On February 24, 2022, the day Russia launched its full-scale invasion of Ukraine, an attack against Viasat's satellite network disrupted thousands of modems in Ukraine and other European countries. The target was not in space. The impact was very much on the ground.

This is an important precedent for today's discussion.

In 2022, Viasat demonstrated that compromising ground infrastructure can have consequences far beyond an individual network.

In 2026, the new Starlink research highlights another part of the same problem: the potential scale of the external attack surface associated with satellite-connected infrastructure.

Neither of these cases proves that an exposed Starlink host represents an imminent attack. But together, they explain why visibility and exposure management cannot be treated as secondary concerns in space infrastructure.

Blast radius

In this context, it is worth looking at blast radius, not simply as an abstract concept from threat modeling, but as a way to assess the real consequences of a compromise.

A compromised workstation is not necessarily just one compromised machine.

If it has access to a management network, uses privileged credentials, is part of a ground station, has access to cloud infrastructure, or is used to work with telemetry, its compromise can become a pivot point for further movement through the environment.

That means the physical location of an endpoint tells us very little about the actual scale of the risk.

The distance between a threat actor and a satellite may be thousands of kilometers. The distance between the threat actor and the first compromised machine may be zero.

And this is why ground infrastructure should be treated not as a "supporting component" of a space system, but as a full security boundary.

Conclusion: what actually needs to be protected

Space cybersecurity should not begin with the question, "How do we protect the satellite?"

The first question should be different:

"Which systems must remain trustworthy for the satellite infrastructure to continue performing its function?"

The answer will almost never be limited to a single spacecraft in orbit.

It will include ground stations, operator workstations, network equipment, cloud infrastructure, identity systems, software supply chains, and all the components connecting them.

That means the practical security baseline for this infrastructure starts with fairly familiar things:

- Asset visibility - knowing which systems actually exist in the environment and how they are connected.

- Exposure management - understanding what is accessible from the internet, why it is accessible, and whether that access is actually necessary.

- Identity security - controlling privileged accounts, credentials, and trust relationships between systems.

- Telemetry & logging - having enough data to reconstruct a timeline after an incident instead of trying to piece one together from fragments.

- DFIR readiness - knowing in advance which artifacts will be needed to determine the scope of a compromise and its operational impact.

And this is the paradox of space cybersecurity.

The most critical system may be thousands of kilometers away. The path to it may begin with an ordinary endpoint, an exposed service, or a compromised credential sitting on the ground.

So the question is no longer whether a satellite can be hacked.

The more useful question is:

How many systems stand between a threat actor and the satellite - and how many of them are actually visible, monitored, and ready to be investigated when one of them becomes the entry point?