Settra Ransomware Recovery: What's Recoverable

Settra is a ransomware group first observed in June 2026. In September 2026 it posted 15 victims on its leak site, more than half of them in the United States (ransomware.live data), which put it among the twenty most active groups that month. Its victims are mostly in consumer services, retail and manufacturing.

The most detailed public analysis is by Huntress, who investigated two Settra intrusions in July and September 2026. This page summarises what is known and what it means for recovering the data.

Settra typically uses compromised credentials, including VPN credentials, and unpatched software. In the cases Huntress investigated, the attackers installed MeshAgent, a legitimate open-source remote management tool: once under a renamed file name (mvtcs.exe), once under its own. An unexpected MeshAgent installation is therefore a strong sign of an intrusion.

In one incident the attackers also dropped gdrv.sys, a legitimate but vulnerable Gigabyte driver, to get kernel access and stop the endpoint security software (a technique known as bring your own vulnerable driver, BYOVD). Stolen data is copied out with Rclone before the encryption starts.

Encrypted files get a .locked or .locked_wip extension, and a ransom note named RESTORE_FILES.txt is left behind. Before encrypting, the operators clear the Windows event logs and switch off the Windows recovery features with reagentc and diskpart, so the built-in ways back are gone. The group also publishes stolen data of victims who do not pay (double extortion).

How much of each large file Settra encrypts has not been published. That is the figure that decides recovery: if databases, virtual disks and backup files were only partly encrypted, their intact parts can be read without the key. It is measured on the encrypted files themselves.

Isolate the affected systems, but do not wipe, reinstall or "clean" anything yet, and do not run decryptors found online on your only copy. Keep the ransom note, a few encrypted files and, if you have them, unencrypted copies of the same files from before the attack: comparing the two shows exactly how the files were encrypted.

Then establish what is recoverable before deciding anything else: how much of each database, virtual disk and backup file was encrypted, and what the untouched parts still hold. Large files are often only partly encrypted, and that is where recovery without the key comes from.