Settra ransomware tries to blind the forensics team on its way out. The encryptor runs a hard-coded list of Windows event logs and wipes them: Application, Security, System, PowerShell, Sysmon, Task Scheduler, the Remote Desktop logs. Twelve in all. One of the twelve is spelled wrong.
The list asks Windows to clear Microsoft-Windows-Defender/Operational. The log is actually called Microsoft-Windows-Windows-Defender/Operational, with the word repeated. So it survived, and Defender's own record of what happened on that machine was still sitting there when Huntress arrived.
Two victims, one familiar playbook
Huntress has now worked two Settra intrusions and published its analysis of both: one in July at a consumer services and retail company, one in September at a manufacturer. Settra first surfaced in June, and IntelFusions noted earlier this month that it had quietly become one of the busier extortion crews. Nobody has published evidence that it runs as a ransomware-as-a-service operation, and Huntress is careful to say so.
Neither investigation pinned down how the attackers got in, though MoxFive reported in July that the group was compromising VPNs and reusing stolen credentials.
The encryptor wears the victim's name
What ties the two cases together is small and strange: in both, the ransomware executable was named after the victim's own domain name, with _win64.exe on the end. Somebody configured a payload per target before running it.
The tooling matched too. In July, Huntress' first detection was MeshAgent, a legitimate remote monitoring tool, renamed to mvtcs.exe and calling 45[.]13[.]122[.]7. The ransomware ran the next day out of C:\Perflogs, encrypting files to a .locked extension and dropping a RESTORE_FILES.txt note. In September MeshAgent turned up again, unrenamed, pointed at 193[.]5[.]65[.]114 and paired with gdrv.sys, a flawed but legitimate driver loaded to knock security tools over from kernel level. The July case showed no sign of that.
Burning the recovery options, checked or not
Both encryptors carried the same embedded clean-up commands, launched as child processes of the ransomware. They ran reagentc /disable to switch off the Windows Recovery Environment, flushed the DNS cache, and drove diskpart through a script Huntress couldn't recover but assesses was there to delete a recovery partition. In July they also ran the built-in cipher utility with /w, overwriting free space so deleted files are far harder to recover.
Huntress makes a pointed observation: nothing suggested the victims used a recovery partition or the recovery environment at all, and there was no apparent attempt to check. The payload just runs the list.
The same workstation, going back to 2024
The September activity carried the workstation name WIN-LIVFRVQFMKO, which Huntress says it has seen in incidents as far back as 24 December 2024, and alongside that same 193[.]5[.]65[.]114 address in November 2025 and February 2026. Whoever is behind the keyboard has been reusing infrastructure for years.
Alert on MeshAgent nobody requested
There's no patch here; none of this is a vulnerability in your software. Huntress' advice is to get the fundamentals right and know what post-compromise activity looks like. From these two cases: alert on remote monitoring tools appearing without a change ticket, especially MeshAgent; treat a new kernel driver service such as gdrv.sys as an incident; and alarm on reagentc /disable, diskpart against a script file, and cipher /w. Forward event logs off the host, because the local copies go first.
Indicators
- 45[.]13[.]122[.]7, MeshAgent command and control in July; the agent was renamed mvtcs.exe
- 193[.]5[.]65[.]114, MeshAgent command and control in September
- WIN-LIVFRVQFMKO, attacker workstation name seen since December 2024
- gdrv.sys, the vulnerable driver dropped in September
- RESTORE_FILES.txt, the ransom note in both cases; .locked and .locked_wip file extensions
Huntress credits Adam Mooney and Jamie Dumas for the investigation. It's worth sitting with how thin the margin was. Defender's log survived not because anybody defended it, but because a criminal developer typed a product name from memory.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.