Settra: il typo nel log che ha confermato le tracce di un nuovo ransomware

Settra, variante ransomware osservata dal giugno 2026, ha colpito due obiettivi nei settori retail e manufacturing con tattiche post-compromissione rigorosamente standardizzate. Un errore di spelling nel path del Windows Defender Event Log, commesso durante il secondo incidente a settembre 2026, ha impedito la cancellazione del log e lasciato agli analisti di Huntress una linea temporale parziale delle attività malevole. Il dettaglio non ha rivelato l'operazione — già identificata come ransomware — ma ha confermato tracce utili per ricostruire la cronologia dell'attacco.

Il pattern operativo: standardizzazione e minimi adattamenti

La costanza metodologica tra i due attacchi è il tratto distintivo documentato da Huntress. In entrambi gli incidenti, il threat actor ha distribuito MeshAgent RMM per mantenere l'accesso persistente. Nel primo caso, a luglio 2026 nel settore consumer services/retail, l'eseguibile è stato rinominato mvtcs.exe e ha connesso al server C2 con IP 45.13.122.7. Nel secondo incidente, a settembre 2026 nel settore manufacturing, MeshAgent ha connesso a 193.5.65.114.

Gli eseguibili ransomware seguono una convenzione di naming: il dominio della vittima concatenato con _win64.exe. Le estensioni dei file cifrati differiscono — .locked nel primo incidente, .locked_wip nel secondo — ma entrambi presentano la nota di riscatto RESTORE_FILES.txt. Secondo i ricercatori di Huntress, le differenze tra i due attacchi sono state minime: naming e IP del MeshAgent, cartelle di lavoro del threat actor, ma la condotta complessiva è risultata notevolmente simile.

"Hanno usato tecniche ransomware consolidate e funzionali: MeshAgent per la persistenza, un driver vulnerabile per potenzialmente compromettere le difese, cancellazione dei log e manomissione del recovery."
— Lindsey O'Donnell-Welch, principal technical community engagement writer presso Huntress [testo originale in inglese]

Il sabotaggio dei meccanismi di recovery

Settra implementa una sequenza anti-recovery metodica. Gli operatori hanno disabilitato Windows Recovery Environment tramite reagentc /disable, rimosso la partizione di recovery con diskpart, sovrascritto lo spazio libero con cipher /w e cancellato i Windows Event Logs. Hanno inoltre eseguito ipconfig /flushdns per eliminare risoluzioni DNS locali.

Questa combinazione di comandi nativi di Windows indica un obiettivo esplicito: impedire il recupero dei dati senza pagare il riscatto e rendere più difficile l'analisi forense post-incidente. La cancellazione dei log di sistema mira a oscurare la cronologia delle azioni intraprese durante la fase di post-compromissione.

Il typo e le sue conseguenze forensi

Nel secondo incidente, il threat actor ha tentato di cancellare il log operativo di Windows Defender ma ha commesso un errore di spelling nel percorso del file. Il path corretto, Microsoft-Windows-Windows-Defender/Operational, è stato inserito con un refuso che ha impedito l'esecuzione del comando. Il log è rimasto intatto, fornendo agli analisti una linea temporale parziale delle attività malevole.

Il dettaglio assume rilevanza analitica perché colloca l'operazione in una fascia specifica del panorama delle minacce. Secondo O'Donnell-Welch, gli attaccanti "possono essere descritti come capaci piuttosto che sofisticati" [testo originale in inglese: "The attackers could be described as capable rather than sophisticated"]. Il gruppo dispone di strumenti funzionali e di una metodologia replicabile, ma la precisione operativa non è quella di attori di livello superiore.

La workstation WIN-LIVFRVQFMKO, associata all'attività del settembre 2026, era stata osservata in incidenti precedenti a partire dal dicembre 2024. Questo elemento suggerisce possibile riutilizzo di infrastrutture o preferenze di naming ricorrenti, ma non consente di stabilire connessioni definitive con altre operazioni.

BYOVD con gdrv.sys: un elemento del secondo incidente

Il secondo incidente ha incluso l'uso del driver vulnerabile gdrv.sys in configurazione BYOVD (Bring Your Own Vulnerable Driver). Questo driver, noto per essere stato abusato da multiple minacce per ottenere esecuzione a livello kernel, è stato osservato nel sistema compromesso a settembre 2026. Huntress non ha documentato la sua presenza nel primo incidente di luglio.

L'impiego di gdrv.sys — driver legittimo firmato con vulnerabilità note — indica una scelta operativa documentata nel panorama delle minacce, non un'elaborazione originale. Il binario è ampiamente disponibile, il che riduce la barriera all'uso.

Cosa cambia

L'analisi di Huntress offre elementi per inquadrare Settra nel contesto delle minacce ransomware attuali. La standardizzazione dei TTPs, piuttosto che l'innovazione tecnica, emerge come caratteristica centrale dell'operazione. MeshAgent, RMM open-source, è stato abusato in entrambi gli incidenti con configurazioni leggermente modificate — nome alterato, IP C2 diverso — ma con la stessa funzione di persistenza.

Il dato che più distingue Settra è la combinazione di metodologia rigorosa e imprecisione esecutiva. Il typo nel path del log non è un dettaglio marginale: è il punto in cui la procedura standardizzata del threat actor ha incontrato un errore umano, con conseguenze misurabili per l'investigazione. Per gli analisti, questo tipo di traccia è spesso più duratura degli strumenti tecnici impiegati.

I dati su 93 vittime totali rivendicate e 4 con data leak confermato, riportati da fonti di terze parti (SOCRadar e MoxFive) e citati da SC World, non sono stati verificati direttamente da Huntress. Huntress non ha inoltre potuto confermare il vettore di accesso iniziale in nessuno dei due incidenti investigati, e non ritiene che esistano evidenze sufficienti per classificare Settra come operazione RaaS.

Chiusura editoriale

Settra rappresenta una tipologia di minaccia che si affida alla replicabilità operativa piuttosto che alla sofisticazione tecnica. Il suo profilo — capacità funzionali, standardizzazione dei TTPs, imprecisioni esecutive — è quello di un attore che sfrutta strumenti esistenti con efficienza ma senza eccellenza. Il typo nel log non ha smascherato l'operazione, ma ha confermato che anche minacce con metodologie consolidate lasciano tracce quando la procedura incontra l'errore umano. Per le organizzazioni, questo significa che la visibilità sui log di sistema e il monitoraggio degli strumenti RMM rimangono elementi di difesa rilevanti, anche contro attori non di prima fascia.

Fonti: Huntress (analisi primaria); Infosecurity Magazine, Cybersecurity Dive, SC World (corroborazione e dati di terze parti). I dati su vittime totali e data leak provengono da SOCRadar e MoxFive, non verificati indipendentemente da Huntress. Il vettore di accesso iniziale non è confermato.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://www.infosecurity-magazine.com/news/settra-ransomware-retail/
• https://www.huntress.com/blog/new-settra-ransomware-variant
• https://www.cybersecuritydive.com/news/settra-ransomware-variant-recent-attacks/830787/
• https://www.hendryadrian.com/ready-settra-go-new-settra-ransomware-variant-deploys-meshagent-rmm-huntress/
• https://radar.offseq.com/threat/ready-settra-go-new-settra-ransomware-variant-deploys-meshagent-rmm-6d9fb129e970c80b
• https://socprime.com/active-threats/ready-settra-go-new-settra-ransomware-variant-deploys-meshagent-rmm/
• https://www.scworld.com/news/settra-ransomware-group-uses-meshagent-rmm-in-recent-attacks
• https://support.huntress.io/hc/en-us
• https://www.infosecurity-magazine.com/news/new-ransomware-weekly/