Quando si pensa a un attacco ransomware, la sequenza sembra ormai consolidata: accesso alla rete, escalation dei privilegi, movimento laterale, disattivazione delle difese, distribuzione del malware e infine cifratura dei sistemi. Ma nel caso di PAYLOAD, analizzato dal Global Emergency Response Team (GERT) di Kaspersky, manca proprio il passaggio che normalmente considereremmo centrale.
Sulle workstation Windows non è stato trovato alcun ransomware.
Non c’erano file cifrati, eseguibili malevoli residenti sul disco, servizi installati dagli attaccanti o processi sospetti in memoria. Eppure, l’organizzazione era stata colpita su scala di dominio: gli utenti si erano ritrovati davanti alla richiesta di riscatto, wallpaper e lock screen erano stati sostituiti e l’account amministratore locale era stato disabilitato.
Il ransomware, in sostanza, non era stato distribuito ai computer. Gli attaccanti avevano trasformato Active Directory nel proprio strumento di distribuzione.
Indice degli argomenti
Tutto comincia da una VPN
L’incidente risale all’aprile 2026 e ha coinvolto un’azienda manifatturiera del Medio Oriente. Secondo la ricostruzione di Kaspersky, l’11 aprile gli attaccanti sono entrati nella rete autenticandosi a una FortiGate SSL VPN utilizzando credenziali di dominio valide ma compromesse.
Non è stato possibile stabilire come quelle credenziali fossero state ottenute. La telemetria disponibile sul dispositivo FortiGate non era sufficiente per ricostruire la fase precedente all’accesso e gli investigatori considerano plausibili diversi scenari: password spraying o credential stuffing contro il portale VPN, phishing finalizzato al furto delle credenziali oppure l’acquisto di un account già compromesso da un Initial Access Broker.
L’account nelle mani degli aggressori disponeva, direttamente o attraverso privilegi delegati, della possibilità di creare Group Policy Object e soprattutto di collegarli alla radice del dominio. Significa possedere una capacità estremamente potente all’interno di un’infrastruttura Windows: una policy collegata a quel livello può propagare le proprie impostazioni ai sistemi sottostanti.
Kaspersky non è riuscita a ricostruire con certezza il percorso seguito dagli attaccanti tra l’accesso VPN e l’ottenimento di questi privilegi. Tecniche come DCSync, Kerberoasting di account privilegiati o Pass-the-Hash/Pass-the-Ticket sono compatibili con uno scenario simile, ma nel caso specifico non esistono elementi sufficienti per confermarne o escluderne l’utilizzo.
Ed è qui che l’attacco prende una direzione particolarmente interessante.
Il ransomware diventa una Group Policy
Il 13 aprile gli aggressori creano un nuovo Group Policy Object chiamato, senza particolare fantasia, PAYLOAD, identificato dal GUID {C897F2C7-C2AC-4E6F-BF48-58036FF29E79}, e lo collegano alla radice del dominio.
Per comprenderne l’efficacia bisogna ricordare come funzionano le Group Policy. Un GPO è composto essenzialmente da un Group Policy Container conservato in Active Directory e da un Group Policy Template presente in SYSVOL. Windows considera questa infrastruttura parte integrante dell’amministrazione del dominio: le policy vengono quindi elaborate attraverso meccanismi legittimi e con privilegi elevati.
È precisamente questa fiducia che PAYLOAD sfrutta.
Sul SYSVOL del domain controller vengono depositati due file: payload.jpg, contenente l’immagine utilizzata per wallpaper e schermata di blocco, e hello.txt, contenente il messaggio di riscatto. Da quel momento non è necessario installare un malware sulle workstation: è Windows stesso a distribuire e applicare le modifiche.
L’analisi Resultant Set of Policy effettuata dagli investigatori ha permesso di ricostruire nel dettaglio il comportamento della policy.
Attraverso la client-side extension dedicata ai file delle Group Policy Preferences, hello.txt viene copiato sul Desktop e nelle directory principali C:\ e D:\, diventando un file di sola lettura chiamato README-payload.txt.
Un’altra componente della policy interviene invece sul Registro di Windows, modificando:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Il valore legalnoticecaption viene impostato su “Welcome to Payload!”, mentre legalnoticetext contiene il testo della richiesta di riscatto. In questo modo il messaggio viene visualizzato direttamente attraverso il normale meccanismo di logon di Windows.
La stessa GPO imposta payload.jpg, conservato nel SYSVOL del domain controller, sia come lock screen sia come wallpaper degli utenti. Infine viene modificato GptTmpl.inf, utilizzato dalle Security Settings delle Group Policy, per disabilitare l’account Administrator locale.
Non c’è bisogno di exploit sull’endpoint, shellcode o process injection. Dal punto di vista del computer, quelle configurazioni arrivano dal dominio e vengono applicate come qualsiasi altra policy aziendale.
Ed è proprio questo a rendere il caso interessante dal punto di vista difensivo.
Windows Firewall spento su tutto il dominio
PAYLOAD non è inoltre l’unica policy creata dagli attaccanti.
Una seconda GPO, denominata “win Firewall Off” e identificata dal GUID {22099AD2-E062-4F56-B574-5099BBA4E7A6}, viene anch’essa collegata alla radice del dominio.
Il suo compito è molto più semplice: disabilitare Windows Firewall sui profili Domain, Private e Public.
Con una singola modifica centralizzata, quindi, l’attaccante può ridurre le difese di tutti i sistemi interessati dalla policy e mantenere maggiore libertà di movimento nella rete. Anche in questo caso l’operazione non viene eseguita da un malware che tenta di spegnere il firewall localmente: è l’infrastruttura amministrativa dell’organizzazione a comunicare ai computer che il firewall deve essere disabilitato.
È un cambio di prospettiva importante. Una volta ottenuto il controllo dell’infrastruttura di gestione, l’attaccante non deve necessariamente combattere contro ogni singolo endpoint: può ordinare agli endpoint di modificare autonomamente la propria configurazione.
Una bomba a orologeria nascosta nelle GPO
C’è poi un dettaglio temporale particolarmente interessante: le policy malevole vengono create il 13 aprile, ma l’impatto visibile si manifesta principalmente il giorno successivo.
L’analisi della Master File Table e delle chiavi del Registro relative alla Group Policy History ha mostrato che la policy era già stata scritta nel SYSVOL e ricevuta dai computer il giorno precedente. Diverse impostazioni di configurazione macchina, tuttavia, sarebbero diventate operative soltanto con il successivo aggiornamento delle policy o con il riavvio dei sistemi.
Per circa un giorno l’attacco è quindi rimasto, per così dire, silenzioso.
Poi le macchine hanno cominciato a riavviarsi e la configurazione si è propagata. Wallpaper sostituiti, schermate di blocco modificate, messaggi di riscatto e account amministrativi disabilitati sono comparsi contemporaneamente su numerosi sistemi.
Dal punto di vista forense questo ritardo è tutt’altro che secondario. L’evento che rappresenta la causa dell’incidente – la creazione o modifica della GPO – può essere temporalmente distante dall’effetto visibile agli utenti. Nel frattempo l’attaccante dispone di una finestra nella quale può continuare a muoversi, esfiltrare informazioni o preparare altre azioni.
Nel caso analizzato, proprio il 13 aprile è stata osservata anche attività di esfiltrazione dai file server e da altri sistemi. I dati sottratti sono stati successivamente pubblicati nel dark web.
Il ransomware senza cifratura
Quando il team di incident response è intervenuto, il 15 aprile, la ricerca del tradizionale payload ransomware ha prodotto un risultato sorprendente: non l’hanno trovato.
L’analisi della MFT non ha evidenziato file con estensione .payload, né operazioni massive di rinomina o pattern di I/O compatibili con una cifratura su larga scala.
Anche i normali punti di persistenza risultavano puliti. Nessun task pianificato malevolo, nessuna modifica sospetta delle chiavi Run o RunOnce, nessun servizio installato, nessuna WMI Event Subscription e nessuna alterazione del boot sector o dell’MBR.
L’analisi della memoria non ha inoltre mostrato process injection, process hollowing o connessioni anomale riconducibili all’attacco.
La persistenza, in questo scenario, non si trova sulla workstation.
La persistenza è la Group Policy stessa.
Ripulire il singolo computer senza rimuovere la GPO dal dominio significa semplicemente aspettare che Windows applichi nuovamente la configurazione compromessa.
Va inoltre fatta una distinzione importante. Kaspersky segnala che esistono varianti Windows di PAYLOAD dotate di capacità crittografiche e tecniche ulteriori, ma queste funzionalità non sono state osservate nell’incidente GPO descritto. Il report distingue esplicitamente le capacità effettivamente rilevate nell’organizzazione da quelle conosciute attraverso il reverse engineering pubblico di altri sample della famiglia.
Tra queste ultime figurano la possibilità di cancellare i Windows Event Log utilizzando wevtapi.dll e API quali EvtOpenChannelEnum, EvtNextChannelPath ed EvtClearLog, l’interruzione di processi e servizi di sicurezza e backup e la cancellazione delle Volume Shadow Copies prima della cifratura.
Il report richiama inoltre tecniche frequenti nell’ecosistema ransomware, come la soppressione locale dell’Event Tracing for Windows tramite patch in memoria e il Bring Your Own Vulnerable Driver, precisando però che non devono essere attribuite automaticamente a PAYLOAD senza evidenze specifiche.
Sui server Linux dell’organizzazione è stata invece individuata una variante PAYLOAD destinata a ESXi, anche se non sono state osservate prove sufficienti per attribuire agli operatori, in questo incidente, modifiche quali disabilitazione di execInstalledOnly, attivazione di SSH o indebolimento delle policy dell’hypervisor.
Se non esiste un malware, cosa deve cercare il SOC?
È probabilmente questa la lezione più importante dell’incidente.
Una strategia di detection concentrata esclusivamente sugli endpoint rischia di avere pochissimo da osservare. Non esiste necessariamente un hash da bloccare, un eseguibile sospetto da mettere in quarantena o un processo anomalo da terminare.
La telemetria rilevante si sposta verso Active Directory e SYSVOL.
Kaspersky indica in particolare tre eventi Windows da monitorare sui domain controller: 5137, relativo alla creazione di un oggetto nel directory service; 5136, relativo alla modifica di un oggetto; e 5141, associato alla sua eliminazione.
Una modifica dell’attributo gPLink sulla radice del dominio effettuata da un account che normalmente non gestisce le Group Policy dovrebbe quindi essere considerata un segnale ad alta priorità. Lo stesso vale per variazioni di attributi quali gPCMachineExtensionNames, gPCUserExtensionNames, gPCFileSysPath e versionNumber.
Anche SYSVOL deve diventare un oggetto di monitoraggio attivo. La comparsa inattesa di immagini, file di testo, script, ScheduledTasks.xml, modifiche a registry.pol o GptTmpl.inf può raccontare un attacco che sull’endpoint tradizionale lascia pochissime tracce.
C’è persino un segnale basato sull’assenza di un evento: una modifica dei contenuti di una GPO all’interno di SYSVOL senza il corrispondente evento 5136 può indicare una manipolazione diretta del template, eventualmente attraverso strumenti come PowerView o SharpGPOAbuse.
Naturalmente, l’assenza dell’evento può anche dipendere da una configurazione di auditing incompleta, per cui il dato deve essere contestualizzato.
Sugli endpoint restano comunque informazioni utili. L’applicazione delle policy viene registrata nel log Microsoft-Windows-GroupPolicy/Operational e lascia tracce nelle chiavi History, Shadow e State del Registro. Nell’incidente analizzato è stata inoltre individuata una voce Loopback-GPO-List, indicativa dell’elaborazione della policy in loopback mode: una scelta che permetteva di applicare la configurazione utente, compreso il wallpaper, indipendentemente dall’utente che effettuava l’accesso alla macchina.
Prima Active Directory, poi gli endpoint
In un ransomware tradizionale una delle prime reazioni può essere isolare e ripulire le workstation compromesse. Qui partire dagli endpoint rischia di essere inutile: finché la policy malevola rimane nel dominio, una macchina ripristinata può ricevere nuovamente la configurazione al successivo refresh.
La priorità diventa quindi il domain controller.
Nel caso PAYLOAD significa eliminare la GPO malevola, rimuovere o ripristinare “win Firewall Off”, cancellare payload.jpg e hello.txt dal SYSVOL, resettare l’account compromesso e verificare account privilegiati e membership dei gruppi amministrativi. In presenza di una compromissione confermata a livello Domain Admin, Kaspersky raccomanda anche la doppia rotazione della password dell’account krbtgt.
Solo successivamente ha senso forzare gpupdate /force sugli endpoint e ripristinare, attraverso policy affidabili, firewall e account amministrativi.
Sul piano strutturale, il caso rafforza inoltre la necessità di separare i privilegi di creazione delle GPO da quelli necessari per collegarle al dominio, limitare gli account Domain Admin secondo un modello amministrativo a tier, adottare workstation dedicate per le attività privilegiate e utilizzare Windows LAPS per evitare password amministrative locali condivise.
Per l’accesso remoto, il punto di ingresso dell’incidente ricorda anche l’importanza di una MFA resistente al phishing e soprattutto di una telemetria VPN sufficientemente dettagliata. Nel caso investigato, proprio l’insufficienza dei log FortiGate ha impedito agli analisti di ricostruire alcune delle fasi decisive dell’intrusione.
Quando l’infrastruttura fidata diventa il payload
PAYLOAD racconta bene un’evoluzione che va oltre questa singola famiglia ransomware.
La sicurezza degli endpoint è stata costruita per anni intorno all’idea di distinguere ciò che il sistema dovrebbe fare da ciò che un programma malevolo cerca di costringerlo a fare. Ma quando un aggressore raggiunge un livello di privilegio sufficiente, quella distinzione diventa molto più sfumata.
In questo incidente Windows non è stato ingannato da un malware. Ha semplicemente eseguito gli ordini ricevuti dalla propria infrastruttura di amministrazione.
La Group Policy ha distribuito i file. La Group Policy ha modificato il Registro. La Group Policy ha cambiato wallpaper e lock screen. La Group Policy ha disabilitato l’amministratore locale. Un’altra Group Policy ha spento il firewall.
Dal punto di vista del sistema operativo, tutto questo era perfettamente legittimo.
Ed è probabilmente questo l’aspetto più significativo del caso: il vero “payload” non deve necessariamente essere un file. Può essere una normale configurazione.
In un’infrastruttura Active Directory, quindi, proteggere gli endpoint senza sorvegliare attentamente chi può modificare le regole (e chi le modifica effettivamente con log su SIEM) che quegli endpoint considerano autorevoli significa lasciare scoperto un livello ancora più importante.
Partecipa alla community