LAUNDRY BEAR kradnie pocztę Zimbra bez klikania. Polska AW i SKW współtworzą ostrzeżenie

Rosyjska grupa wspierana przez państwo wykorzystuje podatność CVE-2025-66376 w Zimbra Collaboration Suite. Złośliwy kod uruchamia się po wyświetleniu przygotowanej wiadomości w podatnym webmailu. Napastnicy mogą automatycznie wykraść 90 dni korespondencji, książkę adresową, hasło, kody 2FA oraz utworzyć osobne hasło aplikacyjne zapewniające trwały dostęp do skrzynki.

Międzynarodowe służby ostrzegają przed kampanią szpiegowską

23 lipca 2026 roku agencje bezpieczeństwa z USA, Wielkiej Brytanii, Holandii, Australii i innych państw opublikowały wspólne ostrzeżenie dotyczące rosyjskiej grupy określanej jako LAUNDRY BEAR.

Dokument współtworzyły również dwie polskie instytucje:

• Agencja Wywiadu,
• Służba Kontrwywiadu Wojskowego.

Według autorów grupa od co najmniej lipca 2025 roku atakuje zachodnie organizacje korzystające z Zimbra Collaboration Suite. Celem jest przede wszystkim ciche pozyskiwanie korespondencji i innych informacji wartościowych dla rosyjskich służb.

Pełny opis kampanii znajduje się w wspólnym ostrzeżeniu opublikowanym przez brytyjskie NCSC. Komunikat udostępniło również Australian Cyber Security Centre.

Kim jest LAUNDRY BEAR?

LAUNDRY BEAR jest nazwą nadaną grupie przez holenderskie służby AIVD i MIVD. W raportach innych instytucji i firm ta sama lub częściowo pokrywająca się aktywność może występować jako:

• Void Blizzard,
• CL-STA-1114,
• TA488,
• wcześniej UNK_PitStop.

Nazwy stosowane przez poszczególne firmy nie zawsze oznaczają dokładnie ten sam zbiór operatorów, narzędzi i operacji.

Grupa działa co najmniej od kwietnia 2024 roku. Wcześniej wykorzystywała między innymi:

• password spraying,
• skradzione dane uwierzytelniające,
• klasyczny phishing,
• przejmowanie plików cookie i sesji,
• fałszywe strony logowania,
• narzędzie Evilginx do ataków adversary-in-the-middle.

Od lipca 2025 roku operatorzy zaczęli wykorzystywać bardziej zaawansowaną technikę wymierzoną bezpośrednio w Zimbra Collaboration Suite.

Złośliwa wiadomość nie wymaga kliknięcia

Tradycyjny phishing zwykle wymaga wykonania działania przez odbiorcę: kliknięcia odnośnika, pobrania załącznika albo wpisania hasła na fałszywej stronie.

W kampanii LAUNDRY BEAR wystarczy wyświetlenie wiadomości w podatnej wersji klasycznego interfejsu Zimbra Web Client.

W treści wiadomości znajduje się przygotowany kod JavaScript. Ze względu na podatność CVE-2025-66376 kod może zostać wykonany w aktywnej, uwierzytelnionej sesji użytkownika.

Ofiara nie musi:

• otwierać załącznika,
• uruchamiać programu,
• wpisywać hasła,
• zatwierdzać komunikatu,
• wyłączać programu antywirusowego.

Mechanizm jest określany jako exploit uruchamiany przez wyświetlenie wiadomości — view-based exploit. Nie jest to całkowicie pasywny atak na serwer: przygotowana wiadomość musi znaleźć się w skrzynce i zostać wyrenderowana w podatnym webmailu. Nie wymaga jednak typowego kliknięcia kojarzonego z phishingiem.

Czym jest CVE-2025-66376?

CVE-2025-66376 jest podatnością typu stored cross-site scripting, czyli trwałym XSS. Problem wynika z niewłaściwego oczyszczania dyrektyw CSS @import znajdujących się w wiadomości HTML.

Napastnik może umieścić zakodowany ładunek w elemencie SVG. Po wyświetleniu wiadomości skrypt:

1. odczytuje token CSRF aktywnej sesji,
2. wysyła żądania do interfejsów Zimbry,
3. zbiera informacje o koncie,
4. kopiuje korespondencję,
5. próbuje pozyskać lub utworzyć dodatkowe dane logowania,
6. wysyła zebrane informacje na serwer napastnika.

Podatność dotyczy:

• Zimbra Collaboration 10 w wersjach wcześniejszych niż 10.0.18,
• Zimbra Collaboration 10.1 w wersjach wcześniejszych niż 10.1.13.

Poprawka została opublikowana 6 listopada 2025 roku. Szczegóły można znaleźć w oficjalnym centrum bezpieczeństwa Zimbra oraz wpisie NVD dotyczącym CVE-2025-66376.

Luka była zero-dayem

Kampania rozpoczęła się w lipcu 2025 roku, czyli kilka miesięcy przed udostępnieniem aktualizacji oraz publicznym opisaniem CVE.

Oznacza to, że w początkowej fazie LAUNDRY BEAR wykorzystywał podatność typu zero-day — producenci i administratorzy nie dysponowali jeszcze publiczną poprawką.

Obecnie luka nie jest już zero-dayem, ponieważ aktualizacja jest dostępna od listopada 2025 roku. Ataki nadal mogą być skuteczne przeciwko organizacjom, które nie zainstalowały poprawki.

Co kradnie narzędzie Ulej?

Grupa wykorzystuje własny mechanizm nazwany Ulej — od rosyjskiego słowa oznaczającego ul.

Po wykonaniu skryptu Ulej próbuje zebrać:

• wiadomości wysłane i odebrane w ciągu ostatnich 90 dni,
• adres e-mail ofiary,
• listę kontaktów,
• globalną książkę adresową organizacji,
• załączniki,
• dane dotyczące środowiska i wersji Zimbry,
• kody zapasowe uwierzytelniania dwuskładnikowego,
• hasło automatycznie uzupełnione przez menedżera haseł,
• informacje o urządzeniach,
• dane dotyczące aplikacji OAuth,
• nowo utworzone hasło aplikacyjne.

Kradzież globalnej książki adresowej może dostarczyć napastnikom danych kolejnych pracowników. Informacje mogą później zostać wykorzystane do przygotowania następnych, bardziej wiarygodnych wiadomości.

Hasło aplikacyjne zapewnia trwały dostęp

Samo skopiowanie wiadomości nie kończy ataku. Skrypt próbuje również przygotować metodę późniejszego logowania do skrzynki.

Włączenie IMAP

Malware wysyła żądanie zmieniające preferencje konta i próbuje włączyć dostęp przez IMAP.

IMAP pozwala klientowi pocztowemu łączyć się bezpośrednio ze skrzynką. W niektórych konfiguracjach nie obsługuje standardowego mechanizmu 2FA stosowanego w interfejsie internetowym.

Utworzenie hasła „ZimbraWeb”

Następnie skrypt próbuje wygenerować Application Passcode o nazwie:

ZimbraWeb

Hasło aplikacyjne może zostać wykorzystane do logowania przez klienta pocztowego bez przechodzenia zwykłej procedury 2FA.

Autorzy ostrzeżenia podkreślają, że hasło aplikacyjne nazwane „ZimbraWeb” jest w tej kampanii bardzo silnym wskaźnikiem kompromitacji. Sam webmail obsługuje 2FA i nie potrzebuje takiego hasła do normalnego działania.

Kradzież kodów zapasowych 2FA

Skrypt wykonuje również żądanie GetScratchCodesRequest, aby pobrać kody awaryjne. Takie kody mogą być wykorzystane zamiast jednorazowego tokenu 2FA.

Oznacza to, że samo włączenie uwierzytelniania dwuskładnikowego nie zatrzyma ataku wykorzystującego aktywną sesję i podatny kod webmaila.

Jak dane opuszczają organizację?

Ulej wykorzystuje dwa kanały przesyłania informacji.

Szyfrowane połączenia HTTPS

Korespondencja, kontakty, załączniki i informacje o koncie są wysyłane do infrastruktury kontrolowanej przez napastników. Grupa korzysta z ważnych certyfikatów Let’s Encrypt, dlatego połączenie może wyglądać jak zwykły szyfrowany ruch HTTPS.

Ważny certyfikat nie oznacza, że serwer jest zaufany. Potwierdza jedynie szyfrowanie połączenia z określoną domeną.

Eksfiltracja przez DNS

Część krótszych informacji może zostać zakodowana w subdomenach i wysłana jako zapytania DNS.

Tą drogą mogą zostać przesłane między innymi:

• adres użytkownika,
• wersja Zimbry,
• typ klienta,
• kody zapasowe 2FA,
• hasło aplikacyjne,
• hasło pobrane z autouzupełniania.

Dla systemu monitorującego ruch może to wyglądać jak seria zapytań do bardzo długich, losowych nazw domen.

Flowerbed odbiera skradzione dane

Dane trafiają do infrastruktury nazwanej Flowerbed. Jest to zestaw kontenerów Docker wykorzystujących między innymi:

• aplikację Python,
• serwer DNS,
• serwer HTTP,
• Nginx,
• Certbot,
• automatyczne certyfikaty Let’s Encrypt.

Serwery operacyjne są zazwyczaj używane przez okres od 7 do 60 dni, a następnie zastępowane nowymi. Utrudnia to wykrywanie wyłącznie na podstawie statycznej listy adresów IP.

W kodzie Flowerbed znaleziono oznaki mogące świadczyć o wykorzystaniu AI podczas tworzenia narzędzia. Autorzy ostrzeżenia oceniają, że grupa mogła używać sztucznej inteligencji do wsparcia prac programistycznych.

Nie oznacza to, że cały atak był autonomicznie prowadzony przez AI. Narzędzia zostały przygotowane i wykorzystane przez operatorów.

Kogo atakuje LAUNDRY BEAR?

Potwierdzone cele obejmują organizacje związane z:

• przemysłem obronnym,
• administracją centralną i lokalną,
• energetyką,
• edukacją,
• organami ścigania,
• mediami,
• organizacjami pozarządowymi,
• sektorem technologicznym.

Wcześniej intensywnie atakowane były podmioty ukraińskie. Następnie techniki wykorzystano również przeciwko organizacjom w USA oraz innych państwach NATO.

Udział polskiej AW i SKW w publikacji ostrzeżenia pokazuje, że zagrożenie ma znaczenie także dla organizacji działających w Polsce. Nie opublikowano jednak liczby ani nazw ewentualnych polskich poszkodowanych.

Jak sprawdzić, czy Zimbra jest bezpieczna?

1. Zweryfikuj dokładną wersję

Administrator powinien potwierdzić wersję działającego serwera, a nie opierać się wyłącznie na dokumentacji wdrożenia.

Minimalne wersje zawierające poprawkę to:

Linia Zimbra	Minimalna poprawiona wersja
ZCS 10.0	10.0.18
ZCS 10.1	10.1.13

Należy instalować najnowsze obecnie wspierane wydanie, a nie ograniczać się do historycznego minimum z listopada 2025 roku.

2. Jeżeli aktualizacja nie jest natychmiast możliwa

Autorzy ostrzeżenia zalecają tymczasowe:

• ograniczenie korzystania z webmaila Zimbra,
• unikanie klasycznego interfejsu ZCS,
• korzystanie z alternatywnego klienta pocztowego,
• monitorowanie serwera i stacji użytkowników.

Jest to wyłącznie rozwiązanie tymczasowe. Nie zastępuje aktualizacji.

3. Zabezpiecz kopie logów

Przed większymi zmianami należy zachować:

• /opt/zimbra/log/mailbox.log,
• logi serwera proxy i WWW,
• logi DNS,
• dane NetFlow,
• logi uwierzytelniania,
• historię zmian ustawień kont,
• informacje o hasłach aplikacyjnych,
• zdarzenia związane z 2FA,
• logi systemów pocztowych i SIEM.

Najważniejsze oznaki kompromitacji

Nietypowe żądania SOAP

W pliku mailbox.log należy wyszukać:

• dużą liczbę SearchGalRequest dla jednego użytkownika w krótkim czasie,
• CreateAppSpecificPasswordRequest,
• utworzenie hasła aplikacyjnego o nazwie ZimbraWeb,
• GetScratchCodesRequest,
• ModifyPrefsRequest włączające IMAP,
• nietypowe serie żądań dotyczących książki adresowej.

Pojedyncze wywołanie części tych funkcji może mieć legalne uzasadnienie. Ich kombinacja w krótkim czasie powinna jednak uruchomić analizę incydentu.

Artefakty w przeglądarce

Ulej zapisuje w localStorage znaczniki dotyczące dni, z których skopiowano wiadomości. Mają one format:

zd_comp_YYYY-MM-DD

Znalezienie takich wartości w danych witryny Zimbra może świadczyć o wykonaniu skryptu. Daty mogą również pomóc w określeniu zakresu skradzionej korespondencji.

Podejrzany ruch DNS

Należy sprawdzić:

• dużą liczbę zapytań do losowych subdomen,
• bardzo długie nazwy hostów,
• charakterystyczny człon .i. przed domeną główną,
• połączenia do nowo zarejestrowanych domen,
• przesyłanie danych do nieużywanych wcześniej serwerów VPS.

Historyczne domeny kampanii

W ostrzeżeniu wymieniono między innymi:

• zmailanalytics[.]com
• zimbra-metadata[.]com
• analyticemailmeter[.]com
• emailanalytics.com[.]ua
• mailnalysis[.]com
• zimbrastat[.]com
• zimbrasoft.com[.]ua
• synacorzimbra[.]nl
• istc-cloud[.]com

Lista ma przede wszystkim znaczenie historyczne. Infrastruktura grupy jest regularnie zmieniana, dlatego brak tych domen w logach nie wyklucza kompromitacji. Kompletną listę adresów IP, certyfikatów i skrótów wiadomości zawiera wspólne ostrzeżenie.

Co zrobić po znalezieniu śladów ataku?

1. Ogranicz korzystanie z podatnego webmaila

Do czasu zainstalowania poprawki użytkownicy nie powinni otwierać wiadomości w podatnym klasycznym interfejsie.

2. Znajdź i poddaj kwarantannie wiadomość

Należy wyszukać pierwotną wiadomość zawierającą przygotowany ładunek, zabezpieczyć ją do analizy, a następnie odnaleźć jej kopie w pozostałych skrzynkach.

Nie należy otwierać podejrzanej wiadomości w podatnym webmailu podczas analizy.

3. Unieważnij wszystkie dodatkowe metody logowania

Autorzy ostrzeżenia zalecają unieważnienie:

• wszystkich haseł aplikacyjnych,
• kodów zapasowych 2FA,
• aktywnych sesji,
• podejrzanych tokenów OAuth,
• innych danych uwierzytelniających powiązanych ze skrzynką.

4. Zmień hasła z czystego urządzenia

Hasła należy zmieniać dopiero z zaufanego komputera. Trzeba również uwzględnić możliwość, że skrypt pobrał hasło automatycznie uzupełnione przez menedżer haseł.

Jeżeli to samo hasło było używane w innym systemie, również wymaga zmiany.

5. Ustal zakres wycieku

Dla każdego zaatakowanego konta należy określić:

• datę pierwszego wykonania skryptu,
• dni oznaczone w localStorage,
• zakres korespondencji z ostatnich 90 dni,
• ujawnione załączniki,
• osoby znajdujące się w książce adresowej,
• systemy i projekty opisane w wiadomościach,
• hasła, klucze i dane dostępowe przesyłane pocztą.

Korespondencja może zawierać informacje pozwalające na przeprowadzenie kolejnych ataków, nawet jeżeli nie zapisano w niej jawnych haseł.

Jak ograniczyć podobne ryzyko?

Aktualizuj system pocztowy w pierwszej kolejności

Serwer pocztowy jest dostępny z internetu i przechowuje dane wielu pracowników. Krytyczne poprawki nie powinny czekać na zwykłe kwartalne okno serwisowe.

Stosuj zewnętrzną warstwę uwierzytelniania

Agencje rekomendują rozważenie zewnętrznego dostawcy tożsamości obsługującego passkeys. Uwierzytelnianie odporne na phishing może ograniczyć skutki kradzieży haseł.

Nie usuwa jednak podatności XSS ani ryzyka związanego z niekontrolowanymi hasłami aplikacyjnymi.

Monitoruj hasła aplikacyjne

Każde utworzenie nowego Application Passcode powinno:

• generować alert,
• posiadać właściciela,
• być powiązane z uzasadnioną aplikacją,
• mieć ograniczony czas ważności,
• podlegać regularnemu przeglądowi.

Przechowuj logi poza serwerem Zimbra

Napastnik posiadający długotrwały dostęp może próbować usunąć lokalne ślady. Logi serwera, DNS i proxy powinny trafiać do oddzielnego systemu SIEM lub bezpiecznego repozytorium.

Monitoruj nietypową eksfiltrację

Alarm powinny powodować między innymi:

• masowe pobieranie wiadomości,
• częste odpytywanie globalnej książki adresowej,
• transfer do nieznanego VPS,
• nietypowe zapytania DNS,
• logowanie przez IMAP po utworzeniu nowego hasła aplikacyjnego,
• dostęp z komercyjnego VPN,
• nagła zmiana ustawień konta.

Fakty potwierdzone i informacje nieustalone

Potwierdzone:

• LAUNDRY BEAR jest grupą wspieraną przez państwo rosyjskie.
• Kampania przeciwko Zimbrze trwa co najmniej od lipca 2025 roku.
• Grupa wykorzystywała CVE-2025-66376 przed publikacją poprawki.
• Wystarczy wyświetlenie przygotowanej wiadomości w podatnym webmailu.
• Exploit może skopiować 90 dni korespondencji, kontakty i książkę adresową.
• Skrypt próbuje wykraść kody zapasowe 2FA i hasła uzupełniane automatycznie.
• Ulej może włączyć IMAP i utworzyć hasło aplikacyjne „ZimbraWeb”.
• Poprawki udostępniono w ZCS 10.0.18 oraz 10.1.13.
• Polska AW i SKW współtworzyły międzynarodowe ostrzeżenie.
• Kampania jest ukierunkowana na szpiegostwo, a nie potwierdzone wymuszenia finansowe.

Nieujawnione lub niepotwierdzone publicznie:

• pełna liczba zaatakowanych organizacji,
• liczba poszkodowanych w Polsce,
• nazwiska i konta konkretnych ofiar,
• wszystkie wykorzystywane obecnie domeny i serwery,
• dokładna data rozpoczęcia każdej operacji,
• pełny zakres danych przekazanych rosyjskim instytucjom,
• to, czy skradzione informacje posłużyły już do kolejnych operacji.

Ocena: szczególnie narażone są organizacje utrzymujące Zimbrę samodzielnie, bez regularnego procesu aktualizacji i z ograniczoną widocznością ruchu DNS. Brak kliknięcia przez użytkownika nie chroni przed atakiem, dlatego szkolenie antyphishingowe musi być uzupełnione aktualizacjami i monitoringiem technicznym.

Podsumowanie

Kampania LAUNDRY BEAR pokazuje, że wiadomość phishingowa może być niebezpieczna nawet wtedy, gdy użytkownik nie kliknie linku ani nie otworzy załącznika. W podatnej wersji klasycznego webmaila Zimbra samo wyświetlenie treści pozwala uruchomić kod w aktywnej sesji.

Organizacje powinny natychmiast potwierdzić używaną wersję ZCS, wdrożyć aktualizację i sprawdzić logi SOAP, hasła aplikacyjne, kody 2FA oraz dane localStorage. Wykrycie hasła aplikacyjnego „ZimbraWeb” lub znaczników zd_comp_YYYY-MM-DD powinno uruchomić pełną procedurę reagowania na incyden