Researchers at Huntress have detailed two ransomware incidents involving Settra, a relatively new strain first observed in June, and revealed a consistent set of post-compromise tactics defenders can use to spot the threat before encryption takes hold.
In a blog post published this week, Huntress researchers Harlan Carvey and Lindsey O’Donnell-Welch said the company had investigated two Settra attacks since July: one at a consumer services and retail organisation, and a second, in September, at a manufacturing firm. In the more recent case, the Huntress agent was only installed after the environment had already been compromised, meaning the attacker may still have been active on the network at the time.
Huntress said it was unable to confirm exactly how the attackers first gained access in either case. However, prior public reporting, including analysis published in July by incident response firm MoxFive, has linked Settra activity to compromised VPNs and stolen credentials as likely initial access routes.
A repeatable playbook
Despite occurring roughly two months apart and at unrelated organisations, the two intrusions followed a strikingly similar pattern. In both cases, the ransomware executable was named after the victim’s own domain, with “_win64.exe” appended, and both incidents saw the attackers deploy the legitimate MeshAgent remote monitoring and management (RMM) tool to maintain persistent access.
In the July incident, MeshAgent was renamed to mvtcs.exe and communicated with a command-and-control address at 45.13.122[.]7. The ransomware binary itself was launched a day later from the C:\Perflogs folder, encrypting files with a “.locked” extension and dropping a ransom note titled RESTORE_FILES.txt. The attackers went on to clear multiple Windows Event Logs, disable the Windows Recovery Environment using reagentc /disable, flush the DNS cache, and run diskpart to remove a recovery partition. They also used the native Windows cipher utility to overwrite free disk space, making file recovery significantly harder.
In the September incident, MeshAgent was left under its default name and pointed to a different C2 address, 193.5.65[.]114, an IP address also found in the tool’s certificate metadata and in active connections on the compromised endpoint at the time. Encrypted files carried a “.locked_wip” extension, and the ransomware was launched from the compromised user’s Documents folder rather than Perflogs. Unlike the July case, this intrusion showed evidence of Bring Your Own Vulnerable Driver (BYOVD) activity, via a driver named gdrv.sys, a technique typically used to disable or blind endpoint security tools.
A telling typo
One detail stood out to Huntress analysts: while the ransomware attempted to clear twelve separate Windows Event Logs during the September attack, one entry in the list was misspelled, referencing “Microsoft-Windows-Defender/Operational” instead of the correct “Microsoft-Windows-Windows-Defender/Operational”. As a result, that particular log survived the clean-up attempt, inadvertently leaving investigators an extra source of forensic evidence.
Huntress also linked the September attack to a workstation named WIN-LIVFRVQFMKO, which its analysts said they had observed in connection with unrelated incidents dating back to December 2024, and which had previously been tied to the same 193.5.65[.]114 IP address as far back as November 2025.
Part of a wider pattern
Huntress noted that Settra is the latest in a string of emerging ransomware variants its SOC has tracked this year, following strains such as Crux, KawaLocker and Cephalus. While the researchers said there is currently no public evidence that Settra operates on a ransomware-as-a-service (RaaS) basis, they stressed that the underlying techniques on display (RMM abuse, BYOVD, and attempts to erase Windows Event Logs) remain common across many ransomware operations, regardless of branding.
The researchers urged defenders to keep a close eye on unexpected RMM installations, monitor for attempts to disable Windows recovery options or clear event logs, and maintain strong detection coverage of post-compromise behaviour rather than relying solely on preventing initial access.
Huntress published indicators of compromise from both incidents, including the two MeshAgent C2 addresses, the malicious workstation name, the RESTORE_FILES.txt ransom note, the gdrv.sys driver, and the two file extensions used to mark encrypted files.
