Archiwa: Admin - Strona 20 z 33 - Security Bez Tabu

“Contagious Interview” rozszerza kampanię: 197 złośliwych paczek npm rozprowadza nowy wariant malware OtterCookie

Wprowadzenie do problemu / definicja luki

Zespół Socket Threat Research opisał nową falę kampanii “Contagious Interview” przypisywanej aktorom powiązanym z DPRK. Od 10 października 2025 r. do końca listopada aktorzy wprowadzili co najmniej 197 kolejnych złośliwych paczek npm, zwiększając łączną liczbę pobrań o >31 tys. Najnowszy łańcuch ataku wykorzystuje npm → Vercel → GitHub do dostarczenia świeżego wariantu OtterCookie – narzędzia łączącego funkcje infostealera i RAT z naciskiem na kradzież aktywów krypto oraz danych deweloperów.

MITRE ATT&CK klasyfikuje Contagious Interview (G1052) jako grupę aktywną od 2023 r., celującą w użytkowników Windows, macOS i Linux – szczególnie w deweloperów oraz osoby powiązane z blockchain/Web3.


W skrócie

  • Skala: +197 złośliwych paczek npm w najnowszej fali; co najmniej 15 w momencie publikacji Socket pozostawało dostępnych (zablokowanych następnie przez zespół npm).
  • Łańcuch: paczka npm z backdoorem → Vercel jako stager → kod z GitHub → uruchomienie OtterCookie i zestawienie C2.
  • Zdolności: fingerprinting, unikanie sandboxów/VM, keylogging globalny, screenshoty multi-monitor, kradzież schowka, skanowanie systemu i przeglądarek (Chrome/Brave, rozszerzenia walletów), zdalny shell.
  • TTPs: postinstall + eval odpowiedzi z sieci, typosquatting (np. tailwind-magic jako fork tailwind-merge), socjotechnika „fałszywi rekruterzy” i „zadania testowe”.

Kontekst / historia / powiązania

Kampania Contagious Interview została opisana m.in. przez Unit 42 (Palo Alto Networks) jako scenariusz, w którym napastnicy podszywają się pod rekruterów i przekonują ofiary do uruchomienia złośliwych narzędzi podczas „rozmów kwalifikacyjnych” lub zadań domowych. Wcześniejsze warianty dostarczały BeaverTail (downloader/infostealer) i InvisibleFerret (backdoor).

MITRE ATT&CK formalnie dodało grupę G1052 w październiku 2025 r., dokumentując m.in. wykorzystanie Vercel, GitHub, rejestrów pakietów oraz mechanizmów społecznościowych (LinkedIn itp.).

W styczniu 2025 r. analitycy NTT Security jako jedni z pierwszych nazwali nową rodzinę OtterCookie, opisując jej ewolucję (m.in. użycie Socket.IO do C2, kradzież „seedów” portfeli i zawartości schowka). Dzisiejsza fala na npm to rozwinięcie tej samej linii rozwojowej.


Analiza techniczna / szczegóły luki

Wejście do łańcucha

  • Paczki npm podszywające się pod popularne biblioteki (np. tailwind-magic imitujące tailwind-merge) zawierały postinstall uruchamiający loader. Loader wykonywał żądanie do stagera na Vercel (tetrismic[.]vercel[.]app), a odpowiedź była dynamicznie wykonywana (eval) w procesie Node.js. Repozytoria kodu i lury (np. projekty DEX/DeFi) utrzymywano na koncie stardev0914 na GitHub.

Stager i payload

  • Stager (Vercel) serwował aktualną zawartość pliku main.js w polu JSON (np. model), co pozwalało na rotację ładunków i modyfikację per cel. Drugi etap uruchamiał OtterCookie, który zestawiał kanał C2 i realizował zadania aktora.

Możliwości OtterCookie (najnowszy wariant)

  • Ewazja: detekcja środowisk wirtualnych/sandbox.
  • Rozpoznanie i kontrola: fingerprinting hosta, zdalny shell, długotrwała łączność C2.
  • Eksfiltracja: keylogging, screenshoty z wielu monitorów, kradzież schowka, rekursywne skanowanie systemu, wykradanie danych przeglądarek (Chrome/Brave) i rozszerzeń portfeli na Windows/macOS/Linux.
  • Cel: dokumenty, hasła, seed phrases, dane projektów krypto/Web3.

Techniki ATT&CK (wybrane)

  • T1195.002 (kompromitacja łańcucha dostaw), T1204.005 (złośliwa biblioteka), T1059.007 (JavaScript), T1497 (ewazja sandboxów), T1056.001 (keylogging), T1539/T1555.001 (ciasteczka sesyjne/Keychain), T1585/T1583.006 (tworzenie kont, usługi web).

Praktyczne konsekwencje / ryzyko

  • Zakażenia stanowisk deweloperskich → wyciek kluczy produkcyjnych, tokenów CI/CD, podpisów wydawniczych i seedów portfeli.
  • Ryzyko lateral movement z laptopa dev do środowisk chmurowych i pipelines (kradzież ciasteczek/przeglądarki).
  • Trwałość dzięki rotacji payloadów i rozproszonej infrastrukturze (npm + Vercel + GitHub).

Rekomendacje operacyjne / co zrobić teraz

1) Traktuj każdy npm install jak RCE

  • Odetnij CI/build od sekretów: brak dostępu do kluczy produkcyjnych, walletów, interfejsów admin chmury.
  • Wymuś egress filtering w czasie buildów; blokuj niespodziewane połączenia (np. .vercel.app spoza allowlisty).

2) Kontrola zależności i blokady wersji

  • Pinowanie wersji + lockfile; zakaz auto-aktualizacji „po cichu”.
  • Weryfikuj nowe/mało znane biblioteki, zwłaszcza „utility” plug-iny włączane globalnie.

3) Polityka kodu i przeglądy

  • Review każdego szablonu z GitHub (szczególnie Web3/DeFi).
  • Skanuj pull requesty pod kątem zachowań: import-time loaders, eval na odpowiedzi HTTP, dostęp do schowka/klawiatury. (Zwróć uwagę na znane paczki-przynęty jak tailwind-magic / „node-tailwind”.)

4) Twardnienie stacji dev

  • Odseparowane przeglądarki do pracy z walletami; menedżery haseł i polityka kluczy air-gapped do podpisywania.
  • Wykrywaj niecodzienne zachowania (global keylogging, multi-monitor screenshots, intensywne I/O na profilach przeglądarek).

5) Edukacja i „purple teaming”

  • Szkolenia dot. fałszywych rekruterów i „zadań testowych”.
  • Ćwiczenia ATT&CK dla technik dokumentowanych w G1052 (T1204.005, T1195.002, itd.).

6) Działania detekcyjno-reakcyjne (IoC/TTP-centric)

  • Przegląd instalacji npm z ostatnich 60–90 dni pod kątem postinstall, połączeń do .vercel.app, eval odpowiedzi JSON, artefaktów OtterCookie (np. aktywność Socket.IO, nietypowe procesy z uprawnieniami).
  • Korelacja z wcześniejszymi wariantami (BeaverTail/InvisibleFerret) – te często współwystępują.

Różnice / porównania z innymi przypadkami

  • OtterCookie vs. BeaverTail/InvisibleFerret: nowy wariant scala funkcje – zamiast łańcucha „downloader → backdoor” część zdolności (kradzież schowka/klawiatury, zdalny shell) jest w jednym module, co upraszcza operacje i utrudnia detekcję sygnaturową.
  • Infrastruktura: wyraźne operacjonalizowanie Vercel jako stagera oraz cykliczne odświeżanie payloadu (deploy’e na repo tetrismic). To odróżnia falę z 4Q’25 od wcześniejszych kampanii bazujących głównie na bezpośrednich serwerach C2.
  • Socjotechnika: stały motyw „rekrutacji” i zadań programistycznych – potwierdzony badaniami Unit 42 i ujęty w profilu MITRE G1052.

Podsumowanie / kluczowe wnioski

  • Kampania Contagious Interview pozostaje systematyczną, „fabryczną” operacją kompromitującą łańcuch dostaw JS: npm → Vercel → GitHub.
  • 197 nowych paczek pokazało, że aktor konsekwentnie adaptuje TTPs, konsolidując możliwości w OtterCookie i optymalizując dystrybucję przez stager.
  • Organizacje muszą traktować instalację zależności jak egzekucję kodu obcego i wdrożyć kontrolę egress, pinowanie, review’y behawioralne oraz izolację sekretów.

Źródła / bibliografia

  1. Socket Threat Research – Inside the GitHub Infrastructure Powering North Korea’s Contagious Interview npm Attacks (26 listopada 2025). (Socket)
  2. MITRE ATT&CK – Contagious Interview (G1052) (utw. 19 października 2025; modyf. 24 października 2025). (attack.mitre.org)
  3. Unit 42 (Palo Alto Networks) – Contagious Interview: DPRK Threat Actors Lure Tech Industry Job Seekers… (9 października 2024). (Unit 42)
  4. NTT Security Japan – OtterCookie, new malware used in Contagious Interview campaign (16 stycznia 2025). (jp.security.ntt)
  5. The Hacker News – North Korean Hackers Deploy 197 npm Packages to Spread Updated OtterCookie Malware (28 listopada 2025). (The Hacker News)

Dlaczego Tradycyjny Backup Kapituluje Przed Ransomware 2.0

Czy backup to wystarczająca tarcza przed ransomware?

Jeszcze do niedawna wiele firm spało spokojnie, wierząc, że regularne kopie zapasowe uchronią je przed każdym atakiem. W końcu, jeśli dane zostaną zaszyfrowane, zawsze można je odzyskać z backupu, prawda? Niestety, nowa generacja ransomware – tzw. Ransomware 2.0 – brutalnie weryfikuje to założenie.

Czytaj dalej „Dlaczego Tradycyjny Backup Kapituluje Przed Ransomware 2.0”

OpenAI ujawnia wyciek danych użytkowników API po incydencie u dostawcy Mixpanel — co to oznacza dla zespołów bezpieczeństwa

Wprowadzenie do problemu / definicja luki

OpenAI poinformowało 26 listopada 2025 r., że na skutek incydentu bezpieczeństwa w firmie Mixpanel (dostawca analityki front-end) doszło do wycieku ograniczonych danych identyfikujących część użytkowników OpenAI API. OpenAI podkreśla, że nie był to atak na jej infrastrukturę i nie wyciekły: treści czatów, zapytania API, klucze API, hasła, dane płatnicze ani dokumenty tożsamości. Z integracji Mixpanel zrezygnowano i rozpoczęto notyfikację podmiotów dotkniętych zdarzeniem.

Mixpanel opisał zdarzenie jako skutek kampanii smishingowej z 8 listopada 2025 r., która doprowadziła do nieautoryzowanego eksportu zbiorów danych części klientów. Firma wdrożyła działania IR, m.in. reset haseł pracowników, unieważnienie sesji i rotację poświadczeń.

W skrócie

  • Zdarzenie miało miejsce u Mixpanel, nie w systemach OpenAI.
  • Dotyczy użytkowników platformy API (platform.openai.com), nie zwykłych kont ChatGPT.
  • Potencjalnie ujawnione: imię/nazwa konta, e-mail, przybliżona lokalizacja (miasto/stan/kraj) z przeglądarki, system/PRZEGLĄDARKA, referrery, ID organizacji/użytkownika.
  • Brak ujawnienia haseł, tokenów, kluczy API, treści zapytań/odpowiedzi, danych płatniczych. Brak potrzeby rotacji haseł/kluczy z tego powodu.
  • OpenAI usunęło Mixpanel z produkcji i prowadzi dochodzenie.
  • Media branżowe oraz raporty wskazują, że wyciek mógł dotknąć także innych klientów Mixpanel (np. CoinTracker). To nie jest potwierdzenie ze strony OpenAI, ale koreluje z relacjami użytkowników.

Kontekst / historia / powiązania

Według OpenAI, 9 listopada 2025 r. Mixpanel wykrył nieautoryzowany dostęp i eksport zbioru danych zawierającego ograniczone PII oraz metadane analityczne części klientów. 25 listopada Mixpanel przekazał OpenAI kopię dotkniętych danych, co umożliwiło notyfikacje i ocenę ryzyka. Następnego dnia OpenAI opublikowało komunikat i FAQ.

Równolegle Mixpanel opublikował własny wpis, wskazując na smishing (SMS phishing) jako wektor inicjujący incydent i opisując działania zaradcze (m.in. blokada IP, rejestracja IOC w SIEM, forensics).

Analiza techniczna / szczegóły luki

Wektor ataku: kampania smishingowa wymierzona w pracowników/użytkowników Mixpanel doprowadziła do naruszenia części systemów i eksportu danych customers’ analytics. (To typowy scenariusz „initial access” przez socjotechnikę → eskalacja → eksfiltracja).

Zakres danych: metadane analityczne z warstwy front-end dla kont API, czyli: identyfikatory organizacyjne/użytkownika i podstawowe atrybuty profilu (imię/nazwa, e-mail), informacje o urządzeniu/przeglądarce/OS, referrery i przybliżona geolokalizacja z przeglądarki. Nie obejmuje to treści promptów, usage logs API ani sekretów.

Łańcuch dostawców (vendor risk): incydent ilustruje ekspozycję ryzyka przez integracje telemetryczno-analityczne w produktach SaaS, gdzie dane PII i identyfikatory techniczne są rutynowo przetwarzane przez podmioty trzecie. Niezależne doniesienia branżowe (SecurityWeek, The Register) potwierdzają timeline i działania OpenAI (odpięcie Mixpanel, notyfikacje).

Praktyczne konsekwencje / ryzyko

  • Spear-phishing & impersonation: baza adresów e-mail + atrybuty kont organizacyjnych mogą posłużyć do precyzyjnego podszywania się (np. rzekome „pilne” komunikaty o rotacji kluczy API OpenAI, faktury, „security advisory”).
  • Rekonesans techniczny: informacje o przeglądarce/OS i refererach mogą ułatwić dobór payloadów lub łańcuchów exploitów webowych (fingerprinting).
  • Korelacja tożsamości: powiązanie e-mail ↔ org/user ID ułatwia mapowanie zespołów developerskich w organizacjach.
  • Ryzyko wtórne u innych klientów Mixpanel: jeżeli organizacja używa Mixpanel w wielu produktach, warto zbadać spójność konfiguracji i zasięg danych. Relacje o wpływie na CoinTracker sugerują efekt „multi-tenant blast radius”. (Uwaga: doniesienia zewnętrzne, nie komunikat OpenAI).

Rekomendacje operacyjne / co zrobić teraz

Dla właścicieli kont OpenAI API (org/admin):

  1. Utwierdź MFA/SSO & phishing-resistant MFA (WebAuthn/FIDO2) dla adminów i developerów.
  2. Wdroż policyjne kontrole anty-phishingowe: DMARC p=reject, DKIM, SPF; uzupełnij security banners i URL detonation/sandbox w secure email gateway.
  3. Ustaw reguły detekcji (SIEM/EDR/SOAR): IOC z komunikatu Mixpanel (jeśli udostępnił), alerty na tematy wiadomości: „OpenAI API key rotation”, „Mixpanel incident”, itp. oraz na domeny-lookalike.
  4. Komunikacja do developerów: jasny playbook – nie klikamy linków z e-maili dotyczących OpenAI/kluczy; panel odwiedzamy tylko przez ręczne wejście na platform.openai.com.
  5. Przegląd dostawców (TPRM): skataloguj wszystkie integracje analityczne/telemetryczne (Mixpanel, GA, PostHog itp.), zweryfikuj zakres PII/ID, okres retencji i mechanizmy anonimizacji.
  6. Monitoring nadużyć: szukaj kampanii spear-phishing do aliasów dev/API; rozważ tymczasowe wzmocnienie rate-limitów i kontroli anomalii dla zarządzania kluczami.
  7. Ocena prawna i notyfikacje: jeśli w twojej organizacji wyciekały dane PII użytkowników końcowych przez analogiczne integracje, skonsultuj obowiązki notyfikacyjne (RODO/UK GDPR/CCPA).

Dla zespołów SOC/IR: szybkie „hunt queries” (przykłady):

  • Telemetria poczty: subject contains ("Mixpanel" OR "OpenAI") AND body contains ("security incident" OR "key rotation" OR "API") w ostatnich 14–30 dniach.
  • DNS/Proxy: detekcja nowo zarejestrowanych domen typosquatting dla openai.com, platform.openai.com, mixpanel.com.
  • EDR: nietypowe uruchomienia przeglądarki z parametrami --disable-features=SafeBrowsing, „headless” itp. po kliknięciu w linki.

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

W przeciwieństwie do głośnych wycieków treści czatów lub danych billingowych, tutaj mamy klasyczny „vendor breach” w łańcuchu dostaw: ekspozycja metadanych i PII o niskiej/średniej wrażliwości, ale o dużej wartości do socjotechniki. Schemat przypomina incydenty u zewnętrznych procesorów (MarTech/Analytics), gdzie realne ryzyko wynika z łączności identyfikatorów technicznych z danymi kontaktowymi — paliwo dla spear-phishingu. Relacje branżowe (SecurityWeek, The Register) potwierdzają, że reakcją OpenAI było odpięcie dostawcy i przegląd całego ekosystemu vendors.

Podsumowanie / kluczowe wnioski

  • Najważniejsze ryzyko jest socjotechniczne, nie kryptograficzne: oczekuj falowych kampanii podszywania się pod OpenAI/„Security Team”.
  • Programy TPRM powinny traktować integracje analityczne jako procesory PII i mieć dla nich odrębne oceny ryzyka, retencję i zasady maskowania.
  • OpenAI zareagowało szybko (odpięcie Mixpanel, FAQ, notyfikacje), ale incydent przypomina, że telemetria front-end często niesie więcej PII niż zakładamy.

Źródła / bibliografia

  1. OpenAI — What to know about a recent Mixpanel security incident, 26–27 XI 2025. (OpenAI)
  2. Mixpanel — Our response to a recent security incident, 27 XI 2025. (mixpanel.com)
  3. BleepingComputer — OpenAI discloses API customer data breach via Mixpanel vendor hack, 27 XI 2025. (zawiera też wzmianki o CoinTracker) (BleepingComputer)
  4. SecurityWeek — OpenAI User Data Exposed in Mixpanel Hack, 27 XI 2025. (SecurityWeek)
  5. The Register — OpenAI dumps Mixpanel after analytics breach hits API users, 27 XI 2025. (The Register)

Polska zatrzymała obywatela Rosji podejrzanego o włamania do systemów firm. Co wiemy i jak się zabezpieczyć?

Wprowadzenie do problemu / definicja luki

27 listopada 2025 r. polskie służby zatrzymały w Krakowie obywatela Rosji podejrzanego o nieuprawnioną ingerencję w systemy teleinformatyczne polskich firm, w tym włamania do baz danych (co najmniej jednego sklepu internetowego). Sąd zastosował trzymiesięczny areszt tymczasowy. Sprawa ma charakter rozwojowy i wpisuje się w szerszy wzorzec rosyjskich operacji sabotażowo-szpiegowskich w regionie.

W skrócie

  • Miejsce i data: Kraków, zatrzymanie 16 listopada; publicznie ogłoszone 27 listopada 2025 r.
  • Podejrzenia: przełamywanie zabezpieczeń IT polskich firm i dostęp do baz danych (e-commerce).
  • Status prawny: 3 miesiące aresztu; śledztwo trwa.
  • Wątki poboczne: mężczyzna miał nielegalnie wjechać do Polski w 2022 r., a w 2023 r. uzyskać status uchodźcy (informacje operacyjne służb).
  • Szerszy kontekst: wzrost liczby incydentów sabotażowych i cyberataków powiązanych z Rosją w Polsce i UE.

Kontekst / historia / powiązania

Zatrzymanie nastąpiło równolegle do serii aktów sabotażu i kampanii cyberszpiegowskich w Europie, które władze w Warszawie wiążą z rosyjską „wojną hybrydową”. Premier i resorty siłowe w ostatnich tygodniach alarmują o eskalacji zagrożeń, m.in. po incydentach na infrastrukturze kolejowej. W reakcji państwo wzmacnia ochronę krytycznej infrastruktury i ogłasza inicjatywy techniczne (np. osłona anty-dronowa). Choć sprawa krakowska dotyczy firm prywatnych, narracja służb wskazuje na łączny efekt presji informacyjno-technicznej ze wschodu.

Analiza techniczna / szczegóły luki

Publicznie dostępne informacje są ograniczone — śledczy nie ujawnili TTPs (techniques, tactics and procedures) ani konkretnego wektora wejścia. Wiemy jednak, że mowa o „przełamywaniu zabezpieczeń” i nieuprawnionym dostępie do baz danych firm, w tym e-commerce. Na tym etapie należy rozważyć najbardziej typowe dla branży wektory ataku na aplikacje webowe i sklepy online:

  1. Błędy w warstwie aplikacji (OWASP Top 10):
    • SQLi/NoSQLi prowadzące do zrzutu tabel z danymi klientów, zamówień i tokenów sesyjnych.
    • Insecure Direct Object Reference (IDOR) i błędy uprawnień pozwalające na eskalację dostępu do paneli administracyjnych.
    • Deserializacja / RCE w wtyczkach CMS/commerce.
  2. Ataki na uwierzytelnianie i sesję:
    • Credential stuffing z paczek wyciekłych haseł, słabe MFA lub jego brak.
    • Session fixation / hijacking przy błędnej konfiguracji cookies i SSO.
  3. Łańcuch dostaw i dostęp uprzywilejowany:
    • Kompromitacja kont partnerów (agencje, software-house’y, hosting).
  4. Eksfiltracja:
    • Zrzut baz (logical backup dump), kopiowanie S3/Blob, lub transfer przez kanały C2 w HTTPS/DNS-over-HTTPS.

Podkreślamy: powyższe to uzasadnione scenariusze ryzyka, a nie potwierdzone fakty w tej konkretnej sprawie — organy ścigania nie podały publicznie technicznych detali.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wycieku danych klientów (PII, adresy, telefony, e-maile, skróty haseł) i fraud (przejęcia kont, chargebacki, phishing wtórny).
  • Ryzyko prawne: kary administracyjne (RODO), roszczenia klientów, obowiązki notyfikacyjne do UODO.
  • Ryzyko operacyjne: przestoje sklepów, konieczność rotacji sekretów (API keys, JWT, klucze płatności), audyty powdrożeniowe.
  • Ryzyko reputacyjne i regulacyjne: presja komunikacyjna w kontekście wojny hybrydowej zwiększa koszty incydentu.

Rekomendacje operacyjne / co zrobić teraz

Dla firm e-commerce i dostawców IT:

  1. Twarde minimum techniczne (48–72h):
    • Wymuś MFA wszędzie (panel admin, VPN, Git, helpdesk, CRM).
    • Rotacja haseł/sekretów i unieważnienie wszystkich tokenów sesyjnych.
    • Log review 30–90 dni: nietypowe logowania, masowe odczyty DB, eksporty, anomalia w łańcuchu zapytań (np. długie SELECTy).
    • Blokady WAF/IPS dla wzorców SQLi/XSS/Path Traversal; aktualizacja sygnatur.
    • Egress filtering: blokuj nieznane destynacje i tunelowanie DNS/DoH.
  2. Środki średnioterminowe (2–6 tygodni):
    • Testy penetracyjne i SAST/DAST kluczowych modułów sklepu; przegląd wtyczek CMS (usunięcie porzuconych).
    • Segregacja uprawnień (least privilege) + JIT access dla administracji.
    • Backup & restore drill: test odtwarzania bazy i plików (RPO/RTO realne, nie „na papierze”).
    • Monitoring behawioralny: reguły w SIEM/EDR (np. masowe SELECT, mysqldump/pg_dump, nieplanowane snapshoty).
  3. Procesy i zgodność:
    • Gotowy plan komunikacji kryzysowej (szablony RODO, Q&A dla klientów).
    • Threat intel: subskrypcje wskaźników kompromitacji (IOC) i TTP grup atakujących e-commerce; korelacja z własnymi logami.
  4. Współpraca ze służbami:
    • Incydenty o cechach przestępstwa zgłaszaj do CBZC/Policji i prokuratury; zabezpieczaj dowody (image dysków, chain of custody).

Różnice / porównania z innymi przypadkami

  • Sabotaż infrastrukturalny vs. cyberwłamania do firm: ostatnie głośne sprawy dot. infrastruktury (np. kolej) mają inny profil techniczny i cel (destabilizacja, presja polityczna). W opisywanym przypadku wektor jest „cyber-przestępczy” z możliwymi implikacjami wywiadowczymi, a celem są dane biznesowe i systemy przedsiębiorstw.
  • Transgraniczność: e-commerce i SaaS sprzyjają operacjom prowadzonym z terytorium RP, ale dotykającym firm także poza granicami — media branżowe wspominają o możliwych europejskich wątkach baz danych (na razie bez szczegółów oficjalnych).

Podsumowanie / kluczowe wnioski

  • Sprawa krakowska to konkret: zatrzymany obywatel Rosji, zarzut włamań do systemów firm, areszt na 3 miesiące.
  • Szczegóły techniczne nie zostały ujawnione — firmy nie powinny czekać na komunikaty, tylko samoocenić ekspozycję i wdrożyć środki redukcji ryzyka typowe dla ataków na e-commerce.
  • Zjawisko wpisuje się w szerszą eskalację działań hybrydowych w regionie; oczekujmy większej presji na bezpieczeństwo aplikacji webowych i łańcucha dostaw IT.

Źródła / bibliografia

  • The Record: „Poland detains Russian citizen suspected of hacking local firms” (27 XI 2025). (The Record from Recorded Future)
  • Reuters: „Poland arrests Russian suspected of hacking Polish companies” (27 XI 2025). (Reuters)
  • CyberDefence24: „Ataki na polskie firmy. Rosjanin zatrzymany przez CBZC” (27 XI 2025). (cyberdefence24.pl)
  • Rzeczpospolita: „Rosyjski haker zatrzymany w Krakowie. CBZC: sprawa jest rozwojowa” (27–28 XI 2025). (Rzeczpospolita)
  • Polskie Radio (EN): „Russian national arrested in Kraków over alleged cyberattacks on Polish firms” (27 XI 2025). (Polskie Radio online)

CVE-2019-18935 — Progress Telerik UI for ASP.NET AJAX RCE (RadAsyncUpload / .NET deserialization)

TL;DR

Krytyczna podatność w Telerik UI for ASP.NET AJAX (do 2019.3.1023) pozwala na zdalne wykonanie kodu poprzez niezabezpieczoną deserializację JSON w komponencie RadAsyncUpload, zwykle w kontekście procesu w3wp.exe. Często wymaga znajomości kluczy szyfrujących (np. MachineKey) — możliwych do pozyskania m.in. przez starsze luki CVE‑2017‑11317/11357 — i jest powszechnie wykorzystywana w łańcuchach ataku (CISA KEV). Zalecenie: aktualizacja co najmniej do R1 2020 (2020.1.114), rotacja kluczy, włączenie WAF oraz proaktywna detekcja ruchu do Telerik.Web.UI.WebResource.axd?type=rau i procesów potomnych w3wp.exe.


Krótka definicja techniczna

CVE‑2019‑18935 to luka typu .NET deserialization w RadAsyncUpload (Telerik UI for ASP.NET AJAX), prowadząca do RCE po dostarczeniu specjalnie przygotowanych danych do endpointu m.in. Telerik.Web.UI.WebResource.axd?type=rau. Od wersji 2020.1.114 domyślne ustawienie łagodzi błąd; w 2019.3.1023 istnieje ustawienie niefabryczne ograniczające wektor. Często wykorzystywana łącznie z CVE‑2017‑11317/11357, które ułatwiają pozyskanie kluczy szyfrujących uploadera.


Gdzie występuje / przykłady platform

  • Windows / IIS – typowe środowisko dla aplikacji ASP.NET korzystających z Telerik UI (komponenty front‑end na serwerze).
  • Aplikacje firm trzecich (np. platformy CMS/CRM, jak Sitecore w starszych buildach, które pakowały Telerik UI) – ryzyko pośrednie, gdy komponent jest zależnością.
  • Chmura (IaaS/PaaS) – instancje IIS za ALB/WAF (AWS) lub Application Gateway/WAF (Azure); sama luka jest aplikacyjna, ale ślady widać w dziennikach WAF/ALB.

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

  • Wektor: żądanie HTTP (zwykle POST) do /Telerik.Web.UI.WebResource.axd?type=rau z ładunkiem, który po stronie serwera trafia do deserializacji przez JavaScriptSerializer, umożliwiając wstrzyknięcie obiektu prowadzące do RCE.
  • Warunek sprzyjający: atak jest trivialny, gdy napastnik zna/odzyska klucze szyfrowania uploadera (MachineKey, parametry RadAsyncUpload) — często poprzez wcześniejsze błędy CVE‑2017‑11317/11357 (słaba kryptografia RAU) lub wyciek web.config.
  • Efekt: wykonanie kodu w kontekście IIS Worker Process (w3wp.exe), często skutkujące uruchomieniem cmd.exe/powershell.exe, zrzutem webshella lub ściągnięciem narzędzi.
  • Dlaczego skuteczna:
    1. komponent szeroko rozpowszechniony (często “ukryty” jako zależność),
    2. endpoint RAU bywa rzadko monitorowany,
    3. łatwo ukryć się w normalnym ruchu HTTP(S),
    4. luka jest w KEV, więc aktywnie skanowana/wykorzystywana przez wiele grup.
  • Remediacja producenta: w R1 2020 (2020.1.114) dodano bezpieczne domyślne ustawienia, starsze łatki nie wystarczają — zalecana aktualizacja do ≥ 2020.1.114.

Artefakty i logi

ŹródłoCo szukaćPrzykłady pól / EIDUwaga
IIS W3CŻądania do Telerik.Web.UI.WebResource.axd?type=rau, nietypowe POST z dużym cs-bytes, 4xx/5xx przy próbachcs-uri-stem, cs-uri-query, cs-method, sc-status, time-taken, c-ipACSC wskazuje, że ruch do ...WebResource.axd?type=rau jest wart analizy.
Windows SecurityProcesy potomne w3wp.execmd.exe/powershell.exeEID 4688 (Process Creation)Koreluj z kontem serwisowym aplikacji.
SysmonUtworzenie podejrzanych plików w webroot (np. *.aspx, *.ashx), potomne procesy w3wp.exeEID 1 (ProcessCreate), EID 11 (FileCreate)Szukaj plików w C:\inetpub\wwwroot\ lub App_Data\RadUploadTemp\.
WAF/ALB (AWS)HTTP do ...WebResource.axd z type=rauWAF logs (httpRequest.uri,httpRequest.args)CloudTrail nie loguje treści HTTP — analizuj WAF/ALB.
Azure WAF / AppGWJak wyżejrequestUri_s, requestQuery_s, httpMethod_sWłącz diagnostykę do Log Analytics.
EDR (MDE/Elastic/…)w3wp.exe spawnuje interpreterynazwy procesów, dow. rodz.Wysoka wartość korelacyjna.
K8s audit / M365 UAL / ESXi[nie dotyczy]Aplikacyjna luka .NET na IIS.

Detekcja (praktyczne reguły)

Sigma (IIS – próby RAU)

title: Telerik RAU Endpoint POST Indicative of CVE-2019-18935
id: 7f2a3e27-2e2c-4b8a-9c9f-rau-iis
status: experimental
description: Wykrywa POST na Telerik.Web.UI.WebResource.axd?type=rau (RadAsyncUpload)
references:
  - https://www.cyber.gov.au/.../advisory-2020-004-remote-code-execution...  # ACSC
logsource:
  category: webserver
  product: iis
detection:
  sel_uri:
    cs-uri-stem|contains: 'Telerik.Web.UI.WebResource.axd'
  sel_query:
    cs-uri-query|contains: 'type=rau'
  sel_method:
    cs-method: 'POST'
  condition: sel_uri and sel_query and sel_method
fields:
  - c-ip
  - cs-method
  - cs-uri-stem
  - cs-uri-query
  - sc-status
  - time-taken
falsepositives:
  - Legalny RadAsyncUpload w aplikacjach używających Telerik (zwłaszcza stare wersje)
level: high

Sigma (Windows – potomne procesy w3wp.exe)

title: Suspicious Interpreter Spawned by w3wp.exe
id: e6b6b494-8c6e-4c22-9e63-w3wp-spawn
status: stable
logsource:
  product: windows
  category: process_creation
detection:
  parent:
    ParentImage|endswith: '\w3wp.exe'
  child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\cscript.exe'
      - '\wscript.exe'
  condition: parent and child
fields:
  - UtcTime
  - User
  - CommandLine
  - ParentCommandLine
  - Image
  - ParentImage
level: high

Splunk (SPL)

IIS / WAF – próby RAU:

(index=web OR sourcetype=iis* OR sourcetype="aws:waf" OR sourcetype="azure:appgw")
| eval method=coalesce(cs_method, httpMethod_s, httpRequest.httpMethod, method)
| eval uri_stem=coalesce(cs_uri_stem, uri, requestUri_s, httpRequest.uri)
| eval uri_query=coalesce(cs_uri_query, query, requestQuery_s, httpRequest.args)
| search uri_stem="*Telerik.Web.UI.WebResource.axd*" (uri_query="*type=rau*" OR uri_stem="*DialogHandler.aspx*") method=POST
| stats count min(_time) as first max(_time) as last by method uri_stem uri_query src c_ip httpRequest.clientIp sc_status

Windows Security (4688) – potomne interpretery:

source="WinEventLog:Security" EventCode=4688
ParentProcessName="*\\w3wp.exe"
(NewProcessName="*\\cmd.exe" OR NewProcessName="*\\powershell.exe" OR NewProcessName="*\\mshta.exe" OR NewProcessName="*\\rundll32.exe" OR NewProcessName="*\\cscript.exe" OR NewProcessName="*\\wscript.exe")
| stats count by ComputerName, SubjectUserName, ParentProcessName, NewProcessName, CommandLine, ParentCommandLine

KQL (Defender for Endpoint / Azure)

MDE – procesy potomne:

DeviceProcessEvents
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ ("cmd.exe","powershell.exe","mshta.exe","rundll32.exe","cscript.exe","wscript.exe")
| project Timestamp, DeviceName, InitiatingProcessAccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine

Azure WAF / AppGW (Log Analytics):

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where requestUri_s has "Telerik.Web.UI.WebResource.axd"
| where requestQuery_s has "type=rau" and httpMethod_s == "POST"
| project TimeGenerated, clientIp_s, httpMethod_s, requestUri_s, requestQuery_s, ruleSetType_s, action_s

CloudTrail / CloudWatch (AWS)

Uwaga: CloudTrail nie rejestruje treści HTTP aplikacji. Do detekcji użyj AWS WAF logs (CloudWatch Logs) lub ALB access logs.
CloudWatch Logs Insights (WAF):

fields @timestamp, httpRequest.clientIp, httpRequest.uri, httpRequest.args, httpRequest.httpMethod, action
| filter httpRequest.uri like /Telerik\.Web\.UI\.WebResource\.axd/ 
  and httpRequest.args like /type=rau/ 
  and httpRequest.httpMethod = "POST"
| sort @timestamp desc
| limit 200

Elastic (KQL/EQL)

HTTP (Elastic APM / ingest):

url.path:"/Telerik.Web.UI.WebResource.axd" and url.query:*type\=rau* and http.request.method:POST

EQL – potomne procesy:

process where process.parent.name == "w3wp.exe" and
        process.name in ("cmd.exe","powershell.exe","mshta.exe","rundll32.exe","cscript.exe","wscript.exe")

Heurystyki / korelacje

  • Korelacja 1: IIS RAU POST(±5 min)w3wp.exe -> cmd.exe/powershell.exe(±5 min) ➜ nowe pliki .aspx/.ashx w webroot.
  • Korelacja 2: Ten sam IP źródłowy generuje wiele 4xx/5xx na RAU i inne ścieżki eksploracyjne.
  • Korelacja 3: Nowe połączenia wychodzące z serwera WWW (który normalnie nie inicjuje ruchu) po RAU‑POST.
  • Korelacja 4: RAU‑POST + znany User‑Agent skanera + rzadkie geolokalizacje.
  • Korelacja 5: W środowiskach z WAF – zdarzenia “allowed but matched rule” dla WebResource.axd + POST.

ACSC i CISA opisują użycie CVE‑2019‑18935 w kampaniach, gdzie po eksploatacji dochodziło do dalszych etapów (webshelle, narzędzia).


False positives / tuning

  • FP: legalne użycie RadAsyncUpload w Twojej aplikacji (stary Telerik), testy QA.
  • Tuning:
    • Ogranicz do method=POST + type=rau.
    • Biała lista znanych klientów (adresy IP, CIDR) lub kont użytkowników aplikacji.
    • Podnieś priorytet, gdy sc-status ∈ {500, 400, 404} lub time‑taken & cs-bytes nienaturalnie duże.
    • W procesach – alertuj tylko, gdy rodzicem jest w3wp.exe i dzieckiem interpreter/skryptor.

Playbook reagowania (IR)

  1. Triage i izolacja: odizoluj host IIS z ruchu wychodzącego (segmentacja/egress filter).
  2. Zabezpieczenie dowodów:
    • zrzut pamięci w3wp.exe i kopia logów IIS/WAF/EDR,
    • kopia webroot (hashy) i web.config.
  3. Szybka analiza:
    • wyszukaj artefakty wg sekcji 6 (procesy potomne, nowe pliki w webroot),
    • przejrzyj żądania ...WebResource.axd?type=rau (czas, źródła).
  4. Eradykacja: usuń webshelle, backdoory, zaplanuj aktualizację Telerik ≥ 2020.1.114, rotację MachineKey, wymuś redeploy.
  5. Hunting w domenie: sprawdź lateral movement od konta serwisowego aplikacji.
  6. Hardening:
    • WAF reguły na RAU, blokada publicznego dostępu do uploadów,
    • minimalne uprawnienia konta aplikacyjnego, App_Data bez exec,
    • monitoring w3wp.exe ➜ interpretery.
  7. Zgłoszenie i lessons learned: KEV/CSIRT, aktualizacja runbooków.

Przydatne polecenia (PowerShell, bezpieczne):

# Nowe pliki skryptowe w webroot z ostatnich 7 dni
Get-ChildItem -Recurse "C:\inetpub\wwwroot" -Include *.aspx,*.ashx,*.asmx -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } | Select FullName,Length,LastWriteTime

# Procesy potomne w3wp.exe (MDE lub lokalnie)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 5000 |
  Where-Object { $_.Properties[1].Value -like '*\w3wp.exe' } |
  Select TimeCreated, @{n='NewProcess';e={$_.Properties[5].Value}}, @{n='Cmd';e={$_.Properties[8].Value}}

Przykłady z kampanii / case studies

  • CISA AA23‑074A: aktorzy APT eksploatowali CVE‑2019‑18935 w środowisku rządowym USA (IIS), często łącząc z CVE‑2017‑11317/11357.
  • Blue Mockingbird (Red Canary): w logach IIS widoczny RAU; po eksploatacji uruchamiano cmd.exe/powershell.exe, kończąc na kopaniu kryptowalut.
  • Raporty 2025 (eSentire): luka nadal popularnym wektorem wejścia do dostarczenia reverse shelli i eskalacji uprawnień.
  • ACSC (2020): wskazówki detekcyjne i dowody aktywnej eksploatacji — analiza ruchu do ...WebResource.axd?type=rau.

Lab (bezpieczne testy)

Tylko w odizolowanym środowisku testowym i na załatanych instancjach:

  1. Symulacja hałasu detekcyjnego (IIS/WAF): curl -X POST "https://twoj-serwer.test/Telerik.Web.UI.WebResource.axd?type=rau" \ -H "Content-Type: application/x-www-form-urlencoded" \ --data "probe=1" Sprawdź, czy pipeline logów/warnów (IIS/WAF/SIEM) wyłapuje zdarzenie (bez żadnej próby eksploatacji).
  2. Symulacja anomalii procesów:
    Uruchom prosty skrypt deployu aplikacji, który nie powinien generować w3wp.exe -> cmd.exe. Zweryfikuj, że reguła z 7.2 nie alarmuje (kalibracja FP).
  3. Testy WAF: utwórz regułę blokującą WebResource.axd + type=rau, potwierdź zadziałanie w logach.

Mapowania (Mitigations, Powiązane techniki)

Technika główna: T1190 Exploit Public‑Facing Application (Initial Access).

Powiązane techniki po eksploatacji:

  • T1505.003 – Web Shell (utrwalenie/remote admin przez .aspx).
  • T1059.001 – PowerShell.
  • T1059.003 – Windows Command Shell.
  • T1105 – Ingress Tool Transfer.

Mitigations (ATT&CK):

  • M1051 – Update Software (patchowanie komponentu do ≥ 2020.1.114).
  • M1050 – Exploit Protection (OS mitigation, hardening, DEP/CFG, itd.).
  • M1037 – Filter Network Traffic (WAF; filtrowanie warstwy 7).
  • M1047 – Audit (systematyczny przegląd konfiguracji i logów).

Źródła / dalsza literatura

  • NVD CVE‑2019‑18935 – opis, wersje, noty o ustawieniach w 2019.3.1023/2020.1.114. (NVD)
  • Telerik KBAllows JavaScriptSerializer Deserialization; Unrestricted File Upload (RAU); rekomendacja upgrade do R1 2020. (Telerik.com)
  • CISA AA23‑074A – kampanie wykorzystujące CVE‑2019‑18935 (IIS w agencji FCEB). (CISA)
  • ACSC 2020‑004 – wskazówki detekcyjne dla ...WebResource.axd?type=rau. (Cyber.gov.au)
  • Red Canary (Blue Mockingbird) – wskazówki huntingowe (IIS + potomne procesy). (Red Canary)
  • Bishop Fox – przegląd techniczny deserializacji w Telerik UI. (Bishop Fox)
  • CISA Top Routinely Exploited Vulns / KEV – kontekst operacyjny i priorytetyzacja. (CISA)
  • MITRE ATT&CK v18 – wersjonowanie i matryca Enterprise. (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC:

  • Reguły na WebResource.axd?type=rau + POST w IIS/WAF/ALB.
  • Korelacja: w3wp.exe → interpretery (cmd/PowerShell/mshta/rundll32).
  • Monitoring nowych plików w webroot (rozszerzenia .aspx/.ashx).
  • Blokady WAF + alerty “match but allow” dla RAU.
  • Threat hunting na źródła z KEV i znane UA skanerów.

CISO / właściciel usługi:

  • Upgrade Telerik ≥ 2020.1.114, weryfikacja zależności pośrednich.
  • Rotacja MachineKey i tajemnic aplikacji po incydencie.
  • WAF w trybie blokującym dla uploadów; brak exec w katalogach upload.
  • Minimalne uprawnienia konta aplikacji IIS.
  • Testy regresyjne i skany zewnętrzne po patchu.

ShadowV2: nowy botnet oparty na Mirai „testował” ataki podczas awarii AWS. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Pod koniec października 2025 r., równolegle z szeroką awarią usług AWS w regionie US-EAST-1, laboratoria FortiGuard zaobserwowały aktywność nowego botnetu ShadowV2 – wariantu Mirai ukierunkowanego na IoT (routery, NAS-y, DVR). Kampania wykorzystywała zestaw znanych podatności (n-day) m.in. w urządzeniach D-Link i TP-Link i – co istotne – była aktywna tylko w oknie trwania awarii, co badacze interpretują jako „próbny bieg” przed większymi operacjami.

W skrócie

  • Czym jest ShadowV2? Mirai-like DDoS bot na IoT; identyfikuje się jako „ShadowV2 Build v1.0.0 IoT version”.
  • Jak atakuje? Wektor wejścia przez znane luki (DD-WRT, D-Link, DigiEver, TBK, TP-Link), dropper binary.sh, C2 na silverpath.shadowstresser[.]info/81.88.18[.]108; ataki UDP/TCP/HTTP.
  • Kiedy uderzył? W czasie globalnej awarii AWS 20–21 października 2025 r.; aktywność ograniczona do tego okna.
  • Dlaczego to ważne? Daje sygnał o łączeniu kampanii IoT z trendem DDoS-as-a-Service opisanym wcześniej przez Darktrace (Docker, API, panel operatorski).

Kontekst / historia / powiązania

ShadowV2 pojawił się w badaniach wcześniej jako platforma DDoS-as-a-Service wykorzystująca kontenery Docker i komponenty w Python/Go, łącznie z rozbudowanym API i panelem operatorskim (m.in. mechanizmy HTTP/2 rapid reset, próby obejścia Cloudflare UAM). Ta „chmurowa” gałąź ShadowV2 łączy się teraz z falą infekcji IoT, co sugeruje projekt modułowy i dostosowanie do różnych środowisk (cloud + brzeg/IoT).

Analiza techniczna / szczegóły luki

Wykorzystywane podatności (wybrane):

  • DD-WRT: CVE-2009-2765
  • D-Link: CVE-2020-25506, CVE-2022-37055, CVE-2024-10914 (znana jako wykorzystywana; brak łatek dla modeli EoL), CVE-2024-10915 (D-Link potwierdził brak poprawek dla dotkniętych modeli).
  • DigiEver: CVE-2023-52163
  • TBK: CVE-2024-3721
  • TP-Link: CVE-2024-53375 (naprawiana w wydaniu beta firmware).

Łańcuch infekcji i C2:
Eksploity → downloader binary.sh z 81.88.18[.]108 → pobranie binariów „shadow.*” → konfiguracja XOR (klucz 0x22) z nagłówkami UA i ścieżkami → rozwiązywanie silverpath.shadowstresser[.]info (fallback na IP) → rejestracja w C2 → wykonanie profili ataków UDP/TCP/HTTP (m.in. UDP flood, TCP SYN/ACK STOMP, HTTP flood). Artefakty pokrywają się ze stylem Mirai (LZRD) i potwierdzają orientację na DDoS.

Zasięg i branże:
Telemetria FortiGuard wskazuje na aktywność w 28+ krajach (Ameryki, Europa, Afryka, Azja, Oceania) oraz w co najmniej 7 sektorach: rząd, technologie, wytwórstwo, MSSP, telekomy/carrierzy, edukacja i retail/hospitality.

Praktyczne konsekwencje / ryzyko

  • Ryzyko DDoS na żądanie: ShadowV2 może być wynajmowany do zalewania ruchem aplikacji/serwisów (UDP/TCP/HTTP), co zwiększa presję na warstwy L3–L7.
  • Ekspozycja IoT i EoL: Duża część wektorów dotyczy urządzeń po końcu wsparcia (EoL) – brak łatek = trwała podatność.
  • Okna zdarzeń podczas awarii chmurowych: globalne awarie (jak AWS 20.10.2025) tworzą „szum” operacyjny i zmieniają wzorce ruchu, co atakujący mogą traktować jako maskowanie testów C2/propagacji.
  • Ryzyko mieszane cloud + edge: wcześniejsze kampanie ShadowV2 wobec Docker/EC2 łączą się teraz z IoT – to podnosi powierzchnię ataku po obu stronach łańcucha.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/Blue Team (24–48 h):

  1. Blokady sieciowe/IDS: dodać IoC z raportu Fortinet (domeny/IP C2, wzorce ruchu Mirai), wymusić blokadę rozwiązywania *.shadowstresser[.]info i 81.88.18[.]108.
  2. Polowanie (threat hunting): szukać pobrań binary.sh, anomalii HTTP z podejrzanymi UA oraz ruchu do publicznych DNS z urządzeń brzegowych.
  3. Telemetria warstw L3–L7: monitorować skoki UDP/TCP/HTTP flood i próby HTTP/2 rapid reset (na WAF/ADC).

Dla NetOps/SecOps (7 dni):

  1. Inwentaryzacja IoT/SoHo: zmapować modele D-Link/TP-Link/DVR/NAS; oznaczyć sprzęt EoL; tam gdzie producent nie łata – wymiana lub segregacja sieciowa (VLAN/ACL).
  2. Twardnienie urządzeń: wyłącz UPnP, WAN admin, zmień hasła, aktualizuj firmware (jeśli dostępny), włącz listy dozwolonych adresów dla paneli.
  3. Zasady DDoS-ready: profilowanie ruchu, scrubbing/blackholing u operatora, pre-shared runbook z dostawcą WAF/CDN.
  4. Gotowość na awarie chmurowe: plany degradacji usług (tryb offline), multi-region i fallback DNS; wnioski z awarii AWS (15+ godzin do pełnej odbudowy usług) wdrożyć do planów DR.

Dla chmury/DevOps:

  • Przegląd ekspozycji Docker/EC2: zamknąć otwarte Docker API; egzekwować IAM least privilege; telemetryzować anomalie API (np. docker-sdk-python/*).
  • Chaos engineering & runbooki: ćwiczyć awarie zależności (DynamoDB/DNS) i kolejki backlogów – lekcja z październikowej awarii AWS.

Różnice / porównania z innymi przypadkami

W odróżnieniu od „klasycznych” klonów Mirai, ShadowV2 łączy stare wektory IoT z nowoczesną logistyką operatorską (kontenery, API, panel, techniki L7 jak HTTP/2 rapid reset). To zbliża botnet bardziej do platformy usługowej (DDoS-aaS) niż do prostego robaka IoT.

Podsumowanie / kluczowe wnioski

  • ShadowV2 wykorzystał globalny „szum” awarii AWS jako okazję testową, sondując podatne urządzenia IoT w wielu krajach i sektorach.
  • Trend jest jasny: konwergencja IoT + chmura + DDoS-aaS. Obrona wymaga jednocześnie higieny IoT, twardnienia chmury i gotowości DDoS.
  • Organizacje z urządzeniami EoL muszą liczyć się z trwałą ekspozycją – segmentacja lub wymiana to jedyne skuteczne środki.

Źródła / bibliografia

  1. FortiGuard Labs: szczegółowa analiza ShadowV2 (IoC, CVE, C2, zasięg). (fortinet.com)
  2. BleepingComputer: omówienie kampanii podczas awarii AWS, status poprawek D-Link/TP-Link. (BleepingComputer)
  3. Darktrace (Inside the SOC): tło ShadowV2 jako DDoS-as-a-Service (Docker/EC2, panel, HTTP/2). (Darktrace)
  4. ThousandEyes: analiza awarii AWS 20.10.2025 (przyczyna DNS/DynamoDB, czas trwania, fazy odbudowy). (thousandeyes.com)
  5. Reuters: relacja newsowa z wpływu awarii (skala i usługi dotknięte). (Reuters)

CVE-2025-0108 — PAN‑OS Authentication Bypass

TL;DR

  • Błąd w WebUI PAN‑OS pozwala bez uwierzytelnienia wywołać określone skrypty PHP, jeśli atakujący ma sieciowy dostęp do portu zarządzania (typowo 443/4443). Nie daje sam w sobie RCE, ale narusza poufność/integralność i bywa łańcuszkowany z innymi lukami (np. CVE‑2024‑9474, CVE‑2025‑0111) do pełnego przejęcia.
  • Największe ryzyko: publicznie dostępny interfejs zarządzania lub profil zarządzania na interfejsie dataplane. GlobalProtect portale/bramy nie są podatne (chyba że ma profil zarządzania).
  • Naprawa: aktualizacje do wersji hotfix wymienionych niżej + ograniczenie dostępu IP/segmentacja. Dodatkowo abonenci Threat Prevention mogą blokować próby sygnaturami Threat ID 510000/510001.
  • ATT&CK: T1190 (Exploitation of public‑facing admin UI). Priorytet: krytyczny, jeśli WebUI jest osiągalne z Internetu.

Krótka definicja techniczna

CVE‑2025‑0108 to obejście uwierzytelniania w WebUI PAN‑OS, umożliwiające niezalogowanemu napastnikowi z dostępem sieciowym do WebUI wywołanie wybranych skryptów PHP. Samo wywołanie nie daje RCE, ale może ujawniać/zmieniać informacje, a w praktycznych łańcuchach z CVE‑2024‑9474 (PE/CI) i CVE‑2025‑0111 (file read) prowadzi do eskalacji.


Gdzie występuje / platformy

  • Palo Alto Networks: PA‑Series, VM‑Series, CN‑Series, Panorama — wersje PAN‑OS wymienione jako podatne; Cloud NGFW i Prisma Accessniepodatne.
  • Środowiska uruchomieniowe: sprzęt on‑prem, ESXi/KVM/Hyper‑V (VM‑Series), chmury AWS/Azure/GCP (VM‑Series).
  • Usługi powiązane: GlobalProtect portale/gateways nie są podatne, ale profil zarządzania na takim interfejsie naraża urządzenie (często port 4443).

Szczegółowy opis techniki (jak działa i dlaczego skuteczna)

Atakujący wysyła specjalnie ułożone żądania HTTP/S do publicznie osiągalnego WebUI PAN‑OS. Błąd w ścieżce uwierzytelniania pozwala ominąć kontrolę logowania i wołać część skryptów PHP zaplecza WebUI. Choć producent podkreśla, że samo to nie daje RCE, realnie umożliwia pozyskanie wrażliwych informacji lub zmianę stanu (konf./sesje), co w połączeniu z innymi błędami (np. CVE‑2024‑9474, CVE‑2025‑0111) bywa wykorzystywane do pełnego przejęcia administracyjnego. Lukę uznano za atakowaną (observed exploit attempts) i wpisano do CISA KEV. Skuteczność wynika z: (1) powszechności błędnych ekspozycji WebUI, (2) niska złożoność i brak wymagań uprawnień/UI, (3) możliwość łańcuchowania.

Wersje/fixy (skrót):

  • 10.1: podatne < 10.1.14‑h9; naprawa ≥ 10.1.14‑h9
  • 10.2: podatne niższe niż 10.2.7‑h24 / 10.2.8‑h21 / 10.2.9‑h21 / 10.2.10‑h14 / 10.2.11‑h12 / 10.2.12‑h6 / 10.2.13‑h3; naprawy ≥ tych wersji
  • 11.1: podatne < 11.1.2‑h18 / < 11.1.4‑h13 / < 11.1.6‑h1; naprawy ≥ tych wersji
  • 11.2: podatne < 11.2.4‑h4 / < 11.2.5; naprawy ≥ 11.2.4‑h4 / 11.2.5
  • EoL (11.0/10.0/9.x): domyślnie uważane za podatne, bez planu poprawek.

Artefakty i logi

ŹródłoTyp/ZdarzenieNajważniejsze polaWskazówki / przykład
PAN‑OS Threat logsBlokady sygnatur Threat ID 510000/510001threat_id/threatid, threat_name, action, src, dst, urlDetekcja prób CVE‑2025‑0108 (wymaga subskrypcji Threat Prevention).
PAN‑OS Traffic logsPołączenia do WebUI (443/4443)dst_port, app (ssl/web-browsing), rule, src, dstRuch z niezaufanych ASN/IP do IP zarządzania; brak reguły NAT/SNAT dla mgmt.
PAN‑OS System/Config logsNieoczekiwane zmiany/akcje w WebUItype=SYSTEM/CONFIG, admin, client, cmd, resultZmiany konfiguracyjne z nietypowych adresów źródłowych po ruchu na 4443.
Cortex Data Lake / CEFZnormalizowane pola CEF (CommonSecurityLog)DeviceVendor="Palo Alto Networks", DeviceProduct="PAN-OS", DeviceEventClassIDW Sentinel KQL filtrujemy DeviceProduct has 'PAN-OS'.
CloudTrail (meta‑kontrola)Zmiany SG/VPC odsłaniające 443/4443AuthorizeSecurityGroupIngress, RevokeSecurityGroupIngressWykrywanie ekspozycji WebUI dla VM‑Series w AWS.
K8s audit / M365 / Windows EIDNie dotyczy tej luki (brak lokalnych EID/M365/K8s).

Detekcja (praktyczne reguły)

Sigma — próby CVE‑2025‑0108 (Threat Prevention lub ślady WebUI)

title: PAN-OS WebUI Auth Bypass Attempt (CVE-2025-0108)
id: 0a0d2c8b-3c7a-4d0e-9a7e-0d9b5b7f0108
status: experimental
description: Wykrywa próby obejścia uwierzytelniania WebUI PAN-OS (CVE-2025-0108) na podstawie sygnatur TP lub nietypowych wywołań WebUI.
references:
  - https://security.paloaltonetworks.com/CVE-2025-0108
logsource:
  category: firewall
  product: paloalto
detection:
  tp_ids:
    threat_id|contains:
      - '510000'
      - '510001'
    action|contains:
      - 'block'
      - 'reset'
  webui_suspicious:
    dst_port|in: [443, 4443]
    app|contains:
      - 'ssl'
      - 'web-browsing'
    url|endswith: '.php'
    user|isempty: true
  condition: tp_ids OR webui_suspicious
falsepositives:
  - Skanery podatności/monitoring pochodzące z dozwolonych adresów
level: high
tags:
  - attack.t1190
  - cve.2025-0108

Uwaga: dopasuj nazwy pól do Twojego parsera (np. threatid/threat_id, url, dstport). Sygnatury 510000/510001 wg advisora producenta.

Splunk (SPL)

A) Trafienia sygnatur 510000/510001 (pan:threat)

index=pan_logs sourcetype=pan:threat
| search threatid IN (510000, 510001)
| stats count min(_time) as firstSeen max(_time) as lastSeen values(src_ip) values(dst_ip) by threatid, threat, action

(„threatid”/„threat” mogą się różnić w zależności od Add‑on; sprawdź normalizację pól).

B) Dostępy do WebUI z Internetu (pan:traffic)

index=pan_logs sourcetype=pan:traffic (dest_port=443 OR dest_port=4443)
| eval isPublic=if(cidrmatch("0.0.0.0/0", src_ip) AND NOT
    (cidrmatch("10.0.0.0/8", src_ip) OR cidrmatch("172.16.0.0/12", src_ip) OR cidrmatch("192.168.0.0/16", src_ip)), 1, 0)
| where isPublic=1
| stats dc(src_ip) as uniqIPs values(app) values(rule) by dest_ip, dest_port

C) Korelacja: po ruchu na WebUI następuje Config change

(index=pan_logs sourcetype=pan:traffic (dest_port=443 OR dest_port=4443) src_ip!=10.0.0.0/8)
| bin _time span=5m
| stats values(src_ip) as srcs values(dest_ip) as mgmtIPs by _time
| join _time [ search index=pan_logs sourcetype=pan:config result="Succeeded"
              | stats values(admin) as admins values(client) as clients by _time ]
| table _time mgmtIPs srcs admins clients

Microsoft Sentinel / KQL (CommonSecurityLog)

A) Sygnatury TP (CEF)

CommonSecurityLog
| where DeviceVendor =~ "Palo Alto Networks" and DeviceProduct has "PAN-OS"
| where DeviceEventClassID =~ "threat"
| extend kv = parse_kv(AdditionalExtensions, ";", "=")
| where tostring(kv.threatid) in ("510000","510001") or tostring(kv.ThreatID) in ("510000","510001")
| summarize count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by SourceIP, DestinationIP, tostring(kv.threat_name)

B) Dostęp do WebUI z niezaufanych adresów

CommonSecurityLog
| where DeviceVendor =~ "Palo Alto Networks" and DeviceProduct has "PAN-OS"
| where DestinationPort in ("443","4443") and ApplicationProtocol in ("ssl","http","https")
| where not(ipv4_is_private(SourceIP))
| summarize dcount(SourceIP), make_set(SourceIP, 5) by DestinationIP, DestinationPort

AWS (CloudTrail/CLI/Flow Logs)

A) Zmiany SG otwierające WebUI na świat (CloudTrail)

AWSCloudTrail
| where EventName in ("AuthorizeSecurityGroupIngress","ModifyNetworkInterfaceAttribute")
| extend open443 = tostring(parse_json(RequestParameters).ipPermissions) has "fromPort\":443"
| extend open4443 = tostring(parse_json(RequestParameters).ipPermissions) has "fromPort\":4443"
| where open443 or open4443
| where tostring(parse_json(RequestParameters).ipPermissions) has "0.0.0.0/0"

B) Szybki audyt CLI (EC2 SG)

aws ec2 describe-security-groups \
  --query "SecurityGroups[?IpPermissions[?((FromPort==443||FromPort==4443)&&contains(IpRanges[].CidrIp, '0.0.0.0/0'))]].{GroupId:GroupId,Name:GroupName}" \
  --output table

C) VPC Flow Logs (CloudWatch Logs Insights) – ruch do 4443

fields @timestamp, srcAddr, dstAddr, dstPort, action
| filter dstPort in [443,4443] and action="ACCEPT"
| sort @timestamp desc
| limit 100

Elastic (EQL / KQL)

EQL – ruch do WebUI z Internetu + ślady PHP w URL

any where observer.vendor == "Palo Alto Networks" and
          event.dataset in ("panw.traffic","panw.threat") and
          destination.port in (443, 4443) and
          (url.path regex ".*\\.php(\\?|$)") and
          not cidrmatch(source.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")

Heurystyki / korelacje

  • Łańcuch czasowy (T1190 → konfiguracja): (1) wzrost 4xx/5xx/nieudanych prób na WebUI → (2) trafienia sygnatur 510000/510001 → (3) Config/System z nietypowych IP → (4) nowe sesje admina/zmiany polityk.
  • Ekspozycja → atak: zdarzenia CloudTrail/SG otwierające 443/4443 dla 0.0.0.0/0 w VPC z VM‑Series + ruch do WebUI + zmiany w PAN‑OS.
  • Łańcuch z innymi CVE: obserwuj następujące wzorce po nieudanym logowaniu: wywołania prowadzące do PE/CI (CVE‑2024‑9474) i file read (CVE‑2025‑0111).

False positives / tuning

  • Skanery podatności / monitoring (np. z adresów skanerów wewnętrznych).
  • Automaty / API do kopii konfiguracji działające z uprzywilejowanych podsieci.
  • CDN/Proxy: pole XFF może maskować źródło — uwzględnij parsowanie XFF.
    Tuning: biała lista skanerów; zawężenie do dest_ip = znane IP zarządzania; korelacja z action != allow lub z sygnaturami TP.

Playbook reagowania (IR)

  1. Izoluj ekspozycję: natychmiast zablokuj dostęp do WebUI z Internetu (ACL/SG/WAF), ogranicz do jump‑boxa/VPN i adresów zaufanych.
  2. Zastosuj poprawki: podnieś PAN‑OS do wersji:
    • 10.1 ≥ 10.1.14‑h9; 10.2 : 10.2.7‑h24 / 10.2.8‑h21 / 10.2.9‑h21 / 10.2.10‑h14 / 10.2.11‑h12 / 10.2.12‑h6 / 10.2.13‑h3; 11.1 : 11.1.2‑h18 / 11.1.4‑h13 / 11.1.6‑h1; 11.2 ≥ 11.2.4‑h4/11.2.5.
  3. Włącz sygnatury: Threat Prevention 510000/510001 (Apps & Threats ≥ 8943). Zweryfikuj trafienia.
  4. Przegląd logów:
    • Threat/Traffic: próby na 443/4443, hosty źródłowe, geolokacja.
    • System/Config: nietypowe admin / client, zmiany reguł, importy konfiguracji.
  5. Hunting łańcucha: wyszukaj wskaźniki wykorzystania CVE‑2024‑9474/CVE‑2025‑0111 po czasie prób CVE‑2025‑0108.
  6. Twarde utwardzanie: odseparuj zarządzanie (VLAN/VRF/DMZ), wymuś MFA dla adminów, wyłącz HTTP, zostaw tylko HTTPS z certyfikatem i restrykcjami IP.
  7. Rotacja poświadczeń / przegląd kont: zmień hasła lokalnych adminów, sprawdź nieznane konta.
  8. Lessons learned: dodaj kontrolę CI/CD zmian SG, testy ekspozycji mgmt (IaC policy), dashboardy SOC.

Wybrane komendy PAN‑OS (CLI) – diagnostyka/bezpieczne

Uruchamiaj w oknie serwisowym, po kopii configu.

show system info
show admins
show config running | match management
show session all filter dst port 4443
show log system direction equal backward query '( subtype eq general )'
show log config direction equal backward

Przykłady z kampanii / case studies

  • Producent: „Palo Alto Networks zaobserwował próby łańcuchowania CVE‑2025‑0108 z CVE‑2024‑9474 i CVE‑2025‑0111 na niezałatanych i źle zabezpieczonych WebUI.”
  • KEV: wpis CISA KEV z datą dodania 2025‑02‑18 potwierdza eksploatację w praktyce.
  • Niezależne analizy: raporty Armis/FortiGuard omawiają aktywne wykorzystanie i łańcuszkowanie.

Lab (bezpieczne testy)

Cel: zweryfikować detekcję i twarde zasady bez ujawniania szczegółów exploitu. Wykonuj w odseparowanym labie.

  1. Topologia: VM‑Series (lab), jump‑host (allowlist), maszyna „Internet” (deny).
  2. Ekspozycja kontrolowana: tymczasowo otwórz 4443 tylko dla jump‑host; potwierdź, że „Internet” jest blokowany.
  3. Generacja ruchu: z „Internet” wyślij neutralne żądania HTTPS do WebUI (np. curl -k https://FW:4443/) i obserwuj logi Traffic/Threat.
  4. Sygnatury: zaktualizuj Applications and Threats do wersji ≥ 8943 i zweryfikuj, że blokady 510000/510001 pojawiają się przy próbach wzorcowych (narzędzie skanujące w labie).
  5. Kwerendy: uruchom reguły SPL/KQL/EQL z pkt 7 i sprawdź alarmy.

(Nie wykonujemy czynności ukierunkowanych na obejście zabezpieczeń ani odtwarzania łańcucha exploitu.)


Mapowania (Mitigations, powiązane techniki)

  • ATT&CK Technika: T1190 Exploit Public‑Facing Application (Initial Access).
  • Mitigations (ATT&CK):
    • M1030 Network Segmentation – izoluj płaszczyznę zarządzania; dostęp tylko z jump‑boxa.
    • M1031 Network Intrusion Prevention – stosuj IPS/WAF do ruchu do WebUI; sygnatury TP 510000/510001.
    • M1050 Exploit Protection – „virtual patching”, blokady behawioralne; polityki hardeningu.
  • Powiązane CVE/techniki do korelacji: CVE‑2024‑9474 (eskalacja/CI), CVE‑2025‑0111 (file read) — korelować jako etap po T1190.

Źródła / dalsza literatura

  • Palo Alto Networks — oficjalny advisory CVE‑2025‑0108 (wersje, sygnatury, status exploitation, mitigation). (Palo Alto Networks Security)
  • NVD CVE‑2025‑0108 — CVSS v3.1=9.1, wpis KEV (data/due date). (NVD)
  • MITRE ATT&CK T1190 (wersja 2.8; modyfikacja 2025‑10‑24). (MITRE ATT&CK)
  • ATT&CK Version History — aktualna wersja v18.1 (od 2025‑10‑28). (MITRE ATT&CK)
  • Armis — łańcuch wykorzystania 0108+9474+0111. (Armis)
  • FortiGuard Labs — aktywna eksploatacja. (FortiGuard)
  • Microsoft — CommonSecurityLog / KQL dla Palo Alto (CEF). (Microsoft Learn)
  • PAN‑OS log fields (Traffic/Threat/System) — dokumentacja. (docs.paloaltonetworks.com)

Checklisty dla SOC / CISO

SOC – dziś

  • Czy żaden WebUI PAN‑OS nie jest dostępny z Internetu? (skan + SG/ACL)
  • Czy mamy aktualizację do naprawionych wersji (patrz lista)?
  • Czy Threat Prevention włączony + sygnatury 510000/510001 działają?
  • Czy działają alerty T1190: ruch na 443/4443 do IP zarządzania, zdarzenia Threat/Config?
  • Korelacja z CVE‑2024‑9474 / CVE‑2025‑0111 po czasie prób.

CISO – w tym kwartale

  • Segmentacja płaszczyzny zarządzania (M1030) i MFA dla adminów.
  • Policy as Code: bloker IaC zmian SG/VPC otwierających 443/4443.
  • Przegląd EoL PAN‑OS (9.x/10.0/11.0) i plan migracji.
  • Testy scenariuszy T1190 w purple‑team (bez exploitu produkcyjnego).