W najnowszym wydaniu Krajobrazu Zagrożeń przyglądamy się kampaniom rosyjskich grup APT z wykorzystaniem techniki half-click oraz podatności w webmailach, dzięki którym do przejęcia skrzynki może wystarczyć samo otwarcie wiadomości. Analizujemy również nowy system nazewnictwa grup APT wprowadzony przez GTIG oraz jego konsekwencje dla pracy analityków CTI. Na koniec omawiamy CosmosEscape — podatność w Azure Cosmos DB, która pokazała jakie skutki może mieć naruszenie izolacji między klientami usługi SaaS.

Zaawansowane zagrożenia

Half-click zamiast phishingu. Rosyjskie grupy APT wykorzystują podatności w webmailach

• Ataki typu half-click pozwalają ominąć klasyczny model phishingu, ponieważ do kompromitacji może wystarczyć samo otwarcie wiadomości w podatnym webmailu.
• TA458 i TA488, grupy powiązane z Rosją, wykorzystywały tę technikę przeciwko użytkownikom Roundcube, Zimbry i OWA.
• Cele kampanii obejmowały m.in. organizacje europejskie, w tym sektor telekomunikacyjny.

Half-click 

Przez lata powodzenie kampanii e-mailowych zależało przede wszystkim od skuteczności socjotechniki i nakłonienia użytkownika do kliknięcia linku czy pobrania załącznika. Sytuacja zaczęła się zmieniać wraz z wykorzystaniem podatności w platformach webmail, które pozwalają przeprowadzić atak bez konieczności dodatkowej interakcji użytkownika. 

Mechanizm określany jako half-click ogranicza wymaganą interakcję użytkownika do otwarcia wiadomości lub, zależnie od klienta, jej podglądu dzięki wykorzystaniu podatności, najczęściej typu cross-site scripting (XSS). Złośliwy HTML jest przetwarzany przez podatny webmail, a następnie uruchamia JavaScript w kontekście aktywnej sesji ofiary. Skrypt uzyskuje w ten sposób dostęp do funkcji i danych dostępnych dla zalogowanego użytkownika. Brak linku, załącznika czy wyraźnego wezwania do działania utrudnia zarówno rozpoznanie zagrożenia przez odbiorcę, jak i wykrycie go przez mechanizmy skupione głównie na klasycznym phishingu. 

Choć nazwa może kojarzyć się z exploitami zero-click, różnica jest istotna. W atakach zero-click ofiara nie wykonuje żadnej akcji – podatny system sam przetwarza złośliwą treść. W przypadku half-click użytkownik musi otworzyć wiadomość, ale na tym jego udział się kończy. Nie klika linków, nie pobiera załączników ani nie uruchamia makr. 

Od Roundcube, przez Zimbrę, do OWA 

Proofpoint opisał w ostatnim czasie trzy kampanie wykorzystujące technikę half-click. Mimo że używane były różne podatności i różne platformy, sposób działania pozostawał bardzo podobny z jednym celem: dostęp do skrzynki pocztowej.  

Pierwsza z grup, TA458, prowadziła operację RoundPress przeciwko kilku platformom webmailowym: Roundcube, Zimbrze  mDaemon, SOGo i Kerio Webmail. Wykorzystywany payload SpyPress służył przede wszystkim do kradzieży korespondencji, kontaktów i danych uwierzytelniających. W przypadku Roundcube operatorzy łączyli exploit XSS z podatnością CVE-2025-49113, uzyskując możliwość wykonania kodu na serwerze i wdrożenia mechanizmów trwałego dostępu. 

Natomiast TA488 wykorzystywała odrębną podatność w Zimbrze — CVE-2025-66376 — oraz payload ZimReaper. Po otwarciu wiadomości narzędzie pozyskiwało dane dostępne w sesji użytkownika, w tym hasła zapisane przez przeglądarkę, kody zapasowe 2FA, kontakty i wiadomości. Tworzyło również hasło aplikacyjne „ZimbraWeb”, zapewniające dalszy dostęp przez IMAP, POP3 lub SMTP.  

W kolejnej kampanii TA488 przeniosła ten model na Outlook Web Access, wykorzystując CVE-2026-42897 i implant OWAReaper. OWAReaper zapewniał utrzymanie dostępu zarówno w artefaktach przeglądarki, jak i przez zmianę uprawnień folderów skrzynki po stronie Exchange.  

TA458 jest oceniana jako prawdopodobnie powiązana z rosyjskim wywiadem wojskowym i działająca pod kierownictwem GRU. W przypadku TA488 pierwotna analiza wykazała podobieństwa do grupy Void Blizzard, znanej również jako Laundry Bear. Związek ten został następnie potwierdzony we współpracy z partnerami rządowymi Stanów Zjednoczonych a dostępne informacje wskazują, że TA488 działa jako prywatny wykonawca na rzecz rosyjskiego wywiadu. 

Cele ataków 

Choć znaczna część kampanii była wymierzona w organizacje związane z Ukrainą, administrację publiczną czy sektor obronny, lista ofiar była znacznie szersza. Obserwowano również działania skierowane przeciwko organizacjom z Europy. Wśród atakowanych podmiotów znalazły się przedsiębiorstwa z sektora telekomunikacyjnego, finansowego, lotniczego i hotelarskiego. Pokazuje to, że zainteresowanie rosyjskich grup nie ogranicza się wyłącznie do administracji państwowej, ale obejmuje również podmioty dysponujące wartościowymi informacjami lub odgrywające istotną rolę w funkcjonowaniu państwa i gospodarki. 

Temat ma znaczenie również z perspektywy polskich organizacji. Zimbra jest popularnym rozwiązaniem wśród części polskich przedsiębiorstw i instytucji, natomiast Outlook Web Access pozostaje powszechnym sposobem dostępu do poczty w środowiskach Microsoft Exchange. 

Patrząc szerzej

Wykorzystanie podatności w webmailach pokazuje, że poczta elektroniczna pozostaje jednym z najcenniejszych celów dla grup prowadzących operacje cyberwywiadowcze. Przejęcie skrzynki pocztowej zapewnia dostęp nie tylko do treści wiadomości, ale również do informacji o strukturze organizacji, relacjach z partnerami oraz bieżących projektach. Dla grup APT dane te mogą być punktem wyjścia do dalszych działań, w tym przygotowania ukierunkowanych wiadomości phishingowych oraz identyfikacji osób mających dostęp do istotnych zasobów. 

Więcej informacji:  
https://www.proofpoint.com/us/blog/threat-insight/cleaning-out-inboxes-ta488-comes-outlook-another-half-click-exploit 
https://www.proofpoint.com/us/blog/threat-insight/ta458-roundpress-exploits 
https://www.proofpoint.com/us/blog/threat-insight/ta488-targets-zimbra-mailservers-half-click-exploits 

Metodyka

Nowe nazwy, stary problem. Google zmienia sposób nazywania grup APT

• Google zmienia sposób nazywania grup APT, zastępując dotychczasowe konwencje Mandiant i TAG jednym systemem Google Threat Intelligence. 
• APT28 staje się LAKE RELIC, APT29 – ICE RELIC, a APT41 – SPIRE CASTLE – nowe nazwy mają być łatwiejsze do zapamiętania i jednocześnie wskazywać na atrybucję aktora.
• Nowa konwencja porządkuje taksonomię Google, ale nie rozwiązuje problemu wielu nazw w CTI – dla analityków oznacza na razie kolejny system aliasów, który trzeba mapować do już istniejących.

Nazewnictwo grup APT od lat przypomina język, w którym na określenie tej samej rzeczy funkcjonuje kilka, a czasami kilkanaście różnych słów. Microsoft ma Midnight Blizzard, CrowdStrike – Cozy Bear, a Mandiant przez lata posługiwał się oznaczeniem APT29. Dla osób zajmujących się Cyber Threat Intelligence nie jest to niczym nowym. Mapowanie aliasów stało się po prostu częścią codziennej pracy analitycznej. Teraz do tego słownika trzeba będzie dopisać kolejne pojęcia.

24 lipca Google Threat Intelligence Group (GTIG) ogłosił wprowadzenie nowego, ujednoliconego systemu nazewnictwa aktorów zagrożeń. Zmiana jest konsekwencją połączenia dwóch rozwijanych wcześniej niezależnie modeli: systemu Mandiant oraz Google Threat Analysis Group (TAG). W ramach GTIG mają one zostać zastąpione wspólną taksonomią wykorzystywaną zarówno wewnętrznie, jak i w publicznych raportach Google. 

Koniec z APT? Nadchodzą CASTLE, RELIC i NEPTUNE 

Nowy system opiera się na dwuczłonowych kryptonimach. Pierwszy człon ma identyfikować konkretnego aktora i, tam gdzie jest to możliwe, nawiązywać do nazwy znanej już z wcześniejszych publikacji. Jeśli takiego określenia nie ma, termin jest generowany losowo, a następnie weryfikowany przez analityków GTIG. 

Znacznie ciekawszy jest drugi człon nazwy. Pełni on funkcję klasyfikacyjną i wskazuje na pochodzenie lub charakter aktywności danego klastra. Google przypisał poszczególnym kategoriom charakterystyczne słowa: 

• CASTLE – aktorzy powiązani z Chińską Republiką Ludową,
• ION – Iran,
• NEPTUNE – Korea Północna,
• RELIC – Rosja,
•  COMET – grupy cyberprzestępcze.

W efekcie dobrze znane oznaczenia zaczynają otrzymywać zupełnie nowe odpowiedniki. APT28 staje się LAKE RELIC, APT29 – ICE RELIC, Sandworm/APT44 – SANDWORM RELIC, APT41 – SPIRE CASTLE, natomiast FIN7 otrzymuje nazwę WILD COMET. 

Pomysł ma pewną intuicyjną zaletę. Widząc po raz pierwszy nazwę RIVER CASTLE, analityk nie musi jeszcze wiedzieć, że wcześniej była to APT15, aby z samej konstrukcji nazwy odczytać, że według GTIG jest to aktor powiązany z Chinami. Podobnie końcówka RELIC natychmiast wskazuje na rosyjską atrybucję, a COMET na charakter cyberprzestępczy. 

Według Google właśnie taki kontekst ma być jedną z najważniejszych zalet nowego rozwiązania. Sekwencyjne oznaczenia w rodzaju APT1 wymagają zapamiętywania znaczenia kolejnych numerów, podczas gdy nowy system ma być bardziej intuicyjny i łatwiejszy do wykorzystania przez obrońców. 

Co istotne, nie wszystkie dotychczasowe elementy systemu Mandiant znikną. Google zapowiedział dalsze stosowanie oznaczenia UNC (Uncategorized) wobec klastrów znajdujących się na wczesnym etapie analizy. Dotychczasowe nazwy mają również pozostać indeksowane i wyszukiwalne w Google Threat Intelligence, razem z aliasami innych dostawców oraz mapowaniem do MITRE ATT&CK. Proces migracji będzie stopniowy – na początku objął kilkadziesiąt najbardziej aktywnych grup. 

Na poziomie technicznym trudno więc mówić o prostym wyrzuceniu starego słownika. Google próbuje raczej zbudować nad nim nową warstwę. 

Jeden aktor, wiele nazw  

Z perspektywy społeczności Cyber Threat Intelligence problemem nigdy nie był wyłącznie fakt, że nazwy takie jak APT28 czy UNC4057 są trudniejsze do zapamiętania niż LAKE RELIC czy COLD RELIC. Problemem jest przede wszystkim fragmentacja systemów nazewnictwa. 

Każdy z dużych dostawców Threat Intelligence posiada własną telemetrię, źródła informacji, kryteria grupowania aktywności i poziomy pewności atrybucji. W rezultacie ten sam przeciwnik może występować w raportach różnych organizacji pod wieloma nazwami. Nie oznacza to przy tym, że wszystkie te nazwy są prostymi synonimami. 

To bardzo ważne rozróżnienie. Dwa zespoły badawcze mogą obserwować częściowo pokrywające się klastry infrastruktury, malware i TTP, ale dysponować różnym poziomem widoczności. Jeden może uważać je za działalność jednej grupy, drugi zachować dwa oddzielne klastry do momentu uzyskania mocniejszych dowodów. 

Google sam zwraca uwagę na ten problem, przyznając, że bezpośrednie porównywanie aktorów śledzonych przez różne organizacje jest trudne, ponieważ żadna z nich nie posiada identycznej widoczności krajobrazu zagrożeń. I właśnie dlatego niezależne systemy nazewnictwa mają metodologiczny sens.  

Alias w CTI nie zawsze oznacza więc równoważność.

Problemem nie jest istnienie wielu konwencji 

Atrybucja w CTI nie przypomina katalogu, w którym istnieje jeden obiektywnie zdefiniowany aktor i jedna poprawna nazwa. Jest to proces analityczny. Nowe dane mogą prowadzić do łączenia wcześniej oddzielnych klastrów, ich rozdzielania albo zmiany poziomu pewności co do ich powiązania z określonym państwem, organizacją czy znaną wcześniej grupą. 

Dlatego trudno postulować stworzenie jednego globalnego słownika grup APT. Paradoksalnie mogłoby to prowadzić do utraty części informacji analitycznej. Jeżeli dwie organizacje obserwują nieco inny zakres działalności przeciwnika, używanie odrębnych nazw może być bardziej poprawne niż przedwczesne uznanie obu zbiorów aktywności za jedną grupę. 

Mandiant przez ponad dekadę zbudował jeden z najbardziej rozpoznawalnych modeli atrybucji w branży. Oznaczenia APT, FIN czy później UNC weszły do języka społeczności CTI. Znajdziemy je w tysiącach raportów, platformach Threat Intelligence, regułach detekcyjnych, repozytoriach IOC, prezentacjach, artykułach naukowych i wewnętrznych bazach wiedzy organizacji. 

Zmiana konwencji nie powoduje, że ten historyczny słownik nagle znika. APT28 nadal będzie APT28 w tysiącach wcześniejszych analiz. Jednocześnie będzie LAKE RELIC w nowych materiałach Google i będzie funkcjonował pod kolejnymi nazwami u innych dostawców. Z punktu widzenia całego ekosystemu nie następuje więc redukcja liczby nazw. 

 Uproszczenie czy rebranding? 

Z perspektywy Google decyzja jest zrozumiała. Połączenie Mandiant i TAG w ramach Google Threat Intelligence Group oznaczało konieczność scalenia dwóch niezależnych systemów śledzenia przeciwników. Stworzenie wspólnej taksonomii jest naturalnym elementem takiej integracji. 

Nowy system ma również zalety. Nazwy są bardziej charakterystyczne, zawierają dodatkowy kontekst i mogą być łatwiejsze do zapamiętania niż kolejne numery APT. Trudniej jednak zgodzić się z tezą, że sama zmiana konwencji przynosi większą klarowność całemu ekosystemowi CTI. Dla społeczności analityków oznacza ona przynajmniej początkowo coś odwrotnego: konieczność nauczenia się kolejnego słownika i mapowania go do nazw funkcjonujących od wielu lat. 

Dlatego warto oddzielić dwie kwestie: uproszczenie wewnętrznego modelu Google Threat Intelligence od uproszczenia sposobu, w jaki cała społeczność CTI komunikuje wiedzę o przeciwnikach. Pierwsze prawdopodobnie właśnie następuje. Drugie pozostaje nierozwiązanym problemem.

Patrząc szerzej

Dyskusja o nowych nazwach Google pokazuje szerszy problem: być może w CTI zbyt mocno przywiązaliśmy się do samej nazwy aktora.  W CTI nazwa grupy jest tylko etykietą – o wiele ważniejsza pozostaje analiza TTP (Tactics, Techniques, and Procedures), infrastruktury oraz kontekstu operacyjnego. 

Wartość nowej konwencji nie będzie zależała od tego, czy LAKE RELIC łatwiej zapamiętać niż APT28. Znacznie ważniejsze będzie to, czy system pomoże analitykom korelować informacje, rozumieć zakres poszczególnych klastrów i właściwie interpretować poziom pewności atrybucji. 

Bo największym problemem nazewnictwa w CTI nigdy nie był brak dobrych nazw. Problemem jest to, że mamy ich zbyt wiele – i nie zawsze oznaczają dokładnie to samo

Więcej informacji:  
https://cloud.google.com/blog/topics/threat-intelligence/updated-cyber-threat-actor-naming-system 

Podatności

CosmosEscape – ucieczka z bazy

• Analitycy firmy Wiz opisali podatność w Azure Cosmos DB pozwalającą na ominięcie izolacji pomiędzy tenantami na platformie SaaS. Badacze uzyskali dostęp do Master Key umożliwiającego dostęp do każdego konta w usłudze.
• Nie były konieczne specjalne uprawnienia ani błędy w konfiguracji po stronie klienta. Dostęp odbywał się za pośrednictwem Gremlin API, ale jego skutki wykraczały daleko poza tę usługę. 
• Microsoft docenił pracę badaczy i odpowiedzialne podejście do publikacji informacji o podatności. Mimo wszystko warto podkreślić odpowiedzialność dostawców usług SaaS za bezpieczeństwo oferowanych platform i znikome możliwości ograniczania ryzyka ze strony klientów.

Podatność CosmosEscape, opisana przez badaczy Wiz, ujawniła krytyczny problem w architekturze Azure Cosmos DB, pozwalający na przełamanie izolacji pomiędzy tenantami w usłudze. Badacze wykazali możliwość uzyskania pełnej kontroli nad dowolnym kontem Cosmos DB bez posiadania uprawnień i niezależnie od konfiguracji bezpieczeństwa zastosowanej przez właściciela zasobu. Scenariusz ataku prowadził do pozyskania kluczy administracyjnych umożliwiających odczyt, modyfikację i usuwanie danych przechowywanych w bazach innych organizacji. Z punktu widzenia bezpieczeństwa platform multi-tenant to jedna z najpoważniejszych podatności, ponieważ narusza podstawowe założenie separacji danych pomiędzy klientami korzystającymi z tej samej infrastruktury. 

Punktem wejścia był interfejs Gremlin API, przeznaczony do obsługi grafowych modeli danych. Analiza przeprowadzona przez Wiz wykazała, że sposób przetwarzania zapytań umożliwiał wykorzystanie mechanizmów refleksji środowiska .NET. Odpowiednio przygotowane zapytanie pozwalało wywoływać klasy i metody, które nie powinny być dostępne z poziomu Gremlina. W rezultacie możliwe było wykonanie kodu poza sandboxem i uzyskanie dostępu do DB Gateway, usługi wykonującej zapytania w imieniu klientów. To ewidentny przykład naruszenia granicy pomiędzy kodem użytkownika a infrastrukturą platformy. 

Po uzyskaniu możliwości wykonania kodu badacze skoncentrowali się na analizie środowiska uruchomieniowego. W pamięci procesu znajdowały się informacje wykorzystywane przez wewnętrzne mechanizmy uwierzytelniania Azure Cosmos DB, w tym master key odpowiedzialny za generowanie kluczy dostępowych. Pozyskanie tego sekretu umożliwiało wygenerowanie prawidłowych kluczy Primary Key dla dowolnego konta usługi. Ponieważ klucze te zapewniają pełne uprawnienia administracyjne, dalszy dostęp do danych odbywał się przy użyciu standardowych interfejsów API i nie wymagał już wykorzystywania samej podatności. 

Szczególnie istotnym aspektem CosmosEscape był zasięg konsekwencji wykorzystania podatności. Chociaż wektor wejściowy wykorzystywał Gremlin API, skutki kompromitacji nie ograniczały się do użytkowników korzystających z grafowych baz danych. Po uzyskaniu możliwości generowania kluczy administracyjnych atakujący mógł uzyskać dostęp do kont wykorzystujących pozostałe interfejsy oferowane przez Azure Cosmos DB, w tym SQL API, MongoDB API, Cassandra API oraz Table API. Oznaczało to, że podatność dotyczyła centralnych mechanizmów zarządzania usługą, a nie pojedynczego modułu odpowiedzialnego za obsługę konkretnego modelu danych. 

W opublikowanej analizie Wiz zwrócił uwagę, że cały proces nie wymagał wykorzystania podatności po stronie klienta ani błędnej konfiguracji środowiska. Atak był możliwy wobec domyślnie skonfigurowanych instancji usługi, ponieważ wykorzystywał wyłącznie błędy znajdujące się w infrastrukturze zarządzanej przez Microsoft. Z tego względu standardowe mechanizmy ochrony, takie jak filtrowanie ruchu sieciowego, prywatne endpointy, segmentacja sieci czy poprawnie skonfigurowane uprawnienia użytkowników, nie eliminowały ryzyka.  

Po zgłoszeniu podatności Microsoft uniemożliwił wykorzystanie opisanego wektora ataku oraz przeprowadził zmiany w komponentach odpowiedzialnych za przetwarzanie zapytań i zarządzanie kluczami dostępowymi. Według informacji przekazanych przez firmę analiza logów telemetrycznych nie wykazała oznak wykorzystania podatności przez osoby nieuprawnione (poza badaczami z Wiz) przed jej usunięciem. Sam proces reakcji pokazuje jednak, jak dużą rolę odgrywa odpowiedzialne ujawnianie podatności oraz ścisła współpraca pomiędzy analitykami bezpieczeństwa a dostawcami usług chmurowych. 

Patrząc szerzej

CosmosEscape jest przykładem trudności związanych z oceną bezpieczeństwa usług SaaS. Klient ma możliwość monitorowania własnych zasobów i konfiguracji, jednak nie dysponuje narzędziami pozwalającymi zweryfikować sposób implementacji mechanizmów izolacji tenantów, zarządzania kluczami czy ochrony środowiska. W konsekwencji podatności występujące w tej warstwie pozostają niewidoczne aż do momentu ich wykrycia przez dostawcę lub niezależnych badaczy.   

Przy korzystaniu z usług SaaS i PaaS poziom bezpieczeństwa zależy nie tylko od poprawnej konfiguracji po stronie klienta, ale również od jakości zabezpieczeń i procesów po stronie operatora platformy. Z perspektywy klient ocena bezpieczeństwa opiera się więc w pełni na zaufaniu do dostawcy i oferowanych przez niego rozwiązań. Warto wziąć to pod uwagę w przypadku analizy ryzyka i weryfikacji możliwości jego mitygacji. 

Więcej informacji:
https://www.wiz.io/blog/cosmosescape-taking-over-every-database-in-azure-cosmos-db