Zimbra Zero-Day: Come Verificare se il Tuo

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:

1. Disabilita l'accesso admin da internet
2. Limita gli IP che possono raggiungere le porte 7071 (admin) e 443
3. 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 è:

1. Patchare — subito, non "la prossima settimana"
2. Monitorare — ogni giorno, non una volta al mese
3. 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.