Acknowledgements: Special thanks to Adam Mooney and Jamie Dumas for their contributions to this investigation.

Background

Huntress analysts recently observed two incidents where a newer ransomware variant, Settra, was deployed. One incident occurred in July at an organization in the consumer services and retail sector, while the other occurred in September at a company in the manufacturing space.

Settra was first seen in June and there has been some public reporting on the variant since then, including reports that have outlined initial access vectors that the attackers behind this ransomware have used. Huntress analysts did not confirm initial access vectors for the two incidents we investigated; however, we found several other valuable traces of post-compromise activity, including the use of RMMs, several attempts by the threat actors to hide their tracks, and evidence of BYOVD.

While some public information is available for this ransomware variant, we are releasing our own analysis so that defenders can better understand the TTPs related to Settra ransomware attacks.

What we know based on public reporting

What is Settra ransomware? Based on publicly available information, Settra ransomware was first observed in June, making it a new variant on the scene. Figure 1 illustrates a Google AI overview describing Settra ransomware. 

Figure 1: AI overview for a Google Search on Settra ransomware showing publicly available information

On July 22, MoxFive shared findings from observed activity up to mid-July, discussing their perspective of the group. Initial access to impacted infrastructures included compromising VPNs and making use of already-obtained credentials. Once they have gained access to the infrastructure, the group has been seen installing BYOVDs to impacted systems, and installing the MeshAgent RMM for persistent access.

Figure 2 illustrates insight on the group shared by SOCRadar, which defines it as "a ransomware and data-extortion group" with a primary focus on global extortion.

Figure 2: SOCRadar insights on Settra ransomware

At this point, nothing has been published publicly stating that Settra ransomware follows a ransomware-as-a-service (RaaS) model. To understand a bit more about what RaaS looks like, check out our previous coverage on this topic (including Inside the RaaS Headlines and How The RaaS Business Model Actually Works).

Huntress TTP observations 

Huntress has observed two Settra ransomware incidents across our customer environments, including an attack in July, and one in September where the Huntress agent was installed mid-incident. That means that the endpoint was already compromised when the Huntress agent was deployed, and the attacker may have still been active afterwards. Huntress analysts did not definitively determine the initial access method into the infrastructure for these two incidents; however, researchers unearthed several notable post-compromise tactics and similarities. 

One such similarity was that across both incidents, the ransomware executable was named for the impacted organization's domain name, appended with _win64.exe.

The July Incident 

One of the first EDR detections for the incident in July was for the MeshAgent RMM, renamed to mvtcs.exe, which pointed to the command-and-control (C2) IP address 45.13.122[.]7. This was followed the next day by the launch of the ransomware executable from the C:\Perflogs folder. Files were then encrypted and renamed with the .locked file extension, and the RESTORE_FILES.txt ransom note was created (Figure 3). 

Once the ransomware executable was launched, EDR telemetry showed several other measures that immediately followed. The threat actor cleared several Windows Event Logs, used reagentc /disable to disable the Windows Recovery Environment, used ipconfig /flushdns to flush the DNS cache, and ran the diskpart native Window utility via a script to remove a recovery partition (the script could not be recovered in either incident). Finally, EDR telemetry showed threat actors using the following command:

cmd.exe /c cipher /w:D:\ >nul 2>&1

This command launched the native Windows cipher utility to overwrite free (previously deleted) space on multiple volumes (in this specific command the D: volume), making deleted data far harder to recover. 

Figure 3: An excerpt from the RESTORE_FILES.txt Settra ransom note

The September Incident

The second occurrence was about two months later, and was the result of the Huntress agent being installed mid-incident. Even so, there was considerable information available for Huntress analysts to piece together the puzzle and develop a picture of the threat actor's activities. 

Figure 4 illustrates signals associated with the detection of BYOVD (gdrv.sys), which is typically installed by threat actors as a way to impact onboard security tooling, crash services related to antivirus applications, and more. Notably, the other Settra incident Huntress observed in July showed no signs of BYOVD. 

Figure 4: Signals indicating the attacker's use of BYOVD and the MeshAgent RMM

In this incident, EDR telemetry also picked up the threat actor installing the MeshAgent RMM. This RMM instance was not renamed, and pointed to the IP address 193.5.65[.]114, which not only appeared in the certificate information for the MeshAgent executable, but was also in the active network connections retrieved from the endpoint at the time of the incident. 

The ransomware executable was launched from the compromised user's Documents folder, and resulted in a similar sequence of actions intended to inhibit recovery. In this incident, the use of the cipher utility was not observed. Encrypted files were appended with the .locked_wip extension, and the ransom note RESTORE_FILES.txt appeared in several folders.

As with the first incident, based on EDR telemetry, the ransomware executable includes embedded commands to disable recovery options, as well as clear several, albeit not all, Windows Event Logs. The list of Windows Event Logs cleared appears as follows:

Application

Security

System

Setup

ForwardedEvents

Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

Microsoft-Windows-TerminalServices-RDPClient/Operational

Microsoft-Windows-Sysmon/Operational

Microsoft-Windows-PowerShell/Operational

Microsoft-Windows-WinRM/Operational

Microsoft-Windows-TaskScheduler/Operational

Microsoft-Windows-Defender/Operational

Looking at the list of Windows Events Logs cleared, it's easy to see why some are included, as clearing them hampers (but does not obviate) digital forensics and incident response activities. However, note that the final Windows Event Log is misspelled; the correct spelling is Microsoft-Windows-Windows-Defender/Operational. As a result, the log was not cleared.

As with the first incident, in this incident the ransomware executable also ran reagentc.exe /disable to disable the Windows Recovery Environment boot image, if one was available, and ran diskpart.exe against a script file. The text of the script could not be recovered, but we assess that the use of the utility was to remove a recovery partition, if one exists. In both incidents, there was no available information to suggest that either option (the use of a Windows Recovery Environment, or the use of a recovery partition) was in active use prior to the compromise. There was also no apparent attempt to determine if this was, in fact, the case. These commands were embedded in the ransomware executable, and launched as a child process of that executable image.

Additional information from this September incident indicates that the workstation name WIN-LIVFRVQFMKO was associated with the malicious activity. This is a workstation name that Huntress analysts have observed associated with other incidents going back to December 24, 2024. In fact, Huntress analysts have observed this workstation name associated with the IP address 193.5.65[.]114 during previous incidents, going back to November 2025, as well as recently as February 2026.

Two Settra incidents: several similar tactics 

While there were slight differences between the two incidents, such as the naming and C2 IP address of the MeshAgent RMM, as well as the folders the threat actors operated from, the overall conduct of the attacks were remarkably similar. Much of the similarities after that occurred due to the commands embedded within the ransomware executable, which again, was named for the impacted organization's domain name, appended with _win64.exe.

Defending against Settra ransomware 

It's not unusual for the Huntress Security Operations Center (SOC) to come across newer ransomware variants like Settra (previously, we observed emerging variants like Crux, KawaLocker, and Cephalus). While new ransomware variants will continue to emerge, many of the TTPs continue to stay the same – whether that's the misuse of RMMs, the use of BYOVD, or attempts by the threat actors to clear Windows Event Logs.

Defenders should continue to focus on the "fundamentals" that can help prevent these types of techniques in the first place. Additionally, they should have a good understanding of the actions that occur post-compromise, in order to build up an aperture for detecting and responding to these attacks before they escalate. 

Indicators of Compromise (IOCs)