Archiwa: SIEM - Strona 27 z 46 - Security Bez Tabu

Tag: SIEM

PowerShell w Windows ostrzega przy użyciu Invoke-WebRequest. Co to zmienia dla bezpieczeństwa i automatyzacji?

Wprowadzenie do problemu / definicja luki

Microsoft dodał do Windows PowerShell 5.1 nowy mechanizm ostrzegania, który wyświetla potwierdzenie bezpieczeństwa podczas uruchamiania skryptów wykorzystujących Invoke-WebRequest (IWR) do pobierania treści WWW. Celem jest ograniczenie ryzyka wykonania złośliwych skryptów osadzonych w pobieranych stronach. Zmiana została dostarczona w pakietach z Patch Tuesday 9 grudnia 2025 r. i jest powiązana z podatnością CVE-2025-54100 (wstrzyknięcie poleceń / command injection w Windows PowerShell).

W skrócie

  • Co się zmieniło? Invoke-WebRequest w PowerShell 5.1 może wyświetlić prompt z ostrzeżeniem o ryzyku wykonania skryptu z pobieranej strony. Użytkownik może kontynuować lub anulować operację.
  • Dlaczego? Aby zamknąć wektor ataku opisany jako CVE-2025-54100 (wysoka skala zagrożenia, CVSS 7.8 wg NVD/MSRC).
  • Jak obejść prompt w automatyzacji? Użyć parametru -UseBasicParsing w IWR (w PowerShell 5.1), który pobiera treść bez parsowania i bez wykonywania skryptów w odpowiedzi HTTP.
  • Kogo dotyczy? Administratorów, DevOpsów i autorów skryptów działających na Windows PowerShell 5.1 (wbudowany w Windows), w tym skryptów uruchamianych bez nadzoru.

Kontekst / historia / powiązania

Invoke-WebRequest to popularny cmdlet do pobierania zasobów HTTP/HTTPS, który parsuje HTML i zwraca zbiory elementów (linki, obrazy itp.). W starszym mechanizmie parsowania mogło dojść do niepożądanego uruchomienia skryptu po stronie klienta podczas przetwarzania odpowiedzi, co stało się osią wektora podatności CVE-2025-54100. Microsoft zaadresował problem w grudniowych aktualizacjach, a media branżowe opisały nowy prompt bezpieczeństwa jako dodatkową „barierę tarcia” dla złośliwego kodu.

Analiza techniczna / szczegóły luki

  • Identyfikator: CVE-2025-54100
  • Klasyfikacja: Command Injection (CWE-77)
  • Wpływ: lokalne wykonanie kodu przy udziale użytkownika (UI:R), wysokie skutki dla poufności, integralności i dostępności.
  • Wektor: pobranie i przetworzenie treści WWW przez IWR w sposób, który umożliwia wykonanie złośliwej skryptowej zawartości osadzonej w odpowiedzi.
  • Ocena ryzyka: CVSS v3.1 7.8 (High) wg NVD; Microsoft udostępnił poprawki w ramach Patch Tuesday.

Nowe zachowanie PowerShell 5.1:
Przy wywołaniu Invoke-WebRequest bez parametru -UseBasicParsing PowerShell 5.1 wyświetla dialog/komunikat potwierdzenia, informując, że parsowanie treści strony może uruchomić skrypt. Użytkownik wybiera Kontynuuj lub Anuluj. Dokumentacja Microsoft zaleca -UseBasicParsing dla scenariuszy nieinteraktywnych (CI/CD, zadań harmonogramu), aby pominąć parsowanie i tym samym uniknąć potencjalnego wykonania skryptu.

Praktyczne konsekwencje / ryzyko

  • Automatyzacja/CI: pipeline’y i zadania, które używają IWR bez -UseBasicParsing, mogą teraz się zatrzymać na potwierdzeniu, co spowoduje błędy w trybie bezobsługowym. Należy zaktualizować skrypty.
  • Eksploatacja w dziczy: luki w PowerShell bywały wykorzystywane przez malware do pobierania payloadów (np. kampanie opisane w raportach o Patch Tuesday). Nowy prompt utrudnia „ciche” wykonanie osadzonych skryptów z WWW.
  • Zgodność: skrypty polegające na starym, „bogatym” parsowaniu HTML mogą wymagać modyfikacji, jeśli przejdą na -UseBasicParsing.

Rekomendacje operacyjne / co zrobić teraz

  1. Zainstaluj grudniowe poprawki (09.12.2025) na wszystkich wspieranych wersjach Windows. Zmiana IWR jest częścią wielu pakietów zbiorczych (KB z 9 grudnia 2025 r.).
  2. Przejrzyj skrypty: wszędzie tam, gdzie wywołujesz Invoke-WebRequest w PowerShell 5.1, dodaj -UseBasicParsing dla zadań automatycznych / bezinteraktywnych.
  3. Waliduj i sanityzuj URL-e/odpowiedzi: ograniczaj pobieranie tylko z zaufanych domen, stosuj walidację treści (np. sprawdzanie hashów plików). (Dobra praktyka ogólna; spójna z charakterem luki.)
  4. Monitoruj telemetry: w SIEM/EDR filtruj procesy z powershell.exe i wzorce zawierające Invoke-WebRequest. Raporty popatchowe podkreślają potrzebę obserwacji tego cmdletu w detekcjach.
  5. Rozważ PowerShell 7+ w nowych projektach: nowsze wersje mają unowocześnioną implementację IWR i inny model parsowania; mimo to zawsze stosuj zasady najmniejszych uprawnień i podpisywanie skryptów.

Minimalny przykład (PowerShell 5.1)

  • Pobranie pliku bez promptu i bez parsowania HTML:
    Invoke-WebRequest -Uri "https://example.com/tool.exe" -OutFile "tool.exe" -UseBasicParsing

Różnice / porównania z innymi przypadkami

  • Przed aktualizacją: IWR mógł parsować odpowiedź HTML w sposób, który w określonych warunkach prowadził do niezamierzonego wykonania skryptu; brakował „hamulec bezpieczeństwa” po stronie użytkownika.
  • Po aktualizacji (PS 5.1): pojawia się prompt ostrzegawczy; -UseBasicParsing wyłącza parsowanie i eliminuje ryzyko wykonania skryptu oraz interakcji użytkownika.
  • PowerShell 7.x: inny stos sieciowy i dokumentowana funkcja IWR; zalecane praktyki bezpieczeństwa pozostają aktualne (brak promptu w 7.x, ale bezpieczne wzorce korzystania).

Podsumowanie / kluczowe wnioski

  • Grudniowy Patch Tuesday 2025 przyniósł istotną zmianę w Windows PowerShell 5.1 – ostrzeżenie i potwierdzenie przy użyciu Invoke-WebRequest. To reakcja na CVE-2025-54100 (command injection).
  • Administratorzy muszą zaktualizować systemy i dostosować skrypty, w szczególności dodając -UseBasicParsing tam, gdzie wymagany jest tryb bezobsługowy.
  • Równolegle należy wzmacniać monitoring pod kątem wywołań IWR i stosować zasadę „zaufaj, ale weryfikuj” dla pobieranych treści.

Źródła / bibliografia

  1. BleepingComputer — „Windows PowerShell now warns when running Invoke-WebRequest scripts” (09.12.2025). (BleepingComputer)
  2. Microsoft Support — „PowerShell 5.1: Preventing script execution from web content” (KB — instrukcje oraz obejście -UseBasicParsing). (Microsoft Support)
  3. MSRC — karta podatności CVE-2025-54100. (msrc.microsoft.com)
  4. NVD — opis i metryka CVE-2025-54100 (CVSS 7.8, CWE-77). (NVD)
  5. BleepingComputer — „Microsoft December 2025 Patch Tuesday fixes 3 zero-days, 57 flaws” (kontekst aktualizacji). (BleepingComputer)

SAP łata trzy krytyczne luki w wielu produktach (grudzień 2025)

Wprowadzenie do problemu / definicja luki

9 grudnia 2025 r. SAP opublikował biuletyn Security Patch Day z 14 nowymi notami bezpieczeństwa, w tym trzema lukami o randze „Critical”. Poprawki obejmują m.in. SAP Solution Manager, SAP Commerce Cloud (komponenty Tomcat) oraz SAP jConnect (SDK for ASE). SAP zaleca natychmiastowe wdrożenie aktualizacji we wszystkich środowiskach.

W skrócie

  • CVE-2025-42880 (CVSS 9.9) — code injection w SAP Solution Manager ST 720; błąd walidacji wejścia może prowadzić do pełnego przejęcia systemu po stronie serwera przez uwierzytelnionego atakującego.
  • CVE-2025-55754 (CVSS 9.6) — podatności w Apache Tomcat wykorzystywanym przez SAP Commerce Cloud (powiązana także CVE-2025-55752); problem z nieprawidłowym „ucieczkowaniem” sekwencji ANSI w logach konsolowych. Zalecana aktualizacja Tomcat do 9.0.109 / 10.1.45 / 11.0.11.
  • CVE-2025-42928 (CVSS 9.1) — deserialization w SAP jConnect (SDK for ASE 16.0.4, 16.1); w określonych warunkach użytkownik z wysokimi uprawnieniami może osiągnąć RCE przygotowanym wejściem.

Kontekst / historia / powiązania

Zestaw poprawek wpisuje się w trend intensywnego łatana krytycznych błędów w ekosystemie SAP. W 2025 r. obserwowano już ataki in-the-wild na inną lukę typu wstrzyknięcie kodu w SAP (CVE-2025-42957), co zwiększa ryzyko szybkiego instrumentowania świeżo ujawnianych usterek.
Niezależne analizy (Onapsis) wskazują, że część z grudniowych „HotNews” dotyczy komponentów o dużym zasięgu i złożonych zależnościach (np. Tomcat w SAP Commerce Cloud), co komplikuje priorytetyzację i wymusza spójne zarządzanie wersjami.

Analiza techniczna / szczegóły luki

CVE-2025-42880 — SAP Solution Manager (ST 720), CVSS 9.9

Brak właściwej sanitacji danych wejściowych przy wywołaniu remote-enabled function module umożliwia uwierzytelnionemu atakującemu wstrzyknięcie kodu i przejęcie kontroli nad systemem (CIA: H/H/H; wektor AV:N/AC:L/PR:L/UI:N/S:C).

CVE-2025-55754 (+ CVE-2025-55752) — Apache Tomcat w SAP Commerce Cloud, CVSS 9.6

Tomcat niepoprawnie przetwarza sekwencje ANSI w logach; na konsolach Windows wspierających kolorowanie możliwa jest manipulacja konsolą/Schowkiem i nakłonienie administratora do uruchomienia poleceń. SAP agreguje podatności w notę #3683579 dla wersji HY_COM 2205, COM_CLOUD 2211, COM_CLOUD 2211-JDK21. Naprawa: podniesienie Tomcat do wersji 9.0.109 / 10.1.45 / 11.0.11.

CVE-2025-42928 — SAP jConnect (SDK for ASE 16.0.4/16.1), CVSS 9.1

Błąd deserializacji niezaufanych danych (CWE-502) pozwala, „w określonych warunkach”, użytkownikowi o wysokich uprawnieniach wywołać RCE poprzez specjalnie przygotowane dane wejściowe (wektor AV:N/AC:L/PR:H/UI:N/S:C).

Praktyczne konsekwencje / ryzyko

  • Przejęcie instancji SolMana i eskalacja w całym krajobrazie SAP (monitoring, konfiguracja, integracje), co może skutkować trwałym naruszeniem integralności procesów biznesowych.
  • Ryzyka łańcuchowe w e-commerce — podatny Tomcat w SAP Commerce Cloud zwiększa powierzchnię ataku na krytyczne procesy (konta klientów, zamówienia, ceny, integracje ERP/CRM).
  • RCE w warstwie łącznikowej (jConnect) może ułatwić atakującym pivot do systemów bazodanowych i exfiltrację danych o wysokiej wartości.

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytetyzacja wg wpływu i ekspozycji:
      1. CVE-2025-42880 (SolMan ST 720) — natychmiastowe wdrożenie noty #3685270.
      1. CVE-2025-55754/55752 — aktualizacja Tomcat do 9.0.109 / 10.1.45 / 11.0.11 w komponentach SAP Commerce Cloud (nota #3683579). Zweryfikuj wszystkie instancje (również EOL).
      1. CVE-2025-42928 — zastosuj notę #3685286; przejrzyj łańcuchy połączeń i uprawnienia kont używanych przez jConnect.
  2. Tymczasowe osłony (jeśli patch window jest ograniczone):
    • Ogranicz dostęp do funkcji zdalnych w SolMan (RFC), segmentacja sieci, dodatkowa MFA dla kont technicznych.
    • W Commerce Cloud: wyłącz uruchamianie w konsoli, przekieruj logi Tomcat do plików/siem, wymuś aktualne runtimes.
    • Dla jConnect: allow-list źródeł połączeń, walidacja danych, monitorowanie nietypowych ładunków serializacyjnych.
  3. Detekcja i monitoring:
    • Szukaj w SIEM m.in. nieoczekiwanych wywołań RFC/RFM w SolMan, nietypowych wzorców w logach Tomcat (sekwencje ESC[), anomalii w ruchu JDBC/jConnect. (Mapowanie do CVE wg biuletynu SAP i NVD).
  4. Higiena wersji:
    • Porównaj wersje Tomcat z tabelami „Security” producenta; utrzymuj min. 9.0.109/10.1.45/11.0.11.
  5. Procesy DevSecOps:
    • Dodaj testy regresyjne pod kątem deserializacji/escape sequences w CI, włącz skanowanie zależności i SCA.

Różnice / porównania z innymi przypadkami

  • Atakowalność: SolMan (PR:L) jest groźny, bo uderza w centralny system ALM z wysokimi uprawnieniami i szerokimi integracjami. jConnect wymaga PR:H, ale skutki RCE są systemowe. Tomcatowe CVE w Commerce Cloud ma profil bardziej „admin-tricking” (manipulacja konsolą), jednak w środowiskach operacyjnych może prowadzić do wykonania poleceń przez operatora.
  • Porównanie z tegorocznymi kampaniami: w 2025 r. widzieliśmy już aktywną eksploatację innej krytycznej luki SAP (CVE-2025-42957) — to sygnał, że „time-to-exploit” dla ekosystemu SAP skraca się po publikacji poprawek.

Podsumowanie / kluczowe wnioski

  • Grudniowy Patch Day SAP przynosi 3 krytyczne luki o szerokim wpływie na krajobraz SAP (ALM, e-commerce, warstwa łącznikowa DB). Patchuj niezwłocznie.
  • Dla SAP Commerce Cloud aktualizacje Tomcat do 9.0.109/10.1.45/11.0.11 są kluczowe, a zarządzanie wersjami powinno objąć wszystkie środowiska.
  • Utrzymuj detekcję anomalii i kontrolę uprawnień — wcześniejsze incydenty pokazują, że luki SAP szybko trafiają na radar aktorów zagrożeń.

Źródła / bibliografia

  • SAP Security Patch Day — December 2025 (lista not, wersje, CVSS). (SAP Support Portal)
  • BleepingComputer: „SAP fixes three critical vulnerabilities across multiple products”. (omówienie i kontekst). (BleepingComputer)
  • NVD: CVE-2025-42880 (Solution Manager), CVE-2025-42928 (jConnect), CVE-2025-55754 (Tomcat). (NVD)
  • Apache Tomcat Security — wersje naprawcze 9.0.109 / 10.1.45 / 11.0.11. (tomcat.apache.org)
  • Onapsis — Patch Day (grudzień 2025) — analiza i priorytetyzacja „HotNews”. (Onapsis)

JS#SMUGGLER: jak atak przez zaufane witryny instaluje NetSupport RAT (pełna analiza i zalecenia)

Wprowadzenie do problemu / definicja luki

Badacze potwierdzili nową kampanię JS#SMUGGLER, która wykorzystuje skompromitowane strony WWW jako wektor dystrybucji malware. Atak przebiega wieloetapowo: obfuskowany JavaScript wstrzyknięty w witrynę uruchamia zdalny HTA (HTML Application) przez mshta.exe, a następnie odszyfrowany PowerShell pobiera i uruchamia NetSupport RAT – narzędzie zdalnej administracji nadużywane do pełnej kontroli stacji roboczych ofiary.

W skrócie

  • Wejście: ukryte iframy i przekierowania z zaufanych (lecz skompromitowanych) serwisów do obfuskowanego loadera phone.js.
  • Egzekucja: loader dynamicznie dobiera ścieżkę (mobile vs desktop), buduje URL-e kolejnych etapów i uruchamia HTA przez mshta.exe.
  • Payload: zaszyfrowane (AES + Base64/GZIP) stager’y PowerShell usuwają swoje artefakty i pobierają NetSupport RAT z utrzymaniem trwałości.
  • Cel: trwała zdalna kontrola, kradzież danych, operacje plikowe i wykonywanie poleceń.
  • Technika: nadużycie mshta.exe (MITRE ATT&CK T1218.005 – Mshta) jako signed binary proxy execution.

Kontekst / historia / powiązania

Nadużywanie legalnych narzędzi RMM i binariów systemowych (Living-off-the-Land) jest trendem utrzymującym się w 2024–2025 – NetSupport był wielokrotnie dostarczany w kampaniach e-mail i „fake update”/ClickFix. Organizacje raportowały przesunięcie akcentu: od fałszywych aktualizacji do socjotechniki ClickFix i dostarczania RMM jako „pierwszego etapu”.

Analiza techniczna / szczegóły luki

Etap 1 – Loader JS (phone.js):

  • Wstrzyknięty w skompromitowaną witrynę, korzysta z ukrytych iframe’ów i cichych przekierowań.
  • Zawiera „śmietnikowe” komentarze i tablice rotowane runtime’em; dekoduje łańcuchy przez funkcje indeksujące, utrudniając statyczną analizę.
  • Używa localStorage do jednorazowego odpalenia logiki (redukcja szumu detekcyjnego).
  • Rozgałęzia ścieżkę w zależności od urządzenia (mobile: fullscreen iframe; desktop: dociągnięcie skryptu 2. fazy).

Etap 2 – HTA przez mshta.exe:

  • Loader konstruuje w locie URL HTA i uruchamia go wykorzystując mshta.exe – zaufany komponent Windows wykorzystywany do proksowania wykonania kodu (MITRE T1218.005).
  • HTA uruchamia zaszyfrowane stager’y PowerShell, minimalizuje okna i ukrywa artefakty, by ograniczyć ślad forensyczny.

Etap 3 – PowerShell → NetSupport RAT:

  • Stager’y AES-256-ECB + Base64/GZIP pobierają, rozpakowują i uruchamiają NetSupport RAT, konfigurując persistencję (m.in. skróty w Autostarcie).
  • NetSupport daje atakującym m.in. zdalny pulpit, transfer plików, egzekucję poleceń, proxy i kradzież danych.

Praktyczne konsekwencje / ryzyko

  • Omijanie zabezpieczeń: wykorzystanie zaufanych domen (kompromitowanych serwisów) i signed binariów (mshta.exe) utrudnia detekcję sygnaturową i reputacyjną.
  • Eskalacja wpływu: po instalacji NetSupport umożliwia trwałą obecność, eksfiltrację danych oraz „hands-on-keyboard”.
  • Szeroki zasięg: kampania celuje w użytkowników korporacyjnych przeglądających zwykłe strony, co zwiększa powierzchnię ataku poza e-mailem.

Rekomendacje operacyjne / co zrobić teraz

Twarde kontrole:

  1. Blokady LoLBin: ogranicz/zasady SRP/AppLocker dla mshta.exe, wscript.exe, cscript.exe – przynajmniej poza zaufanymi kontenerami. (MITRE T1218.005)
  2. CSP i nagłówki przeglądarkowe: wymuś Content-Security-Policy (blok skryptów z nieautoryzowanych domen, frame-ancestors), X-Frame-Options dla własnych serwisów.
  3. Egress i DNS: kontrola wyjścia do świeżo zarejestrowanych domen / nietypowych TLD; segmentacja i proxy z inspekcją TLS. (wnioskowane na bazie łańcucha C2)
  4. Ochrona endpointów: włącz PowerShell Constrained Language Mode, Script Block/Module Logging, AMSI i rejestrowanie zdarzeń 4104.
  5. Monitorowanie mshta/HTA: reguły EDR/SIEM na zdalne HTA uruchamiane przez mshta.exe (np. event + command line zawierający URL/HTA). Dostępne gotowe reguły detekcyjne wskazują na wartość takiego use-case’u.

Detekcje (przykładowe sygnały):

  • Process = mshta.exe AND CommandLine CONTAINS http/https OR *.hta. (MITRE T1218.005)
  • powershell.exe z ciągami FromBase64String, GZIP, AES, Expand-Archive, New-Object Net.WebClient.
  • Tworzenie skrótów w %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\.
  • Połączenia do domen/ścieżek podobnych do */call/phone.js i nietypowych hostów wskazanych w analizie.

Higiena i reagowanie:

  • Hardening przeglądarek i serwerów WWW, skan integracyjny pod kątem wstrzyknięć JS/iframe.
  • Playbook IR dla NetSupport/RMM nadużywanych – odcięcie hosta, usunięcie autostartu, inwentaryzacja kont i sesji, rotacja poświadczeń, przegląd ruchu proxy/VPN. (wspierane wcześniejszymi obserwacjami kampanii z NetSupport)
  • Uświadamianie użytkowników w zakresie fałszywych „napraw kliknięciem” (ClickFix) oraz ostrzeżeń o skryptach PowerShell.

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

W odróżnieniu od mailowych kampanii z NetSupport (częste u graczy finansowo motywowanych), JS#SMUGGLER omija e-mail i wchodzi przez skompromitowane strony oraz łańcuch web-owy (JS→HTA→PowerShell). To zbliża go do ataków fake update/ClickFix, ale tutaj kluczową rolę gra mshta.exe jako signed binary oraz warunkowe branching po stronie JS (mobile vs desktop), co utrudnia replikację i detekcję.

Podsumowanie / kluczowe wnioski

  • JS#SMUGGLER to dojrzała, warstwowa operacja web-malware z naciskiem na stealth i selektywność ekzekucji.
  • Krytycznym elementem jest nadużycie mshta.exe (T1218.005) i zaszyfrowane stager’y PowerShell, które dostarczają NetSupport RAT.
  • Obrona musi łączyć polityki wykonywania, telemetrię PowerShell, kontrole przeglądarkowe (CSP) i monitoring LoLBin – same blokady domen nie wystarczą.

Źródła / bibliografia

  1. The Hacker News – „Experts Confirm JS#SMUGGLER Uses Compromised Sites to Deploy NetSupport RAT”, 8 grudnia 2025. (The Hacker News)
  2. Securonix Threat Research – „JS#SMUGGLER: Multi-Stage – Hidden iframes, Obfuscated JavaScript, Silent Redirectors & NetSupport RAT Delivery”, 3 grudnia 2025. (Securonix)
  3. MITRE ATT&CK – „T1218.005 Mshta (Signed Binary Proxy Execution)”. (attack.mitre.org)
  4. Proofpoint – „Remote Monitoring and Management (RMM) tooling increasingly attackers’ first choice”, 7 marca 2025. (kontekst NetSupport/RMM) (proofpoint.com)
  5. eSentire – „Unpacking NetSupport RAT Loaders Delivered via ClickFix”, 23 października 2025. (tło i taktyki z 2025) (eSentire)

LockBit 5: „nowa, bezpieczna domena bloga” i… błyskawiczny wyciek infrastruktury

Wprowadzenie do problemu / definicja luki

LockBit 5.0 ogłosił „nową, bezpieczną domenę bloga z wielowarstwową ochroną przed wszechmocnym FBI”. Zaledwie kilkadziesiąt godzin później OSINT-owcy i media branżowe powiązali tę infrastrukturę z konkretną domeną i adresem IP, ujawniając wrażliwe szczegóły konfiguracji serwera. To kolejny przykład kompromitacji higieny operacyjnej (opsec) gangu po jego powrocie na scenę.

W skrócie

  • Nowa infrastruktura LockBit 5.0 została powiązana z domeną karma0[.]xyz oraz adresem IP 205.185.116.233 (AS53667 – PONYNET/FranTech).
  • Serwer wykazywał otwarte porty wysokiego ryzyka (m.in. 3389/TCP – RDP, 5985 – WinRM), co przeczy narracji o „wielowarstwowej ochronie”.
  • Na nowym DLS (data leak site) pojawiły się recyklingowane wpisy ofiar – część ofiar miała pochodzić z wcześniejszych wycieków i innych grup (Weyr0/RansomHouse).
  • Równolegle monitorujący leak-sitów odnotowali nowy onion dla „bezpiecznego bloga”.
  • W szerszym tle: po Operation Cronos (luty 2024) gang odbudował się i w 2025 r. wypuścił LockBit 5.0 z technicznymi usprawnieniami.

Kontekst / historia / powiązania

Operacja służb „Cronos” w lutym 2024 r. uderzyła w infrastrukturę i panele LockBit, co znacząco ograniczyło jego możliwości – ale nie zakończyło działalności afiliantów. W 2025 r. gang ogłosił wersję 5.0 i stopniowo odbudował ekosystem RaaS. Dzisiejsza wpadka z domeną i IP wpisuje się w pasmo problemów opsec po serii wcześniejszych ekspozycji zaplecza grupy.

Analiza techniczna / szczegóły luki

  • Punkty wiązania (pivoty): badacze powiązali „nowy bezpieczny blog” z domeną karma0[.]xyz (zwracała stronę z brandingiem „LOCKBITS.5.0”) oraz adresem 205.185.116.233 w AS53667 (PONYNET/FranTech). Dane te zostały publicznie opublikowane na X (Twitter) przez analityka OSINT i następnie opisane w serwisach branżowych.
  • Konfiguracja usług: skany zewnętrzne wskazywały na wiele otwartych portów, m.in. 21/FTP, 80/HTTP (Apache/2.4.58 + PHP 8.0.30), 3389/RDP, 5000/HTTP, 5985/WinRM, 47001/HTTP i 49666 (usługa plików). Obecność RDP/3389 i WinRM/5985 na hostach przestępczych to rzadko spotykany błąd opsec, ułatwiający identyfikację, fingerprinting i potencjalne zakłócenia. (Uwaga: lista portów pochodzi z publikacji branżowej; nie stanowi niezależnie zweryfikowanego skanu.)
  • Metadane rejestracyjne: w materiałach pojawia się rozbieżność dat WHOIS (część źródeł podaje rejestrację 2 listopada 2025, inne – 12 kwietnia 2025 i użycie nameserverów Cloudflare). To typowe w przypadku prywatności WHOIS i zmian rejestratora; należy traktować te daty jako niejednoznaczne.
  • Nowy onion / DLS: wpis monitorujący leak-sity wskazuje nowy adres .onion opisany przez LockBit jako „new secure blog domain with a multi-layered protection system”.

Praktyczne konsekwencje / ryzyko

  • Ryzyko eskalacji DDoS i ingerencji: publiczne powiązanie adresu IP i domeny zwiększa szansę na działania obronne (blokady, zgłoszenia nadużyć) oraz kolizję z innymi gangami/crowd-sourcowanymi atakami.
  • Podważona wiarygodność DLS: sygnały o recyklingu ofiar podkopują presję negocjacyjną LockBit (ofiary i negocjatorzy mogą uznać nowe „publikacje” za blef).
  • Wymierne IOCs dla obrony: karma0[.]xyz, 205.185.116.233, AS53667 i nowy onion to artefakty do blokowania i korelacji w telemetrii SOC/TI.
  • Nieprzerwany rozwój narzędzi TTP: mimo wpadek opsec, LockBit 5.0 pozostaje technicznie dojrzały (wieloplatformowość: Windows/Linux/ESXi, obfuscation, utrudnianie analizy, szybkie szyfrowanie), co przekłada się na wciąż wysokie ryzyko dla organizacji.

Rekomendacje operacyjne / co zrobić teraz

Blokady i detekcje (prewencja):

  • Dodać do polityk blokowania: karma0[.]xyz, 205.185.116.233, segmenty AS53667; monitorować ewentualne rotacje IP/domen.
  • Aktualizować listy domen/URL DLS/CS w secure web gateway/EDR/NDR.
  • W regułach IDS/IPS oraz SIEM dodać korelację na nowy onion (jeśli telemetrycznie widoczny w ruchu TOR).

Twardnienie środowisk:

  • Egzekwować MFA + restrykcje sieciowe na RDP/WinRM/SSH/VPN; dla RDP – preferować RD Gateway + Just-In-Time + przesiadka na tunelowane połączenia bastionowe.
  • Wyłączyć SMB v1, ograniczyć „shadow copy” i włączyć tamper protection w EDR.
  • Wdrożyć application allowlisting dla hostów serwerowych, segmentację sieci (zwłaszcza ESXi/hiperwizory) i kopie zapasowe 3-2-1 z testem odtwarzania.

Detekcje TTP (przykłady):

  • Wykrywanie masowego rename + nietypowe rozszerzenia plików, wyłączenia ETW, zabijania usług AV/EDR, zrzutów LSASS, eksfiltracji poprzez tunelowanie HTTP(S)/TOR.
  • Korelowanie artefaktów LockBit 5.0 ze wskaźnikami znanymi z badań (np. obfuskacja, dynamiczne rozwiązywanie API, wsparcie ESXi).

Reakcja i komunikacja:

  • Przy incydentach z „LockBit 5.0” ocenić autentyczność wpisu na DLS – weryfikować, czy nie jest to recykling. Nie płacić za „stare” dane.

Różnice / porównania z innymi przypadkami

W przeszłości wycieki infrastruktury dotyczyły m.in. paneli afiliańckich i czatów LockBit (2025), ale obecny incydent jest nietypowy, bo uderza w „nową, wzmocnioną” domenę PR-owo reklamowaną przez gang – i to niemal natychmiast po starcie. W materialne technicznym 5.0 widać progres po stronie malware’u, podczas gdy opsec i warstwa publikacyjna pozostają piętą achillesową operacji.

Podsumowanie / kluczowe wnioski

  • LockBit 5.0 traci narrację o „nietykalności”: domena karma0[.]xyz i 205.185.116.233 szybko trafiły do publicznych IOCs, a serwer wyglądał na słabo utwardzony.
  • Recykling ofiar dodatkowo podważa presję szantażową gangu.
  • Dla obrońców to moment na blokady, korelacje i hunting z użyciem świeżych wskaźników, pamiętając, że technicznie LockBit 5.0 pozostaje niebezpieczny.

Źródła / bibliografia

  1. DataBreaches.net: „LockBit 5’s ‘new secure blog domain’ infra leaked already” (07.12.2025). (DataBreaches.Net)
  2. CyberSecurityNews: „LockBit 5.0 Infrastructure Exposed in New Server, IP, and Domain Leak” (07.12.2025). (Cyber Security News)
  3. Ransomware.live: wpis „new blog domain lockbit 5.0” (05.12.2025). (Ransomware Live)
  4. Europol: „Law enforcement disrupt world’s biggest ransomware operation” (20.02.2024). (Europol)
  5. Trend Micro Research: „New LockBit 5.0 Targets Windows, Linux, ESXi” (25.09.2025). (www.trendmicro.com)

Korea zaostrzy audyty ISMS po wycieku danych w Coupang. Co to oznacza dla firm?

Wprowadzenie do problemu / definicja luki

Rząd Korei Południowej ogłosił, że zaostrzy proces certyfikacji i nadzoru nad państwowym systemem zarządzania bezpieczeństwem informacji (ISMS) oraz ISMS-P po masywnym wycieku danych w platformie e-commerce Coupang. W agendzie są m.in. obowiązkowe stosowanie ISMS dla kluczowych sektorów, dogłębne kontrole po-incydentowe oraz możliwość unieważniania certyfikatów w razie poważnych naruszeń. Decyzję zakomunikowano po międzyresortowym spotkaniu Personal Information Protection Commission (PIPC) i Ministerstwa Nauki i ICT (MSIT).

W skrócie

  • Skala: ujawniono dane ok. 33–33,7 mln kont klientów Coupang; incydent miał pozostawać niewykryty przez kilka miesięcy.
  • Wektor: w śledztwie analizowany jest wątek insiderski oraz wykorzystanie skradzionego klucza prywatnego/uprzywilejowanego dostępu.
  • Regulacje: rząd planuje obowiązkowość ISMS dla telekomów i platform oraz ostrzejsze audyty i kontrole terenowe; możliwe zmiany ustawowe.
  • Działania PIPC: nadzwyczajne posiedzenie PIPC nałożyło na Coupang środki zaradcze i obowiązek rozszerzonej notyfikacji.

Kontekst / historia / powiązania

Koreański ISMS/ISMS-P to państwowe reżimy certyfikacyjne pokrywające ogólne bezpieczeństwo informacji (ISMS) oraz ochronę danych osobowych (ISMS-P). Dotąd uzyskanie certyfikatów często następowało na wniosek operatora; władze zapowiadają przejście na model obowiązkowy dla wybranych branż i wzmocnienie nadzoru „po fakcie”. Impulsem stał się wyciek w Coupang — największy od lat — oraz rosnąca presja polityczna i społeczna.

Analiza techniczna / szczegóły luki

Dostępne raporty śledcze wskazują na kilka krytycznych obszarów kontroli, które mogły zawieść:

  1. Zarządzanie kluczami i tożsamościami – pojawiły się doniesienia o wykorzystaniu skradzionego klucza prywatnego oraz możliwym zaangażowaniu osoby związanej wcześniej z systemami uwierzytelniania i IAM w Coupang. To sugeruje niedostatki w HSM/KMS, rotacji kluczy i monitoringu użycia kluczy.
  2. Detekcja i czas ujęcia incydentu (MTTD) – naruszenie mogło trwać od czerwca do listopada, co wskazuje na luki w telemetryce i korelacji zdarzeń (SIEM/UEBA) oraz w alertingu anomalii egress.
  3. Segmentacja i najmniejsze uprawnienia – skoro możliwe było długotrwałe pobieranie rekordów PII, segmentacja danych, kontrole DLP i polityki just-in-time access musiały być niewystarczające. (Wniosek analityczny oparty na dotychczasowych ustaleniach śledztwa).

Praktyczne konsekwencje / ryzyko

  • Regulator „po drugiej stronie kabla”: firmy działające w Korei (lub obsługujące klientów/kontenery danych w KR) mogą spodziewać się częstszych kontroli, audytów na miejscu i testów skuteczności — nie tylko weryfikacji dokumentów.
  • Ryzyko łańcucha dostaw: dostawcy i BPO z dostępem do PII klientów koreańskich będą włączani w zakres wymogów ISMS/ISMS-P.
  • Koszt naruszeń: po incydencie politycy wzywają do wyższych kar i odszkodowań karnych, co podnosi ryzyko finansowe.

Rekomendacje operacyjne / co zrobić teraz

Dla CISO i działów bezpieczeństwa (także poza Koreą, jeśli obsługujesz użytkowników z KR):

  1. Zamroź i przeglądnij łańcuch zaufania: inwentaryzacja kluczy, weryfikacja ochrony KMS/HSM, natychmiastowa rotacja kluczy o podniesionym ryzyku, wdrożenie key-use attestation i alertingu nadużyć.
  2. Wzmocnij IAM: przegląd ról uprzywilejowanych, JIT + MFA hardware, sesje krótkotrwałe, ciągły behavioral UEBA dla adminów i developerów.
  3. Telemetryka i czas ujęcia: reguły detekcji exfiltracji (DNS, S3, BigQuery, Object Storage), eBPF/EDR na hostach przetwarzających PII, korelacja z DLP. Incydent pokazał, że miesiące „ciszy” są realne.
  4. Kontrola dostawców: rozszerz GRC o dowody skuteczności, nie tylko certyfikaty (logi z testów odzyskiwania, wyniki purple-team, wyniki TTP-based controls).
  5. Ćwiczenia insider-risk: scenariusze z nadużyciem kluczy i offboardingiem pracowników (revoke, rotation, break-glass review).
  6. Komunikacja i zgodność: przygotuj playbook PIPC (wzory notyfikacji, kanały komunikacji, FAQ), aby spełnić wymagania rozszerzonej notyfikacji i działań naprawczych.

Różnice / porównania z innymi przypadkami

  • ISMS/ISMS-P vs ISO/IEC 27001/27701: ISO kładzie nacisk na system zarządzania i cykl PDCA, natomiast ISMS/ISMS-P w Korei – oprócz elementów systemowych – w praktyce jest bardziej operacyjny i sektorowy (telekom, platformy), a po zmianach ma mocniejszy nadzór po-incydentowy z sankcją unieważnienia certyfikatu. Zapowiedzi idą w kierunku obowiązkowego zakresu dla wybranych branż, podczas gdy ISO pozostaje dobrowolne (choć rynkowo wymagane).
  • RODO (UE): podobnie jak w UE, rośnie presja finansowa i oczekiwanie „efektywności” środków, nie samej zgodności formalnej; koreańskie władze – wzorem praktyk EOG – naciskają na real-world security outcomes i szybkie notyfikacje.

Podsumowanie / kluczowe wnioski

  • Korea przechodzi od „checklist compliance” do „assurance of effectiveness”: audyty, kontrole terenowe i realna odpowiedzialność (włącznie z utratą certyfikatu).
  • Incydent w Coupang podkreśla, że największe ryzyko często siedzi „wewnątrz”: ochrona i monitoring kluczy, IAM i telemetria muszą być priorytetem.
  • Organizacje działające w KR (lub przetwarzające dane Koreańczyków) powinny zacząć przygotowania już dziś: przegląd kluczy, inspekcje dostawców, scenariusze insider-risk i gotowe szablony notyfikacji do PIPC.

Źródła / bibliografia

  1. Korea JoongAng Daily: „Gov’t to toughen certification screening for information security system amid Coupang data breach”, 7 grudnia 2025. (Korea Joongang Daily)
  2. The Korea Times: „Gov’t to toughen certification screening for information security system…”, 6 grudnia 2025. (The Korea Times)
  3. Reuters: „South Korea’s Lee calls for tougher penalties after Coupang data breach”, 2 grudnia 2025. (Reuters)
  4. Reuters: „Coupang apologises over massive data breach (33.7m accounts)”, 29 listopada 2025. (Reuters)
  5. Digital Policy Alert: „PIPC required Coupang to implement corrective notification and strengthened mitigation”, 3 grudnia 2025. (Digital Policy Alert)

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 Centre – Malware 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 Intelligence – Brickstorm espionage campaign (analiza GTIG/Mandiant), 24 września 2025. (Google Cloud)
  4. CyberScoop – Expansive, ongoing China espionage threat riding on Brickstorm, 4 grudnia 2025. (CyberScoop)
  5. Reuters – Chinese-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)