Archiwa: APT - Strona 33 z 45 - Security Bez Tabu

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)

Ukrywanie Procesów W Systemach Operacyjnych – Mechanizmy, Techniki i Przykłady

Jak system naprawdę widzi procesy i dlaczego to ważne przed analizą ukrywania

Czy da się ukryć działający proces przed administratorem systemu? Niestety tak – istnieją zaawansowane techniki pozwalające zataić obecność procesu zarówno w systemach Linux, jak i Windows. W tym artykule, omawiamy ukrywanie procesów krok po kroku: od metod działania w przestrzeni użytkownika (user-mode) po głębokie modyfikacje w jądrze systemu (kernel-mode).

Czytaj dalej „Ukrywanie Procesów W Systemach Operacyjnych – Mechanizmy, Techniki i Przykłady”

Lazarus (KR): urzędnicy łączą $30 mln kradzież z giełdy Upbit z północnokoreańskimi hakerami

Wprowadzenie do problemu / definicja incydentu

Po „nietypowej wypłacie” z gorącego portfela Upbit — największej giełdy krypto w Korei Południowej — urzędnicy państwowi wskazali na północnokoreańską grupę Lazarus jako prawdopodobnego sprawcę. Według doniesień, napastnicy wyłudzili lub przejęli uprawnienia administracyjne i wytransferowali ok. 44,5 mld KRW (~30 mln USD), po czym giełda zamroziła depozyty i wypłaty oraz przeniosła środki do cold walletów. Upbit zapowiedział pokrycie strat klientów.

W skrócie

  • Cel: Upbit (Korea Płd.), gorący portfel.
  • Skala: ~30 mln USD wyprowadzonych aktywów.
  • Atrybucja wstępna: TTP wskazujące na Lazarus (KR/DPRK).
  • Działania obronne: wstrzymanie operacji on-chain, migracja do cold wallet, próby zamrożenia części środków.
  • Tło rynkowe: dzień wcześniej Naver Financial ogłosił przejęcie operatora Upbit (Dunamu) za ~10 mld USD; w toku incydentu odnotowano „abnormal withdrawal”.

Kontekst / historia / powiązania

Upbit był już celem głośnego włamania w 2019 r. (342k ETH, ~42–49 mln USD wówczas), które południokoreańska policja w 2024 r. formalnie powiązała z północnokoreańskimi grupami Lazarus/Andariel. Bieżący atak ma „podobny podpis” do sprawy z 2019 r., co wzmocniło hipotezę o DPRK.

W skali globalnej DPRK-APT (m.in. Lazarus/APT38) odpowiadały w ostatnich latach za rekordowe kradzieże krypto – np. Bybit, luty 2025: ~1,5 mld USD, oficjalnie wskazane przez FBI jako operacja powiązana z „TraderTraitor”.

Analiza techniczna / szczegóły luki

Wektor wejścia. Według urzędników napastnicy „podszyli się pod administratorów” Upbit i zainicjowali transfery, co sugeruje kompromitację kont uprzywilejowanych (phishing/OAuth/SSO abuse, kradzież kluczy) lub obejście kontroli transakcyjnych w hot walletach. Ten modus operandi — nadużycie tożsamości adminów i szybkie odprowadzenie środków do mieszarek/chain hopping — był wielokrotnie obserwowany przy operacjach Lazarusa.

Łańcuchy prania. Historycznie Lazarus stosował segmentację przepływów, równe porcjowanie transakcji, cross-chain swapy i miksery (np. Sinbad / wcześn. Blender), co odnotowywały firmy analityczne i organy ścigania. W sprawie Upbit śledczy próbowali śledzić i zamrażać fragmenty środków już w pierwszej dobie.

Wskaźniki i TTP (przykładowe):

  • Impersonacja admina / kradzież sesji / złośliwe podpisy transakcyjne (blind-signing) – technika używana także w Bybit 2025.
  • Porcjowanie wypłat na powtarzalne kwoty i wielowarstwowe miksy.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla użytkowników: krótkoterminowe wstrzymania wypłat/depozytów, opóźnienia w rozliczeniach i możliwe skoki fee. Upbit deklaruje pokrycie strat, ale presja płynnościowa może utrzymywać się do czasu pełnej rekonsyliacji.
  • Ryzyko systemowe: ataki na warstwę operacyjną giełd (tożsamość i uprawnienia) omijają typowe zabezpieczenia smart-kontraktów.
  • Ryzyko regulacyjne: nowe wytyczne dot. kluczy admina, cold-/warm-wallet policy, obowiązkowe „withdrawal throttling” i adresy-dozwolone (allowlist) są coraz bardziej prawdopodobne po serii incydentów 2024–2025. Trend potwierdza skala Bybit 2025 i statystyki DPRK z raportów analitycznych.

Rekomendacje operacyjne / co zrobić teraz

Dla giełd i kustodianów

  1. Zerowy zaufanie dla operacji admina: U2F/WebAuthn + FIDO2 dla kont uprzywilejowanych, polityka „two-person rule” dla podpisów > X USD i obowiązkowe timelocki dla wypłat z hot/warm walleta.
  2. Segmentacja kluczy i horyzontów czasowych: dziel klucze na role (init/sign/approve), ogranicz okna ważności sesji i stosuj „just-in-time access”.
  3. Automatyczne reguły AML on-chain: blokady heurystyczne na znane węzły prania DPRK, eskalacja KYC i natychmiastowe freeze requesty do partnerów.
  4. Runbooki kryzysowe: gotowe playbooki z listą kontaktów (LEA, analityka blockchain, giełdy partnerskie), „war room” i wstępnie uzgodnione komunikaty.
  5. Monitoring nieinteraktywny kluczy: HSM + polityki nieopuszczania klucza, separacja środowisk podpisu, detekcja anomalii w patternach wypłat (równe porcje, cicliczne batch’e).
  6. Ćwiczenia red-team/blue-team z scenariuszem DPRK TraderTraitor.

Dla użytkowników

  • Trzymaj większe środki w self-custody (hardware wallet), włącz allowlisty adresów i limity dobowych wypłat.
  • Weryfikuj komunikaty giełdy wyłącznie w oficjalnych kanałach i wstrzymaj się z dużymi transferami, dopóki giełda nie zakończy pełnej rekonsyliacji po incydencie.

Różnice / porównania z innymi przypadkami

  • Upbit 2019 vs. Upbit 2025: wspólne elementy to atak na warstwę operacyjną giełdy i wzorce wypłat przypisywane DPRK; różni się skala (2019: ~42–49 mln USD, 2025: ~30 mln USD) oraz dojrzałość mechanizmów zamrażania środków.
  • Bybit 2025 (1,5 mld USD): inny profil — manipulacja procesem podpisu (blind-signing) i największa znana pojedyncza kradzież, oficjalnie przypisana DPRK przez FBI; pokazuje eskalację zdolności napastnika.

Podsumowanie / kluczowe wnioski

  • Wstępna atrybucja do Lazarus (KR) jest spójna z historią ataków na Upbit i globalną aktywnością DPRK w 2024–2025.
  • Wektor tożsamościowy/administracyjny pozostaje najsłabszym ogniwem dużych giełd — „smart” kontrola wypłat musi iść w parze z twardymi procedurami dla kont uprzywilejowanych.
  • Rynek powinien traktować runbooki incident-response i automatyczne freeze’y jako standard branżowy.
  • Statystyki z 2024–2025 (1,34 mld USD skradzione przez KR-APT w 2024; 1,5 mld USD w pojedynczym incydencie 2025) wskazują, że ryzyko systemowe nie maleje mimo spadku części wskaźników rynkowych.

Źródła / bibliografia

  1. The Record: „Officials accuse North Korea’s Lazarus of $30 million theft from crypto exchange” (01.12.2025). (The Record from Recorded Future)
  2. Reuters: „Naver’s payment arm to acquire Dunamu (Upbit) in $10 bln deal” + wzmianka o „abnormal withdrawal” (27.11.2025). (Reuters)
  3. Reuters (za Yonhap): „South Korea suspects North Korea behind hack of crypto exchange Upbit” (28.11.2025). (Reuters)
  4. Chainalysis: „Bybit hack… DPRK stole ~$1.34B across 47 incidents in 2024” (24.02.2025). (Chainalysis)
  5. FBI (IC3 PSA): „North Korea Responsible for $1.5 Billion Bybit Hack” (26.02.2025). (Internet Crime Complaint Center)