The Plan

Firstly, we will set a realistic stage for these events to play out in. After all, before we attack a space system and ultimately the SV it operates, we need to know why. Let’s say a nation state has decided to sponsor a cyber attack campaign against an academic space system as a proof of concept and learning evolution for potential follow-on militarized cyber domain actions. This way the target is likely a softer one, without classified or sensitive systems and some of the added protections they might come with. Additionally, since the targets are not military in nature, it will be viewed less as an act of war if the activity was somehow attributed by the targeted academic institution or host country. Lastly, there is the added benefit that many academic institutions work hand in hand with the defense sectors of many countries’ governments, and tactics, tools, and procedures learned and utilized against the test target could be rolled into actual operations.

Targeting

To determine the target for a scenario like this, which will be used as a proof of concept, the nation state is likely to let the target identify itself. This is done by simply picking what looks like the lowest hanging fruit; instead of an actual cyber operation which may have determined the target first and approached attack avenues after, here the attack avenues choose the target for ease of exploitation. So the attacker will canvass the Internet for academic instructions announcing their first ever space and small satellite programs which have recently or will soon launch their SV. This way the target set includes only institutions new at space and small satellite development and likely to make more mistakes than those with established programs.

Once the institution is identified, the attacker can canvass social media and the institutions’ web sites and other locations like LinkedIn or GitHub for those students who will be involved in the program, specifically those who are likely to be involved in writing or uploading code such as electrical engineers and computer science students. Once a target individual is picked, the attacker can research what projects and collaborations the student has been involved in. Then, creating a fake persona that looks like it is an academic within a related field from a prestigious university who wants help or to collaborate on something since they read the target’s work and were obviously thoroughly impressed.

Personal Computer

The first step in the actual exploit and compromise purpose is to gain access and privileges to the personal computers of the target individual within the target institution.

How

Once the right individual has been selected for targeting, the attacker can use the fake persona from the prestigious academic university to build a rapport with the target and eventually use that rapport to get him or her to open files that contain malware which when executed give the attacker remote access to the target’s personal laptop. There are many ways to abuse a social relationship to get a target to execute something, but some common and relevant methods could be using macros within a Microsoft Word document or PDF. Once that document is opened and a pop-up is clicked (at the instruction of the attacker), malicious code is now running with the context of that user, and one of any number of privilege escalation techniques can be used to gain system access and further implant backdoors and other malware on the target’s personal laptop, as shown in Figure 10-1.

Phone

With access to the personal laptop gained, the attacker will look to exploit something like a personal phone as that sort of device is more likely to be taken into areas of interest than a laptop. In cases where both are taken to areas where space system work is done, then the attacker has simply doubled his or her access.

How

With system-level access to a Microsoft Windows personal computer, there are any number of ways to exploit and gain access to the devices such as smart phones which get plugged in for charging and file movement purposes. To cite a specific example, there is a Windows executable Trojan called DualToy¹ described and reported on by Paolo Alto in 2016 which allows for the loading of malicious applications and their code via USB charging cable connections and relying on already established android smart phone to Windows computer profile relationships. This would allow the attacker to backdoor and install toolkits and malware on the phone as necessary; the movement of the attacker’s access is shown in Figure 10-2.

Lab Computer

The malware installed on the phone allows the attacker to run commands remotely on the phone and to explore the file systems of other computers it is plugged in to. Using this capability, the attacker identifies that the student routinely plugs his phone in for charging via a USB cable to a server he regularly works on at the school’s space system lab. File system queries allow the attacker to determine that the server is a common Linux distribution and also that there are several scripts that are world writable, meaning anyone can append to them, which execute as root daily. The attacker leverages the phone implant to write a Linux backdoor to the file system and append code to a world writable script to execute it. This way of getting access to and escalating privilege on a Linux system is as old as there are users and admins on Linux systems who make mistakes or have bad security practices. When the script is executed by root later that day, it executes the attacker’s backdoor as root as well, enabling them to install a stealthy rootkit to persist access across reboots. Even though not connected to the Internet or any other device, when the student’s phone is plugged in to charge on it, the rootkit the attacker installed can communicate to Internet-hosted redirection servers the attacker utilizes to obfuscate their location and task the implants in this compromise chain.

How

Figure 10-3 shows the next pivot the attacker will make to the lab server hosting virtual machines.

Ground Station Computer

Security on the ground station is essentially the last layer of defense in depth protecting the satellite. Tasking from the ground is inherently trusted by the SV, and it affords attackers the most reasonable way to attack the SV components.

How

Because the ground station software installed on the ground station virtual machine is not forward compatible with newer versions of Windows, it is still running an older version of Windows. This means that it remains vulnerable to the remote Windows exploit MS17-010 that was made famous by the WannaCrypt malware (https://docs.microsoft.com/en-us/security-updates/securitybulletins/2017/ms17-010). The risk of leaving the ground station computer installed with a risky operating system to run the ground station software that flies and tasks the flight computer and payload was done despite the risk of exploitation because of the stand-alone nature of the virtual machine it runs on and the stand-alone nature of the Linux server hosting it which is updated weekly. The exploit installed another implant that called back to the attacker through tunnels on the host Linux machine and out via the Internet connection of the student’s phone whenever it is plugged in for 6–8 hours a day each week day charging which is shown in Figure 10-4.

Payload Computer

The first computing device on board the SV that the attackers are going to target is the payload computer since it takes very straightforward tasking from the ground station to include software and operating system updates. Additionally, altering behavior of the payload computer and/or its code will not result in immediately noticeable effects by those operating the space system as the attacker learns the rest of the attack surface on board. So long as the attacker allows the payload to continue carrying out the tasks those on the ground expect, any additional malicious activities are not likely to be noticed.

How

Legitimate commands are utilized to tell the payload to upload a software update which contains malware that when executed will overwrite the backup images of the operating system copies of those operating systems that also contain malware so that it will be persisted through reimaging of the payload computer operating system. This malware also looks for tasking in legitimate payload tasking files which the attacker uses metadata sections of the file to input tasking hidden from the space system operators. Evidence of both of these actions are deleted from logs on both the SV and the ground station as are artifacts of the malicious activity, and the attacker now has access to the SV which is shown in Figure 10-5.

Data Handler

Scans run by the payload implant reveal the presence of a C&DH computer which is responsible for watchdog, health, and maintenance functions for the rest of the spacecraft and is likely what talks to the software defined radio which the attacker intends to eventually leverage to kill the satellite.

How

The data handler is running a current year version of VxWorks which in 2018–2019 had many vulnerabilities disclosed to include some six which would enable remote code execution.² One of these is leveraged by an executable sent up to the implant in the payload computer and executed. The vulnerability can be used to execute commands which enumerate the data handler computer and send the data back to the payload computer implant for eventual download and passage over the attacker communication channels, which are illustrated in Figure 10-6.

SDR

The piece of computing equipment which allows the SV to communicate with the ground station is the SDR, and compromise of it and execution of malicious code could prevent any further communication to it.

How

Some SDRs including the one on the target SV run the POSIX operating system. POSIX allows for running of the born-again shell or bash which is vulnerable to the remote vulnerability shellshock.³ The attacker used the remote code execution ability of leveraging the VxWorks exploit from the payload computer to have the data handler upload and run shellshock against the SDR, as shown in Figure 10-7.