TL;DR
- Cosa impari: Come verificare se il tuo server Zimbra è stato violato tramite il zero-day di Laundry Bear (Void Blizzard)
- Tempo richiesto: 30-45 minuti
- Difficoltà: Media — servono accesso admin e familiarità con log di sistema
Il Problema
Hai un server Zimbra in produzione? Perfetto, siediti.
CISA ha appena pubblicato un avviso (AA26-032A) che non puoi ignorare. Il gruppo russo Laundry Bear (noto anche come Void Blizzard o Gamaredon) sta usando una combinazione letale: un zero-click flaw su Zimbra Collaboration + phishing mirato per rubare intere caselle email.
Zero-click significa che l'utente non deve cliccare su niente. Nessun allegato malevolo, nessun link sospetto. L'attaccante invia una mail che il server Zimbra processa automaticamente, e boom — ha le tue credenziali.
Se stai leggendo questo probabilmente hai visto:
- Utenti che lamentano attività sospette nelle proprie caselle (invio di mail che non hanno scritto)
- Sessioni SMTP/IMAP da IP geografici improbabili (Russia, Ucraina, Bielorussia)
- File sconosciuti nella cartella Drafts o Sent
- Il server Zimbra che consuma CPU inspiegabilmente alta
La vulnerabilità è già stata sfruttata in natura. Non è una questione di "se", ma di "quando".
Prerequisiti
Prima di iniziare, assicurati di avere:
- Accesso root o sudo al server Zimbra
- Accesso all'interfaccia di amministrazione Zimbra
- Possibilità di leggere i log in
/opt/zimbra/log/
- Un browser per controllare le sessioni attive
- Accesso ai DNS del dominio (per verificare record MX e SPF)
Se non hai almeno uno di questi, coinvolgi subito chi ce l'ha.
Step 1: Verifica le Sessioni IMAP/SMTP Attive
Il primo passo è controllare chi è connesso al momento.
# Come utente zimbra
su - zimbra
zmsoap -z GetActiveSessionsRequest
Questo ti dà un elenco delle sessioni attive. cerca anomalie:
- Sessioni da IP esterni che non riconosci
- Sessioni multiple dello stesso utente da location diverse
- Sessioni che sono attive da troppo tempo ( giorni )
Errori comuni:
- "zmsoap command not found" → Usa il percorso completo
/opt/zimbra/bin/zmsoap
- Permission denied → Esegui come utente zimbra, non root
Se vedi roba sospetta, disconnetti subito:
zmsoap -z KillSessionRequest/by user/nome.utente@tuodominio.it
Step 2: Controlla i Log di Accesso
Qui trovi le tracce dell'attacco. I log di Zimbra sono in /opt/zimbra/log/.
# Log autenticazione — cerca tentativi multipli o da IP strani
grep -i "authentication failed" /opt/zimbra/log/mailbox.log | tail -100
# Log delle sessioni recenti
grep -i "session" /opt/zimbra/log/mailbox.log | tail -50
# Log degli allegati — cerca upload di file strani
grep -i "attachment" /opt/zimbra/log/mailbox.log | tail -50
Cosa cercare:
- Tanti tentativi di login successivi dallo stesso IP
- Login da IP che non sono nella tua lista bianca
- Comandi IMAP strani (es.
SELECT, FETCH ripetuti)
- Richieste di
export o import di mailbox
Comando utile per IP sospetti:
# Estrai IP unici che hanno fallito l'autenticazione
grep "authentication failed" /opt/zimbra/log/mailbox.log | grep -oE "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" | sort | uniq -c | sort -rn | head -20
Se vedi IP russi, ucraini o di VPN/proxy pubbliche, hai un problema.
Step 3: Verifica le Folder e i Filtri Utente
Laundry Bear spesso crea regole di inoltro automatico per intercettare le email. Controlla i filtri di ogni casella:
# Lista le regole di filtro per un utente
su - zimbra -c "zmmailbox -z -m utente@tuodominio.it getFilterRules"
# Lista tutti gli invii automatici (forward)
zmprov ga utente@tuodominio.it zimbraPrefMailForwardingAddress
Cosa cercare:
- Forward verso domini esterni che non conosci
- Regole che spostano automaticamente email in folder nascoste
- Filtri che inoltrano tutto a un indirizzo terzo
Se trovi qualcosa di sospetto:
# Rimuovi un forward malevolo
zmprov ma utente@tuodominio.it zimbraPrefMailForwardingAddress ""
# Rimuovi tutte le regole filtro
zmmailbox -z -m utente@tuodominio.it removeFilterRules
Step 4: Controlla gli Allegati Recenti
Il zero-day può permettere l'esecuzione di attachment malevoli. Verifica cosa è stato caricato:
# Lista allegati recenti (ultimi 7 giorni)
find /opt/zimbra/store -name "*" -type f -mtime -7 | head -50
# Cerca file eseguibili caricati di recente
find /opt/zimbra/store -type f -mtime -7 \( -name "*.exe" -o -name "*.sh" -o -name "*.vbs" -o -name "*.js" \)
I file di Zimbra sono organizzati per ID. Se non sai cosa cercare, concentrati su:
- File nella
/tmp del server Zimbra
- File scaricati nelle ultime 24-48 ore
- Attachment con nomi sospetti (invoice, payment, document_urgent)
Step 5: Verifica la Versione di Zimbra e Applica le Patch
Questo è il momento di assicurarti di essere aggiornato. Controlla la versione:
zmcontrol -v
# Output tipico:
# Release 10.0.5 ZCS, Patch 5
# Release 9.0.0 ZCS, Patch 18
vai su Zimbra Support Portal e verifica quale patch è l'ultima disponibile per la tua versione.
Patch note:
- Zimbra 9.0.0 e 10.0.x hanno ricevuto fix per CVE-2024-45519 e vulnerabilità simili
- Assicurati di avere almeno la patch relativa ai fix di sicurezza di agosto 2024
Se non puoi patchare subito (capisco, ci sono sistemi che non si possono toccare), almeno:
- Disabilita l'accesso admin da internet
- Limita gli IP che possono raggiungere le porte 7071 (admin) e 443
- Abilita il logging avanzato
Step 6: Verifica i DNS e il Dominio
L'attacco può aver modificato i record DNS per redirigere il traffico. Controlla:
# Verifica record MX
dig MX tuodominio.it +short
# Verifica record SPF
dig TXT tuodominio.it +short
# Verifica record DMARC
dig _dmarc.tuodominio.it +short
Cosa non deve cambiare:
- I server MX devono puntare ai tuoi server Zimbra
- SPF deve includere solo i tuoi server autorizzati
- DMARC deve essere ancora attivo
Se i DNS sono cambiati (es. nuovi MX che non riconosci), hai un problema serio — probabilmente il dominio è stato compromesso a monte.
Verifica: Come Testare che Sei al Sicuro
Dopo aver fatto i passaggi precedenti, ecco come confermare che il server è pulito:
Test 1: Nessuna sessione sospetta
zmsoap -z GetActiveSessionsRequest | grep -v "127.0.0.1"
Nessun risultato = nessuna sessione strana
Test 2: Log puliti
grep -i "error\|failed\|unauthorized" /opt/zimbra/log/mailbox.log | tail -20
Solo errori legittimi (es. password sbagliata da utente reale)
Test 3: Forward puliti
zmprov -l getAllAccounts | while read account; do
forward=$(zmprov ga "$account" zimbraPrefMailForwardingAddress 2>/dev/null | grep ":")
if [ -n "$forward" ]; then
echo "$account: $forward"
fi
done
Solo i forward che conosci
Se tutti e tre i test passano, per ora sei a posto. Ma ricorda: "per ora" è la parola chiave.
Troubleshooting
D: Non ho accesso come utente zimbra, solo come root R: Esegui su - zimbra -s /bin/bash oppure usa sudo -u zimbra prima dei comandi
D: I log sono enormi, il grep impiega una vita R: Usa tail -1000 prima del grep per limitare ai log recenti, oppure zgrep per i log compressi
D: Trovo attività sospetta ma non sono sicuro R: Isola il server dalla rete immediatamente. Contatta il supporto Zimbra e considera di coinvolgere un SOC
D: Non posso patchare subito il server R: Minimizza l'esposizione — disabilita l'accesso admin da internet, limita le sessioni concurrent per utente, attiva 2FA se possibile
D: Come faccio a sapere se la vulnerabilità è stata già sfruttata? R: Cerca nei log attività prima della data del patch. Se vedi sessioni da IP stranieri che non sono tuoi dipendenti in viaggio, è probabile
Conclusione
Il zero-day di Zimbra non è uno scherzo. Laundry Bear è un APT che non si limita a rubare credenziali — ruba intere caselle email, spia conversazioni, usa quelle informazioni per attacchi mirati contro la tua organizzazione.
I 6 step che ti ho dato non sono la soluzione definitiva. Sono il punto di partenza. La vera difesa è:
- Patchare — subito, non "la prossima settimana"
- Monitorare — ogni giorno, non una volta al mese
- Formare gli utenti — perché il phishing che accompagna questo attacco è ancora più pericoloso
Se non hai le risorse per farlo internamente, valuta una soluzione che semplifica: MailSniper gestisce la protezione email con sandboxing e analisi real-time, così non devi preoccuparti di patchare manualmente ogni vulnerabilità.
La sicurezza al 100% non esiste. Ma between "non ho fatto niente" e "ho controllato e sono al sicuro", c'è una differenza enorme. Oggi hai fatto il secondo passo.