PAYLOAD: il ransomware che ha reso Active Directory stesso un'arma

Il 14 aprile 2026, centinaia di workstation in un'organizzazione manifatturiera del Medio Oriente hanno smesso di funzionare nel modo consueto. Non c'erano file criptati, nessun processo malevolo in esecuzione, nessun binario sospetto su disco. Il team GERT di Kaspersky, chiamato in soccorso il giorno successivo, ha scoperto che l'intero attacco viveva dentro Active Directory stesso: un singolo oggetto Criteri di Gruppo, creato con privilegi di amministratore di dominio, aveva trasformato l'infrastruttura interna in un'arma di estorsione.

La cronologia di un assalto invisibile: dall'accesso VPN al wallpaper di riscatto

L'ingresso è avvenuto l'11 aprile 2026, quando l'attaccante si è autenticato tramite una porta FortiGate SSL VPN usando credenziali di dominio compromesse. Il percorso esatto tra questo primo accesso e il controllo equivalente a domain admin rimane parzialmente oscuro: il report GERT non ricostruisce i passaggi intermedi di lateral movement e privilege escalation. Ciò che è documentato con precisione sono le due azioni decisive del 13 aprile: la creazione del GPO "PAYLOAD", con GUID {C897F2C7-C2AC-4E6F-BF48-58036FF29E79}, e il suo collegamento alla radice del dominio, seguiti poco dopo da un secondo oggetto denominato "win Firewall Off" che disabilitava Windows Firewall su tutti i profili.

La "detonazione" è scattata il 14 aprile, quando i riavvio delle workstation hanno applicato le nuove policy. Il risultato: wallpaper sostituiti con immagini di riscatto, lock screen modificati, banner di logon imposti tramite le chiavi di registro legalnoticecaption e legalnoticetext, note di riscatto distribuite come file README-payload.txt, e l'account amministratore locale disabilitato su ogni macchina. L'effetto psicologico e operativo era indistinguibile da un ransomware convenzionale, ma la sostanza tecnica era radicalmente diversa.

RSOP svela l'anatomia di un attacco senza payload

L'analisi forense condotta dal team GERT ha utilizzato il Resultant Set of Policy (RSOP) per ricostruire punto per punto il meccanismo di distribuzione. Il GPO PAYLOAD ha sfruttato cinque Group Policy Client-Side Extensions legittimi, ciascuno con una funzione specifica nel panorama dell'estorsione.

Il Files CSE ha gestito la distribuzione dei file di riscatto: hello.txt trasformato in README-payload.txt. Il Registry CSE ha imposto i banner di logon. Il Personalization Policy CSE e il Desktop Policy CSE (ramo User) hanno iniettato l'immagine payload.jpg come wallpaper e schermata di blocco. Infine, il Security Settings CSE, attraverso il file GptTmpl.inf, ha disabilitato l'account amministratore locale su tutti gli endpoint. Nessuna di queste operazioni richiede codice malevolo: sono funzionalità documentate, supportate e firmate di Windows, eseguite automaticamente da un servizio di sistema con privilegi SYSTEM.

Il campione PAYLOAD è esistito, ma solo in un altro ecosistema: un ransomware per server ESXi su Linux, trovato sui sistemi non Windows. Su tutte le workstation del dominio, invece, non è stato rilevato alcun malware residente, alcuna persistenza endpoint, alcun processo anomalo. L'intero attacco ha abitato dentro SYSVOL e le directory di Active Directory.

Perché gli EDR tradizionali sono diventati invisibili di fronte a questo vettore

La rilevanza tattica dell'operazione PAYLOAD sta proprio nell'invisibilità strutturale che conferisce al canale Group Policy. Secondo il report GERT, "Group Policy is a signed, allowlisted, SYSTEM-privileged distribution channel that the majority of endpoint detection and response tools is designed not to inspect". Questa caratteristica non è un bug di implementazione: è il risultato di un'architettura di sicurezza costruita per assumere che il traffico da controller di dominio a endpoint sia intrinsecamente affidabile.

Il paradosso è completo. Le piattaforme EDR sono ottimizzate per rilevare processi sospetti, scrivere su disco eseguibili anomali, individuare pattern di criptazione. Quando l'impatto viene erogato attraverso un meccanismo già autorizzato, firmato e integrato nel sistema operativo, lo stack di rilevamento basato su file e processi diventa letteralmente cieco. Come annotano gli analisti di Kaspersky: "an organization whose detection strategy depends on catching a ransomware executable would have seen nothing until the first endpoint rebooted and the ransom wallpaper appeared". E ancora: "By delivering impact through GPO rather than through malware, the actor sidestepped the entire file- and process-based detection stack".

Il trend che rende PAYLOAD un segnale, non un'anomalia

L'assenza di criptazione sui sistemi Windows non è un caso isolato, ma la punta di un fenomeno in accelerazione. Secondo Symantec, il settore ha registrato 6.182 attacchi di estorsione nel 2025, con un incremento del 23% rispetto al 2024, inclusi quelli encryptionless. Un dato aggregato del report annuale Kaspersky indica che il 28% dei riscatti è stato pagato nel 2025, un fattore che spinge gli operatori a cercare modi di pressione meno costosi e meno rilevabili della criptazione massiccia.

Il ricorso a Group Policy come vettore di attacco ha precedenti documentati. Microsoft stessa ha descritto nel 2020 come Ryuk utilizzasse GPO per propagare ransomware. Kaspersky ha riportato l'abuso di Group Policy da parte di LockBit 2.0. Tuttavia, in tutti questi casi storici il GPO serviva a distribuire un encryptor: il payload binario restava il fulmine, Group Policy solo il parafulmine. PAYLOAD inverte questa logica: il GPO non è più il veicolo, ma l'arma stessa. L'impatto è puro, senza intermediazione eseguibile.

"The entire attack lived inside Active Directory itself" — Kaspersky GERT, report incident response PAYLOAD

Cosa fare adesso

La risposta difensiva richiede un riallineamento fondamentale: trattare le modifiche a Group Policy come eventi di sicurezza di prima classe, non come amministrazione di routine.

• Abilitare e centralizzare il monitoraggio dell'evento Windows 5136, che traccia ogni modifica agli oggetti Criteri di Gruppo in Active Directory, con alert immediato su creazione o collegamento di GPO a livello di radice dominio
• Implementare audit granulari sui privilegi di amministrazione del dominio, con verifica periodica di chi può creare, modificare o collegare GPO, e rimozione di permessi non strettamente necessari
• Rivedere le policy di trust: il canale SYSVOL/Group Policy non deve essere considerato inherentemente sicuro, ma sottoposto a ispezione e validazione come qualsiasi altro vettore di distribuzione software
• Progettare la detection assumendo che la compromissione di Active Directory possa essere usata come arma di impatto diretto, non solo come piattaforma di lancio per malware tradizionale

Il confine sottile tra amministrazione e aggressione

PAYLOAD solleva una questione architetturale più profonda della singola campagna. Active Directory è stato progettato come strumento di controllo centralizzato: chi ne detiene le chiavi detiene la rete. Questa concentrazione di potere, gestita per decenni come problema di disponibilità e gestione, sta emergendo come problema di sicurezza offensiva. Quando gli strumenti di amministrazione quotidiana possono essere riadattati in minuti per paralizzare un'intera organizzazione, il perimetro tradizionale tra insider legittimo e attaccante esterno si dissolve.

Gli analisti GERT non identificano il threat actor dietro PAYLOAD, né il percorso preciso delle credenziali FortiGate compromise. Il report non specifica se le credenziali siano state ottenute tramite password spraying, credential stuffing o acquisto da un initial access broker. Questi limiti non attenuano il segnale: il metodo è replicabile, la superficie d'attacco è vasta, e le difese attuali sono inadeguate. Il prossimo PAYLOAD potrebbe non chiamarsi così, ma il meccanismo — un amministratore di dominio che trasforma la policy in messaggio di riscatto — è già codificato in ogni installazione Windows esistente.

Domande frequenti

Perché questo attacco non è stato rilevato dagli antivirus?

Non c'era nulla da rilevare. L'attacco ha usato esclusivamente componenti legittimi di Windows — Group Policy Client-Side Extensions — che eseguono con privilegi SYSTEM attraverso un canale firmato e allowlisted. Gli strumenti EDR tradizionali sono progettati per non ispezionare questo traffico.

Il GPO PAYLOAD conteneva malware nascosto?

No. Secondo il report GERT, il GPO non conteneva alcun payload binario malevolo. L'impatto era generato interamente attraverso la configurazione di policy esistenti: distribuzione file, modifica registro, personalizzazione desktop, impostazioni di sicurezza.

Questo approccio può essere usato per danni più gravi della sostituzione del wallpaper?

Il report GERT non documenta impatti oltre quelli descritti nell'incidente specifico. Tuttavia, il meccanismo — controllo completo delle configurazioni endpoint tramite GPO — ha potenziale intrinseco che va oltre l'estorsione visiva. Il dossier non esplora scenari ipotetici futuri.

Fonti

• https://securelist.com/tr/payload-ransomware-via-group-policy/121335/
• https://www.security.com/threat-intelligence/ransomware-extortion-epidemic
• https://securelist.com/state-of-ransomware-in-2026/119761/
• https://securelist.com/group-policies-in-cyberattacks/115331/
• https://www.microsoft.com/en-us/security/blog/2020/03/05/human-operated-ransomware-attacks-a-preventable-disaster/
• https://www.kaspersky.com/blog/ransomware-group-policies/40877/