Settra Ransomware: 93 Victims in Four Months Using Your Own VPN Against You

A ransomware group called Settra has been quietly building a victim list since June 2026, and the numbers are moving fast: researchers have documented 93 claimed victims in under four months. Huntress published a detailed technical breakdown this week after investigating two confirmed intrusions — one in July at a retail organization, one in September at a manufacturing firm. The playbook Settra is running is a textbook example of how a mid-tier ransomware operation can punch well above its weight by recycling legitimate tooling and staying off custom-malware radars.

Who Gets Hit

Settra's victim list, as documented by Huntress and corroborated by MoxFive and SOCRadar tracking of the group's data-leak site, skews heavily toward exactly the kinds of organizations that often underinvest in security: retail and hospitality, manufacturing and production, professional services, construction and engineering, and food and beverage. These are businesses that depend heavily on uptime, have real sensitive data (customer records, financials, supplier contracts), and frequently run with lean IT teams. They are not Fortune 500 targets — they are the businesses that make up the bulk of the web-hosting market.

Getting In: The VPN Front Door

Settra's most common initial access vector is compromised VPN credentials. That means either credentials purchased from an initial-access broker, harvested through phishing or credential-stuffing, or obtained via a previously breached account that was never rotated. The group also exploits unpatched software where credentials alone aren't available. Either way, they arrive through a legitimate entry point — which is why detection during the first stage of an intrusion is so hard without proper network-anomaly monitoring.

The takeaway here isn't subtle: if your VPN authenticates on username and password alone, or if any admin accounts share passwords with other services, you have already handed attackers a key. Settra is one of many groups who knows it.

Staying In: MeshAgent as a Weapon

Once inside, Settra installs MeshAgent, the open-source agent component of MeshCentral — a fully legitimate remote monitoring and management (RMM) platform. In the July incident, the binary was renamed to mvtcs.exe and configured to phone home to a Settra-controlled server at 45.13.122[.]7. In September, the attackers left the binary unmodified and used a different C2 at 193.5.65[.]114.

MeshAgent gives the operators a persistent, encrypted remote-access channel that most security tools treat as benign because the software is genuinely benign in legitimate use. It lets them stage tools, run commands, and time the final encryption push without relying on noisy custom malware. Huntress observed roughly one day between the moment MeshAgent was deployed and the moment ransomware executables fired — enough time to map the environment and stage the payload, not so long that defenders are likely to notice.

Killing Defenses: BYOVD and the Gigabyte Driver

In the September incident, Huntress found evidence of a Bring Your Own Vulnerable Driver (BYOVD) technique. Attackers dropped gdrv.sys, a legitimate but vulnerable Gigabyte kernel driver, to gain kernel-level access and crash or disable endpoint security services before the encryption payload ran. Running a signed, known-good driver through Windows kernel trust mechanisms is a well-documented technique for neutralizing endpoint detection and response tools, and it works precisely because the driver itself isn't malicious — only the code using it is.

Burning the Evidence and the Recovery Path

After encryption, Settra spends real effort on cleanup. In both incidents, operators issued commands to clear a wide range of Windows Event Logs: Application, Security, System, Setup, ForwardedEvents, TerminalServices, Sysmon, PowerShell, WinRM, TaskScheduler, and Defender channels. They also ran reagentc /disable to kill the Windows Recovery Environment and used diskpart.exe scripts to delete recovery partitions. In the July case they ran cipher /w:D: to overwrite free space on the data volume, making forensic recovery of deleted files harder.

Here is where Settra handed defenders a small gift: in the September incident, the operator misspelled the Windows Defender Event Log channel name when issuing the clearing command. The Defender log survived intact. That single logging artifact became evidence of what had happened and part of the forensic chain. It is a reminder that logs forwarded off-box — to a SIEM, a cloud log service, anywhere the ransomware operators cannot reach — are often the only forensic trail left and the fastest path to understanding what happened before the encryption clock started.

Ransom notes drop as RESTORE_FILES.txt in multiple folders. Encrypted files get the .locked extension (July) or .locked_wip (September), and the ransomware binary itself is compiled with the victim's domain name baked in — victimcompany_win64.exe — suggesting victim-specific builds and at least moderate operational discipline.

What to Do Right Now

• Enforce MFA on every VPN login. A compromised credential is inert against an MFA prompt an attacker cannot satisfy. This single control stops the most common Settra entry vector cold.
• Audit your RMM inventory. Know which RMM agents are authorized on which machines. An instance of MeshAgent (or any agent) that your IT team didn't install is an intrusion indicator, not a misconfiguration.
• Ship logs off-box in real time. Settra's operators clear local Event Logs before they leave. If those logs only exist locally, they're gone. If they're streaming to a remote SIEM or log aggregator, they survive. In September, a typo saved the forensics — don't make that your plan.
• Protect Windows Recovery and backups separately. Settra disables the Windows Recovery Environment and removes recovery partitions. Backups stored on the same network the ransomware can reach get encrypted along with everything else. Offsite or immutable backup storage that requires separate credentials to modify is what gets you back online without paying.
• Patch VPN appliances, not just servers. Unpatched VPN concentrators are the other confirmed entry vector. Treat your VPN firmware like you treat your operating system patches: apply them promptly and don't let them slide because rebooting the VPN is inconvenient.
• Alert on suspicious driver drops. gdrv.sys and similar vulnerable drivers appearing on endpoints outside a sanctioned update process are strong BYOVD indicators. Modern EDR tools can detect known-vulnerable drivers; make sure the alert isn't silenced.

Settra is four months old and has 93 claimed victims. At that pace, this group will be a household name in incident response circles by year-end. The tradecraft they're using — credential-stuffed VPN access, repurposed RMM for persistence, kernel-level defense evasion — is not exotic. It's available to any moderately organized criminal group willing to put in the preparation work. At Falcon Internet, logging and restore testing aren't afterthoughts; they're the disciplines that determine whether a ransomware incident becomes an afternoon or a month-long disaster.