Settra ransomware appears in retail and manufacturing intrusions

Cybersecurity researchers have documented two attacks involving Settra ransomware, exposing a repeatable post-compromise playbook that combines legitimate remote-management software, recovery sabotage and efforts to erase forensic evidence.

Huntress said the incidents affected a consumer services and retail organisation in July and a manufacturing company in September. Settra was first observed publicly in June, but the two investigations provide fresh detail on how operators maintain access after compromise and prepare systems for encryption.

Researchers could not determine the initial access method in either Huntress case. Separate incident-response work has linked Settra activity to compromised virtual private network credentials and previously obtained account credentials, but Huntress cautioned that those routes were not confirmed in the two intrusions it analysed.

Both attacks involved MeshAgent, a legitimate remote monitoring and management tool, which was used to maintain persistent access. The ransomware executables were also tailored to the victims, with filenames based on each organisation’s domain followed by “_win64. exe”, Huntress said.

The July intrusion first produced endpoint detection alerts for MeshAgent, which had been renamed “mvtcs. exe” and configured to communicate with the command-and-control address 45.13.122[.]7. The following day, attackers launched the ransomware executable from the C:Perflogs directory.

Files were encrypted and given the “. locked” extension, while a ransom note named RESTORE_FILES. txt was placed on the system. Telemetry then showed commands designed to frustrate recovery and investigation, including clearing several Windows Event Logs, disabling the Windows Recovery Environment and flushing the DNS cache.

The attackers also executed the Windows diskpart utility through a script that Huntress assessed was intended to remove a recovery partition. Another command invoked the native cipher utility to overwrite free space on drives, making previously deleted material more difficult to recover.

The September manufacturing incident followed a closely related pattern. Huntress was installed while the intrusion was already under way, allowing analysts to capture evidence of the attacker’s activity despite not observing the initial breach.

MeshAgent was again installed, this time without being renamed, and connected to 193.5.65[.]114. The ransomware executable was launched from a compromised user’s Documents folder. Encrypted files received the “. lockedwip” extension and the same RESTOREFILES. txt ransom note appeared in multiple folders.

Investigators also found evidence of a bring-your-own-vulnerable-driver technique involving “gdrv. sys”. Such tactics exploit legitimate but vulnerable drivers to interfere with endpoint security products or other defensive services. Huntress did not observe the same driver activity in the July case.

The ransomware attempted to clear a broad set of Windows logs covering security, PowerShell, remote desktop, task scheduling and other activity. One attempted deletion failed because the attackers misspelled the Windows Defender event log path, leaving that log available to investigators.

As in July, the malware launched commands to disable the Windows Recovery Environment and called diskpart against a script. Huntress said it could not recover the script itself, but assessed that it was probably intended to remove an available recovery partition. The company found no evidence that the attackers first checked whether those recovery features were actively being used.

A workstation name seen in the September incident, WIN-LIVFRVQFMKO, had appeared in other malicious activity observed by Huntress going back to December 2024. The same name had also been associated with the September command-and-control address during earlier investigations, indicating infrastructure or operational overlap.

Cynet Research Labs, analysing a Settra payload obtained during a separate incident-response case, found that the ransomware’s inner encryptor was stored inside an encrypted blob and required an operator-supplied password before execution. An incorrect or missing password caused the program to terminate, a design that can complicate automated malware analysis.

Cynet said the loader also checked for an attached debugger and dynamically resolved Windows programming interfaces. Once researchers obtained the victim-specific password used in the attack, they were able to extract and examine the inner Windows encryptor.