Settra Ransomware: The Log Attackers Forgot to Clear

Settra Ransomware: How Attackers Abuse MeshAgent and Vulnerable Drivers, and How SOC Teams Can Catch Them

Last verified: September 18, 2026. This is a fast-moving story, so victim counts and indicators may change.

Quick Answer: Settra is a ransomware group first seen in June 2026. Huntress saw it use MeshAgent, log clearing and recovery tampering in two attacks. Alert on unapproved RMM installs, driver loads and log clearing; secure VPN logins with phishing-resistant MFA.

Picture an attacker who believes they have erased every trace of an intrusion, and one misspelled word leaves the evidence behind. That is roughly what Huntress reported in a recent Settra ransomware case. It is also a good reminder of why ransomware detection and response has to focus on what happens before encryption, not just on the ransom note.

Settra is a relatively new operation. Its tradecraft is not exotic, and that is exactly why it matters. It combines familiar tools with a few well-worn tricks, and the mix is enough to put a mid-sized company in a very bad week.

This post separates what has been confirmed from what is analysis, then walks through the logs, commands and controls a SOC team can use right now.

Table of Contents

• What we know about Settra so far
• The Settra attack chain, step by step
• Why remote monitoring and management (RMM) security matters here
• A realistic scenario: how this looks in a mid-sized manufacturer
• Logs, Event IDs and indicators to watch
• Read-only triage commands
• Prevention and hardening
• Ransomware incident response plan and cyber insurance
• Expert tips
• FAQ
• Conclusion
• Sources

What we know about Settra so far

Three public sources shape most of the picture: Huntress, MOXFIVE and SOCRadar. Cybersecurity Dive summarized the Huntress findings on September 18, 2026.

Huntress investigated two Settra incidents. One hit a consumer services and retail organization in July. The other hit a manufacturing company in September. In the September case, Huntress's agent was installed mid-incident, so the attacker may still have been active on the network.

MOXFIVE, an incident response firm, began tracking Settra in late June 2026. It describes a double-extortion group that steals data, encrypts systems, and threatens to leak files on a Tor-based site. Victims negotiate over Tox, an encrypted chat protocol.

Confirmed (per vendor reports)	Analysis / not confirmed
Two Huntress incidents: July (retail/consumer services), September (manufacturing)	Whether the two intrusions share the same operators is an inference from similar tradecraft
MeshAgent RMM used for persistence in both	Huntress could not confirm how the attackers got in
Ransomware executable named after the victim's domain, ending in _win64.exe	One analysis suggests per-victim builds help operators track targets and blend in
Event log clearing and Windows Recovery Environment tampering in both	Attribution to any wider group or affiliate network
Vulnerable driver abuse seen in the September case (per Huntress)	Whether the July intrusion also used one is unknown; Huntress saw no signs of it
MOXFIVE saw compromised VPN credentials as initial access in its own cases	Exact victim totals; counts differ by source and date

On scale, SC Media, citing SOCRadar data, reported 93 claimed victims. An earlier roundup from The Hacker News cited 70. The gap most likely reflects timing, so treat any single number as a snapshot.

Huntress's Lindsey O'Donnell-Welch called the attackers "capable rather than sophisticated," as quoted by Cybersecurity Dive. That is the key takeaway: standard controls done well would have made this harder.

The Settra attack chain, step by step

1. Initial access: valid accounts, not magic

MOXFIVE reports Settra getting in through compromised VPN credentials and then moving around with those legitimate logins. Public reporting also says the group targets organizations with unpatched systems or weak access management.

Huntress did not confirm the entry point in its two cases. Treat VPN and credential abuse as the most probable route, but not a proven one for every victim.

2. Persistence: MeshAgent as a foothold

In both Huntress incidents, the attackers installed MeshAgent, an open-source remote management agent. In July it was renamed mvtcs.exe. In September it kept its default name. Each instance phoned home to a different address.

The value to an attacker is simple. A legitimate remote management tool gives interactive access that survives beyond the first login session, and it looks like normal IT activity to many tools.

3. Discovery, credentials and lateral movement

According to MOXFIVE, Settra used NetExec and Netscan for network discovery, Procdump and Mimikatz for credential access, and PAExec (similar to PsExec) for lateral movement. These are dual-use tools, which is why behavior-based detection matters more than file names.

4. Defense evasion: blinding the sensors

Both vendors describe vulnerable driver abuse, though in different cases. Huntress saw gdrv.sys in the September incident. MOXFIVE named STProcessMonitor_v114.sys and a tool called edr_blind in its casework.

The technique is often called BYOVD, short for "bring your own vulnerable driver." The attacker loads a legitimately signed driver that has a known weakness, then uses its kernel access to interfere with security tools. ESET's March 2026 research, as summarized by third-party write-ups, catalogued nearly 90 EDR-killer tools, so this is now a mainstream technique rather than an exotic one.

5. Impact: encryption plus recovery sabotage

Once the ransomware ran, commands embedded in the executable went after recovery. Huntress observed:

• Windows Event Logs cleared
• The Windows Recovery Environment disabled with the built-in reagentc utility
• diskpart run against a script, likely to remove a recovery partition (the script was not recovered)
• In July only: a DNS cache flush and the native cipher utility used to overwrite free space on a data drive, making deleted data harder to recover

Encrypted files got a .locked extension in July and .locked_wip in September. The ransom note in both cases was RESTORE_FILES.txt.

Then came the mistake. The September log-clearing list included the Microsoft Defender operational log, but the actors misspelled the channel name. Per Huntress, that log was not cleared, which left defenders a valuable source of evidence.

Why remote monitoring and management (RMM) security matters here

Many organizations run at least one approved RMM tool, and attackers know it. When a second, unapproved one appears, some tools treat it as routine admin activity.

MOXFIVE's guidance is to maintain a strict "default deny" list of approved RMM tools, enforced through EDR rules or web filtering, and to alert on anything else. That advice fits Settra well because MeshAgent shows up in both Huntress cases.

Practical starting point: build an inventory of every sanctioned remote access tool, including the ones your managed service provider uses. Anything outside that list should page someone.

A realistic scenario: how this looks in a mid-sized manufacturer

The following is an illustrative scenario built from the reported tactics. It is not a description of a specific victim.

A plant engineer's VPN credentials show up in a stolen-credentials dump. Someone logs in at 1 a.m. from an unfamiliar network. The VPN accepts it, because the password is correct and MFA is either absent or the type that can be worn down with repeated prompts.

Over the next day, a remote management agent appears on a file server under an unfamiliar name. A credential-dumping tool touches a domain-joined workstation. A driver that nobody in IT recognizes loads on one server shortly before its endpoint agent stops reporting.

The next morning, files carry a strange extension and a text note sits in every folder. The logs that would have explained the previous 48 hours are gone from the affected machines.

Every step in that story leaves a trace somewhere. The job of detection is to make sure those traces land in a place the attacker cannot reach.

Logs, Event IDs and indicators to watch

These are standard Windows and Sysmon events. Availability depends on your audit policy and Sysmon configuration.

Source / Event ID	What it tells you	Why it matters for Settra
Security 1102	Security log was cleared	Log clearing was observed in both Huntress incidents
System 104	A log (such as System) was cleared	Same behavior, different log
System 7045 / Security 4697	A new service was installed	RMM agents and driver services often register this way
Sysmon 6	Driver loaded	Your best window to spot a vulnerable driver before it blinds the sensor
Sysmon 1 / Security 4688	Process creation (4688 needs command-line auditing enabled)	Catches reagentc, diskpart, cipher and unknown executables
Sysmon 10	Process access (watch lsass.exe as the target)	Credential dumping, per MOXFIVE's reported tools
Sysmon 11	File created	Ransom note creation across many folders
Defender 5001 / 5007	Real-time protection disabled / configuration changed	Evidence of security tool tampering

Indicators reported by Huntress (defanged)

Indicator	Context
45.13.122[.]7	MeshAgent command-and-control address, July incident
193.5.65[.]114	MeshAgent command-and-control address, September incident
mvtcs.exe	Renamed MeshAgent, July incident
gdrv.sys	Vulnerable driver, September incident
STProcessMonitor_v114.sys	Vulnerable driver reported by MOXFIVE
RESTORE_FILES.txt	Ransom note
.locked / .locked_wip	Encrypted file extensions
WIN-LIVFRVQFMKO	Workstation name linked to the September activity and earlier incidents
[victim-domain]_win64.exe	Naming pattern of the ransomware executable

One caution on that workstation name. Huntress noted it also appeared in earlier incidents, some dating back to late 2024. That points to reused infrastructure, but it does not prove who is behind Settra.

Read-only triage commands

Run these from an elevated prompt on a suspect Windows host. They only read data and change nothing. Indicators are shared for detection, so do not reproduce the attacker actions listed at the end of this section.

1. Check whether the Security log was cleared

wevtutil qe Security /q:"*[System[(EventID=1102)]]" /c:5 /rd:true /f:text

Use it when logs look suspiciously short. Expected output: no events on a healthy host, or a record showing which account cleared the log and when.

2. Check whether other logs were cleared

wevtutil qe System /q:"*[System[(EventID=104)]]" /c:5 /rd:true /f:text

Expected output: nothing normally. A hit tells you the time window to investigate.

3. Look for Defender being switched off

wevtutil qe "Microsoft-Windows-Windows Defender/Operational" /q:"*[System[(EventID=5001)]]" /c:5 /rd:true /f:text

Expected output: events only if real-time protection was disabled. Compare timestamps with any log clearing.

4. Find services running from unusual locations

Get-CimInstance Win32_Service | Where-Object { $_.PathName -match 'PerfLogs|\\Users\\|\\Temp\\' } | Select-Object Name, State, PathName

Expected output: usually empty. Anything listed deserves a look, since Huntress saw activity launched from C:\Perflogs and user folders.

5. Check the PerfLogs folder for executables

Get-ChildItem C:\PerfLogs -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.Extension -in '.exe','.dll','.sys' } | Select-Object FullName, Length, LastWriteTime

Expected output: normally nothing. Any executable here is worth a hash lookup and a closer look.

6. Check for the flagged driver

Get-CimInstance Win32_SystemDriver | Where-Object { $_.PathName -match 'gdrv|STProcessMonitor' } | Select-Object Name, State, PathName

Expected output: nothing on most fleets. Note that gdrv.sys is a known vulnerable driver historically tied to vendor utilities, so a hit can be legitimate software. Still treat it as high priority and confirm the source.

7. Check Windows Recovery Environment status

reagentc /info

Expected output: a line showing whether Windows RE is enabled or disabled. /info only reports status. Never run /disable on a production machine.

Warning: the attacker actions Huntress observed included reagentc /disable, scripted diskpart use, ipconfig /flushdns and cipher /w. These are destructive or evidence-erasing and are listed only so you can recognize them in EDR telemetry.

Prevention and hardening

Choosing EDR tools that survive tampering

If your endpoint detection and response (EDR) tools can be switched off by a signed driver, you have a single point of failure. Ask vendors specifically about tamper protection, kernel-level self-defense, and alerting when the agent stops reporting.

Also make sure a silent agent is itself an alert. A server that goes quiet during off-hours is a signal, not a network glitch.

Controls that map directly to the reported tactics

• Phishing-resistant MFA on VPN and remote access. MOXFIVE calls this one of the most direct ways to close the credential-abuse gap.
• Vulnerable driver blocking. Microsoft maintains a vulnerable driver blocklist. Confirm it is active on your fleet and add the specific drivers named in vendor reports.
• Application control and memory integrity. Restricting which drivers and executables can run, and enabling hardware-backed protections where supported, shrinks the room attackers have.
• RMM allowlisting. Default deny for remote management tools, with alerts on anything new.
• LSASS monitoring. Alert on unusual access to credential memory.
• Off-host log forwarding. Attackers can clear local logs but not the copy already sitting in your SIEM.
• Egress monitoring. Data theft usually comes before encryption in double extortion, so large outbound transfers to unfamiliar destinations are an early warning.
• Offline, immutable backups. Keep them out of reach of domain accounts. Because Settra tampers with Windows recovery features, do not treat the built-in recovery environment as your plan.

No single control here guarantees protection. Layering them is what raises the cost for the attacker.

Ransomware incident response plan and cyber insurance

If you see the signs above, speed matters more than perfection. A workable first-hour plan looks like this:

1. Isolate suspected hosts from the network while preserving power and memory where your process allows.
2. Disable or reset the VPN accounts involved and review recent remote logins.
3. Pull forwarded logs from your SIEM, since local logs may be gone.
4. Look for unapproved RMM agents across the fleet, not just on the alerting machine.
5. Protect backups by disconnecting them before restoration begins.
6. Bring in your legal, insurance and incident response contacts early.

Insurers often ask about MFA, EDR coverage, backup isolation and logging. Those are the same controls above, so documenting them helps both security and coverage conversations.

On regulatory clocks, rules vary by industry and region. As general examples, GDPR typically expects notification to the supervisory authority within 72 hours of becoming aware of a personal data breach, and public companies in the US may face SEC disclosure timelines once an incident is deemed material. HIPAA has its own breach notification rules for covered entities. This is general information rather than legal advice, so confirm your obligations with counsel.

From a framework view, the story maps cleanly to the NIST Cybersecurity Framework: strong identity controls (Protect), log and behavior monitoring (Detect), a rehearsed plan (Respond), and isolated backups (Recover).

Expert tips

• Hunt the first 24 hours. In the July case Huntress saw MeshAgent the day before the ransomware ran. That gap is your detection window.
• Treat log clearing as a high-severity alert. Legitimate reasons are rare. Events 1102 and 104 should page someone.
• Look for the typo effect. Attackers make mistakes. Check every log source, including ones the attacker probably forgot, like Defender's own operational log.
• Do not trust file names. A renamed MeshAgent is still MeshAgent. Detect by signature, hash, network destination and install behavior.
• Check your MSP's tooling. Know which remote tools your providers use so you can tell friend from foe quickly.
• Rehearse recovery without Windows RE. If your restore plan assumes the recovery partition exists, test what happens when it does not.

Related Cybersecurity Topics You Should Explore

• UAE's AI Lab Tests Every Model for Hidden Risks
  
• Check Point CVE-2026-91843: Root Access, No Login Needed (Patch Now)
  
• Why 40% of Indian SMEs Got Breached Despite Rising Cybersecurity Budgets
  
• cPanel's EmailTrack Bug: How Low-Privilege Users Reach Root Access
  
• 3,562 Redis Servers Hacked for Crypto Mining: Is Your Server Next?
  
• CVE-2026-26084 Explained: Patch FortiSandbox Now
• Fortinet Patches Silent MITM Flaw in FortiOS and FortiProxy ZTNA
  
• Linux cut Command Explained: Extract Any Field, Column, or Character in Seconds

FAQ

What is Settra ransomware?

Settra is a ransomware and data-extortion operation first observed in June 2026. Researchers describe it as a double-extortion group that leaks stolen data on a Tor-based site if victims do not pay.

Is Settra a ransomware-as-a-service operation?

There is no public evidence that it is. Huntress and MOXFIVE both said nothing published so far confirms a RaaS model, and MOXFIVE noted patterns that could point to a very small crew.

How does Settra get into networks?

MOXFIVE observed compromised VPN credentials in its own cases, and public reporting points to unpatched systems and weak access management. Huntress could not confirm the entry point in its two incidents.

Why do attackers install MeshAgent?

It is a legitimate remote management tool that gives persistent, interactive access and can blend into normal IT activity. That is why an RMM allowlist is such a useful control.

What is a BYOVD attack?

BYOVD stands for "bring your own vulnerable driver." Attackers load a signed driver with a known weakness and use its kernel-level access to disable or interfere with security tools.

Which industries has Settra targeted?

Huntress saw retail/consumer services and manufacturing. MOXFIVE lists retail and hospitality, manufacturing, professional services, construction and engineering, and food and beverage among claimed victims, and describes the targeting as opportunistic rather than sector-specific.

Conclusion

Settra does not need a novel toolkit. Valid credentials, a remote management agent, a vulnerable driver and a few built-in Windows utilities were enough to cause serious disruption in the reported cases.

The encouraging part is that every stage leaves a trace: a new agent, a driver load, a cleared log, a disabled recovery feature. Catch any one of them early and encryption may never happen.

If this was useful, share it with your SOC or IT team, and tell us in the comments which of these controls you find hardest to roll out.

Analysis based on SOC monitoring and public threat intelligence review.