Settra ransomware is emerging as a serious threat to Windows networks after investigators linked it to two recent intrusions involving remote-management software and recovery-blocking actions.
The operation encrypts files, leaves victims with ransom notes, and tries to make both investigation and restoration more difficult. Public reporting indicates that the people behind Settra have gained entry through virtual private networks or previously stolen credentials.
That makes exposed remote access and weak account controls a central concern, while the use of legitimate administration software reflects the wider misuse of remote management tools in intrusions.
Analysts from Huntress identified two incidents, one affecting a consumer services and retail organization in July and another affecting a manufacturing company in September.
They could not confirm how either network was first breached, but found an almost identical post-compromise pattern in both cases.
Huntress said in a report shared with Cyber Security News (CSN) that the activity matters because it combines rapid encryption with actions designed to limit recovery and erase useful evidence.
In each case, the ransomware executable used a name based on the affected organization’s domain, a choice that may help it appear less out of place on a compromised system.
New SETTRA Ransomware
Settra operators installed MeshAgent, a remote monitoring and management tool, after gaining access. Such tools can give attackers a reliable way to maintain control of a machine, execute commands, and advance their operation without relying only on custom malware.
A separate FortiGate intrusion using MeshAgent likewise showed how RMM utilities can be repurposed after a network breach. In the July incident, the MeshAgent program was renamed and reached an attacker-controlled command-and-control server.
The next day, researchers observed the ransomware run from a Windows performance-log directory, encrypt files with a unique extension, and create a ransom note.
The September incident contained evidence of BYOVD, or Bring Your Own Vulnerable Driver. This approach uses a legitimate but flawed driver to interfere with defensive software, potentially allowing an intruder to disable security services before encryption.
Recent reporting on trusted Windows drivers shows why this technique has become a recurring concern in ransomware investigations.
MeshAgent in the September intrusion was not renamed and connected to a different command-and-control server.
The ransomware launched from the compromised user’s Documents folder, used another file extension, and placed ransom notes in multiple directories. Researchers also connected the malicious activity to a workstation name previously observed alongside that server.
Recovery Disruption Raises Response Pressure
After launching the ransomware, the attackers cleared several Windows Event Logs and disabled the Windows Recovery Environment. They also used DiskPart in both incidents, apparently to remove a recovery partition, and flushed the DNS cache in July.
These steps can delay recovery while reducing the evidence available to responders. In the July case, Settra also ran the Windows Cipher utility to overwrite free space on a data drive.
That action can make deleted material harder to retrieve. In September, the operators attempted to remove Defender logging but misspelled the log channel name, leaving the Windows Defender Event Log intact. Central collection of Windows event logs can preserve evidence when attackers try to erase local records.
Organizations should focus on basic controls that disrupt this chain early: protect VPN access with strong authentication, restrict and monitor remote-management tools, and investigate unexpected driver installations or suspicious processes launched from user folders and Windows system directories.
Teams should also maintain tested, offline or otherwise protected backups and verify that recovery features remain available. They should also test response playbooks against simulated encryption events, including loss of endpoint visibility.
This reduces the chance an incident becomes a crisis. The two cases show that Settra does not need an entirely new toolkit to create major disruption.
Familiar tools, vulnerable drivers, and built-in Windows utilities can be combined to put defenders under pressure quickly. Fast detection of abnormal RMM activity, protected logs, and rehearsed recovery procedures remain important safeguards.
Indicators of compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| IP address | 45.13.122[.]7 | MeshAgent command-and-control address in the July incident |
| IP address | 193.5.65[.]114 | MeshAgent command-and-control address in the September incident |
| File name | mvtcs.exe | Renamed MeshAgent executable identified in the July incident |
| File name pattern | | Ransomware executable naming pattern observed in both incidents |
| Workstation name | WIN-LIVFRVQFMKO | Workstation associated with September activity and prior incidents |
| File name | RESTORE_FILES.txt | Ransom note created in both incidents |
| Driver file | gdrv.sys | BYOVD filename observed in the September incident |
| File extension | .locked_wip | Extension added to encrypted files in the September incident |
| File extension | .locked | Extension added to encrypted files in the July incident |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC
