Wprowadzenie do problemu / definicja luki
BRICKSTORM to zaawansowany backdoor wykorzystywany do długotrwałej obecności (long-term persistence) w sieciach ofiar – ze szczególnym naciskiem na warstwę wirtualizacji VMware vSphere (vCenter/ESXi) oraz wybrane komponenty środowisk Windows. W grudniu 2025 r. CISA, NSA i kanadyjskie Cyber Centre zaktualizowały raport analityczny, rozszerzając go o nowe wskaźniki kompromitacji (IoC) i sygnatury detekcyjne dla kolejnych próbek.
To nie jest „zwykły trojan na stacji roboczej”. W tym przypadku zagrożenie dotyka płaszczyzny zarządzania (control plane) – a więc elementów, które często mają najwyższe uprawnienia i jednocześnie bywają najsłabiej monitorowane.
W skrócie
- Autorzy raportu (CISA/NSA/Cyber Centre) oceniają, iż BRICKSTORM jest używany przez państwowych aktorów z ChRL do utrzymywania trwałego dostępu do systemów ofiar.
- Aktualizacja z 19.12.2025 dodaje IoC i sygnatury dla trzech dodatkowych próbek (łącznie analizowano 11).
- BRICKSTORM występuje jako ELF (środowiska linuksowe/appliance; m.in. komponenty vSphere) i jest implementowany w Go oraz Rust.
- W opisywanym incydencie napastnicy utrzymali dostęp od co najmniej kwietnia 2024 do co najmniej 3 września 2025, m.in. poprzez vCenter, a także przejęli kontrolery domeny i serwer ADFS, eksportując klucze kryptograficzne.
Kontekst / historia / powiązania
Wspólny komunikat USA–Kanada podkreśla, iż aktywność była obserwowana przede wszystkim w sektorze government oraz IT, a wektorem zainteresowania są środowiska VMware vSphere.
W szerszym krajobrazie zagrożeń BRICKSTORM wpisuje się w trend działań, w których grupy powiązane z Chinami preferują implanty działające na urządzeniach/appliance’ach i serwerach infrastrukturalnych, często poza zasięgiem klasycznych agentów EDR. Google Threat Intelligence opisywał BRICKSTORM jako backdoor wykorzystywany w długotrwałym cyberszpiegostwie, z naciskiem na platformy, gdzie tradycyjna telemetria bywa ograniczona.
Dodatkowo, doniesienia medialne (na bazie informacji instytucji rządowych) łączą ten typ aktywności z ryzykiem nie tylko szpiegostwa, ale też potencjalnego przygotowania dostępu „na przyszłość”.
Analiza techniczna / szczegóły luki
Co wiemy o mechanice BRICKSTORM (na podstawie raportu analitycznego)
Raport AR25-338A opisuje BRICKSTORM jako backdoor nastawiony na inicjację, trwałość i bezpieczny C2. W próbkach zaobserwowano m.in. mechanizmy „self-watching” – malware potrafi odtwarzać się / restartować, jeżeli zostanie zakłócone.
W części dotyczącej inicjacji widać charakterystyczny przepływ: jeżeli BRICKSTORM nie działa z oczekiwanej ścieżki, potrafi się skopiować w docelowe miejsce, zmodyfikować zmienne środowiskowe (np. PATH), uruchomić skopiowaną wersję, a następnie zakończyć proces rodzica. To zachowanie utrudnia analizę „na gorąco” i sprzyja przetrwaniu w środowisku.
W raporcie pojawiają się też przykłady lokalizacji i nazw plików, które mogą imitować elementy systemowe/produktowe (np. katalogi powiązane z VMware oraz binaria o nazwach wyglądających „technicznie” jak vmware-sphere, updatemgr, vami).
C2 i „maskowanie” ruchu
BRICKSTORM ma komunikować się z infrastrukturą C2 z użyciem warstw kryptograficznych i protokołów, które mogą upodabniać ruch do legalnego (np. HTTPS i WebSockets). Raport wskazuje też na techniki utrudniające wykrycie na poziomie sieci.
Detekcja: YARA i Sigma (to ważna część aktualizacji)
AR25-338A zawiera reguły YARA oraz odniesienia do reguł Sigma przygotowanych do polowania na artefakty BRICKSTORM. W praktyce oznacza to możliwość szybkiego wdrożenia detekcji zarówno w pipeline’ach do analizy plików (YARA), jak i w logach/SIEM (Sigma).
Co wnosi aktualizacja z 19.12.2025
W aneksie „Dec. 19, 2025 Updates” autorzy wskazują, iż przeanalizowano trzy dodatkowe próbki (Samples 9–11) pozyskane od zaufanej strony trzeciej, uzupełniając raport o dodatkowe metadane i sygnatury.
Praktyczne konsekwencje / ryzyko
Największe ryzyko nie wynika wyłącznie z samego backdoora, ale z miejsca jego osadzenia:
- vCenter/ESXi jako „punkt dominacji”: przejęcie warstwy wirtualizacji daje wpływ na wiele systemów jednocześnie – w tym na kopie maszyn, snapshoty i sieć wirtualną.
- Kradzież poświadczeń przez snapshoty/klony: raport ostrzega, iż mając dostęp do konsoli vCenter, aktorzy mogą pozyskiwać snapshoty/klony VM do ekstrakcji credentiali.
- Ukryte „rogue VM”: w raporcie opisano możliwość tworzenia maszyn ukrytych przed konsolą zarządzania, co komplikuje inwentaryzację i monitoring.
- Tożsamość jako cel (ADFS): opis incydentu obejmuje kompromitację ADFS i eksport kluczy kryptograficznych – to scenariusz, który może umożliwić dalsze nadużycia tożsamości (np. w federacji).
Rekomendacje operacyjne / co zrobić teraz
Poniżej zestaw działań „SOC/IR-ready”, ułożony tak, żeby dało się go wykonać bez czekania na pełną analizę:
A. Detekcja i hunting (pierwsze 24–48h)
- Wdróż IoC i sygnatury z AR25-338A (w tym aktualizację z 19.12.2025) w SIEM/NDR/EDR oraz narzędziach do skanowania plików.
- Uruchom reguły YARA/Sigma z raportu w środowiskach, gdzie masz telemetrię (repozytoria artefaktów, sandbox, EDR file scanning, pipeline’y DFIR).
- Skup się na vCenter/ESXi: przegląd nietypowych binariów/uruchomień, kontrola anomalii w ruchu wychodzącym (HTTPS/WebSockets), analiza procesów/usług. (W raporcie opisano mechanizmy inicjacji i kopiowania, które warto mapować na własne logi).
B. Ograniczenie skutków i odzyskanie kontroli
- Jeśli wykryjesz oznaki BRICKSTORM lub powiązanej aktywności: traktuj to jako incydent wysokiej wagi i uruchom procedury IR (izolacja, akwizycja artefaktów, ustalenie osi czasu).
- Zweryfikuj integralność i tożsamość: w szczególności komponenty AD/ADFS (rotacja kluczy i poświadczeń zależy od Twoich procedur, ale w opisywanym scenariuszu atakujący eksportowali klucze).
- Kontrola „rogue VM” i snapshotów: przeprowadź przegląd nietypowych snapshotów/klonów i maszyn, które mogły zostać utworzone poza standardowym procesem.
C. Działania długofalowe (hardening)
- Zwiększ widoczność na warstwę wirtualizacji: logowanie, alerty anomalii dla vCenter/ESXi, kontrola dostępu administracyjnego, segmentacja i ograniczenie egress z komponentów zarządzających. (Raport wskazuje, iż to właśnie ta warstwa jest atrakcyjnym „przyczółkiem”).
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
W porównaniu do typowych kampanii malware na endpointach, BRICKSTORM jest groźny z dwóch powodów:
- „Atak na control plane” zamiast na stacje robocze: kompromitacja vCenter/ESXi daje „efekt dźwigni” na wiele systemów naraz i potrafi omijać część kontroli działających na maszynach wirtualnych.
- Preferencja dla platform o słabszej telemetrii: Google GTIG zwraca uwagę, iż takie implanty często są dobierane tak, by działać na systemach/appliance’ach, gdzie klasyczne EDR-y nie są standardem.
Podsumowanie / najważniejsze wnioski
Aktualizacja raportu z 19 grudnia 2025 r. to sygnał, iż BRICKSTORM jest aktywnie rozwijany i pojawiają się nowe warianty oraz nowe dane detekcyjne (kolejne próbki i IoC).
Jeżeli Twoja organizacja korzysta z VMware vSphere (szczególnie vCenter/ESXi) i ma krytyczne zależności od AD/ADFS, potraktuj temat priorytetowo: wdrożenie reguł YARA/Sigma, polowanie na artefakty w warstwie wirtualizacji oraz przegląd integralności tożsamości to zestaw działań, który realnie redukuje ryzyko.
Źródła / bibliografia
- CISA / NSA / Canadian Centre for Cyber Security – Malware Analysis Report AR25-338A: BRICKSTORM Backdoor (z aktualizacją 19.12.2025) (U.S. Department of War)
- NSA – komunikat o BRICKSTORM i rekomendacji użycia IoC/sygnatur (nsa.gov)
- Canadian Centre for Cyber Security – omówienie wspólnego raportu i kontekstu vSphere (Canadian Centre for Cyber Security)
- Google Threat Intelligence – kontekst kampanii i charakterystyka BRICKSTORM/UNC5221 (Google Cloud)
- Reuters – kontekst medialny i ryzyko długotrwałego dostępu (Reuters)
