Ghostwriter colpisce l’Ucraina con phishing Prometheus e malware OYSTER

Il gruppo Ghostwriter, noto anche come UAC-0057 o UNC1151, colpisce enti governativi ucraini con una campagna di phishing avanzata che sfrutta il tema della piattaforma di apprendimento online Prometheus per aumentare la credibilità delle email e indurre i dipendenti pubblici ad aprire allegati malevoli. L’attore, allineato con la Bielorussia e già associato a operazioni persistenti contro l’Ucraina, intensifica le attività dalla primavera del 2026, secondo quanto documentato dal CERT-UA. Le organizzazioni statali ricevono messaggi inviati da account di posta compromessi, elemento che aumenta la fiducia del destinatario perché le comunicazioni sembrano provenire da contatti già noti, partner istituzionali o fornitori legittimi. Le email contengono allegati PDF che includono collegamenti verso archivi ZIP contenenti file JavaScript malevoli. Una volta eseguito, il codice avvia una catena di infezione modulare che punta alla raccolta di dati sensibili, alla persistenza e all’installazione di payload di post-sfruttamento. La campagna mostra una combinazione classica ma efficace di social engineering, abuso di account compromessi, offuscamento JavaScript, uso del registro di Windows e successiva esecuzione di Cobalt Strike, framework ampiamente utilizzato per operazioni di post-exploitation. Il tema Prometheus risulta particolarmente efficace perché la piattaforma viene associata a formazione, certificati e procedure amministrative, contesti percepiti come ordinari da molti dipendenti pubblici.

Prometheus diventa l’esca per certificati e procedure false

La campagna sfrutta il contesto della piattaforma Prometheus per costruire messaggi plausibili legati a certificati, registrazioni o documentazione formativa. L’allegato PDF appare come un documento legittimo e invita l’utente a seguire un collegamento per scaricare materiale aggiuntivo. Il link conduce a un archivio ZIP il cui nome cambia tra i campioni osservati, ma conserva spesso riferimenti coerenti con l’esca, come certificate, Certificate.pdf, certificate.zip o varianti ucraine come Сетифікат_CAF. Questa strategia agisce su due livelli: da una parte offre un’apparenza formale attraverso il PDF, dall’altra usa un tema familiare per abbassare le difese cognitive della vittima. Il CERT-UA osserva che i messaggi possono essere personalizzati per l’organizzazione bersaglio e che l’uso di caselle compromesse riduce la probabilità di blocco da parte dei filtri antispam. Una volta scaricato e aperto l’archivio, la vittima trova un file JavaScript che viene eseguito tramite wscript.exe nei sistemi Windows privi di restrizioni specifiche. Questo passaggio costituisce il vero punto di ingresso della campagna. Ghostwriter non tenta soltanto di convincere l’utente ad aprire un allegato, ma costruisce una sequenza in cui ogni elemento appare coerente con il precedente, rendendo meno evidente il salto verso l’esecuzione del codice. Il successo dell’operazione dipende proprio dall’apparente normalità della richiesta, dalla reputazione del mittente compromesso e dalla familiarità del tema formativo.

OYSTERFRESH avvia l’infezione e prepara il registro di Windows

Il file JavaScript iniziale viene classificato come OYSTERFRESH e rappresenta il primo stadio operativo dell’attacco. Il suo compito è gestire l’interazione iniziale con la vittima, mantenere una copertura visiva e preparare il sistema all’esecuzione dei componenti successivi. OYSTERFRESH mostra un documento decoy che simula il certificato o il modulo atteso, così l’utente continua a percepire il processo come legittimo e non collega immediatamente l’apertura del file a un comportamento anomalo. In parallelo, lo script scrive nel registro di Windows un payload offuscato e cifrato denominato OYSTERBLUES, usando chiavi collocate sotto HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Blue. Questa scelta riduce la visibilità su disco e permette agli attaccanti di separare lo stadio iniziale dal payload principale. OYSTERFRESH scarica poi il componente OYSTERSHUCK, che svolge la funzione di decoder. La catena risulta progettata per ostacolare l’analisi statica: il codice non espone immediatamente il payload finale, usa più passaggi di trasformazione e mantiene parte del contenuto nascosta nel registro. L’esecuzione tramite wscript.exe diventa quindi il punto tecnico da monitorare con maggiore attenzione, perché un utente standard che avvia script JavaScript da una cartella temporanea, da %LOCALAPPDATA% o da %APPDATA% rappresenta un indicatore forte di compromissione. La dipendenza da wscript.exe rende però la catena vulnerabile a policy difensive mirate, soprattutto in ambienti governativi dove l’esecuzione di script da parte degli utenti non privilegiati può essere limitata senza compromettere la normale operatività.

OYSTERSHUCK decodifica il payload nascosto e passa a OYSTERBLUES

Il secondo stadio OYSTERSHUCK entra in azione come componente di decodifica e recupera il payload OYSTERBLUES dal registro di Windows. La sequenza osservata dal CERT-UA include più trasformazioni consecutive: rovesciamento della stringa, applicazione di ROT13 e decodifica URL. Questa catena serve a rendere meno leggibile il contenuto durante un controllo statico e a impedire che strumenti di sicurezza basati su firme semplici intercettino immediatamente il payload. OYSTERSHUCK prepara quindi il codice per l’esecuzione mantenendo l’impianto modulare dell’operazione. Ogni componente svolge un compito preciso e passa il controllo allo stadio successivo senza produrre rumore eccessivo. Il modello è coerente con campagne orientate alla persistenza e alla raccolta di intelligence, dove l’obiettivo non è generare impatti visibili ma ottenere accesso stabile, mappare il sistema e aprire la strada a strumenti più potenti. L’uso del registro come deposito temporaneo del payload e l’esecuzione in memoria riducono gli artefatti tradizionali e complicano l’attività degli antivirus basati soprattutto su file. Gli analisti possono però cercare comportamenti correlati, come accessi sospetti alle chiavi Microsoft\Windows\Blue, presenza di script con nomi come amplifier.js, avvio anomalo di wscript.exe e connessioni HTTP verso domini sospetti. La coerenza comportamentale tra varianti permette di costruire detection basate non solo sugli hash, facilmente modificabili dagli attaccanti, ma sulla sequenza operativa complessiva.

OYSTERBLUES raccoglie dati e apre la strada a Cobalt Strike

OYSTERBLUES costituisce il cuore della fase di raccolta informazioni. Una volta decodificato, il payload estrae dati sul sistema compromesso, tra cui nome del computer, account utente, versione del sistema operativo, orario dell’ultimo avvio e lista completa dei processi in esecuzione. Queste informazioni vengono inviate a un server di comando e controllo tramite richiesta HTTP POST, usando traffico apparentemente ordinario per confondersi con comunicazioni legittime. Dopo l’invio iniziale, OYSTERBLUES attende istruzioni dal server remoto e può ricevere ulteriore codice JavaScript eseguito direttamente tramite eval. Questo meccanismo offre a Ghostwriter flessibilità operativa perché consente di caricare payload dinamici senza dover scrivere nuovi file su disco. In molti casi, la fase successiva porta all’esecuzione di Cobalt Strike, strumento che fornisce capacità di post-sfruttamento come esecuzione di comandi remoti, movimento laterale, raccolta di credenziali, pivoting e controllo persistente dell’ambiente compromesso. La raccolta iniziale di informazioni permette agli operatori di valutare il valore della macchina, capire se si trova dentro una rete interessante, identificare processi di sicurezza e decidere quali moduli successivi distribuire. Il design di OYSTERBLUES mostra quindi una finalità di intelligence più che di sabotaggio immediato. La campagna privilegia furtività, adattabilità e presenza prolungata, caratteristiche coerenti con attacchi contro enti governativi dove l’obiettivo principale può essere l’accesso a documenti, comunicazioni interne, credenziali e informazioni sensibili.

Domini .icu e Cloudflare complicano attribuzione e blocco

L’infrastruttura della campagna Ghostwriter usa domini con estensione .icu protetti da Cloudflare, scelta che nasconde gli indirizzi IP reali dei server di comando e controllo e rende più complessa l’attribuzione tecnica immediata. Il CERT-UA identifica numerosi domini associati alla campagna, spesso caratterizzati da pattern ricorrenti ma sufficientemente variabili da aggirare blocchi statici e liste di controllo troppo rigide. Gli indicatori tecnici comprendono varianti di Certificate.pdf, certificate.zip, certificate.js, amplifier.js e Oyster.js, oltre a percorsi di esecuzione in directory come %LOCALAPPDATA% e %APPDATA%. La presenza della chiave HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Blue\Oyster rappresenta un indicatore rilevante perché collega la macchina alla catena OYSTER. Altri elementi da monitorare includono User-Agent specifici, comunicazioni HTTP verso domini .icu, esecuzione di wscript.exe da percorsi utente e sequenze di decodifica compatibili con ROT13, URL decoding e stringhe invertite. Gli attaccanti aggiornano regolarmente i file per generare nuovi hash e mantenere efficaci i payload contro rilevamenti basati su firme. Per questo, la difesa deve combinare indicatori statici, regole comportamentali e analisi del traffico. Il ricorso a Cloudflare non rende invisibile la campagna, ma obbliga le organizzazioni a concentrarsi su dominio, pattern di richiesta, telemetria endpoint e contesto di esecuzione, invece di affidarsi solo al blocco dell’IP finale.

Il CERT-UA raccomanda il blocco di wscript.exe per gli utenti standard

La misura principale indicata dal CERT-UA consiste nel limitare l’esecuzione di wscript.exe per gli account degli utenti standard. Questo controllo interrompe la catena al primo stadio, impedendo a OYSTERFRESH di eseguire il file JavaScript scaricato dall’archivio ZIP. In ambienti governativi, dove l’esecuzione di script lato utente non dovrebbe essere necessaria nella maggior parte dei casi, questa restrizione può ridurre in modo significativo la superficie d’attacco senza compromettere le attività essenziali. Le organizzazioni devono applicare la regola tramite Group Policy, soluzioni di application control o strumenti EDR capaci di bloccare l’esecuzione di script da percorsi non attendibili. Oltre a questo, è necessario monitorare modifiche al registro, in particolare sotto HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Blue, controllare comunicazioni verso domini .icu, analizzare log di posta per identificare account compromessi usati come mittenti e rafforzare il training del personale su email che sfruttano temi familiari come certificati, formazione o piattaforme istituzionali. Il blocco proattivo dei domini noti, il controllo del traffico HTTP verso infrastrutture protette da Cloudflare e l’analisi delle esecuzioni di wscript.exe rappresentano misure complementari. Il punto chiave è anticipare la catena prima dell’arrivo di Cobalt Strike, perché dopo il caricamento del beacon la compromissione può evolvere rapidamente verso movimento laterale, furto credenziali e accesso persistente.

Ghostwriter conferma il valore strategico del phishing istituzionale

La campagna contro gli enti governativi ucraini conferma che il phishing resta uno dei vettori più efficaci nelle operazioni di intelligence digitale, soprattutto quando viene costruito su temi credibili, account compromessi e payload modulari. Ghostwriter non punta su una tecnica spettacolare, ma su una sequenza affidabile: email apparentemente legittima, allegato PDF, archivio ZIP, script JavaScript, decoy visivo, payload nel registro, decoder, backdoor e possibile Cobalt Strike. Questa linearità rende l’attacco scalabile e adattabile a più organizzazioni. Il focus sul settore governativo ucraino suggerisce un interesse persistente per informazioni sensibili, processi amministrativi, comunicazioni interne e asset collegati alla sicurezza nazionale. La componente geopolitica, associata all’allineamento con la Bielorussia, rafforza il contesto dell’operazione, ma il valore tecnico della campagna riguarda tutte le organizzazioni esposte a phishing tematico e abuso di script. Le reti governative devono assumere che un singolo endpoint compromesso possa diventare punto di appoggio per intrusioni successive. Per questo la difesa non può limitarsi al filtro email, ma deve includere restrizioni sull’esecuzione di script, segmentazione, monitoraggio endpoint, rilevamento delle anomalie nel registro, analisi dei processi e risposta rapida agli indicatori pubblicati dal CERT-UA. La lezione operativa è chiara: in una campagna come questa, bloccare wscript.exe al momento giusto vale più di inseguire il beacon quando l’attaccante è già dentro la rete.