SCATMAN: What We Know – and What We Don't

In 2026, SpaceX's plans for orbital AI infrastructure found themselves unexpectedly linked to a story about two allegedly compromised accounts on a social platform within the company's corporate group. The incident involved a memecoin promotion, but the corporate background is documented.

On 2 February 2026, SpaceX announced its acquisition of xAI. According to a Bloomberg estimate cited in media reports, the combined company was valued at around $1.25 trillion (SpaceX, Reuters). Along with xAI, SpaceX also gained control of X: on 28 March 2025, xAI had acquired X Holdings Corp., the holding company that owned the social network. In early July 2026, xAI rebranded as SpaceXAI: its X account changed its name and handle, and the company unveiled a new logo (Free Press Journal). Among the stated aims of the merger is the development of computing infrastructure for AI in orbit.

On 12-13 July, according to several media outlets, the SpaceXAI and Starlink accounts on X reposted promotions for a cryptocurrency called SCATMAN. The token's price initially surged before collapsing to almost zero (BeInCrypto, Incrypted). The reported sequence is unusual: shortly after the rebrand, the accounts of SpaceX's AI division and Starlink amplified a cryptocurrency promotion on a social network belonging to the same corporate group.

The SCATMAN episode raises a question that goes beyond social media: what can happen when someone gains access to a trusted identity and uses it to initiate actions? Passwords, sessions, accounts and human error remain part of the security picture even when computing infrastructure moves into orbit. The consequences, however, can extend far beyond a corporate network.

SCATMAN: What Is Known and What Is Not

According to Cyber Security News, the promotion originated from an account called “Sam Catman”, which displayed an affiliation badge suggesting an official connection to SpaceX's AI division. The official SpaceXAI and Starlink accounts then reposted the promotion, exposing it to millions of followers through feeds they already trusted. Screenshots published in connection with the incident show the reposts among routine updates about Grok, with no visible changes to the accounts' avatars or profile banners.

The token's market performance followed a familiar memecoin pattern. According to BlockBeats, its market capitalization rose to approximately $2 million before liquidity was withdrawn and the price collapsed. Estimates of the proceeds attributed to the attacker range from approximately $125,000 in ETH, according to BeInCrypto, to $135,000, according to CryptoPotato. The difference appears to depend on which transactions are included in the calculation. Neither figure has been independently confirmed.

Several important details remain unverified. SpaceX, Starlink and X have not publicly confirmed that their accounts were compromised. There is no reliable public information about how access was obtained, whether other accounts were affected or how much money buyers lost.

The available reporting is therefore insufficient to reconstruct the incident in detail. It does, however, provide a useful starting point for examining a broader class of attacks involving compromised identities and the trust placed in them.

Trust as an Attack Vector

If the reported account compromise did occur, SCATMAN illustrates how platform trust mechanisms can become part of an attack rather than a barrier against it.

Consider how the promotion would have appeared to an ordinary X user. The affiliation badge associated the “Sam Catman” account with SpaceX's AI division. The familiar verification mark added another trust signal. Then the official SpaceXAI and Starlink accounts reposted the promotion. Their posts appeared alongside routine updates about Grok, without any visible indication that something was wrong. Taken together, these details made the promotion look like an endorsement from the company itself. That perception may have influenced users to buy a token that subsequently collapsed.

From the platform's perspective, the reposts came from legitimate corporate accounts. A detection rule based only on account identity would have little reason to flag them. More useful signals would include a new login session, an unfamiliar application, an unusual posting time or interactions with accounts outside the brand's normal activity.

Several established techniques could explain how access to such accounts might be obtained. These include phishing messages disguised as platform policy notifications, credential theft through infostealers, and SIM swapping involving the phone number used for account recovery. A well-known example is the compromise of the US Securities and Exchange Commission's X account in January 2024, which was used to publish a false announcement about the approval of spot bitcoin ETFs. The SEC later attributed the incident to a SIM swap involving the linked phone number.

Account recovery also involves more than changing a password. X's help center explicitly notes that changing a password does not automatically terminate all active mobile app sessions. The platform recommends reviewing the associated email address, revoking access granted to third-party applications and terminating sessions that the account owner does not recognize. A password change is therefore only one part of restoring control.

For organizations, this has several practical implications:

• A brand account is a privileged identity. Organizations need an inventory of who can access it, through which applications and contractors, and from which devices.
• Authentication should resist phishing. Hardware security keys or passkeys are preferable to SMS-based authentication. Recovery email accounts should have independent MFA protection, and recovery phone numbers should be treated as potential attack vectors.
• Third-party applications and delegated access require regular review. An active OAuth grant may preserve access even after a password has been changed.
• Incident containment must cover all access paths. Sessions, tokens and delegated permissions need to be reviewed and revoked where necessary, not just the account password.

Why Talk About This Now

The account incident is a relatively small episode against the backdrop of much larger plans for orbital computing.

On 30 January 2026, SpaceX filed an application with the FCC for a proposed orbital data center constellation of up to one million satellites. Starcloud submitted a separate application covering 88,000 satellites. Both remain proposals, not authorizations.

In its IPO prospectus, approved on 5 June 2026, SpaceX acknowledges that orbital computing depends on technologies that have yet to be proven under real-world conditions. The company also states that it does not plan to service or repair processors in space.

Regardless of where the computing hardware is located, operators will still manage it through ground infrastructure: accounts, consoles, software deployment systems and communication links. These components will remain part of the attack surface, and their compromise will have to be handled by incident response teams.

From Account to Command

A social media account and a spacecraft command system are fundamentally different environments. They do not share authentication mechanisms, even when they belong to the same corporation. The relevant similarity lies in the trust model: both rely on mechanisms that establish whether an identity or command source is authorized.

Space policy addresses this directly. The 2020 US directive SPD-5 defines “positive control” as the assurance that a space vehicle will execute commands only from an authorized source, in the proper order and at the intended time.

NASA's Space Security Best Practices Guide identifies the ground segment as a potential route for malicious interaction with a spacecraft. Principle MI-AUTH-01 recommends that spacecraft be capable of rejecting or constraining malicious interactions originating from a compromised ground segment. MI-AUTH-02 addresses actions requiring strong authentication and authorization, including flight software updates, changes to fault responses, uploads of command sequences and execution of critical commands.

There are also standardized mechanisms for protecting the communications link itself. The CCSDS Space Data Link Security (SDLS) protocol provides frame authentication, integrity protection and replay protection, with confidentiality available where required. Public sources do not establish whether a particular operator implements this protocol or how it is configured.

Even when such protection is in place, cryptographic verification has a defined scope. It confirms that a frame was authenticated using the key associated with the relevant security association. It does not establish that the person or system initiating the command had the authority to do so. The distinction between authentication and authorization is particularly important when the environment holding those credentials or keys has itself been compromised.

A similar chain of events can be modeled for a compromised ground segment:

1. An attacker compromises a ground segment administrator's account through phishing, credentials stolen by an infostealer or a reused password.
2. Using the stolen credentials or session, the attacker gains access to the network and establishes persistence.
3. From there, the attacker reaches the mission planning system or command console.
4. An unauthorized command is prepared and submitted for transmission.
5. An independent authorization mechanism must determine whether the command is legitimate and prevent its execution if it is not.

The first four steps describe a conventional intrusion into corporate or ground-segment infrastructure. This is also where the documented incidents in the space sector have predominantly occurred. The ETH Zurich Center for Security Studies recorded 407 cyber incidents affecting 183 space-sector organizations in 2025. All documented incidents involved ground systems or corporate IT. The researchers caution that these figures reflect observable incidents, not proof that spacecraft have never been attacked: onboard detection capabilities remain limited in many systems. I have written before about how the path to a satellite usually starts on the ground.

The fifth step is where the consequences of a compromised ground environment become particularly important. If an attacker gains access to the cryptographic keys used to protect the communications link, frame authentication alone may not prevent unauthorized commands from being accepted. Cryptographic integrity and independent authorization serve different purposes. The latter must remain effective even when the operator's working environment is compromised.

NIST IR 8401, the cybersecurity profile for the ground segment, addresses this problem through recommendations aimed at maintaining or recovering positive control of the spacecraft. The implementation details depend on the operator and the architecture of the mission. However, the separation between access to the ground environment and authority to execute critical spacecraft operations is a question that should be addressed during system design.

Incident Response When Part of the Infrastructure Is in Orbit

Scoping, containment, evidence collection and recovery remain central to incident response. However, the available response options depend on the spacecraft's architecture, communications links and onboard security controls. Much of this information is not publicly available, so the following four questions should be addressed with the operator before launch.

1. When and how can the response team reach the spacecraft?

In a conventional corporate network, a response team can usually access a compromised host through available management channels. In space infrastructure, the ability to interact with a spacecraft depends on its communications architecture. With direct links to ground stations, access is limited by radio visibility windows. More frequent communication may require additional ground stations, increasing operational costs.

The communications schedule therefore affects the response timeline. A team may identify a compromise immediately but still have to wait for the next available communication window before it can interact with the spacecraft. The operator needs to establish in advance which actions can be performed remotely, how quickly commands can be transmitted and what options remain between scheduled contacts.

2. Can a compromised component be contained without stopping the entire mission?

NASA recommends incorporating domain separation and least privilege into onboard architecture, communications and control (MI-ARCH-02). Whether these controls are implemented in a particular system, and what isolation mechanisms are available, must be established before an incident.

Safe mode also requires attention. NASA warns that a transition to safe mode must not disable command-link protection (MI-DCO-02). Otherwise, an attacker could deliberately trigger a fault to move the spacecraft into a less protected state. Containment procedures must account for this possibility rather than assuming that a transition to a safer operating mode automatically improves security.

3. What evidence will be available, and can the event timeline be reconstructed?

Onboard telemetry and logs are primarily designed for fault diagnosis. Dedicated capabilities for detecting malicious activity may be absent. NASA recommends incorporating an onboard function for detecting adversary actions into the mission architecture (MI-DCO-01).

On the ground, investigators will need to correlate several sources of evidence: IT system logs, command logs and telemetry records. These sources may have different timestamp formats, retention periods and synchronization mechanisms. If their clocks are not aligned, reconstructing the order of events becomes difficult.

The operator should be able to explain which logs are retained, for how long, who can access them and how time synchronization is maintained across ground and space systems.

4. How can the integrity of the spacecraft and its software be verified after an incident?

A system becoming operational again does not establish that it is trustworthy. Investigators need to determine which commands were transmitted during the compromise, whether those commands were authorized and whether the spacecraft's software or configuration was modified.

NASA recommends verifying the integrity of software images and updates using cryptographic hashes, with the reference values themselves protected by digital signatures (MI-MALW-01, MI-MALW-02). This prevents an attacker from simply replacing both the software package and the reference value used to verify it.

These questions do not require the incident response team to design the spacecraft. They do require the team to understand what evidence, access and recovery mechanisms the operator can provide. If a necessary security control or logging capability was never incorporated into the architecture, adding it after launch may be difficult or, in some cases, impossible.

What This Means for Security Teams

Moving computing infrastructure into orbit does not remove the security responsibilities associated with operating it. Administrative access, software integrity, command authorization and third-party dependencies will remain part of the system's security architecture.

For incident response teams, the critical difference is the limited ability to intervene once a spacecraft is in orbit. A missing log source, an inadequate command authorization mechanism or an onboard component that cannot be isolated may leave investigators with few options. These limitations cannot be addressed by incident response procedures alone.

The security of orbital computing will therefore depend not only on protecting access to ground infrastructure, but also on ensuring that a compromised ground environment cannot independently authorize critical spacecraft operations.