Settra Ransomware: The Attack Chain Behind a Misspelled Log Channel
In September 2026, Huntress caught a ransomware group mid-incident at a manufacturing company. The attackers had covered almost every track — cleared Windows Event Logs, disabled Windows Recovery via reagentc, loaded a vulnerable signed driver to blind EDR at the kernel level.
Except they misspelled the Defender operational log's channel name while trying to clear it. That log survived and became key evidence.
This is Settra — a double-extortion group tracked by Huntress and MOXFIVE since June 2026, with 93 claimed victims so far. What makes it worth a deep dive isn't novel tooling, it's that the entire chain runs on things most SOCs already have visibility into, if they're watching the right signals:
→ Compromised VPN credentials (no MFA bypass exploit — just weak or absent phishing-resistant MFA)
→ MeshAgent (legit open-source RMM tool) installed for persistence, sometimes renamed
→ NetExec, Mimikatz, PAExec for discovery, credential dumping, and lateral movement
→ BYOVD (bring-your-own-vulnerable-driver) to disable EDR — gdrv.sys in one case
→ reagentc, diskpart, and cipher abused post-encryption to sabotage recovery
I wrote up the full breakdown with the specific Windows/Sysmon Event IDs to alert on (1102, 104, Sysmon 6, 4688, Defender 5001/5007), read-only PowerShell/wevtutil commands for triage, confirmed IOCs, and prevention controls mapped to each attack stage.
If you're building detections or just want to understand how BYOVD attacks actually work in the wild, it's here:
https://www.xpert4cyber.com/2026/09/settra-ransomware-meshagent-detection.html
Curious if anyone here has dealt with BYOVD detection specifically — what's worked for catching a driver load before it kills your EDR agent?
Top comments (0)