Zimbra pod ostrzałem: aktywna luka RCE
Atakujący wykorzystują lukę w Zimbra, by uruchamiać komendy, stawiać web shelle i wykradać dane z poczty oraz sekrety uwierzytelniania.
Zimbra na celowniku atakujących
W sieci obserwowane są aktywne ataki wykorzystujące załataną już lukę w Zimbra Collaboration Suite. Problem dotyczy podatności oznaczonej jako CVE-2026-73570, ocenionej na CVSS 8.9. W praktyce pozwala ona na nieautoryzowaną injekcję poleceń systemowych, a w konsekwencji na zdalne wykonanie kodu na serwerze pocztowym.
Podatność można uruchomić przez specjalnie przygotowaną wiadomość SMTP wysłaną do publicznie dostępnego serwera Zimbra. Warunek jest istotny: podatny jest scenariusz, w którym włączone są SNMP notifications, a dodatkowo zainstalowany jest opcjonalny pakiet zimbra-snmp. Do ataku nie jest potrzebne uwierzytelnienie ani żadna interakcja użytkownika.
Co robią napastnicy po wejściu do systemu
Zgromadzone obserwacje pokazują, że po skutecznej eksploitacji sprawcy nie ograniczają się do jednorazowego uruchomienia komendy. Ich działania są wyraźnie nastawione na utrzymanie dostępu i kradzież danych.
Wśród zaobserwowanych technik znalazły się między innymi:
- wdrażanie JSP web shelli i reverse shelli,
- eskalacja uprawnień,
- uruchamianie narzędzi do trwałego zdalnego dostępu,
- wykonywanie kodu bezpośrednio z pamięci,
- pobieranie i uruchamianie dodatkowych ładunków przez
wgetlubcurl, - tworzenie persystencji przez
cron,systemdi pliki startowe powłoki.
W części kampanii atakujący zakładali także własne usługi systemowe, tworzyli lokalne konta i wykorzystywali klucze SSH, aby przemieszczać się między powiązanymi hostami w klastrze.
Cel: poczta, tokeny i sekrety uwierzytelniania
Najcenniejszym celem okazały się nie same skrzynki, lecz sekrety konfiguracyjne i uwierzytelniające Zimbry. Sprawcy używali polecenia zmlocalconfig -s, aby pobrać dane z poziomu serwera, zamiast atakować pojedyncze hasła użytkowników.
Następnie wykorzystywali zdobyte informacje do wykonywania zapytań LDAP i wyciągania wartości takich jak:
zimbraPreAuthKey,zimbraAuthTokenKey,zimbraTwoFactorAuthSecret.
Zaobserwowano też dostęp do poczty oraz zbieranie danych związanych z kontami i skrzynkami. W niektórych przypadkach dane były pakowane do archiwów ZIP albo do plików tar, a potem przygotowywane do wyprowadzenia poza środowisko ofiary.
Dodatkowe narzędzia i mechanizmy exfiltracji
W jednej z kampanii napastnicy wykorzystali lekki downloader shellowy, który pobierał binarkę Go o nazwie Zimdown2. Ta z kolei instalowała komponent zdalnego dostępu Zimclient2.
Ten agent umożliwiał:
- interaktywną powłokę,
- dwukierunkową operację na plikach,
- proxy SOCKS5,
- transport przez WebSocket, TLS i raw TCP.
W innym scenariuszu sprawcy użyli również narzędzi chmurowych do próby wyprowadzenia danych. Na jednym z przejętych serwerów spakowano świeże kopie zapasowe skrzynek do final.tar.gz, a potem pobrano AzCopy i próbowano wysłać dane do zasobu w Azure Blob Storage. Nie ma jednak potwierdzenia, że transfer zakończył się powodzeniem.
Kto jest zagrożony i jakie systemy są narażone
Microsoft wskazał, że zaatakowane zostały organizacje z więcej niż jednego regionu i branży. Na ten moment nie wiadomo, kto stoi za kampanią. Istotne jest jednak to, że aktywność była widoczna w okresie między publikacją poprawki dla Zimbra 10.1.20 a późniejszym ujawnieniem luki.
Dodatkowe sygnały ostrzegawcze pojawiły się wcześniej: polski CERT zwracał uwagę na konieczność sprawdzania logów /var/log/zimbra.log oraz poszukiwania podejrzanych plików w katalogach tymczasowych i w webapps. Następnie luka trafiła też do katalogu znanych, aktywnie wykorzystywanych podatności CISA.
Co zrobić teraz
Najlepszą obroną jest natychmiastowa aktualizacja do Zimbra 10.1.20 lub nowszej wersji. Jeśli patchowanie nie jest możliwe od razu, warto:
- odinstalować pakiet
zimbra-snmp, - wyłączyć SNMP notifications,
- ograniczyć dostęp do SNMP i SMTP wyłącznie do zaufanych hostów,
- zrotować sekrety uwierzytelniania Zimbry,
- przeskanować serwer pod kątem web shelli i dodatkowych mechanizmów persystencji.
W przypadku Zimbry nie chodzi więc tylko o łatkę, ale o pełne sprawdzenie, czy serwer nie został już wcześniej wykorzystany jako punkt wejścia do dalszego ataku.