Settra Ransomware Targets Retail and Manufacturing

Executive Summary

Security researchers at Huntress have detailed the tactics of a new ransomware group known as Settra, which has been actively targeting the retail and manufacturing sectors since at least June 2026. The group employs a consistent and effective post-compromise playbook, leveraging the open-source Remote Monitoring and Management (RMM) tool MeshAgent for persistent access. To hinder recovery and forensic analysis, Settra operators systematically clear Windows Event Logs and disable the Windows Recovery Environment. In a recent incident, the attackers also utilized a Bring Your Own Vulnerable Driver (BYOVD) technique, using a legitimate Gigabyte kernel driver (gdrv.sys) to bypass security controls. The group practices double extortion, threatening to leak stolen data on its leak site.

Threat Overview

The Settra ransomware group has been operational since at least June 2026 and has claimed 93 victims according to intelligence from SOCRadar. While initial access vectors vary, they are thought to include compromised VPN credentials and exploitation of unpatched software. Once inside a network, the threat actors follow a clear pattern of activity focused on establishing persistence, disabling defenses, and preventing recovery before deploying the final ransomware payload.

Technical Analysis

Analysis of two recent incidents by Huntress reveals a structured attack chain:

1. Persistence: The attackers deploy the open-source RMM tool MeshAgent to maintain access. This tool was observed named mvtcs.exe in one case, a common tactic to masquerade as a legitimate process. This aligns with T1219 - Remote Access Software.
2. Defense Evasion: Settra operators take multiple steps to evade detection and hinder response:
   • Clear Event Logs: They use commands to clear critical Windows Event Logs, including Application, Security, Setup, and System. This is a direct implementation of T1070.001 - Clear Windows Event Logs.
   • Disable Recovery: The attackers disable the Windows Recovery Environment using the command reagentc /disable and have been seen attempting to delete the recovery partition with diskpart. This is a form of T1490 - Inhibit System Recovery.
   • BYOVD: In a September 2026 attack, the group used a Bring Your Own Vulnerable Driver technique by installing the legitimate but vulnerable Gigabyte driver gdrv.sys. This driver is often abused to terminate security processes from the kernel level, a tactic mapped to T1562.001 - Disable or Modify Tools.
3. Impact: The final ransomware payload is deployed, typically named after the victim's domain (e.g., victimdomain_win64.exe). The ransomware encrypts files (T1486 - Data Encrypted for Impact) and the group exfiltrates data for double extortion.

Impact Assessment

An attack by the Settra ransomware group can be devastating for targeted organizations, particularly in the manufacturing and retail sectors. The encryption of critical data can halt production lines, disrupt supply chains, and stop sales operations. The group's focus on disabling recovery options makes restoration from backups more difficult and time-consuming, increasing pressure on the victim to pay the ransom. The double extortion tactic adds the risk of reputational damage, regulatory fines, and loss of customer trust if sensitive data is leaked publicly.

IOCs — Directly from Articles

Cyber Observables — Hunting Hints

The following patterns could indicate related activity:

• Process Creation: Monitor for the execution of reagentc.exe with the /disable command line argument. This is a strong indicator of an attempt to inhibit system recovery.
• File System: Look for the presence of gdrv.sys in unusual locations or the installation of new, unsigned drivers. Monitor for the creation of executables named after your own domain, such as mydomain_win64.exe.
• Network Traffic: Monitor for outbound connections to unknown domains or IP addresses on ports commonly used by RMM tools like MeshAgent. Baseline legitimate RMM traffic and alert on deviations.
• Event Log Clearing: While the logs may be cleared, the act of clearing them often generates a specific event (Event ID 1102 in the Security log) just before the log is wiped. If this event is forwarded to a SIEM in real-time, it can serve as a high-fidelity alert.

Detection & Response

• EDR/EPP: Endpoint solutions should be configured to detect and block the execution of known malicious RMM tools and the loading of known vulnerable drivers like gdrv.sys. Use D3-PA: Process Analysis to detect suspicious command-line activity like reagentc /disable.
• Log Forwarding: Ensure all critical endpoint and server logs, especially security event logs, are forwarded to a centralized, immutable SIEM. This preserves evidence even if the local logs are cleared by the attacker.
• Driver Blacklisting: Implement application control policies to blacklist the loading of known vulnerable drivers, including gdrv.sys.
• RMM Monitoring: Strictly control and monitor the use of all RMM software in the environment. Any unauthorized RMM installation should trigger an immediate high-priority alert.

Mitigation

• Restrict RMM Tools: If not required for business operations, block the execution of common RMM tools like MeshAgent using application control policies (D3-EDL: Executable Denylisting). If required, strictly limit their use to authorized personnel and monitor all activity.
• Backup and Recovery: Maintain regular, offline, and immutable backups of critical data and systems. Routinely test the recovery process to ensure it is effective and not reliant on the Windows Recovery Environment.
• Patch Management: Aggressively patch internet-facing systems and software to prevent initial access via exploitation.
• User Account Control: Enforce the principle of least privilege. Standard user accounts should not have permissions to install software or drivers.