Falsi attacchi mirati a Zimbra rubano email e dati sensibili

Falsi attacchi mirati a Zimbra rubano email e dati sensibili

Un attacco sofisticato contro le caselle di posta può mettere a rischio mesi di conversazioni, credenziali e informazioni riservate. Se la tua organizzazione usa Zimbra, la priorità è verificare subito gli aggiornamenti, revocare passcode applicativi sospetti e controllare i log per attività anomale.

Cosa sta succedendo

Una campagna di spionaggio informatico attribuita a un gruppo sostenuto dallo Stato russo ha preso di mira organizzazioni occidentali sfruttando una vulnerabilità zero-day in Zimbra Collaboration Suite. L’obiettivo non era il guadagno economico, ma la raccolta silenziosa di informazioni strategiche, con particolare attenzione a email, dettagli degli account e contenuti sensibili.

Il bersaglio principale è stato l’ambiente di posta elettronica di enti pubblici e privati attivi in settori come governo, difesa, energia, istruzione, media, ONG e tecnologia. In queste operazioni, il valore dell’accesso alla casella di posta è altissimo: da lì passano conversazioni interne, allegati riservati, contatti e spesso anche dati utili per movimenti laterali nella rete.

Come avviene l’attacco

L’ingresso iniziale avviene tramite una email di spear-phishing contenente un payload JavaScript incorporato in un file SVG. In alcuni casi non serve nemmeno interagire con un link o scaricare un allegato: la semplice apertura del messaggio in un client Zimbra vulnerabile può attivare l’esecuzione del codice a causa di una gestione impropria dei CSS.

La vulnerabilità sfruttata è identificata come CVE-2025-66376 e riguarda una falla di cross-site scripting nel webmail di Zimbra. Una volta eseguito, lo script automatizza una serie di controlli sull’account della vittima e raccoglie elementi utili al furto di dati e al mantenimento dell’accesso.

Tra le informazioni raccolte figurano l’indirizzo email, lo stato del dispositivo, i consumer OAuth e i codici di recupero 2FA. Questo passaggio è particolarmente importante perché permette agli aggressori di aggirare o indebolire i meccanismi di protezione multifattore.

Perché è pericoloso

Uno degli aspetti più insidiosi della campagna è la capacità di creare un nuovo Zimbra Application Passcode con il nome “ZimbraWeb”. In pratica, gli aggressori ottengono una via d’accesso persistente che può continuare a funzionare anche quando la password principale cambia o quando la 2FA è attiva.

Il malware prova anche a sfruttare i password manager del browser, tentando di far compilare automaticamente credenziali in moduli di login nascosti. Questo aumenta il rischio di ulteriore sottrazione di account e di movimento laterale verso altri servizi collegati.

Come vengono sottratte le email

La parte dedicata all’esfiltrazione è costruita per operare con discrezione. Lo script interroga la mailbox per recuperare i messaggi non contrassegnati come spam degli ultimi 90 giorni. I dati raccolti vengono poi compressi e preparati per il trasferimento attraverso un framework operativo denominato Ulej.

L’infrastruttura di comando e raccolta utilizza un sistema Python chiamato Flowerbed. Questo ambiente gestisce il recupero dei dati, evita di esportare più volte le stesse email già sottratte e continua però a raccogliere con costanza i messaggi del giorno corrente a ogni esecuzione dell’exploit.

La trasmissione dei dati avviene con due canali principali: HTTPS e DNS. I dati più piccoli vengono codificati in Base32 e trasferiti tramite query DNS generate da URL di immagini costruiti ad arte. I file più grandi, come archivi di posta e contenuti della Global Address List, vengono invece inviati via HTTPS verso l’infrastruttura controllata dagli aggressori.

Come è costruita l’infrastruttura offensiva

Flowerbed sfrutta container Docker per separare le diverse funzioni operative, inclusi i servizi per l’esfiltrazione via HTTP e DNS e i controlli di salute del sistema. L’uso di certificati Let’s Encrypt e di un reverse proxy Nginx aiuta a far sembrare i server più legittimi e a nascondere parte dell’attività malevola.

Gli operatori usano anche servizi VPN come Mullvad per ridurre la tracciabilità. I log JSON e i file payload vengono preparati con cura per l’esfiltrazione, mentre i file più vecchi vengono rimossi automaticamente per limitare le tracce e mantenere basso il profilo operativo.

Impatto sulle organizzazioni

Un incidente di questo tipo non riguarda solo la perdita di email. L’accesso a 90 giorni di messaggi può rivelare decisioni interne, progetti, credenziali temporanee, elenchi di contatti e informazioni utili per attacchi successivi. Per questo la compromissione di una casella di posta va trattata come un evento ad alto impatto, soprattutto in ambienti con scambi riservati o connessi a infrastrutture critiche.

L’elemento più preoccupante è la persistenza: se l’aggressore ha creato un passcode applicativo e ha raccolto codici di recupero 2FA, il semplice reset della password potrebbe non bastare. Serve una bonifica completa dell’account e una verifica estesa di tutte le integrazioni collegate.

Cosa fare subito

Aggiorna immediatamente Zimbra alla versione corretta o al fix disponibile per la vulnerabilità indicata. Revoca tutti i passcode applicativi sospetti, compresi quelli creati di recente o con nomi non riconosciuti.

Controlla anche i codici di recupero 2FA e valuta la loro invalidazione, perché possono essere stati sottratti durante la fase iniziale dell’attacco. È consigliabile esaminare i log della mailbox per individuare attività SOAP anomale, accessi insoliti e richieste non coerenti con il comportamento normale dell’utente.

Verifica inoltre eventuali indicatori nel localStorage del browser, che possono aiutare a ricostruire le date di esfiltrazione delle email. Se trovi segnali di compromissione, isola subito l’account, forza la rotazione delle credenziali e valuta un’analisi forense dell’ambiente interessato.

Misure di riduzione del rischio

  • Applicare con urgenza le patch di sicurezza disponibili.
  • Revocare e ricreare i passcode applicativi usati con Zimbra.
  • Invalidare i codici di recupero 2FA dopo una verifica della compromissione.
  • Controllare i log per richieste SOAP, accessi insoliti e attività non autorizzate.
  • Monitorare i flussi DNS e HTTPS in uscita per individuare possibili canali di esfiltrazione.
  • Rafforzare i controlli antiphishing sulle email in arrivo.
  • Limitare l’uso di accessi applicativi non strettamente necessari.
  • Segmentare gli account e ridurre i privilegi dove possibile.

Perché questa campagna è importante

Questa operazione mostra come un singolo messaggio email possa diventare il punto di ingresso per una compromissione estesa e silenziosa. La combinazione tra spear-phishing, vulnerabilità zero-day, furto di token di accesso e canali di esfiltrazione mascherati rende l’attacco particolarmente efficace contro organizzazioni che dipendono fortemente dalla posta elettronica.

Il caso evidenzia anche una tendenza più ampia: gli attori malevoli stanno industrializzando le loro catene di attacco, unendo automazione, infrastrutture distribuite e tecniche di occultamento sempre più raffinate. Per i difensori, questo significa che la sicurezza della posta non può essere trattata come un tema secondario.

Technical Deep Dive

Il vettore iniziale sfrutta un payload JavaScript veicolato in un SVG inserito in una email di spear-phishing. In un client Zimbra vulnerabile, l’elaborazione impropria di contenuti CSS può innescare l’esecuzione del codice senza azione esplicita da parte dell’utente, trasformando una semplice visualizzazione del messaggio in un evento di compromissione.

La raccolta dati lato account include attributi come email address, device status, OAuth consumers e 2FA scratch codes. Questi elementi sono sufficienti per costruire un profilo operativo dettagliato dell’utente e per aggirare i controlli di autenticazione tramite meccanismi di persistenza basati su application passcode.

Il passcode “ZimbraWeb” agisce come un token applicativo secondario che può mantenere l’accesso indipendentemente dal ciclo di vita della password primaria. In scenari reali, la compromissione di questi artefatti richiede una risposta incidentale più ampia del semplice reset delle credenziali, perché l’aggressore può avere già stabilito una via d’accesso alternativa.

La logica di estrazione posta interroga la mailbox per i messaggi non junk degli ultimi 90 giorni, mentre il giorno corrente viene raccolto sistematicamente a ogni esecuzione. Questo comportamento suggerisce una combinazione di raccolta storica e sincronizzazione incrementale, utile a mantenere aggiornata la copia remota della posta della vittima.

Ulej e Flowerbed costituiscono la componente infrastrutturale dell’operazione. Ulej gestisce la pipeline di raccolta e smistamento, mentre Flowerbed fornisce un backend Python per l’esfiltrazione e l’orchestrazione dei servizi. L’impiego di container Docker separa i ruoli operativi e consente una rapida sostituzione dei componenti, riducendo la fragilità dell’infrastruttura offensiva.

L’esfiltrazione usa un modello ibrido: DNS per dati piccoli e HTTPS per dataset più voluminosi. La codifica Base32 in URL di immagini è una tecnica utile per mascherare il contenuto reale delle richieste, mentre il trasporto via HTTPS verso server con certificati pubblici riduce le anomalie visibili a un’analisi superficiale del traffico.

Per il rilevamento difensivo, i punti di osservazione più utili includono log SOAP anomali, creazione di application passcode non autorizzati, variazioni sospette nei pattern di accesso alla mailbox e traffico DNS con domini o sottodomini ad alta entropia. Anche i residui nel localStorage del browser possono conservare tracce temporali dell’attività di esfiltrazione e risultare preziosi in fase di triage.

In un’ottica di hardening, gli amministratori dovrebbero affiancare alla patching strategy controlli di mail security più severi, limitazione dei client web legacy, revisione dei privilegi degli account e rotazione forzata dei segreti applicativi. La riduzione della superficie d’attacco è essenziale, ma nei casi di compromissione già avvenuta è altrettanto importante il ripristino controllato degli artefatti di autenticazione e la verifica dei movimenti post-exploit.

Fonte: https://cybersecuritynews.com/russian-hackers-exploiting-zimbra-zero-day/

Torna in alto