Archiwa: APT - Strona 19 z 32 - Security Bez Tabu

Systemy Bazowe Dla Kontenerów Docker – Analiza Bezpieczeństwa

Kiedy „oficjalny obraz” nie oznacza „bezpieczny obraz”

W świecie Dockera często mówimy o obrazach i kontenerach, ale rzadziej zastanawiamy się nad systemem bazowym, na którym te kontenery są oparte. A to poważny błąd – „base image” to fundament naszego kontenera. Jeśli jest słaby lub popękany od znanych podatności, cała aplikacja może być zagrożona.

Czytaj dalej „Systemy Bazowe Dla Kontenerów Docker – Analiza Bezpieczeństwa”

DOJ i CISA ostrzegają: rosyjskie grupy CARR/NoName057(16) i Z-Pentest celują w infrastrukturę krytyczną (woda, energia, żywność)

Wprowadzenie do problemu / definicja luki

9 grudnia 2025 r. amerykański Departament Sprawiedliwości (DOJ) i CISA wraz z innymi agencjami opublikowały wspólne ostrzeżenie dotyczące kampanii prorosyjskich „hacktywistów” uderzających w systemy OT/ICS w sektorach wody i ścieków, energii oraz żywności. Ataki wykorzystują przede wszystkim słabo zabezpieczone, wystawione do internetu połączenia VNC do paneli HMI, co umożliwia zdalne manipulowanie procesami technologicznymi i wywoływanie efektów fizycznych.

W skrócie

  • Kto atakuje: Cyber Army of Russia Reborn (CARR), NoName057(16), Z-Pentest oraz powiązana od 2025 r. grupa Sector16.
  • Jak atakują: skanowanie otwartych portów VNC, brutalne łamanie haseł/wykorzystanie haseł domyślnych, dostęp do HMI/SCADA, zmiany parametrów i wyłączanie alarmów, czasem równoległe DDoS.
  • Skutki: realne oddziaływanie na procesy – m.in. rozlanie setek tysięcy galonów wody pitnej i incydent z amoniakiem w zakładzie mięsnym w Los Angeles (XI 2024).
  • Powiązania z państwem: CARR miała być finansowana/kierowana przez GRU; NoName057(16) – projekt sankcjonowany przez państwo, z własnym narzędziem DDoSia.

Kontekst / historia / powiązania

Wraz z eskalacją wojny Rosji przeciw Ukrainie (2022) wzrosła liczba prorosyjskich grup, które zaczęły łączyć DDoS z ingerencjami w OT. W 2024 r. administratorzy CARR i NoName zainicjowali Z-Pentest, deklarując specjalizację w intruzjach OT i porzucając DDoS na rzecz „głośniejszych” włamań do HMI. W 2025 r. pojawiła się także Sector16 współpracująca z Z-Pentest.

Równolegle trwa presja prawna i „kinetyczna”: w lipcu 2025 r. operacja międzynarodowa Eastwood (Europol/Eurojust) uderzyła w infrastrukturę NoName057(16), a 9 grudnia 2025 r. DOJ ogłosił dwa akty oskarżenia wobec obywatelki Ukrainy powiązanej z CARR i NoName.

Wcześniej (19 lipca 2024 r.) OFAC nałożył sankcje na liderkę CARR Julię Pankratovą i kluczowego hakera Denisa Degtiarenkę.

Analiza techniczna / szczegóły luki

Wspólna porada CISA/NSA/FBI/EPA/DOE/DISA identyfikuje powtarzalny, tani łańcuch działań (TTP), nastawiony na oportunistyczne cele:

  • skanowanie internetu w poszukiwaniu wystawionych HMI/SCADA z otwartym VNC,
  • użycie VPS do bruteforce i/lub korzystanie z domyślnych/słabych haseł,
  • przejęcie widoku i sterowania w HMI (zmiany parametrów, nazw urządzeń, wyłączanie alarmów, restart),
  • rejestracja ekranu/„proofy” i propaganda w Telegramie; czasem DDoS równolegle, by ułatwić wejście do sieci.

Autorzy wskazują, że sprawcy często nie rozumieją w pełni procesów przemysłowych (niska „maturity”), ale mimo to doprowadzają do fizycznych skutków i „loss of view”, wymuszając ręczne przejęcie sterowania przez operatorów.

Praktyczne konsekwencje / ryzyko

  • Woda i ścieki: manipulacje SCADA doprowadziły do rozlania „setek tysięcy galonów” wody pitnej; DOJ łączy te incydenty z CARR.
  • Żywność: atak na zakład mięsny w Los Angeles (XI 2024) – skażenie/utylizacja mięsa i wyciek amoniaku.
  • Energetyka i inne sektory: czasowe utraty widoczności, defacement HMI, przerwy w działaniu, koszty operacyjne i reputacyjne.

Rekomendacje operacyjne / co zrobić teraz

Architektura i dostęp

  • Bezwzględnie zablokuj VNC z internetu; jeśli VNC musi istnieć, tylko przez VPN + MFA, allow-listy i jump-hosty; rozważ całkowitą eliminację VNC z OT.
  • Segmentacja sieci (ISA/IEC 62443), oddzielenie stref IT/OT, dostęp uprzywilejowany (PAM) dla kont operatorów HMI.

Twardnienie HMI/SCADA

  • Zmień domyślne hasła, wymuś MFA tam, gdzie możliwe; wyłącz nieużywane usługi, ogranicz konta serwisowe.
  • Wymuś lock-out po nieudanych logowaniach; monitoruj nietypowe sesje VNC/RDP.

Monitoring i detekcja

  • Rejestrowanie i alertowanie na: otwarcie portów VNC, nowe połączenia z VPS/hostingów, nagłe wyłączenia alarmów HMI, zmiany parametrów procesu.
  • Wdrażaj mapowanie do MITRE ATT&CK for ICS i testy w oparciu o znane TTP z CSA.

Procedury i ćwiczenia

  • Playbooki na loss of view i ręczne przejęcie sterowania; regularne ćwiczenia z zespołami utrzymania ruchu.
  • Kanały eskalacji i komunikacja z regulatorami/CSIRT-ami sektorowymi.

Zarządzanie ryzykiem dostawców

  • Kontrole zdalnego serwisu (czasowe dostępy, jednorazowe poświadczenia), SBOM dla elementów ICS, weryfikacja zabezpieczeń paneli HMI produkowanych przez OEM.

Różnice / porównania z innymi przypadkami

W odróżnieniu od klasycznych kampanii APT (np. długotrwałe, ukryte infiltracje), opisywane ataki są głośne i oportunistyczne – mają dawać szybki efekt propagandowy (screeny z HMI), ale i tak potrafią wywoływać realne skutki fizyczne. Z-Pentest odróżnia się od typowych „DDoS-brigad” tym, że celuje bezpośrednio w OT/HMI, a nie wyłącznie w warstwę www/IT.

Podsumowanie / kluczowe wnioski

  • Największym wektorem ryzyka jest VNC do HMI wystawione do internetu.
  • Grupy CARR/NoName/Z-Pentest mają (według DOJ/CISA) związki organizacyjne/finansowe z rosyjskimi strukturami państwowymi, a ich działania wykraczają poza DDoS, dotykając realnych procesów przemysłowych.
  • Nawet „małe” zakłady i gminne wodociągi są na celowniku – ataki są automatycznie skanowane i niezależne od skali ofiary.

Źródła / bibliografia

  • The Record: przegląd ostrzeżeń DOJ/CISA i powiązanych działań (10 grudnia 2025). (The Record from Recorded Future)
  • DOJ: „Justice Department Announces Actions to Combat Two Russian State-Sponsored Cyber Criminal Hacking Groups” (9 grudnia 2025). (Department of Justice)
  • Wspólna porada CISA/NSA/FBI/EPA/DOE/DC3: „Pro-Russia Hacktivists Conduct Opportunistic Attacks Against Critical Infrastructure” (9 grudnia 2025).
  • OFAC: sankcje na liderów CARR (19 lipca 2024). (U.S. Department of the Treasury)
  • Europol: Operacja Eastwood przeciw NoName057(16) (16 lipca 2025). (Europol)

Fortinet łata krytyczne luki „FortiCloud SSO login auth bypass” (CVE-2025-59718, CVE-2025-59719). Co musisz zrobić teraz

Wprowadzenie do problemu / definicja luki

Fortinet opublikował poprawki dla dwóch krytycznych podatności, które umożliwiają ominięcie uwierzytelniania FortiCloud SSO w wielu produktach: FortiOS, FortiProxy, FortiSwitchManager (CVE-2025-59718) oraz FortiWeb (CVE-2025-59719). Atak możliwy jest z sieci (bez uwierzytelnienia) poprzez spreparowany komunikat SAML, który zostaje błędnie uznany za prawidłowo podpisany kryptograficznie.

W skrócie

  • Wektor: sieć / brak uwierzytelnienia; ominięcie logowania SSO FortiCloud przez fałszywe odpowiedzi SAML.
  • Produkty: FortiOS, FortiProxy, FortiSwitchManager (CVE-2025-59718) oraz FortiWeb (CVE-2025-59719).
  • Ciężar: CVSS v3.1 9.8 (Critical) (dla CVE-2025-59719 wg NVD).
  • Domyślna ekspozycja: funkcja FortiCloud SSO nie jest domyślnie włączona; może się aktywować w procesie rejestracji do FortiCare, jeśli administrator nie wyłączy przełącznika.
  • Mitigacja natychmiastowa: wyłącz FortiCloud SSO do czasu aktualizacji do wersji niepodatnych.

Kontekst / historia / powiązania

Urządzenia Fortinet są regularnie wykorzystywane w kampaniach APT i ransomware (często jako zero-day). W 2025 r. głośne były m.in. masowe nadużycia błędów FortiWeb (CVE-2025-64446/58034). Dzisiejsze luki w SSO wpisują się w ten trend – funkcje tożsamości i zdalnego zarządzania to atrakcyjny cel dla napastników.

Analiza techniczna / szczegóły luki

Sednem obu CVE jest „improper verification of cryptographic signature” (CWE-347) w ścieżce przetwarzania SAML. Odpowiedź SAML, która powinna być podpisana przez zaufanego IdP, może zostać zaakceptowana mimo fałszerstwa – to prowadzi do ominięcia FortiCloud SSO i uzyskania dostępu administracyjnego.
Zakres wersji podatnych (wybór najważniejszych gałęzi wg NVD / agregatorów):

  • CVE-2025-59718 (FortiOS/FortiProxy/FortiSwitchManager):
    FortiOS 7.6.0–7.6.3, 7.4.0–7.4.8, 7.2.0–7.2.11, 7.0.0–7.0.17;
    FortiProxy 7.6.0–7.6.3, 7.4.0–7.4.10, 7.2.0–7.2.14, 7.0.0–7.0.21;
    FortiSwitchManager 7.2.0–7.2.6, 7.0.0–7.0.5.
  • CVE-2025-59719 (FortiWeb):
    FortiWeb 8.0.0; 7.6.0–7.6.4; 7.4.0–7.4.9.

Fortinet podkreśla, że FortiCloud SSO nie jest włączone w ustawieniach fabrycznych. Włącza się podczas rejestracji do FortiCare, o ile administrator nie odznaczy przełącznika „Allow administrative login using FortiCloud SSO”. To krytyczna informacja dla oceny ekspozycji.

Praktyczne konsekwencje / ryzyko

Jeśli FortiCloud SSO jest aktywne, dowolny z Internetu atakujący może ominąć logowanie i uzyskać pełne uprawnienia administracyjne w dotkniętym urządzeniu (firewall/WAF/proxy/switch manager). To otwiera drogę do:

  • zmiany konfiguracji i reguł filtracji,
  • wdrożenia backdoorów (np. zmian w politykach lub skryptach),
  • pivotu do innych segmentów sieci i eksfiltracji danych.

Rekomendacje operacyjne / co zrobić teraz

  1. Wyłącz FortiCloud SSO (jeśli włączone) natychmiast, a następnie zaplanuj aktualizację do wersji niepodatnych wg PSIRT.
    • GUI: System → Settings → przełącz “Allow administrative login using FortiCloud SSO” na Off.CLI: config system global set admin-forticloud-sso-login disable end
  2. Zaktualizuj FortiOS/FortiProxy/FortiSwitchManager/FortiWeb do wydań z poprawką dla FG-IR-25-647. Gdy strona PSIRT będzie dostępna, zweryfikuj konkretne „Solution” wersje i matryce zgodności.
  3. Przegląd audytowy:
    • Sprawdź, gdzie faktycznie włączono FortiCloud SSO (nie zakładaj ustawień domyślnych po rejestracji do FortiCare).
    • Przejrzyj logi uwierzytelniania i administracyjne pod kątem anomalii (logowania bez korelacji z IdP).
    • Wymuś rotację haseł/tokenów administratorów oraz odśwież SAML metadata na IdP po aktualizacji.
  4. Twardnienie dostępu zarządczego:
    • Ogranicz trusted hosts i segmentację dla interfejsów zarządczych.
    • Wymuś MFA poza SSO (lokalne konto break-glass, out-of-band).
    • Rozważ tymczasowe odseparowanie portów zarządczych od Internetu (VPN z certyfikatami + allow-list).
  5. Atak powierzchniowy – redukcja: jeśli musisz utrzymać SSO, włącz monitoring integralności SAML i alerty korelujące błędy weryfikacji podpisu/issuer.
  6. Zarządzanie ryzykiem dostawcy: uwzględnij nowe CVE w asset discovery i inwentaryzacji – skanery (np. RunZero/Tenable) już wykrywają podatne wersje.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Wcześniejsze głośne incydenty Fortinet (np. FortiWeb CVE-2025-64446) dotyczyły błędów w panelach zarządzania prowadzących m.in. do tworzenia kont admina. Nowe CVE uderzają w warstwę federacji tożsamości (SAML/SSO) – skutkiem jest ominięcie logowania bezpośrednio na bramie, co bywa jeszcze trudniejsze do wykrycia, jeśli logi IdP nie pokazują próby logowania.

Podsumowanie / kluczowe wnioski

  • Dwie krytyczne luki (CVE-2025-59718/59719) pozwalają ominąć FortiCloud SSO w wielu produktach Fortinet.
  • Ekspozycja występuje tylko, gdy FortiCloud SSO jest włączone – ale może zostać automatycznie aktywowane podczas rejestracji do FortiCare, jeśli nie odznaczono przełącznika.
  • Działanie natychmiastowe: wyłącz SSO FortiCloud i aktualizuj do wersji podanych w FG-IR-25-647; zweryfikuj logi i wzmocnij dostęp administracyjny.

Źródła / bibliografia

  1. BleepingComputer – „Fortinet warns of critical FortiCloud SSO login auth bypass flaws”, 9 grudnia 2025. (BleepingComputer)
  2. NVD – CVE-2025-59718 (FortiOS/FortiProxy/FortiSwitchManager): opis i zakres wersji. (NVD)
  3. NVD – CVE-2025-59719 (FortiWeb): opis, CVSS, zakres wersji. (NVD)
  4. Fortinet PSIRT (FG-IR-25-647) – strona doradcza (matryca rozwiązań; chwilowo zdarzają się błędy 5xx). (fortiguard.com)
  5. runZero – szybka identyfikacja aktywów Fortinet dotkniętych CVE-2025-59718/59719 (listy wersji). (runZero)

Storm-0249 przechodzi od brokerstwa dostępu do precyzyjnych ataków ransomware: ClickFix, „fileless” PowerShell i DLL sideloading

Wprowadzenie do problemu / definicja luki

Storm-0249 – dotąd klasyfikowany głównie jako initial access broker (IAB) – eskaluje taktyki i zaczyna samodzielnie przygotowywać grunt pod atak ransomware. Najnowsze obserwacje pokazują łańcuch ataku łączący ClickFix (nakłanianie ofiary do uruchomienia poleceń przez okno „Uruchom”), fileless PowerShell oraz DLL sideloading z wykorzystaniem plików powiązanych z EDR, co utrudnia detekcję i sprzyja ukrytej łączności C2. Te działania sygnalizują przejście z kampanii masowego phishingu do precyzyjnych operacji post-eksploatacyjnych nastawionych na późniejsze szyfrowanie zasobów.

W skrócie

  • TTPs: ClickFix → curl.exe → fileless PowerShell → MSI z uprawnieniami SYSTEM → DLL sideloading (np. wobec binariów agenta EDR) → zaszyta komunikacja C2 z procesu „zaufanego”.
  • Cel: utrzymanie dostępu i „ciche” przygotowanie pod ransomware (m.in. zbieranie identyfikatorów systemu jak MachineGuid do wiązania kluczy szyfrujących).
  • Ewolucja aktora: z IAB obsługującego grupy jak Storm-0501, do operatora prowadzącego własne działania post-eksploatacyjne.
  • ClickFix stał się popularną techniką (potwierdzaną przez wielu dostawców), wykorzystywaną także przez bardziej zaawansowane podmioty.

Kontekst / historia / powiązania

Microsoft już w 2024 r. opisywał model współpracy ransomware, w którym tacy brokerzy jak Storm-0249 sprzedają dostęp grupom szyfrującym (np. Storm-0501). Obecna zmiana – przejście od masowego phishingu do „EDR-aware” operacji – skraca czas do eskalacji i zmniejsza liczbę sygnałów ostrzegawczych w SOC. Równolegle ClickFix ewoluował od prostych „fix your PC” stron do złożonych przynęt z wideo-instrukcjami i automatycznym kopiowaniem komend, co zwiększa konwersję ataków.

Analiza techniczna / szczegóły ataków

  1. ClickFix i wejście do środka
    Ofiara trafia na stronę „pomocy”, gdzie proszona jest o skopiowanie/uruchomienie komendy w Win+R. Wzorzec od Microsoft: phishing/malvertising → landing page → polecenie do schowka → użytkownik uruchamia je sam, omijając część filtrów.
  2. curl → PowerShell (fileless)
    W przykładach przypisywanych Storm-0249 ciąg znaków wykorzystuje curl.exe do pobrania skryptu z podszytego pod Microsoft hosta (np. ścieżka /us.microsoft.com/... na domenie zewnętrznej), po czym pipelinuje zawartość bezpośrednio do PowerShell, który wykonuje kod w pamięci – bez artefaktów na dysku.
  3. MSI z uprawnieniami SYSTEM
    Fileless stager uruchamia MSI działające jako SYSTEM, co pozwala na zrzut komponentów w lokalizacjach użytkownika i ustawienie trwałości z wysokimi uprawnieniami.
  4. DLL sideloading na procesie EDR
    Atakujący umieszczają zaufany plik EXE (np. komponent agenta EDR) wraz ze spreparowaną biblioteką DLL (np. SentinelAgentCore.dll) tak, by EXE załadował agresora „z boku”. Daje to: (a) maskowanie pod sygnowany proces, (b) kanał C2 z „białej listy”, (c) trudniejsze alertowanie o LOLBins/LOLDrivers.
  5. Recon i przygotowanie pod ransomware
    Z poziomu „zaufanego” procesu wykonywane są LOLBins (np. reg.exe, findstr.exe) do odczytu MachineGuid i innych znaczników. Dane te służą m.in. do wiązania kluczy szyfrujących z konkretną maszyną w ramach operacji RaaS.
  6. Łączność C2 i unikanie detekcji
    C2 inicjowany jest z procesu agenta (telemetria EDR), często do świeżo rejestrowanych domen i z pełnym TLS, co utrudnia DPI i systemy reputation-based. Detekcja wymaga bazowania zachowań i anomalii sieciowych dla procesów „zaufanych”.

Praktyczne konsekwencje / ryzyko

  • SOC blind spot: ruch wychodzący „z EDR” wygląda wiarygodnie; klasyczne reguły na PowerShell/curl nie zadziałają, bo aktywność „znika” w pamięci i w telemetrii zaufanych binariów.
  • Szybsza ścieżka do ransomware: zebrane identyfikatory + utrzymanie SYSTEM → szybka eskalacja do szyfrowania, bez głośnego „kill chainu”.
  • ClickFix obchodzi świadomość użytkownika: nawet przeszkoleni pracownicy mogą „sami” uruchomić polecenie, bo komunikat udaje oficjalną pomoc Microsoft.

Rekomendacje operacyjne / co zrobić teraz

Prewencja i twarde polityki

  • Blokady AMSI + Constrained Language Mode dla PowerShell tam, gdzie to możliwe; egzekwuj Script Block Logging i Module Logging.
  • WDAC/AppLocker: wymuś ładowanie DLL wyłącznie z katalogów systemowych dla procesów o wysokim zaufaniu (EDR, backup).
  • DNS/TI: alertuj na połączenia do nowych domen (<30–90 dni) inicjowane przez procesy EDR/AV; baseline znane FQDN agenta i odchylenia.
  • Zasady uruchamiania: blokuj curl.exe/bitsadmin.exe/msiexec.exe wywoływane z Win+R/Shell-Execute bez kontekstu administratora (AppLocker/WDAC).

Detekcja i hunting (przykładowe kierunki)

  • DLL sideloading: szukaj uruchomień zaufanych EXE z prywatnych ścieżek (np. %AppData%) i nienatywnych bibliotek obok EXE.
  • ClickFix: zdarzenia schowka + otwarcia okna Run bez poprzedzającej interakcji z helpdesk/IT; koreluj z wklejeniem długiego ciągu Base64/PowerShell.
  • LOLBins recon: nietypowe zestawienia reg.exe/findstr.exe → odczyty gałęzi z identyfikatorami systemu; koreluj z nowym beaconem TLS.

Twarde reagowanie

  • Traktuj nieautoryzowane MSI uruchomione jako SYSTEM jako incydent wysokiej ważności; wykonaj memory forensics (ETW/AMSI logs, PSReadLine history).
  • EDR self-check: porównaj listę legalnych DLL ładowanych przez agenta vs. obserwowane w telemetry (pref. z hashami/Publisher).
  • Segmentacja i backupy: instant isolates + test odtworzeń; przygotuj playbook pod ekspresową ścieżkę ransomware (MFA-bypass, shadow copies, AD).

Różnice / porównania z innymi przypadkami

  • IAB → operator post-eksploatacyjny: typowa rola IAB (sprzedaż dostępu) zmienia się w „broker + enabler” z pełnym przygotowaniem pod szyfrowanie. To zbieżne z trendem RaaS opisywanym wcześniej w ekosystemie Storm-0501.
  • ClickFix vs. klasyczny phishing:** zamiast pobierania EXE/ZIP ofiara uruchamia komendę sama, co utrudnia AV/Proxy; technika jest opisywana przez wielu dostawców (Microsoft, Proofpoint) i bywa adaptowana także przez aktorów APT.

Podsumowanie / kluczowe wnioski

Storm-0249 łączy socjotechnikę (ClickFix) z „living-off-the-land” i EDR-aware sideloading, przesuwając punkt ciężkości obrony z klasycznych sygnatur na behawior, uprzywilejowane ścieżki ładowania i telemetrię procesów „zaufanych”. Organizacje powinny priorytetowo wdrożyć kontrolę ładowania DLL, monitoring nowych domen i pełne logowanie PowerShell. To trend, który zwiększa prędkość i skuteczność operacji ransomware – zanim zobaczysz klasyczne IOC, bywa już za późno.

Źródła / bibliografia

  • The Hacker News: „Storm-0249 Escalates Ransomware Attacks with ClickFix, Fileless PowerShell, and DLL Sideloading” (09.12.2025). (The Hacker News)
  • ReliaQuest Threat Research: „Threat Spotlight: Storm-0249 Moves from Mass Phishing to Precision EDR Exploitation” (09.12.2025). (ReliaQuest)
  • Microsoft Security Blog: „Think before you Click(Fix): Analyzing the ClickFix social engineering technique” (21.08.2025). (Microsoft)
  • Microsoft Security Blog: „Storm-0501 ransomware… expanding to hybrid cloud; IABs like Storm-0249” (26.09.2024). (Microsoft)
  • BleepingComputer: „Ransomware IAB abuses EDR for stealthy malware execution” (09.12.2025). (BleepingComputer)

PRC „Brickstorm”: chińskie grupy APT z backdoorem na vSphere i Windows. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

4 grudnia 2025 r. CISA, NSA i kanadyjski Cyber Centre opublikowały raport analizy złośliwego oprogramowania (MAR) opisujący BRICKSTORM – niestandardowy backdoor (Go/ELF) używany przez państwowo wspieranych aktorów z ChRL do długotrwałej obecności w sieciach ofiar. Główne cele to sektor publiczny (Government Services & Facilities) oraz firmy IT. Malware obsługuje środowiska VMware vSphere (vCenter/ESXi) i ma również warianty dla Windows.

W skrócie

  • Wejście i trwałość: implant na hostach vCenter/ESXi, modyfikacja plików startowych, watchdog autorestartu/reinstalacji. Średnia „dwell time” w wykrytych operacjach liczona była w miesiącach, a w niektórych przypadkach przekraczała rok.
  • C2 i ukrywanie: wielowarstwowe szyfrowanie (HTTPS/WebSockets/nested TLS), DNS-over-HTTPS do rozwiązywania adresów C2, imitacja ruchu serwerów.
  • Cele i skala: rząd i IT w USA/Kanadzie; media i badacze informują o dziesiątkach organizacji i działaniach o charakterze szpiegowskim z potencjałem sabotażu.
  • Środowiska wirtualne: po przejęciu vCenter napastnicy klonują snapshoty VM (ekstrakcja poświadczeń) i mogą tworzyć ukryte, „rogue” VM.

Kontekst / historia / powiązania

Kampania wpisuje się w długofalową aktywność APT z Chin opisywaną wspólnie przez CISA/NSA (np. wcześniejsze CSA nt. kompromitacji sieci krytycznych), ale BRICKSTORM to świeży komponent zwiększający trwałość w warstwie wirtualizacji. Niezależnie, Google Threat Intelligence (GTIG) i Mandiant raportowały jesienią 2025 r. aktywność „Brickstorm”/pokrewnych narzędzi z długim czasem utrzymania dostępu (~393 dni), szczególnie w branżach prawnej, SaaS i BPO.

Analiza techniczna / szczegóły luki

Wejście i ruch boczny. W incydencie IR opisanym przez CISA napastnicy:

  • dostali się na serwer web w DMZ (poprzez web shell),
  • użyli kont usługowych do RDP na kontrolery domeny (kopie NTDS.dit),
  • zdobyli poświadczenia MSP i przeszli do vCenter,
  • eskalowali uprawnienia (sudo), zrzucili BRICKSTORM do /etc/sysconfig/ i zmodyfikowali plik init rozruchu vSphere, aby uruchamiać implant przy starcie,
  • uzyskali dostęp do dwóch DC oraz serwera ADFS (eksport kluczy kryptograficznych). Z persystencją co najmniej od kwietnia 2024 do 3 września 2025.

Funkcje BRICKSTORM.

  • Backdoor (Go/ELF): interaktywny shell, operacje na plikach (upload/download/list/create/delete), tryb SOCKS proxy do tunelowania i ruchu bocznego.
  • C2 i maskowanie: HTTPS/WebSockets + DoH do rozwiązywania C2, „web server mimicry” do wtapiania się w normalny ruch.
  • Trwałość: watchdog samonaprawy (restart/reinstalacja po zakłóceniu).
  • Warianty: próbki dla vSphere; istnieją raporty o wersjach Windows.
  • Reguły detekcji: pakiet YARA/Sigma do pobrania z MAR.

Cele specyficzne dla wirtualizacji. Po wejściu do vCenter aktorzy:

  • klonują snapshoty wrażliwych VM dla ekstrakcji haseł/kluczy,
  • tworzą ukryte VM, które bywają pomijane przez standardowe monitorowanie,
  • utrwalają obecność modyfikując ścieżki startowe usług vSphere.

Praktyczne konsekwencje / ryzyko

  • Ryzyko utraty integralności tożsamości (eksport kluczy ADFS, kradzież biletów/claims) i długotrwałe „życie w chmurze” atakującego w środowiskach wirtualnych.
  • Utrata widoczności SOC: DoH, WebSockets i „mimikra” HTTP utrudniają klasyczne IOCs/IDS.
  • Potencjał sabotażu: dostęp uprzywilejowany do warstwy wirtualizacji umożliwia szybkie, szerokie skutki (np. wyłączanie klastrów, manipulacja storage). Organy USA i Kanady ostrzegają, że operacje mają wymiar szpiegowski, ale niosą ryzyko zakłóceń.

Rekomendacje operacyjne / co zrobić teraz

Detekcja i polowanie

  1. Wdróż reguły z MAR (YARA/Sigma); przejrzyj wyniki retro (24+ m-ce) w SIEM/EDR/NDR.
  2. Analityka DoH: wyłapuj nietypowe zapytania DoH (destynacje niezwiązane z Twoim resolverem), koreluj z WebSockets i długimi połączeniami TLS.
  3. Telemetry vSphere:
    • zmiany w /etc/sysconfig/ i skryptach init na ESXi/vCenter,
    • nietypowe operacje clone/snapshot VM,
    • tworzenie nierejestrowanych/ukrytych VM,
    • użycie sudo na appliance’ach vCenter.
  4. AD/ADFS: hunting pod kątem kopiowania NTDS.dit, dostępu do ADFS i eksportu kluczy.

Hardening i kontrola powierzchni ataku

  1. Segmentacja i zasada „rzadkich rąk” do vCenter (MFA, PAM/JIT, brak stałych kont usługowych MSP w prod).
  2. Monitoring i kontrola DoH: preferuj własne, autoryzowane resolvery DoH/DNS; blokuj „dzikie” endpointy DoH na brzegu.
  3. Zasady snapshotów: ogranicz prawo do clone/snapshot, alertuj o masowych/pozaschematowych operacjach.
  4. Łatanie i konfiguracja vSphere/Windows, w tym aktualne appliance’y, rotacja certyfikatów i HSTS/TLS hardening na brzegach proxy. (Inference na bazie wytycznych CISA/NSA dot. krytycznej infrastruktury.)

Odpowiedź na incydent (IR) – minimalny playbook

  • Izolacja vCenter/ESXi (odseparowane sieci zarządzające, odcięcie dostępu z kont zewnętrznych/MSP).
  • Zrzuty i triage: pamięć + dysk vCenter/ESXi; weryfikacja plików init i ścieżek w /etc/sysconfig/.
  • AD/ADFS: natychmiastowa rotacja kluczy ADFS, przegląd trustów, audyt kont usługowych i SPN.
  • Korekta polityk DoH/HTTP proxy, wymuszanie resolwera korporacyjnego.
  • Zgłoszenie do CISA/Cyber Centre; użycie udostępnionych IOC/Sigma.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W porównaniu do wcześniejszych kampanii PRC opisywanych przez CISA/NSA (routery, urządzenia brzegowe), BRICKSTORM celuje w warstwę wirtualizacji i tożsamość (AD/ADFS), łącząc długą persystencję z trudnym do wykrycia C2 (DoH/WebSockets). To przesunięcie „w dół” stosu (hypervisor/zarządzanie) zwiększa wpływ i utrudnia odzyskanie środowiska.

Podsumowanie / kluczowe wnioski

  • BRICKSTORM to ukierunkowany backdoor na vSphere/Windows pozwalający APT z ChRL na wielo-miesięczną obecność.
  • Operacje na vCenter/ESXi (clone/snapshot, rogue VM) i kradzież kluczy ADFS podnoszą ryzyko eskalacji domenowej i łańcuchowych kompromitacji.
  • Widoczność na DoH/WebSockets i telemetria vSphere to teraz krytyczne obszary detekcji.
  • Wdrożenie reguł YARA/Sigma z MAR, hardening tożsamości i segmentacji vCenter to „must-do” dla SOC/IT.

Źródła / bibliografia

  1. CISA/NSA/Cyber CentreMalware Analysis Report: BRICKSTORM Backdoor, 4 grudnia 2025 (TLP:CLEAR). Najpełniejszy opis próbek, TTP, IOC, reguły YARA/Sigma.
  2. CISA – komunikat: CISA, NSA and Cyber Centre Warn Critical Infrastructure of BRICKSTORM malware…, 4 grudnia 2025. (cisa.gov)
  3. Google Threat IntelligenceBrickstorm espionage campaign (analiza GTIG/Mandiant), 24 września 2025. (Google Cloud)
  4. CyberScoopExpansive, ongoing China espionage threat riding on Brickstorm, 4 grudnia 2025. (CyberScoop)
  5. ReutersChinese-linked hackers use ‘Brickstorm’ back door…, 4 grudnia 2025 (kontekst medialny i skala). (Reuters)

Bliźniacy z Virginii aresztowani za skasowanie ~96 rządowych baz FOIA. Co wiemy i jak się przed tym bronić

Wprowadzenie do problemu / definicja luki

3–4 grudnia 2025 r. w stanie Wirginia aresztowano braci bliźniaków, Muneeba i Sohaiba Akhterów (34 l.), którym zarzucono nadużycie uprawnień wykonawcy federalnego do skasowania ok. 96 baz danych z informacjami rządowymi – m.in. rejestrów wniosków FOIA (Freedom of Information Act) oraz danych śledczych kilku agencji. Według Departamentu Sprawiedliwości, do incydentu miało dojść w lutym 2025 r., a zatrzymania dokonano 3 grudnia.

W skrócie

  • Typ zdarzenia: sabotaż/insider threat po stronie podwykonawcy (byli/zwalniani pracownicy).
  • Skala: ~96 baz danych związanych z obsługą FOIA i sprawami śledczymi (w tym systemy powiązane z DHS).
  • Wektor: pozostawione aktywne konto i uprawnienia po rozmowie HR dot. zakończenia współpracy.
  • Maskowanie śladów: zapytania do narzędzia AI o instrukcje czyszczenia logów (SQL Server/Windows).
  • Tło sprawców: wcześniejsze wyroki za włamania (2015 r., m.in. Departament Stanu).

Kontekst / historia / powiązania

Akhterowie byli już wcześniej skazani w 2015 r. za spiskowanie w celu uzyskania nieautoryzowanego dostępu do systemów rządowych i prywatnych. Mimo tej historii mieli pracować przy kontrakcie federalnym; według relacji prasowych działania destrukcyjne nastąpiły tuż po zakomunikowaniu im przez HR zakończenia współpracy, gdy dostęp nie został natychmiast wyłączony. Sprawa unaocznia klasyczny problem offboardingu w ekosystemie wykonawców i podwykonawców administracji publicznej.

Analiza techniczna / szczegóły luki

Publicznie dostępne dokumenty i relacje wskazują na następujące elementy techniczne:

  • Uprawnienia i tożsamość: wykorzystanie niewycofanego konta oraz nadanych wcześniej ról/permission sets do ingerencji w produkcyjne instancje baz danych. Wątek ten pada w materiałach prasowych i streszczeniach akt sprawy.
  • Zakres szkód: usunięto ~96 baz (SQL) związanych z FOIA i sprawami dochodzeniowymi; co najmniej jedna baza należała do środowiska związanego z DHS.
  • Antyforensics: w minutę po skasowaniu jednej z baz (DHS) padło zapytanie do narzędzia AI o czyszczenie logów SQL Server/Windows Server 2012, co może świadczyć o próbie utrudnienia dochodzenia (time correlation).
  • Łańcuch zdarzeń: według DOJ – nadużycie pozycji wykonawcy federalnego, kradzież/wyprowadzenie danych i sabotaż systemów w lutym 2025 r.; aresztowania 3 grudnia, akt oskarżenia ogłoszony 4 grudnia.

Praktyczne konsekwencje / ryzyko

  • Dostępność i przejrzystość państwa: utrata/zakłócenie obsługi wniosków FOIA wpływa na jawność życia publicznego i terminowość odpowiedzi organów.
  • Ryzyko prawne i zgodność: potencjalne naruszenie przepisów dot. przechowywania dokumentacji publicznej, retencji danych i łańcucha dowodowego (agencje śledcze).
  • Koszty odtworzenia: przy RPO/RTO > 0 może dojść do utraty danych między backupami, długich przestojów oraz konieczności ręcznego odtworzenia rekordów. (Wniosek analityczny na bazie opisanej skali kasacji).
  • Reputacja i zaufanie: sabotaż dokonany przez wykonawcę podważa zaufanie do całego łańcucha dostaw IT w sektorze publicznym.

Rekomendacje operacyjne / co zrobić teraz

Dla instytucji publicznych i wykonawców:

  1. Zero-delay offboarding: automatyczne, atomowe odebranie dostępu (IdP/PAM/DB) w trakcie rozmowy offboardingowej; “break glass” tylko z rejestracją i zgodą 4-oczu.
  2. Zasada najmniejszych uprawnień + JIT: role time-boxed, dostępy Just-In-Time do środowisk prod, bound by ticket.
  3. Kontrola zmian w DB: egzekwowanie DDL/DML przez change data capture, database activity monitoring (DAM), wymóg trybu SAFE/DRY RUN dla destrukcyjnych poleceń i approval gates dla DROP DATABASE.
  4. Backupy niezmienialne: kopie immutable/WORM (S3 Object Lock, Azure Immutable Blob) + air-gap; regularne testy przywracania (game days) i wskaźniki RPO/RTO na poziomie wymagań FOIA.
  5. Detekcja antyforensics: reguły SIEM/EDR na wzorce „czyszczenia logów” wkrótce po operacjach DDL/DROP; korelacja czasowa z IdP (login), CMDB i HRMS (status pracownika).
  6. Segregacja obowiązków: osobne konta do administrowania, osobne do pracy deweloperskiej; MFA hardware dla kont uprzywilejowanych; rotacja tajemnic (PAM) po każdym zdarzeniu HR.
  7. Kontrakty i due diligence: weryfikacja dostawców (background checks), clause’y o natychmiastowej deprowizji i karach umownych; audyty uprawnień kwartalnie.
  8. Kill switch w środowisku DB: polityki, które automatycznie blokują destrukcyjne operacje, gdy status pracownika = „terminated” w HRMS.

Dla zespołów PR/FOIA/Legal: przygotujcie plan ręcznego odtwarzania rekordów FOIA z kopii offline i logów transakcyjnych; komunikaty dla wnioskodawców dot. możliwych opóźnień.

Różnice / porównania z innymi przypadkami

  • Insider vs. APT: w przeciwieństwie do ataków APT, tu wektor to legalny dostęp wykonawcy (insider). Skuteczność obrony zależy więc bardziej od governance i procesów HR/IdP niż od klasycznej detekcji perymetrycznej.
  • Motyw sabotażu po offboardingu: schemat podobny do innych incydentów „last-day sabotage”, ale rzadko spotyka się tak dużą liczbę skasowanych baz w sektorze publicznym. (Wniosek na bazie przeglądu sprawy i relacji prasowych).

Podsumowanie / kluczowe wnioski

  • Kluczowe było opóźnienie w deprowizji dostępu po rozmowie HR – to wystarczyło, by w krótkim czasie skasować dziesiątki baz krytycznych dla przejrzystości państwa (FOIA) i działań śledczych.
  • Próba maskowania śladów z użyciem narzędzi AI to dziś realny pattern antyforensics – warto mieć na to gotowe reguły detekcyjne.
  • Silne procesy offboardingu, PAM, immutable backupy i automatyka w IdP to najskuteczniejsze „tarcze” na podobne przypadki.

Źródła / bibliografia

  • U.S. Department of Justice – komunikat o aresztowaniu (3–4 grudnia 2025 r.). (Department of Justice)
  • The Record (Recorded Future News): „Virginia brothers charged with hacking, deleting federal databases holding FOIA info” (4 grudnia 2025 r.). (The Record from Recorded Future)
  • CyberScoop: „Twins with hacking history charged in insider data breach…” (3 grudnia 2025 r.). (CyberScoop)
  • BleepingComputer: „Contractors with hacking records accused of wiping 96 govt databases” (4 grudnia 2025 r.). (BleepingComputer)
  • Axios: „Virginia brothers arrested for allegedly tampering with government databases” (3 grudnia 2025 r.). (Axios)

Microsoft „po cichu” łagodzi zero-day w Windows (.LNK) aktywnie wykorzystywany przez APT i cyberprzestępców

Wprowadzenie do problemu / definicja luki

Microsoft w listopadowych aktualizacjach 2025 r. wprowadził ciche zmiany w sposobie wyświetlania właściwości skrótów Windows (.LNK), co ogranicza skuteczność aktywnie wykorzystywanej luki CVE-2025-9491. Błąd pozwalał atakującym ukrywać złośliwe argumenty poleceń w polu Target tak, by użytkownik (lub analityk) nie widział rzeczywiście wykonywanego łańcucha polecenia. Microsoft wcześniej twierdził, że z uwagi na wymaganą interakcję użytkownika i ostrzeżenia „Mark of the Web”, problem „nie spełnia progu dla serwisowania”, ale mimo to w systemie pojawiła się mitygacja interfejsowa.


W skrócie

  • Identyfikator: CVE-2025-9491 (wcześniej ZDI-CAN-25373 / ZDI-25-148), CWE-451 (UI Misrepresentation). CVSS: 7.0 (High).
  • Wektor: złośliwe pliki .LNK z ukrytymi argumentami poleceń; zwykle dostarczane w archiwach ZIP/RAR w kampaniach phishingowych.
  • Eksploatacja: potwierdzona od co najmniej 2017 r. przez 11 grup APT i gangi cyberprzestępcze (m.in. Mustang Panda/UNC6384, Kimsuky/APT43, APT37, RedHotel, SideWinder, Evil Corp).
  • „Patch” Microsoftu: zmiana UI – teraz okno Właściwości pokazuje cały łańcuch Target (nie tylko pierwsze 260 znaków), co utrudnia ukrycie złośliwych argumentów. Nie jest to pełny „kodowy” fix.
  • Micropatch 0patch: dodatkowa, nieoficjalna mitygacja skracająca Target >260 znaków i ostrzegająca użytkownika; dostępna głównie dla starszych/niewspieranych wersji Windows.

Kontekst / historia / powiązania

Trend Micro ZDI opublikowało w marcu 2025 r. analizę, dokumentując prawie 1000 złośliwych skrótów .LNK i szerokie wykorzystanie luki przez aktorów sponsorowanych przez państwa. Microsoft – po kilku rundach komunikacji – uznał wówczas, że problem „nie spełnia progu” na łatkę bezpieczeństwa. Jesienią 2025 r. Arctic Wolf Labs opisało świeże kampanie UNC6384 (Mustang Panda) przeciw europejskim dyplomatom, dystrybuujące PlugX przez spreparowane .LNK. W efekcie temat wrócił, a w listopadzie interfejs Windows został zmieniony.


Analiza techniczna / szczegóły luki

  • Sedno podatności: UI misrepresentation – Windows w Właściwościach skrótu wyświetlał tylko pierwsze 260 znaków pola Target. Atakujący wypełniali początek długiego łańcucha białymi znakami (spacje, tabulatory), spychając właściwe, złośliwe argumenty poza widoczny fragment. Użytkownik mógł więc zobaczyć „niewinne” powershell.exe/cmd.exe bez realnych parametrów wywołujących pobranie i uruchomienie malware.
  • Wejście do ekosystemu LOLBins: Parametry często uruchamiały living-off-the-land binaria (PowerShell, rundll32, cmd, conhost) do pobrania i uruchomienia ładunku (np. PlugX, Gh0st RAT, Ursnif).
  • „Cicha” zmiana w Windows: po aktualizacjach z listopada 2025 UI pokazuje cały łańcuch Target (teoretycznie do ~32k znaków). To utrudnia socjotechniczne ukrycie argumentów, ale nie blokuje wykonania polecenia per se.

Praktyczne konsekwencje / ryzyko

  • Ataki phishingowe z archiwami zawierającymi .LNK, często stylizowane na dokumenty konferencyjne/urzędowe (tematy NATO/KE itp.), pozostają skuteczne, jeśli użytkownicy nadal uruchamiają skróty.
  • Eskalacja i utrzymanie dostępu: po kliknięciu skrótu następuje łańcuch pobrania i uruchomienia RAT/loadera, często z mechanizmami trwałości.
  • Widoczność w SOC: sama zmiana UI pomaga człowiekowi to zauważyć, ale nie zastępuje kontroli technicznych – IOC/telemetria EDR nadal kluczowe.

Rekomendacje operacyjne / co zrobić teraz

  1. Polityki poczty i bramek: blokuj załączniki .LNK oraz archiwa zawierające .LNK (ZIP/RAR/7z). Włącz sandboxing i detekcję zawartości w archiwach.
  2. Kontrola uruchamiania skrótów:
    • GPO/AppLocker/WDAC: ogranicz uruchamianie .LNK z lokalizacji użytkownika (Downloads, %TEMP%, %AppData%).
    • Blokuj uruchomienia PowerShell/cmd/rundll32 z argumentami z niezaufanych ścieżek. (Technika mapowana do MITRE ATT&CK T1204/T1059).
  3. Defender/EDR:
    • Włącz ASR (blokowanie procesów child z Office/niezaufanych miejsc, blokowanie podejrzanych skryptów PowerShell).
    • Monitoruj zdarzenia „process creation” z bardzo długimi łańcuchami poleceń i obecnością nietypowych białych znaków.
  4. Higiena plików z Internetu: enforce’uj Mark-of-the-Web i blokuj znane MOTW bypassy w Twojej flocie przeglądarek/klientów archiwów.
  5. Sygnatury/YARA: skorzystaj z reguł opublikowanych przez Trend Micro ZDI do wykrywania „padded LNK”. (Dostosuj do własnych pipeline’ów skanowania plików).
  6. Aktualizacje systemu: zainstaluj listopadowe aktualizacje 2025 na wspieranych wydaniach Windows, by uzyskać pełne wyświetlanie Target. Dla starszych wersji rozważ 0patch (micropatch: limit 260 znaków + alert) – po ocenie ryzyka i zgodności.
  7. Szkolenia i playbooki SOC: uaktualnij runbooki analityczne: przy incydentach z plikami .LNK zawsze sprawdzaj cały Target i historię pochodzenia pliku (strefa Internet/MOTW).

Różnice / porównania z innymi przypadkami

  • Stuxnet (CVE-2010-2568) vs CVE-2025-9491: Stuxnet wykorzystywał RCE w parserze .LNK (brak interakcji). Tu problemem jest ukrycie informacji w UI, a RCE wynika z uruchomienia „zaufanego” skrótu przez użytkownika. Inne klasy zagrożeń; wspólny mianownik: .LNK jako nośnik.
  • Nowsze kampanie APT: bieżące operacje (UNC6384) to spear-phishing + .LNK + PlugX i motyw szpiegowski, a nie masowa cyberprzestępczość.

Podsumowanie / kluczowe wnioski

  • CVE-2025-9491 to realny wektor w rekonesansie i intruzjach APT – wykorzystywany od lat, często niezauważany przez człowieka, bo UI wprowadzało w błąd.
  • Microsoft nie wydał klasycznej poprawki bezpieczeństwa, ale zmienił UI tak, by ujawniać pełen łańcuch poleceń. To pomaga, ale nie eliminuje ryzyka – twarde polityki wykonania, EDR i bramki pocztowe pozostają kluczowe.
  • Organizacje powinny wdrożyć warstwowe mitygacje: kontrolę .LNK w mailu/endpointach, ASR/WDAC, monitoring długich command lines i edukację użytkowników.

Źródła / bibliografia

  1. BleepingComputer: „Microsoft ‘mitigates’ Windows LNK flaw exploited as zero-day” (03.12.2025). (BleepingComputer)
  2. Trend Micro ZDI: „ZDI-CAN-25373: Windows Shortcut Exploit Abused as Zero-Day in Widespread APT Campaigns” (18.03.2025, aktualizacje). (www.trendmicro.com)
  3. Zero Day Initiative – Advisory ZDI-25-148 (CVE-2025-9491) i timeline korespondencji z Microsoft. (zerodayinitiative.com)
  4. Arctic Wolf Labs: „UNC6384 Weaponizes ZDI-CAN-25373 to Deploy PlugX Against European Diplomatic Entities” (30.10.2025). (Arctic Wolf)
  5. 0patch (ACROS Security): „Microsoft Silently Patched CVE-2025-9491 – We Think Our Patch Provides More Security” (02.12.2025). (blog.0patch.com)