Archiwa: PowerShell - Strona 21 z 34 - Security Bez Tabu

Tag: PowerShell

Złośliwe rozszerzenia w VSCode Marketplace ukrywały trojana w fałszywym pliku PNG

Wprowadzenie do problemu / definicja luki

Badacze ReversingLabs opisali kampanię, w której 19 rozszerzeń VS Code publikowanych w oficjalnym VSCode Marketplace zawierało złośliwy ładunek ukryty w folderze node_modules. Najbardziej charakterystyczny element ataku: plik banner.png, który nie był obrazem, lecz archiwum z dwoma binariami — wykorzystywany był cmstp.exe (Living-off-the-Land) oraz trojan napisany w Rust. Kampania miała działać od lutego 2025 r., a znaleziska zgłoszono do Microsoftu na początku grudnia; rozszerzenia zostały usunięte z marketplace.

W skrócie

  • 19 złośliwych rozszerzeń (głównie „theme’y”) dostarczało zmodyfikowane zależności w node_modules, aby ominąć pobieranie z npm i ukryć różnice.
  • Atak modyfikował popularny pakiet path-is-absolute (ponad 9 mld pobrań) lub alternatywnie @actions/io, dorzucając klasę inicjującą dropper.
  • Dropper dekodował zaszyfrowany JavaScript z pliku lock (base64 + odwrócenie łańcucha), następnie uruchamiał binaria z fałszywego banner.png przez cmstp.exe, co finalnie ładowało trojana w Rust.
  • Microsoft usunął zgłoszone pozycje z Marketplace; użytkownicy powinni sprawdzić system pod kątem kompromitacji.

Kontekst / historia / powiązania

Marketplace’y dla IDE stały się atrakcyjnym wektorem łańcucha dostaw. W 2025 r. obserwowano kolejne incydenty z udziałem złośliwych rozszerzeń VS Code oraz pakietów Go/npm/Rust kradnących dane devów. Równolegle badania Wiz wykazały setki wycieków sekretów i tokenów publikacyjnych w pakietach rozszerzeń (co umożliwia skryte „pchanie” aktualizacji do całej bazy instalacyjnej). Te trendy pokazują, że nawet „niewinne” motywy/tematy mogą być nośnikiem ryzyka supply-chain.

Analiza techniczna / szczegóły luki

Pakowanie zależności w rozszerzeniach VS Code. W przeciwieństwie do typowego obiegu npm (gdzie npm install pobiera świeże zależności), rozszerzenia VS Code dostarczają kompletny folder node_modules w paczce .vsix. To pozwala atakującym „podmienić” treść popularnych paczek tylko na potrzeby swojego rozszerzenia — bez modyfikowania artefaktów na npm i bez czerwonych flag po stronie użytkownika.

Modyfikacja dependency. Atakujący dodali nową klasę do index.js w path-is-absolute (lub w części próbek użyli @actions/io), która automatycznie uruchamiała się przy starcie VS Code i dekodowała obfuskowany dropper z pliku lock (base64 + reverse).

Fałszywy obraz banner.png. W większości wariantów w node_modules znajdował się banner.png — w praktyce archiwum z dwoma binariami: cmstp.exe (LOLBin) do uruchomienia ładunku oraz docelowym trojanem Rust. W wersjach z @actions/io pliki były ukryte w parach .ts/.map. Zdolności trojana są nadal analizowane, ale łańcuch wykonywania jest spójny między próbkami.

Przykładowe nazwy rozszerzeń (IOC): m.in. Malkolm Theme, PandaExpress Theme, Prada 555 Theme, Priskinski Theme — wszystkie w wersji 1.0.0; ReversingLabs opublikował pełną listę nazw/SHA1.

Praktyczne konsekwencje / ryzyko

  • Ryzyko supply-chain po stronie devów. Wystarczy instalacja „tematu”/„motywu”, by kod w node_modules uruchomił dropper podczas startu VS Code. W środowisku developerskim to często maszyny z tajemnicami (tokeny, SSH, ciasteczka przeglądarek, konfiguracje chmurowe).
  • Trudność detekcji. Zależności są „zaufane z nazwy”, a plik PNG nie otwiera się jako obraz — nie generuje to oczywistych alertów. LOLBin cmstp.exe zaciera ślady.
  • Szybka dystrybucja / aktualizacje. Auto-update rozszerzeń i (osobny problem) wyciekające PAT-y wydawców zwiększają zasięg i prędkość potencjalnego skażenia.

Rekomendacje operacyjne / co zrobić teraz

1) Triage i hunting (Windows/macOS):

  • Inwentaryzacja VS Code: code --list-extensions --show-versions i weryfikacja na liście IOC ReversingLabs. Usuń podejrzane rozszerzenia, zwłaszcza o nazwach z rodziny Malkolm/PandaExpress/Prada 555/Priskinski (v1.0.0).
  • Przegląd paczek .vsix: rozpakuj (ZIP) i zbadaj node_modules pod kątem zmodyfikowanego index.js w path-is-absolute/@actions/io, obecności plików lock, fałszywych .png, nietypowych .ts/.map z binariami.
  • Telemetria / EDR: poluj na uruchomienia cmstp.exe przez procesy VS Code (Code.exe, code), nietypowe wywołania curl/PowerShell oraz świeże binaria Rust w katalogach rozszerzeń.

2) Odtwarzanie zaufania:

  • Reset sekretów na stacjach dev (tokeny API, PAT, klucze chmurowe, cookies przeglądarek) jeżeli wykryto instalację z listy IOC. Zalecana rotacja haseł i odświeżenie sesji przeglądarek. (Kontekst: znane kampanie kradły cookies, Wi-Fi i zrzuty ekranu).
  • Segregacja środowisk: minimalizuj pracę z wrażliwymi sekretami na stacjach z bogatym zestawem rozszerzeń VS Code.

3) Hardening procesowy:

  • Allowlista rozszerzeń i centralna polityka dla VS Code (np. przez Settings Sync for Business, polityki systemowe, MDM). Ogranicz auto-update dla rozszerzeń wysokiego ryzyka lub wymuś update’y z repozytorium wewnętrznego po skanowaniu.
  • Skanowanie rozszerzeń przed dystrybucją (CI) — rozpakowanie .vsix, statyczna analiza node_modules, reguły na anomalie (np. binaria w PNG, obecność cmstp.exe).
  • Program „least extensions”: ogranicz liczbę instalowanych pluginów; weryfikuj reputację wydawcy, historię wersji, liczbę pobrań i recenzje.

4) Kontrole platformowe (dla zespołów platform/devx):

  • Repo lokalne rozszerzeń (mirror/allowlist) zamiast bezpośredniego Marketplace.
  • Sekrety w pakietach: przegląd publikowanych przez organizację rozszerzeń pod kątem wycieków PAT/API i zaciśnięcie polityk TTL dla tokenów (wnioski z badań Wiz).

Różnice / porównania z innymi przypadkami (2025)

  • GlassWorm / WhiteCobra i inne fale — wcześniejsze kampanie celowały w VS Code/Open VSX, dostarczając m.in. infostealery (kradzież ciasteczek, sesji, portfeli). Opisywany dziś przypadek wyróżnia się „fałszywym PNG” i nadużyciem pre-pakowanych zależności w node_modules, zamiast prostego pobrania payloadu po instalacji.
  • „Material Icon Theme” – Rust implants — niedawna analiza Nextron wykazała wykorzystanie implantów Rust i nietypowych kanałów C2 (Solana/Google Calendar). To inna kampania, ale trend wykorzystania Rust + sprytnych nośników się utrzymuje.

Podsumowanie / kluczowe wnioski

  • Atakujący schowali malware w zaufanych nazwach zależności i w „obrazku” PNG, co świetnie wpisuje się w model niskiej widoczności w IDE.
  • Audyt rozszerzeń musi obejmować folder node_modules. Samo zerknięcie w package.json to za mało.
  • Organizacje powinny centralizować kontrolę nad rozszerzeniami, rotować sekrety po incydentach i polować na LOLBiny odpalane przez VS Code.

Źródła / bibliografia

  • ReversingLabs: „VS Code extensions use fake image containing a trojan” (pełne IOC, szczegóły techniczne). (ReversingLabs)
  • BleepingComputer: „Malicious VSCode Marketplace extensions hid trojan in fake PNG file” (daty, usunięcie z Marketplace). (BleepingComputer)
  • The Hacker News: „Researchers Find Malicious VS Code, Go, npm, and Rust Packages…” (szerszy kontekst kradzieży danych przez rozszerzenia/pakiety). (The Hacker News)
  • Wiz Research: „Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces” (ryzyko tokenów wydawców, rekomendacje hardeningu). (wiz.io)
  • Nextron Systems: „Analysis of the Rust implants found in the malicious VS Code extension” (porównawczo: Rust C2/implanty). (nextron-systems.com)

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)

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)

Microsoft łata 57 luk (w tym 3 zero-day). Co wiemy o grudniowym Patch Tuesday 2025?

Wprowadzenie do problemu / definicja luki

Grudniowy Patch Tuesday (9 grudnia 2025) domyka rok paczką poprawek Microsoftu. Firma załatała 57 podatności, w tym trzy zero-day (jedna aktywnie wykorzystywana) — liczby te mogą się minimalnie różnić w zależności od metodologii liczenia poszczególnych serwisów (56–57 CVE). Najpoważniejsza z nich to CVE-2025-62221 w Windows Cloud Files Mini Filter Driver, która umożliwia podniesienie uprawnień do SYSTEM.

W skrócie

  • Liczba poprawek: 57 wg SecurityWeek/BleepingComputer; część analiz operuje liczbą 56 CVE (różnice w wliczaniu komponentów Chromium/Edge/Mariner).
  • Zero-day (3):
    • CVE-2025-62221 – Cloud Files Mini Filter (EoP), aktywnie wykorzystywana.
    • CVE-2025-64671 – GitHub Copilot for JetBrains (RCE), publicznie ujawniona.
    • CVE-2025-54100 – PowerShell (RCE/command injection), publicznie ujawniona.
  • Najwięcej klas: podniesienie uprawnień (EoP) oraz RCE (w tym Office/Outlook).

Kontekst / historia / powiązania

Końcówka 2025 r. stoi pod znakiem licznych EoP po stronie Windows oraz rosnącej liczby błędów w ekosystemie narzędzi AI/IDE (przykład: Copilot dla JetBrains z podatnością na cross-prompt injection prowadzącą do command injection). Trend ten był sygnalizowany w analizach ZDI oraz mediów branżowych przez cały rok.

Analiza techniczna / szczegóły luki

1) CVE-2025-62221 – Windows Cloud Files Mini Filter Driver (EoP)

  • Typ: Use-After-Free w sterowniku mini-filtra Cloud Files.
  • Skutek: lokalne podniesienie uprawnień do SYSTEM; idealny łącznik w łańcuchach RCE→EoP.
  • Status: aktywnie wykorzystywana na wolności; brak szczegółów TTP od Microsoftu.

Dodatkowo Microsoft załatał pokrewne EoP w tym samym komponencie (np. CVE-2025-62454), które są „likely to be exploited”. Wskazuje to na szerszą klasę błędów w Cloud Files.

2) CVE-2025-64671 – GitHub Copilot for JetBrains (RCE)

  • Przyczyna: command injection wyzwalany m.in. przez cross-prompt injection w nieufnych plikach lub serwerach MCP; możliwe do wykorzystania lokalnie, ale realnie z wektorem socjotechnicznym.

3) CVE-2025-54100 – PowerShell (RCE)

  • Przyczyna: nieprawidłowa neutralizacja danych z sieci; Invoke-WebRequest mógł wykonywać skrypt osadzony w pobieranej stronie.
  • Zmiana: dodano ostrzeżenie i rekomendację użycia -UseBasicParsing.

Office/Outlook i inne komponenty

  • Office RCE: m.in. CVE-2025-62554 i CVE-2025-62557 (wektor Preview Pane).
  • Outlook RCE: CVE-2025-62562, w specyficznych warunkach oceniona jako krytyczna.
  • Azure/AMA, RRAS, ReFS: poprawki obejmują też AMA (RCE), RRAS (RCE/Info Disclosure) i ReFS (RCE).

Praktyczne konsekwencje / ryzyko

  • Eskalacja uprawnień (zwłaszcza przez CVE-2025-62221) znacząco obniża barierę przejścia z początkowego footholda (np. makro, złośliwy skrót .LNK, exploit w przeglądarce) do pełnej kompromitacji hosta.
  • Łańcuchy z AI/IDE: błąd w Copilot for JetBrains pokazuje, że prompt injection może być punktem wejścia do command injection w lokalnym środowisku deweloperskim.
  • PowerShell jako narzędzie ofensywne: podatność łączy się z powszechnymi TTP (living-off-the-land), zwiększając ryzyko „cichego” wykonania kodu podczas automatyzacji/parsingu treści web.

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytetyzuj wdrożenie poprawek dla Windows/Office oraz CVE-2025-62221 (Cloud Files), CVE-2025-64671 (Copilot for JetBrains) i CVE-2025-54100 (PowerShell).
  2. Stacje deweloperskie:
    • Wyłącz auto-approve komend w terminalu IDE.
    • Ogranicz zaufanie do plików/serwerów MCP; egzekwuj polityki „trusted workspace”.
  3. PowerShell hardening:
    • Wymuś Constrained Language Mode tam, gdzie to możliwe; monitoruj użycie Invoke-WebRequest i wymagaj -UseBasicParsing.
    • Zbieraj i koreluj logi Script Block/Module Logging.
  4. Higiena Windows:
    • Włącz Attack Surface Reduction (ASR), Credential Guard i bieżące reguły Defendera.
    • Segmentuj uprawnienia administratorów lokalnych, minimalizuj konta z prawami instalacji sterowników/filtrów. (Wnioski zgodne z analizami ZDI/DR dot. przewagi EoP).
  5. Office/Outlook:
    • Ogranicz Preview Pane i zablokuj automatyczne przetwarzanie zawartości zewnętrznej.
    • Wdróż reguły transportowe DLP/AV dla załączników typowych w atakach socjotechnicznych.

Różnice / porównania z innymi przypadkami

  • Rozbieżność 56 vs 57 CVE: Tenable/ZDI wskazują 56 (bez części elementów Chromium/Edge/Mariner), podczas gdy media (SecurityWeek/BleepingComputer/Dark Reading) raportują 57 – to różnica metodologiczna, nie merytoryczna. Ważniejsze są trzy zero-day i ich priorytety.
  • Kontynuacja trendu: podobnie jak w poprzednich miesiącach, dominują EoP i komponenty Office/Outlook; październik/listopad również zawierały głośne luki łączone w łańcuchy ataków.

Podsumowanie / kluczowe wnioski

  • Patch now: załataj CVE-2025-62221 (aktywnie wykorzystywana), CVE-2025-64671 (Copilot/JetBrains) i CVE-2025-54100 (PowerShell).
  • Zadbaj o stacje dev i PowerShell: wyłącz automaty, które mogą „dokleić” komendy; loguj i ograniczaj PowerShell.
  • Traktuj EoP jako „must-fix”: to spoiwo dla większości udanych łańcuchów ataku w Windows w 2025 r.

Źródła / bibliografia

  • SecurityWeek: „Microsoft Patches 57 Vulnerabilities, Three Zero-Days” (09.12.2025). (SecurityWeek)
  • BleepingComputer: „Microsoft December 2025 Patch Tuesday fixes 3 zero-days, 57 flaws” (09.12.2025). (BleepingComputer)
  • Trend Micro ZDI: „The December 2025 Security Update Review” (09.12.2025). (zerodayinitiative.com)
  • Tenable: „Microsoft’s December 2025 Patch Tuesday Addresses 56 CVEs” (09.12.2025). (Tenable®)
  • Dark Reading: „Microsoft Fixes Exploited Zero Day in Light Patch Tuesday” (09.12.2025). (Dark Reading)

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)

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)

Askul wznawia ograniczone przyjmowanie zamówień po ataku ransomware: co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

Japoński detalista i operator platform e-commerce Askul (m.in. Askul, Lohaco, Soloel Arena) 19 października 2025 r. padł ofiarą ataku ransomware, który wywołał szeroką awarię systemów i zatrzymał nowe zamówienia oraz wysyłki. Po ~6 tygodniach przestoju firma wznowiła limitowane przyjmowanie zamówień online, zapowiadając stopniowe przywracanie usług.

W skrócie

  • Data incydentu: 19 października 2025 r. (wykrycie i odcięcie systemów).
  • Skala zakłóceń: wstrzymane zamówienia, anulacje wysyłek, niedostępna obsługa klienta; tymczasowo przyjmowano zamówienia… faksem.
  • Aktualny status: ograniczone wznowienie przyjmowania zamówień online; pełne przywrócenie ma następować stopniowo, Lohaco dla klientów indywidualnych ruszy później.
  • Komunikaty spółki: oficjalne zawiadomienia giełdowe i raporty incydentowe (EN) potwierdzają ransomware i działania naprawcze.

Kontekst / historia / powiązania

Atak na Askul wpisuje się w falę destrukcyjnych kampanii ransomware wymierzonych w duże japońskie firmy w 2025 r. (np. Asahi). W efekcie łańcuchy dostaw i sprzedaż online w Japonii były w ostatnich tygodniach szczególnie podatne na zakłócenia.

Analiza techniczna / szczegóły incydentu

  • Wektor i efekt: w oficjalnych raportach Askul potwierdził infekcję ransomware i odcięcie systemów w celu ograniczenia propagacji. Skutkiem był paraliż zamówień, logistyki i części procesów back-office.
  • Zakres usług: wstrzymane zostały trzy główne serwisy (Askul – B2B, Lohaco – B2C, Soloel Arena – klienci korporacyjni).
  • Odbudowa: po 45 dniach firma zaczęła stopniowo odblokowywać funkcje zakupowe (najpierw B2B), utrzymując ograniczenia asortymentu i przepustowości.

Uwaga: na moment publikacji brak jednoznacznego, oficjalnego wskazania grupy odpowiedzialnej w komunikatach Askul; doniesienia branżowe o potencjalnej afiliacji traktujemy jako niepotwierdzone i dlatego nie opieramy na nich wniosków. (Stan na 4 grudnia 2025 r.)

Praktyczne konsekwencje / ryzyko

  • Operacje i przychody: długi przestój (ponad 6 tygodni) oznacza realne straty sprzedaży i koszty odtworzenia usług, a także ryzyko opóźnień dostaw do partnerów-sprzedawców.
  • Łańcuch dostaw: atak na dostawcę/logistykę uderza w marki zależne od infrastruktury Askul (efekt kaskadowy).
  • Ryzyko wtórne: możliwość wycieku danych i nadużyć (phishing na bazie historii zamówień/zwrotów) – brak jest jednak publicznych potwierdzeń skali wycieku w oficjalnych raportach giełdowych spółki w chwili obecnej.

Rekomendacje operacyjne / co zrobić teraz

Dla firm współpracujących z Askul (sprzedaż/zakupy/logistyka):

  1. Segmentuj ryzyko dostawcy: tymczasowo wprowadź podwójne ścieżki zamówień (drugi operator / manualne obejścia) i limity wolumenów do czasu pełnej stabilizacji.
  2. Weryfikuj komunikację: potwierdzaj zmiany kont płatniczych, terminy dostaw i RMA kanałem niezależnym (voice back).
  3. Monitoruj kompromitację: wdroż brand & supply-chain monitoring (np. wzmianki o Twojej domenie/markach w kampaniach phishing).
  4. Twarde SLA i runbooki: dopisz do umów z dostawcami RTO/RPO, zasady tabletopów i wspólne testy odtwarzania.

Dla zespołów bezpieczeństwa:

  • Segmentacja i „kill switch”: mikrosegmentacja sieci, listy blokad lateral movement (SMB, RDP), oraz gotowy do użycia playbook izolacji.
  • Backupy testowane pod presją czasu: polityka 3-2-1 + testy bare-metal restore i recovery aplikacji z zależnościami (DB, kolejki, pliki).
  • EDR + zasady blokady makr/skryptów: wzmocniona telemetria, kontrola PowerShell/WSH, ASR/WDAC, blokowanie wbudowanych narzędzi (LOLBins).
  • MFA/PAM dla kont serwisowych: rotacja tajemnic i just-in-time access dla adminów oraz integracji B2B.
  • Ćwiczenia z komunikacji kryzysowej: gotowe szablony do klientów/partnerów i spójny kanał statusowy.

Różnice / porównania z innymi przypadkami

  • Askul (handel, platformy e-commerce): silny efekt łańcucha dostaw (partnerzy, marki zależne), długi czas odbudowy funkcji sprzedażowych.
  • Asahi (produkcja FMCG): równoległy trend w Japonii – zakłócenia logistyki i potencjalne naruszenia danych na dużą skalę, ale inna branża i profil systemów OT/ERP. (Kontekst do fali ataków w kraju).

Podsumowanie / kluczowe wnioski

  • Atak ransomware na Askul potwierdza, że dostawcy logistyczno-e-commerce są dziś jednymi z najbardziej krytycznych „punktów nacisku” w łańcuchach dostaw.
  • Czas odtworzenia (RTO) liczony w tygodniach nie jest wyjątkiem – plany ciągłości działania muszą przewidywać manualne obejścia i alternatywnych operatorów.
  • Transparentne raportowanie i stopniowy powrót do pełni usług sugerują, że odporność operacyjna staje się równie ważna jak sama prewencja.

Źródła / bibliografia

  • The Record: wstrzymanie usług po ataku (20.10.2025) oraz wznowienie ograniczonego przyjmowania zamówień (04.12.2025). (The Record from Recorded Future)
  • Oficjalny raport ASKUL do inwestorów (EN), 20.10.2025 (ransomware i działania naprawcze). (Yahoo Finance)
  • The Register: powrót sprzedaży online po 45 dniach od ataku. (The Register)
  • The Japan Times: wznowienie przyjmowania zamówień i kolejność przywracania serwisów (B2B przed B2C/Lohaco). (The Japan Times)