[NotAWorkNick]

Dumb Question here but my thoughts were - why not push the corrupted update to the sats? AKA hack the sat firmware? I'm fairly certain that they aren't wide open doors but still - I would guess that it would be a lot easier doing it that way. Perhaps it was both, or someting else entirely. It will make for an interesting read one day.

[myself248]

It's easy to buy an end-user terminal and tear it apart on your workbench to develop an understanding of how it works. I don't know about you, but I haven't seen any satellites on eBay recently.

Also, most satellites are intentionally as dumb as possible, just a "bent pipe" transponder, putting all the complexity on the ground stations which are easier to service if something goes wrong. There might not be much to do on the satellite itself.

[lxgr]

With the right commands, you could flip the satellite by 180 degrees, move it from Europe to the pacific ocean, or crash it into one of its neighbors.

All geostationary satellites need to be capable of at least some station-keeping to correct for drift, move them to other service areas, or move them to a graveyard orbit at their end of life. (Unlike LEO, GEO satellites don't carry enough fuel for de-orbiting, and friction is essentially nonexistent at that altitude.)

That layer of commands is hopefully very well protected.

[okl]

> That layer of commands is hopefully very well protected.

Typically some form of HMAC authentication. You can read about it in the CCSDS Blue Book.

[lxgr]

What a fascinating rabbit hole. Thank you!

[shaklee3]

that is a completely separate layer run by and built by a different company using technology from 20 years ago

[Nextgrid]

The satellite layer is probably very custom and requires specific skills and initial recon work which could be visible and risky. In contrast, getting access to the management network and sending intentionally-malformed configurations or firmware updates to the terminals is much easier and doesn't require any satellite-specific knowledge. The satellite terminals (at least the router part of it) are just standard Linux embedded devices, so no special skills required.

If your objective is to disable the devices like they've done, attacking the "easy" layer is enough so why waste time on unnecessary complexity? Of course they might well have also done recon on the satellite side and collected valuable data they can use in the next round.

[stephen_g]

The satellite command and control is probably the one bit of the network that's actually hardened (possibly even air-gapped), completely proprietary, etc. - that bit is designed by the companies that make $200 million satellites, not the people who make fairly cheap modems and have different priorities.

The current generation of satellites themselves generally do nothing to the data stream - for each of the dozens of spot beams they're transmitting, they generally just take an RF signal from the ground station (multiplexed in various ways up to the satellite) and convert the frequency. Same with the receive path just in reverse.

The actual modulation/demodulation all happens at the ground station. This is because they expect modem technology will improve, but the satellite has to be able to work for 25-30 years. (Though in the industry they are talking about putting more and more 'software defined' functionality on the satellites, but again this will mostly have to go via their secure systems at the ground station, not from the terminals)

So there's basically no way to interact with any 'satellite firmware' unless you're in a very specific location (near their ground station) with extremely specialised gear.

[tgsovlerkhgsel]

Because it's one thing to attack hardware in Ukraine and have some collateral damage in other parts of the world, and an entirely different thing to directly attack an expensive space asset of another country just because it is used to provide service to Ukraine.

Also, the affected ground stations are in Germany, the satellite belongs to a US company.