// 4 ZERO-DAY · 3 CVE · 4 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H
Il gruppo ransomware Hyadina sfrutta il driver PoisonX, firmato Microsoft, per disabilitare endpoint security. La tecnica BYOvd espone il ritardo strutturale del

Il gruppo ransomware-as-a-service Hyadina ha messo in campo un nuovo locker, GodDamn, utilizzando un driver kernel firmato Microsoft per disarmare tool di sicurezza endpoint prima della cifratura. L'incidente documentato da Symantec mostra una finestra operativa di 24 ore tra compromissione iniziale e deploy della payload: il 29 maggio compare un'istanza AnyDesk, il 30 maggio il driver PoisonX neutralizza le difese. La firma valida di Microsoft sul driver rende il vettore BYOVD — Bring Your Own Vulnerable Driver — particolarmente insidioso perché bypassa i controlli di caricamento kernel-mode, mentre il blocklist reattivo di Redmond lascia settimane di margine agli attaccanti.

Punti chiave
  • Hyadina, operazione RaaS attiva da circa quattro anni, ha sostituito i precedenti locker Beast e Monster con GodDamn e colpisce prevalentemente organizzazioni statunitensi nei settori healthcare, manufacturing ed education.
  • Il driver PoisonX, pubblicato su GitHub il 7 aprile 2026 dall'autore "oxfemale" come "research tool", possiede una firma Microsoft Hardware Compatibility valida che consente caricamento in kernel mode e invio di IOCTL per terminare processi security-related.
  • In un caso analizzato da Symantec, la catena operativa si sviluppa in 24 ore: AnyDesk il 29 maggio come primo segnale, PoisonX droppato tramite un binary mascherato da "symantec.exe" il 30 maggio.
  • Symantec e Carbon Black implementano monitoraggio comportamentale driver-agnostic per rilevare IOCTL anomali verso prodotti di sicurezza, contro il ritardo strutturale di giorni o settimane nel blocklist Microsoft.

Il percorso operativo di GodDamn: da AnyDesk alla cifratura in 24 ore

I ricercatori Symantec hanno ricostruito una catena di compromissione che inizia il 29 maggio 2026 con il caricamento di un'istanza AnyDesk nella cartella Music di un endpoint. Il giorno successivo, su un secondo computer della stessa rete, l'attaccante ha droppato un binary denominato symantec.exe. Questo eseguibile ha installato PoisonX, driver kernel che Symantec etichetta come malware senza legittimo utilizzo.

PoisonX opera a livello kernel inviando IOCTL per terminare processi security-related e rimuovere API hooks in user-mode. Il risultato è la neutralizzazione dei tool endpoint security prima che il locker GodDamn proceda alla cifratura. La movimentazione laterale avviene tramite PsExec, toolkit standard per l'amministrazione remota Windows.

Il dossier non specifica il vettore di intrusione iniziale né le tattiche di social engineering impiegate. L'identità dell'organizzazione vittima non è rivelata.

PoisonX: la firma Microsoft come arma di elusione

PoisonX è stato pubblicato su GitHub il 7 aprile 2026 da un account denominato "oxfemale", che lo descrive come "research tool". Secondo il profilo LinkedIn citato dalla fonte, l'autore si presenta come ricercatrice russa specializzata in reverse engineering e rilascia tool red team con frequenza settimanale o giornaliera. Symantec non verifica indipendentemente questa affiliazione nazionale, che resta un claim autopresentato.

Il driver possiede una firma Microsoft Hardware Compatibility valida. I ricercatori Symantec non hanno potuto determinare i passi che hanno portato all'ottenimento della firma né il meccanismo con cui gli attaccanti — o chi per loro — hanno convinto Microsoft a firmare il binary. La firma valida consente a PoisonX di essere caricato in kernel mode su sistemi Windows senza triggerare allarmi di blocking basati su reputazione.

"it is easy to say that yes, it shouldn't have been signed by Microsoft. However, we do not know the steps taken by the attackers to get the driver signed or how they might have tricked Microsoft into doing so." — Brigid O Gorman, Symantec

Il toolkit da 14 programmi: quando l'open source diventa infrastruttura offensiva

Nella fase di post-exploitation, Hyadina ha deployato 14 tool open source per credential theft su sistemi Windows. La composizione è specifica: 13 utility provengono da NirSoft, noto sviluppatore di strumenti di amministrazione e recupero password, più una istanza di Mimikatz per l'estrazione di credenziali in memoria. I programmi coprono funzioni di browser stealer, email e IM stealer, intercettazione traffico Wi-Fi e network.

La scelta di utility legittime complica la detection signature-based: nessun binary è intrinsecamente malevolo, e la loro presenza isolata non costituisce indicatore di compromissione affidabile. La fonte non specifica quali credenziali siano state effettivamente esfiltrate né la natura dei dati successivamente cifrati da GodDamn.

Perché il blocklist Microsoft non regge il confronto con il tempo degli attaccanti

Microsoft mantiene il Vulnerable Driver Blocklist, elenco di driver noti abusabili per tecniche BYOVD. Il meccanismo è reattivo: un driver viene identificato, segnalato, valutato, inserito nella lista, e la lista viene distribuita agli endpoint enterprise. Tra questi stadi intercorre un intervallo che Symantec quantifica in giorni, più spesso settimane.

"There is a lag of days, more often weeks, between a driver being identified and the blocklist update reaching enterprise endpoints. This means that only a subset of known vulnerable drivers is blocklisted at any given time, and unfortunately, attackers often move quicker than the blocklist." — Brigid O Gorman, Symantec

Brigid O Gorman, ricercatrice Symantec citata dalla fonte, enfatizza che questa asimmetria temporale è strutturale, non contingente. I RaaS ruotano driver a ritmo settimanale; il blocklist, per sua natura centralizzato e manuale, accumula inevitabilmente ritardo. La conseguenza è una finestra di vulnerabilità sistemica in cui driver già noti agli attaccanti circolano liberamente su endpoint che non hanno ancora ricevuto l'update.

Perche e importante

Il dossier non documenta misure correttive specifiche emesse in risposta a questa campagna. Non emergono patch di emergenza, advisory vendor diretti né CVE assegnati a PoisonX o al meccanismo BYOVD descritto.

La fonte primaria non specifica come le organizzazioni target debbano modificare le proprie configurazioni endpoint in risposta a Hyadina. Il brief non elenca raccomandazioni di hardening, policy di gruppo, regole firewall, requisiti di autenticazione multi-fattore né procedure di backup.

Ciò che il dossier documenta è un approccio di detection alternativo: Symantec e Carbon Black implementano monitoraggio comportamentale driver-agnostic, che intercetta IOCTL anomali — inclusi richieste di terminazione processi dirette a prodotti di sicurezza — indipendentemente dalla reputazione o dalla firma del driver coinvolto. La fonte non quantifica la diffusione di questa capacità tra i clienti né ne misura l'efficacia contro GodDamn in campo.

Resta ignota l'estensione geografica della campagna GodDamn, il numero totale di vittime, e la data esatta di inizio delle operazioni con il nuovo locker. L'incidente descritto risale a fine maggio; l'articolo è pubblicato il 9 luglio 2026.

La lezione: firma non equivale a fiducia, e il kernel non perdona

Il caso GodDamn/Damn/Hyadina/PoisonX (il nome del locker varia tra GodDamn e Damn nelle fonti, con GodDamn come forma principale) illustra una tensione architetturale di Windows: la firma Microsoft valida apre il kernel, e il kernel compromesso azzera tutto ciò che si appoggia al user-mode. Gli EDR, gli AV, le API hooks diventano linee di codice mute quando un driver autorizzato invia IOCTL di terminazione.

Il paradosso è che Microsoft firma involontariamente l'arma che disarma i propri sistemi di difesa. La risposta non è abolire la firma — il kernel mode richiede un modello di trust — ma riconoscere che il trust point è diventato target primario. I ricercatori Symantec insistono sullo shift da detection basata su identità del file a detection basata su comportamento del driver. Il brief non specifica se altri vendor endpoint abbiano implementato analoghe capacità.

Per i team di sicurezza, la domanda concreta è se i propri endpoint product implementino monitoraggio IOCTL driver-agnostic. La fonte non fornisce una checklist di verifica, ma identifica il criterio tecnico da richiedere: la capacità di rilevare interazioni sospette driver-processo indipendentemente dalla firma o dalla reputazione del driver.

Hyadina continua a operare. GodDamn è il terzo locker del gruppo in circa quattro anni. La frequenza di rilascio di "oxfemale" su GitHub suggerisce che il catalogo di driver firmati e weaponizzabili cresca più velocemente di qualsiasi blocklist reattivo.

Le informazioni sono basate sull advisory citata e aggiornate al momento della pubblicazione.

FAQ

Cos'è esattamente la tecnica BYOVD?

Bring Your Own Vulnerable Driver: l'attaccante introduce un driver legittimamente firmato che presenta funzionalità abusabili (terminazione processi, lettura/scrittura memoria kernel, bypass protezioni) per eludere le difese endpoint. La firma valida consente il caricamento in kernel mode dove il driver opera al di sopra dei controlli user-mode.

Posso proteggermi aggiornando il blocklist Microsoft?

La fonte indica che il blocklist presenta ritardi strutturali di giorni o settimane. Non è uno strumento sufficiente contro attaccanti che ruotano driver settimanalmente. Il brief non documenta alternative operative immediate.

"oxfemale" è l'attaccante?

No. È l'autore del tool PoisonX su GitHub. Il collegamento diretto con Hyadina non è provato. La fonte riporta il claim LinkedIn di nazionalità russa ma non lo verifica indipendentemente.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. darkreading.com
  2. security.com