Settra: The Log Typo That Confirmed Traces of a New Ransomware

The Settra ransomware variant, observed since June 2026, hit two targets in the retail and manufacturing sectors using rigorously standardized post-compromise tactics. A spelling error in the Windows Defender Event Log path, made during the second incident in September 2026, prevented the log's deletion and left Huntress analysts a partial timeline of malicious activity. The detail did not reveal the operation — already identified as ransomware — but confirmed traces useful for reconstructing the attack timeline.

Key Takeaways

Settra has been active since June 2026; Huntress directly investigated two incidents, in July 2026 (retail) and September 2026 (manufacturing).
MeshAgent RMM was abused in both attacks for persistence, with different C2 IPs: 45.13.122.7 and 193.5.65.114.
Anti-recovery techniques include disabling Windows RE, removing the recovery partition, overwriting free space with cipher, and deleting event logs.
A typo in the Windows Defender log path prevented its deletion in the second incident, leaving forensic traces.
The gdrv.sys driver was observed only in the second incident; the initial access vector remains unconfirmed in both.

The Operational Pattern: Standardization and Minimal Adaptation

The methodological consistency across the two attacks is the distinguishing trait documented by Huntress. In both incidents, the threat actor deployed MeshAgent RMM to maintain persistent access. In the first case, in July 2026 in the consumer services/retail sector, the executable was renamed mvtcs.exe and connected to a C2 server at IP 45.13.122.7. In the second incident, in September 2026 in the manufacturing sector, MeshAgent connected to 193.5.65.114.

The ransomware executables follow a naming convention: the victim's domain concatenated with _win64.exe. The encrypted file extensions differ — .locked in the first incident, .locked_wip in the second — but both present the RESTORE_FILES.txt ransom note. According to Huntress researchers, the differences between the two attacks were minimal: MeshAgent naming and IP, threat actor working directories, but the overall conduct was remarkably similar.

"They used established, functional ransomware techniques: MeshAgent for persistence, a vulnerable driver to potentially compromise defenses, log deletion, and recovery tampering."
— Lindsey O'Donnell-Welch, principal technical community engagement writer at Huntress [original text in English]

Sabotaging Recovery Mechanisms

Settra implements a methodical anti-recovery sequence. The operators disabled the Windows Recovery Environment via reagentc /disable, removed the recovery partition with diskpart, overwrote free space with cipher /w, and deleted Windows Event Logs. They also ran ipconfig /flushdns to clear local DNS resolutions.

This combination of native Windows commands indicates an explicit objective: prevent data recovery without paying the ransom and make post-incident forensic analysis more difficult. The deletion of system logs aims to obscure the history of actions taken during the post-compromise phase.

The Typo and Its Forensic Consequences

In the second incident, the threat actor attempted to delete the Windows Defender operational log but made a spelling error in the file path. The correct path, Microsoft-Windows-Windows-Defender/Operational, was entered with a typo that prevented the command from executing. The log remained intact, providing analysts a partial timeline of malicious activity.

The detail assumes analytical relevance because it places the operation in a specific tier of the threat landscape. According to O'Donnell-Welch, the attackers "could be described as capable rather than sophisticated." The group possesses functional tools and a replicable methodology, but its operational precision is not that of top-tier actors.

The workstation WIN-LIVFRVQFMKO, associated with the September 2026 activity, had been observed in previous incidents dating back to December 2024. This element suggests possible infrastructure reuse or recurring naming preferences, but does not allow definitive connections to other operations.

BYOVD with gdrv.sys: An Element of the Second Incident

The second incident included the use of the vulnerable driver gdrv.sys in a BYOVD (Bring Your Own Vulnerable Driver) configuration. This driver, known to have been abused by multiple threats to achieve kernel-level execution, was observed on the compromised system in September 2026. Huntress did not document its presence in the first incident in July.

The use of gdrv.sys — a legitimate, signed driver with known vulnerabilities — indicates a documented operational choice in the threat landscape, not an original development. The binary is widely available, which lowers the barrier to use.

What This Changes

Huntress's analysis provides elements to contextualize Settra within the current ransomware threat landscape. The standardization of TTPs, rather than technical innovation, emerges as the central characteristic of the operation. MeshAgent, an open-source RMM, was abused in both incidents with slightly modified configurations — altered name, different C2 IP — but with the same persistence function.

The datum that most distinguishes Settra is the combination of rigorous methodology and executional imprecision. The typo in the log path is not a marginal detail: it is the point where the threat actor's standardized procedure met human error, with measurable consequences for the investigation. For analysts, this type of trace is often more durable than the technical tools employed.

Data on 93 total claimed victims and 4 with confirmed data leaks, reported by third-party sources (SOCRadar and MoxFive) and cited by SC World, have not been directly verified by Huntress. Huntress also could not confirm the initial access vector in either of the two investigated incidents, and does not believe sufficient evidence exists to classify Settra as a RaaS operation.

Editorial Close

Settra represents a class of threat that relies on operational replicability rather than technical sophistication. Its profile — functional capabilities, TTP standardization, executional imprecision — is that of an actor leveraging existing tools with efficiency but without excellence. The log typo did not unmask the operation, but it confirmed that even threats with consolidated methodologies leave traces when procedure meets human error. For organizations, this means visibility into system logs and monitoring of RMM tools remain relevant defensive elements, even against non-top-tier actors.

Sources: Huntress (primary analysis); Infosecurity Magazine, Cybersecurity Dive, SC World (corroboration and third-party data). Data on total victims and data leaks come from SOCRadar and MoxFive, not independently verified by Huntress. The initial access vector is unconfirmed.

Information has been verified against cited sources and updated at time of publication.

Sources

Sources and references

Get DeafLetter