How can security teams detect SPACESHIP?

What security teams should look for on Windows hosts

Detection starts with the host, because the earliest reliable signal is usually on the endpoint rather than in the network. Watch for new persistence artefacts, scheduled task changes, services that appear without a deployment reason, and processes launched from user-writable or unusual locations. Hidden loaders often leave short execution chains, unusual command lines, and parent-child relationships that do not fit normal administration patterns.

It is also important to separate true operator activity from routine automation. Legitimate software updates and admin tooling can create noisy telemetry, so the useful question is whether the process tree, execution path, and timing align with expected change windows. When they do not, the anomaly is often more valuable than any single alert.

For teams that want a structured baseline for adversary behaviour and host telemetry, MITRE ATT&CK Enterprise Matrix is the most direct external reference for mapping persistence, execution, and follow-on activity to known techniques.

How network telemetry helps confirm suspicious activity

Endpoint activity alone is rarely enough to close the loop. DNS and proxy logs help confirm whether a suspicious host is reaching out to command-and-control infrastructure, generating periodic beacons, or making connections at intervals that do not match business applications. Even when payloads are encrypted, the rhythm, destination patterns, and unusual user-agent or protocol behaviour can still be strong indicators.

Teams should pay attention to rare domains, newly registered infrastructure, and repeated short connections after execution on the host. If the endpoint shows loader behaviour and the network shows outbound beaconing, the two signals together are much more compelling than either one by itself. That correlation is what turns a noisy alert into an actionable investigation.

For broader detection and response structure, NIST Cybersecurity Framework 2.0 gives a useful control-oriented lens for organising detection, response, and recovery work around the events you are observing.

The Malware Guide is also useful background when you are trying to distinguish loaders, RAT-style behaviour, evasion techniques, and malware families that tend to produce this kind of telemetry.

What a reliable detection workflow looks like in practice

The best workflow is layered: endpoint alerts identify the suspicious execution, network telemetry confirms external communication, and analyst review determines whether the pattern reflects an intrusion or a benign tool. That means correlating process ancestry, file path, script content, and outbound connections rather than triaging each alert in isolation.

Good detections are specific enough to reduce false positives but broad enough to catch variations in tooling. In practice, that means looking for the behaviour around the malware, not a single filename or hash. If the same host also shows credential access, abnormal lateral movement, or repeated attempts to reconnect after termination, the priority should move from simple containment to full incident investigation.

For incident handling discipline, FIRST is a useful reference point for response coordination and CSIRT practice, especially when the detection needs to be escalated quickly across multiple teams.

Risk and Threat Considerations

Windows hosts are attractive targets because they often carry broad access, persistence opportunities, and enough normal administrative activity to hide in. Attackers commonly rely on living-off-the-land execution, script-based staging, and low-and-slow beacons to blend into routine operations while maintaining access.

Failure mechanism: If teams monitor only a narrow set of signatures, they may miss the loader stage, the persistence mechanism, or the operator’s communication channel. That creates a gap where compromise is present but not yet obvious from a single control.

Impact: The result can be prolonged dwell time, repeated re-entry, and expansion from one infected host to additional systems. Once the attacker has stable execution and outbound connectivity, containment becomes more expensive and the chance of secondary credential or data exposure rises.

Practitioner Guidance

What to verify: Confirm whether the alerting host has a legitimate change ticket, scheduled maintenance window, or sanctioned admin tool that explains the process tree and network traffic. If not, treat the event as suspicious even when the executable name looks harmless.

What to prioritise: Correlate process ancestry, persistence artefacts, and outbound connections first. That sequence usually tells you whether you are seeing benign automation, staged malware, or an active operator session.

Practitioner takeaway: The strongest detections come from joining host behaviour and network behaviour, because neither one alone is enough to distinguish a stealthy intrusion from ordinary administrative noise.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?