Biuletyn Threat Intelligence nr 11: Długotrwała kampania Brickstorm w VMware

Podsumowanie

Aktorzy pozostający pod wpływem Chin wykorzystują backdoor Brickstorm do osiągania długotrwałej, ukrytej obecności w środowiskach wirtualizacji VMware vSphere (vCenter/ESXi) oraz w systemach Windows. Atakujący uzyskują dostęp do zaufanych mechanizmów administracyjnych, co umożliwia kradzież snapshotów maszyn wirtualnych i pozyskanie poświadczeń, a także tworzenie ukrytych maszyn (rogue VM), niewidocznych w standardowej inwentaryzacji. Kampania ma charakter szpiegowski, celem jest trwały dostęp i ciche tunelowanie ruchu z wykorzystaniem DNS‑over‑HTTPS oraz zagnieżdżonych kanałów TLS/WebSocket. Działania były obserwowane co najmniej od kwietnia do września 2025 roku, lecz niewykluczone, że kampania może trwać dalej.

Aktorzy stojący za Brickstorm: tożsamość i cele

Dokładna tożsamość aktorów dokonujących ataków z użyciem backdoora Brickstorm nie jest znana. Obserwowana działalność APT (advanced persistent threat) wskazuje na UNC5221. Grupa ta realizuje zadania szpiegowskie na rzecz chińskiego rządu, często stosując techniki ukrywania długotrwałej obecności. Ponosi odpowiedzialność za m.in. wykorzystanie podatności zero-day w Ivanti w styczniu tego roku [1]. Ze względu na podobieństwo działań, CrowdStrike grupuje zbiór aktywności pod ogólną nazwą Wrap Panda. Klaster ten działa co najmniej od 2022 roku, zawsze wykazując powiązania z chińskimi aktorami [2].

Choć atrybucja nie jest formalnie jednolita, konsensus analityczny podkreśla szpiegowski charakter operacji. Aktorzy wykorzystują podobne techniki i specyficzne oprogramowanie (Brickstorm, GuestConduit, Junction) celem uzyskania dostępu do zasobów o wysokiej wartości. Wykradają przede wszystkim tożsamości, klucze, poświadczenia, wrażliwe dane. Najczęściej ofiarami są organizacje rządowe, podmioty z sektora technologicznego, prawnego i produkcyjnego, a także operatorzy usług IT. Rzeczywistą intencją jest skalowanie osiąganych rezultatów — atakujący uzyskują w ten sposób dostęp do środowisk klientów i partnerów [3].

Analiza backdoora Brickstorm

Brickstorm jest backdoorem napisanym w Go, zaprojektowany do pracy przede wszystkim na systemach *nix (vCenter/ESXi), a w wybranych wariantach Windows. Zapewnia interaktywną powłokę, zarządzanie plikami, serwer HTTP z handlerami API, a także funkcję SOCKS proxy do tunelowania operatorów w głąb sieci ofiary. Kluczową cechą jest mechanizm samonadzoru (self‑watcher), który po zabiciu procesu podejmuje próby restartu lub ponownej instalacji. W środowiskach VMware utrwala się przez modyfikację skryptów init.

Uzyskiwanie długotrwałego dostępu i utrzymywanie niewykrywalności są jednymi z kluczowych elementów kampanii, na co wskazuje kierunek jej ewolucji. Wykorzystywane są dodatkowe moduły w vSphere: Junction (na ESXi) oraz GuestConduit (w maszynach gościa). Ich celem jest rozszerzenie możliwości tunelowania i ukrywania komunikacji [2, 3].

Przebieg ataku: łańcuch od DMZ do vCenter i ADFS

Analiza opublikowana przez CISA opisuje reprezentatywny incydent, dobrze ilustrujący sposób prowadzenia kampanii. Atak rozpoczął się od kompromitacji serwera WWW w strefie DMZ (z wykorzystaniem web shell). Następnie, dzięki pozyskaniu kont serwisowych, rozpoczęto działania lateralne (ruch boczny) do kontrolera domeny w DMZ (RDP), dalej do wewnętrznego kontrolera domeny. Stamtąd adwersarz uzyskał dostęp do bazy Active Directory i pozyskał poświadczenia kont usługodawcy (MSP) [3, 4].

Pozyskanie tych uprawnień pozwoliło na przeskok do serwera VMware vCenter oraz równolegle do serwera ADFS (SMB), gdzie atakujący wyeksportował klucze kryptograficzne. W efekcie uzyskano możliwość podszywania się pod zaufane tożsamości i utrzymywania kanałów dostępowych na poziomie zarządzania wirtualizacją [3].

Po przejęciu vCenter operatorzy Brickstorm rozpoczynają działania związane z kradzieżą danych docelowych. M.in. tworzą i kopiują snapshoty maszyn wirtualnych, które pozwalają im na ekstrakcję poświadczeń w trybie offline, dla zmniejszenia ryzyka wykrycia. Ponadto tworzą ukryte, nieewidencjonowane maszyny wirutalne, wykorzystywane jako mosty komunikacyjne. Dalszy ruch jest tunelowany przez zaufane komponenty vSphere [3]. Odnotowano także wykorzystywanie konta vpxuser i kanałów SSH/SFTP między hostami, czy techniki zacierania śladów (czyszczenie logów, zmianę znaczników czasu) [2]. Na poziomie Command&Control (C2) Brickstorm wykorzystuje DNS‑over‑HTTPS. Nawiązywane są połączenia HTTPS, które są podnoszone do WebSocket i dodatkowo chronione kolejnymi warstwami TLS. Wybrane warianty używają VSOCK do komunikacji między maszynami na tym samym hoście [5].

Wykrywanie naruszenia: praktyka i materiały pomocnicze

CISA opublikowała kompletny zestaw wskaźników kompromitacji (IoC) oraz reguły YARA i Sigma, które można bezpośrednio wdrożyć w procesach monitoringu i polowania na zagrożenia. Zasoby są udostępnione w ramach raportu AR25‑338A wraz z możliwością pobrania plików [3]. Ponadto lista zawiera dodatkowe materiały od Mandiant (Google).

Organizacje korzystające z VMware powinny niezwłocznie włączyć te sygnatury do SIEM/EDR. Zaleca się także uruchomienie hunting na hostach vCenter/ESXi/guest VM i zestawić wyników z ruchem sieciowym. Szczególną uwagę należy poświęcić nietypowym DNS‑over‑HTTPS, ruchowi WebSocket/TLS wychodzącego z płaszczyzny zarządzania i nieautoryzowanych połączeń SOCKS. Dodatkowo GTIG/Mandiant udostępnił skaner, który replikuje regułę YARA i pozwala skanować *nix/appliance bez konieczności instalacji YARA.

W praktyce warto zbudować profil anomalii dla vSphere przez monitorowanie:

• tworzenia nieautoryzowanych lub niezarejestrowanych VM;
• anomalii w aktywności konta vpxuser,
• obecność i użycie SSH/SFTP między hostami oraz niestandardowe wzorce egresu z vCenter/ESXi.

Analiza logów hostd/vpxa może ujawnić próby czyszczenia dzienników i timestomping. Na poziomie sieci kluczowe jest zablokowanie nieautoryzowanych dostawców DoH oraz wyegzekwowanie listy dozwolonych resolverów, aby utrudnić przeciwnikowi ukrywanie kanałów C2.

Zalecane działania dla organizacji narażonych na Brickstorm

Organizacje powinny ocenić ryzyko bycia potencjalnym celem działań adwersarzy stojących za Brickstorm. W przypadku zweryfikowania słuszności obaw, lub choćby podejrzenia incydentu związanego z przedmiotowym backdoorem, zaleca się niezwłoczne podjęcie działań, zgodnie z podaną poniżej checklistą:

Wnioski

Płaszczyzna zarządzania wirtualizacją (vCenter, ESXi, Hyper-V) jest często traktowana jako infrastruktura techniczna, a nie krytyczny zasób bezpieczeństwa. W praktyce jej kompromitacja może dać istotną kontrolę nad środowiskiem, co udowadniają techniki wykorzystywane przez Brickstorm. Wiązać się to może nie tylko z kradzieżą danych, lecz możliwością wyłączenia, modyfikacji lub przejęcia całych środowisk produkcyjnych.

Ma to szczególne znacznie w zakresie łańcuchów dostaw: zarówno w zakresie korzystania z usług, jak i świadczenia ich na rzecz klientów. Przejęcie poświadczeń i podszywanie się pod zaufane tożsamości mogą znacząco skalować reperkusje incydentów w zakresie wielu podmiotów. Dopuszczenie do takiej sytuacji prowadzić może nie tylko do problemów wizerunkowych i odpowiedzialności cywilnej, lecz także naruszenia prawa. Europejskie prawodawstwo (DORA, NIS2) kładzie szczególny nacisk na łańcuchy dostaw, które stają się coraz częstszym celem ataków.

Dlatego istotnym stają się rozwiązania systemowe, a nie reakcyjne, wdrażane zgodnie z uznanymi standardami, takimi jak ISO/IEC 27001 czy ISO 22301. Nadzór nad łańcuchami dostaw powinien opierać się na cyklicznej ocenie ryzyka i zależności, jak również analizie odporności systemów. Natomiast te powinny być stale monitorowane, regularnie testowane (podatności, penetracja, red teaming, itd.) oraz zarządzane w oparciu o przewidywalne procesy.

Opracowanie: Mateusz Rakowski