Leveling Up with NightSpire Ransomware

Our industry has a ransomware actor categorization problem. 

News articles will frequently feature splashy headlines like “Akira ransomware group targets critical infrastructure.” However, the reality is that Akira, and many other ransomware variants, are distributed via an affiliate model. This is commonly referred to as a “Ransomware-as-a-Service,” or RaaS, model. This means that a core set of developers create and maintain the file encryptor and infrastructure, and may provide other services (i.e., manage ransom negotiations and collection, review and categorize stolen data, etc.), but sell the file encryptor to third-party groups, or affiliates, that then execute the actual attacks where the ransomware is deployed. In some cases, affiliates have not exclusively stuck to one ransomware variant, moving between multiple, different ransomware providers. 

So, what? What does that mean for investigations, detections, and impacted organizations? 

Perhaps most importantly, this means that very often, indicators and tactics, techniques, and procedures (TTPs) will vary from one attack to another, even when the files are encrypted by the same ransomware. Particularly for MSSPs and MDRs, while there may be a cluster of attacks across their customer base that include the same or very similar indicators and TTPs, over time there will likely be several distinct clusters that clearly illustrate different affiliates or groups at work. As a result, attacks attributed to “the ransomware group” will often be markedly different depending upon when, and who, is doing the reporting. A successful ransomware attack reported six months ago, in a completely different vertical or geographic region, may follow an entirely different playbook than a more recent attack, from initial access, through defense evasion, data staging and exfiltration, through ransomware deployment.

Further, multiple RaaS samples have been observed to contain embedded commands to terminate processes, and/or inhibit recovery, lowering the bar to a successful attack and ransom payment so that an affiliate doesn’t have to remember to take these actions themselves. For example, the Akira file encryptor is widely known to launch a PowerShell command, as a child process, to delete available Volume Shadow Copies (VSCs). In 2020, Sodinokibi samples were found to include 156 unique embedded commands to terminate processes and services associated with anti-virus products. This is an observation, not to say that this is exclusive to RaaS variants and samples.

Is NightSpire RaaS? 

NightSpire ransomware was reportedly first discovered in February 2025, and was active throughout the year. There appears to be some confusion as to whether or not NightSpire follows a ransomware-as-a-service (RaaS) model or not. Researchers with Halcyon have argued that the actors are keeping their operations in-house, stating in a July 2025 post, “They’re not running a public RaaS operation, and there’s no affiliate program; it’s a closed shop.” However, two months later, further reporting from HivePro indicates that the attackers are “operating under a Ransomware-as-a-Service (RaaS) model”.

It’s possible that this is less about confusion, and more about an evolution of the structure and model of the group itself. But why does it ultimately make a difference from the perspective of defenders? 

NightSpire incident

At the end of March 2026, the Huntress agent was installed on several endpoints for a newly joined customer. Shortly after the agent was installed on the first endpoints, malicious footholds, or persistence mechanisms, were detected, indicating that the agent was likely being installed after the incident had already begun. As monitoring continued, additional signals were generated, including of NightSpire ransomware being launched on an endpoint. From there, a deeper investigation ensued.

This investigation revealed that the threat actor had accessed one endpoint via RDP several days prior to the Huntress agent being installed, and had installed Chrome Remoting Desktop, followed by Everything, a file search tool freely available from voidtools. Two days later, the threat actor could be seen running MEGASync, likely for data exfiltration, and then installing VMWare Workstation on the endpoint, and then running Everything, from which the threat actor could then be seen, based on process lineage, accessing files via the Everything interface. The threat actor could then be seen running 7Zip to archive files from a specific folder. The following day, the threat actor was observed installing WPS Office, a multi-platform office suite freely available from the Chinese company Kindsoft Office Software. Figure 1 illustrates an excerpt from the WPS web site.

Figure 1: Excerpt from WPS website

On a second endpoint within the infrastructure, as illustrated in Figure 2, foothold signals for Chrome Remoting Desktop and AnyDesk were generated shortly after the Huntress agent was installed.

Figure 2: Foothold signals

These foothold or persistence signals mirrored those on the first endpoint. 

Figure 3 illustrates an excerpt from the ransom note recovered from the infected endpoint. 

Figure 3: Ransom note excerpt, March 2026

The ransom note is remarkably specific, and without another more recent incident to compare it to, it’s sheer speculation as to its accuracy. We know that the threat actor ran Everything, 7Zip, and MEGASync, and we know that the threat actor viewed some files via Everything, but we do not have the evidence to validate the statement that “2.5TB” of data was taken, nor the actual content of the files taken.

Previous NightSpire incident

It turns out that this wasn’t the first time Huntress had seen a customer environment where the NightSpire ransomware had been deployed. During this incident, there was not a great deal of data related to the threat actor TTPs captured, but it was noted that encrypted files had the .nspire extension added to them, and a copy of the _nightspire_readme.txt ransom note was retrieved from one of the endpoints.

Figure 4 illustrates the full contents of the ransom note recovered from the December 2, 2025 incident.

Figure 4: Ransom note, December 2025

Observations

Publicly available reporting of NightSpire ransomware indicates that attacks have included the use of native utilities, or “LOLBins,” like WMI or PsExec. However, in the most recent incident investigated by Huntress, this does not appear to be the case. In fact, the threat actor, be they “the NightSpire ransomware group” or an affiliate, appears to have had to “truck in” all of their tooling, including Chrome Remoting Desktop and AnyDesk for persistence, 7Zip and Everything for data staging and collection, MEGASync for data exfiltration, and VMWare Workstation and WPS Office for other purposes. None of these applications are native to the compromised environment, and they had to be downloaded to the endpoints. 

This shows one differentiation from previous publicly reported incidents linked to NightSpire. While looking at the previous incident that Huntress observed in December 2025, there are other differences in TTPs. While a good deal of information is no longer available regarding this incident, one thing is clear; the ransomware file encryptor itself appears to have been modified at some point in the almost four months leading up to the end of March 2026. For example, ransom note file names and contents were modified. 

These differences may indicate an evolution of the ransomware itself, or they could represent variation due to affiliates distributing NightSpire. While it remains to be seen as to whether or not NightSpire follows a RaaS model, the varying TTPs in these incidents show that Indicators of Compromise (IoCs) tied to ransomware “groups” aren’t always set in stone, particularly if affiliates are potentially involved. Huntress analysts have seen this with other RaaS variants, where IoC and TTP clusters are markedly different between attacks, starting with workstation names, and progressing through the rest of their playbook, through data staging and exfiltration to ransomware deployment. While some things may appear consistent across attacks, such as initial access and the fact that various tools are used, other aspects of the attacks tend to vary in significant ways, lending credence to the fact that different groups or affiliates are responsible for the attacks.

Indicators of Compromise