Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 416 z 487

Autor: Wojciech Ciemski

Krytyczna podatność w Apache Tika prowadzi do XXE — co trzeba załatać już dziś (CVE-2025-66516)

Wprowadzenie do problemu / definicja luki

W Apache Tika ujawniono krytyczną podatność XXE (XML External Entity Injection) oznaczoną jako CVE-2025-66516 i ocenioną na CVSS 10.0. Błąd umożliwia atakującemu wstrzyknięcie zewnętrznych encji XML poprzez spreparowany plik PDF zawierający XFA, co może prowadzić do odczytu wrażliwych plików, SSRF, a nawet Denial-of-Service. Luka dotyczy kluczowych modułów Tiki i została skorygowana w najnowszych wydaniach projektu.

W skrócie

  • CVE-2025-66516 (CVSS 10.0) — XXE w Tice wyzwalane przez PDF z XFA.
  • Dotyczy m.in.: tika-core (1.13–3.2.1), tika-pdf-module (2.0.0–3.2.1), tika-parsers (1.13–1.28.5).
  • Źródło problemu leży w tika-core; samo podniesienie wersji parsera PDF nie wystarczało. Naprawa wymaga aktualizacji tika-core ≥ 3.2.2.
  • Luka rozszerza wcześniejsze CVE-2025-54988 – obecny wpis obejmuje więcej pakietów/gałęzi 1.x.

Kontekst / historia / powiązania

W sierpniu 2025 r. Apache Tika załatała XXE w module tika-parser-pdf-module (CVE-2025-54988). Późniejsza analiza wykazała jednak, że wektor wejścia był w PDF-parserze, lecz istotą podatności był kod w tika-core. Stąd drugi wpis CVE-2025-66516, który poszerza zakres dotkniętych pakietów, w tym gałąź 1.x (gdzie PDFParser znajdował się w „tika-parsers”). To wyjaśnia przypadki, w których organizacje zaktualizowały sam PDF-parser, a i tak pozostały podatne.

Analiza techniczna / szczegóły luki

Podatność polega na niewłaściwym przetwarzaniu zewnętrznych encji XML podczas analizy PDF-ów zawierających formularze XFA. W praktyce napastnik może osadzić w PDF odwołania do file://, http(s):// czy innych schematów, zmuszając Tikę do:

  • odczytu lokalnych plików i ich ujawnienia (np. /etc/passwd, klucze, tokeny),
  • wykonywania żądań SSRF do zasobów wewnętrznych (np. metadane chmury, serwisy admin),
  • potencjalnego przepełnienia zasobów (DoS) poprzez ekspansję encji.
    Dotknięte zakresy wersji wskazane są dla tika-core 1.13–3.2.1, tika-pdf-module 2.0.0–3.2.1 oraz tika-parsers 1.13–1.28.5. Naprawa wymaga aktualizacji tika-core; sama aktualizacja parsera PDF nie usuwała ryzyka.

Praktyczne konsekwencje / ryzyko

Apache Tika jest powszechnie wbudowana w systemy wyszukiwania, DMS/ECM, pipeline’y ETL, antywirusy, serwisy e-discovery i platformy bezpieczeństwa. W środowiskach, gdzie Tika parsuje niezweryfikowane dokumenty (np. uploady użytkowników, skrzynki pocztowe, roboty indeksujące), XXE może skutkować:

  • wyciekiem danych z hosta analizującego,
  • SSRF do sieci wewnętrznej/chmury,
  • eskalacją na łańcuchach (np. pobranie kluczy, które umożliwią dalszy ruch boczny),
  • a w określonych konfiguracjach — RCE (gdy łańcuchy XXE/SSRF dotykają usług wykonujących polecenia).

Rekomendacje operacyjne / co zrobić teraz

  1. Pilna aktualizacja pakietów Tiki
    • Zaktualizuj do wydań naprawczych, w szczególności tika-core ≥ 3.2.2, oraz powiązane moduły (tika-pdf-module, tika-parsers). Jeśli używasz metapakietów (np. tika-server-standard, tika-app), upewnij się, że transitively podnoszą tika-core.
  2. Twardnienie środowiska analizy plików
    • Sandbox (konteneryzacja, seccomp, AppArmor/SELinux) dla procesu parsowania.
    • Blokada egress: ogranicz ruch wychodzący z hostów parsujących (eliminuje SSRF exfil).
    • Mounty „read-only” i brak dostępu do sekretów (klucze, tokeny) dla kontenerów Tiki.
  3. Konfiguracja parsera PDF / XML
    • Jeżeli to możliwe, wyłącz rozwiązywanie zewnętrznych encji XML dla ścieżek, gdzie Tika jest używana (np. przez odpowiednie fabryki parserów XML/bezpieczne funkcje w JVM), do czasu pełnej aktualizacji. (Wskazówka ogólna przy XXE).
  4. Weryfikacja łańcucha zależności
    • Przejrzyj SBOM/aplikacje korzystające z Tiki (w tym aplikacje serwerowe: tika-server-standard, tika-grpc, tika-app oraz paczki „standard-modules/package”). Upewnij się, że wszystkie zależności podbiły tika-core.
  5. Monitoring i detekcja
    • Szukaj nietypowych wywołań file:///http:// w logach Tiki, błędów parsera PDF, anomalii sieci wychodzącej z hostów analizy.
    • Rozważ reguły detekcyjne dla wzorców XXE/SSRF w ruchu wychodzącym. (Dobre praktyki wg opracowań branżowych).

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

  • CVE-2025-54988 (sierpień 2025) opisano pierwotnie jako XXE w tika-parser-pdf-module. Obecny wpis CVE-2025-66516 koryguje i rozszerza zakres: problem faktycznie tkwił w tika-core, a dodatkowo wskazano dotknięte gałęzie 1.x. Dlatego część środowisk po wcześniejszej „łatce” nadal była podatna.

Podsumowanie / kluczowe wnioski

  • To krytyczna XXE (CVSS 10.0) w powszechnie wykorzystywanym komponencie — Tika.
  • Aktualizacja tika-core jest obowiązkowa; sama podmiana PDF-parsera nie wystarcza.
  • Środowiska parsujące niezaufane dokumenty są szczególnie narażone — wdrażaj sandbox, blokadę egress i monitoring.
  • Sprawdź cały łańcuch zależności (serwery Tiki, metapakiety), aby uniknąć „fałszywego poczucia bezpieczeństwa” po częściowych aktualizacjach.

Źródła / bibliografia

  • SecurityWeek: „Critical Apache Tika Vulnerability Leads to XXE Injection” (08.12.2025). (SecurityWeek)
  • CVE Program (cve.org): CVE-2025-66516 — rozszerzenie zakresu wobec CVE-2025-54988. (CVE)
  • GitHub Advisory: „Apache Tika has XXE vulnerability — CVE-2025-66516” (zakres wersji i wymóg tika-core ≥ 3.2.2). (GitHub)
  • CSO Online: przegląd i kontekst „patch widziany jako niepełny” (grudzień 2025). (CSO Online)
  • Belgian CCB Advisory: implikacje dla metapakietów (tika-server-standard, tika-app, itp.) i rozszerzenie wobec CVE-2025-54988. (CCB Safeonweb)

Tri-Century Eye Care: wyciek danych po ataku ransomware dotknął ~200 tys. osób

Wprowadzenie do problemu / definicja luki

Tri-Century Eye Care (kliniki okulistyczne w hrabstwie Bucks, Pensylwania) ujawniło incydent bezpieczeństwa będący skutkiem ataku ransomware przypisywanego grupie PEAR. Według rejestru naruszeń HHS/OCR skala zdarzenia szacowana jest na około 200 000 osób (pacjentów i pracowników). Doniesienia o ataku potwierdzają, że sprawcy twierdzą, iż wykradli wieloterabajtowy zbiór plików.

W skrócie

  • Skala: ok. 200 tys. rekordów PHI/PII.
  • Typ zdarzenia: atak ransomware + kradzież danych (tzw. double extortion).
  • Sprawcy: grupa PEAR (deklaracja na stronach śledzących wycieki).
  • Oficjalny status: spółka opublikowała stronę „Notice of Data Security Incident” i wysyła zawiadomienia.
  • Zakres danych: potencjalnie PII/PHI pacjentów i pracowników (m.in. SSN, dane kontaktowe, informacje ubezpieczeniowe – według komunikatów branżowych i kancelarii).

Kontekst / historia / powiązania

Sektor ochrony zdrowia w USA pozostaje jednym z najczęściej atakowanych – motywacją jest wysoka wartość danych medycznych i presja dostępności usług. Incydent w Tri-Century wpisuje się w trwającą od miesięcy serię ataków na placówki medyczne i dostawców usług medycznych. W tym przypadku do zdarzenia doszło jesienią 2025 r., a SecurityWeek powiązał wyciek z roszczeniami grupy PEAR o „>3 TB” skradzionych danych.

Analiza techniczna / szczegóły luki

Tri-Century nie udostępniło publicznie szczegółów wektora wejścia ani wykorzystanych luk, potwierdziło jednak zdarzenie i dystrybucję listów z zaleceniami ochrony tożsamości (kontakt do biur kredytowych, monitoring). Zbieżnie, opisy incydentu w specjalistycznych serwisach i alertach prawnych wskazują na klasyczny schemat ransomware z eksfiltacją: przejęcie środowiska, kradzież danych, szyfrowanie/zagrożenie publikacją. Atrybucja do PEAR pojawia się w materiałach branżowych (Paubox) oraz w agregatorach aktywności grup ransomware (ransomware.live).

Co mogło zostać naruszone (na podstawie typowych wzorców w ochronie zdrowia i komunikatów):

  • Dane identyfikacyjne (imię, nazwisko, adres, data urodzenia),
  • SSN oraz informacje dot. zatrudnienia (dla pracowników),
  • Dane ubezpieczeniowe i elementy PHI (np. identyfikatory pacjenta, informacje rozliczeniowe).

Uwaga: precyzyjny katalog pól dla każdej osoby może różnić się w zależności od rekordu; oficjalna strona Tri-Century kieruje odbiorców do bezpośrednich zaleceń i kontaktów z biurami kredytowymi.

Praktyczne konsekwencje / ryzyko

  • Ryzyko kradzieży tożsamości i fraudu finansowego – dane PII/SSN ułatwiają otwieranie kont, wnioskowanie o kredyt, składanie fałszywych roszczeń ubezpieczeniowych.
  • Phishing i vishing medyczny – personalizowane oszustwa podszywające się pod klinikę, ubezpieczyciela czy laboratorium. (Wzorzec znany z wcześniejszych incydentów w sektorze zdrowia.)
  • Ryzyko wtórnych włamań – ponowne wykorzystanie danych do resetów haseł i przejęć kont.

Rekomendacje operacyjne / co zrobić teraz

Dla pacjentów i pracowników:

  1. Skorzystaj z oferowanego monitoringu tożsamości (jeśli zapewniono) i zamrożenia kredytu (credit freeze) w biurach Equifax, Experian, TransUnion.
  2. Włącz alerty kontowe, obserwuj wyciągi bankowe/ubezpieczeniowe; natychmiast reklamuj nieautoryzowane transakcje.
  3. Uważaj na kontakt „z kliniki/ubezpieczyciela” – weryfikuj kanałem oficjalnym; nie podawaj kodów ani danych logowania.

Dla zespołów IT/bezpieczeństwa w placówkach medycznych (lekcja z incydentu):

  • E-mail i zdalny dostęp: bezwzględne MFA (fob/biometryczne), zakaz SMS OTP w dostępie uprzywilejowanym; rotacja i ograniczanie dostępu do portalów zdalnych.
  • Segmentacja i EDR/XDR: mikrosegmentacja systemów rejestracyjnych/EHR, automatyczne izolowanie hostów z anomaliami (behavioral ransomware detection).
  • Backup i tabletopy: niezmienialne kopie (immutability, WORM) + ćwiczenia odtwarzania usług krytycznych (rejestracja, płatności, e-prescriptions).
  • DLP i egress control: reguły blokujące masowe transfery z serwerów dokumentowych/plików obrazowych (PACS), monitorowanie SFTP/HTTP(S).
  • Logistyka powiadomień: gotowe szablony HIPAA/HITECH + linie wsparcia dla pacjentów.

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

Na tle głośnych incydentów 2024–2025 (np. Change Healthcare – >100 mln osób) skala Tri-Century jest mniejsza, ale profil danych (PHI + SSN) czyni ryzyko jednostkowo wysokim. Wspólny mianownik: eksfiltacja + presja publikacji jako dominujący model przestępczy.

Podsumowanie / kluczowe wnioski

  • Atak na Tri-Century Eye Care to kolejny przykład presji ransomware na sektor ochrony zdrowia: kradzież danych + szantaż.
  • Szacunek ~200 tys. osób wynika z rejestru HHS i bieżących publikacji branżowych.
  • Priorytety: ochrona tożsamości poszkodowanych oraz wzmocnienie kontroli dostępu, segmentacji i detekcji eksfiltracji.

Źródła / bibliografia

  • SecurityWeek: „Tri-Century Eye Care Data Breach Impacts 200,000 Individuals”. (SecurityWeek)
  • Tri-Century Eye Care – „Notice of Data Security Incident” (strona informacyjna dla poszkodowanych). (Tri-Century Eye Care)
  • HHS/OCR – rejestr naruszeń (breach portal). (OCR Portal)
  • Paubox (Healthcare security): opis ataku PEAR na Tri-Century. (Paubox)
  • ransomware.live: wpis o przypisaniu ataku grupie PEAR. (Ransomware.live)

Android: nowe malware FvncBot i SeedSnatcher oraz zmodernizowany ClayRat — jak kradną dane i omijają zabezpieczenia

Wprowadzenie do problemu / definicja

Badacze opisali dwie nowe rodziny złośliwego oprogramowania na Androida — FvncBot (trojan bankowy) i SeedSnatcher (stealer fraz seed do portfeli krypto) — oraz zaktualizowany wariant spyware ClayRat o znacznie rozszerzonych możliwościach. FvncBot podszywa się pod aplikację bezpieczeństwa mBanku i celuje w użytkowników w Polsce; SeedSnatcher kradnie frazy mnemoniczne i OTP/2FA; ClayRat dodaje nadużycia usług ułatwień dostępu, nagrywanie ekranu i fałszywe powiadomienia. Wszystkie trzy intensywnie nadużywają Android Accessibility Services, nakładek (overlays), MediaProjection i/lub roli domyślnej aplikacji SMS.

W skrócie

  • FvncBot: świeży kod (nie klon ERMAC-a), loader przebrany za „aplikację bezpieczeństwa mBanku”, funkcje: HVNC, keylogging z Accessibility, web-injecty, streaming ekranu; cel: użytkownicy bankowości w PL. Zaobserwowany identyfikator buildu call_pl wskazuje na Polskę.
  • SeedSnatcher: dystrybuowany jako „Coin” przez Telegram, kradnie frazy seed (BIP-39) do wielu popularnych portfeli (np. Trust Wallet, MetaMask), przechwytuje SMS/OTP, używa integer-based C2 (2000–2400) i dynamicznego ładowania klas/Dex.
  • ClayRat (nowy wariant): dodaje Accessibility + MediaProjection, automatyczne odblokowywanie ekranu (PIN/hasło/wzór), fałszywe interaktywne notyfikacje, trwałe nakładki i utrudnianie wyłączenia/odinstalowania; dystrybuowany m.in. przez phishingowe domeny podszywające się pod YouTube i lokalne aplikacje.

Kontekst / historia / powiązania

Informacje pochodzą z niezależnych raportów zespołów Intel 471 (FvncBot, 4 grudnia 2025), CYFIRMA (SeedSnatcher, 3 grudnia 2025) i Zimperium zLabs (ClayRat, 4 grudnia 2025). Syntetyczne omówienie pojawiło się 8 grudnia 2025 w The Hacker News. Zbieżność osi czasu wskazuje na rozwój ekosystemu mobilnych grup przestępczych aktywnie adaptujących techniki omijania polityk uprawnień Androida 13+.

Analiza techniczna / szczegóły

FvncBot (banking trojan)

  • Impersonacja mBanku: aplikacja-loader podszywa się pod „aplikację bezpieczeństwa mBanku”. Po uruchomieniu prosi o „komponent Google Play” i wykorzystuje podejście sesyjne do obejścia ograniczeń Accessibility na Androidzie 13+.
  • Komunikacja i identyfikacja celu: logowanie zdarzeń do serwera C2, konfiguracja z identyfikatorem call_pl i wersją 1.0-P, co sugeruje wczesny etap i target Polska.
  • Zdolności: HVNC (ukryte VNC), MediaProjection do streamingu ekranu, keylogging z Accessibility, overlays / web-injecty, zrzut listy aplikacji i informacji o urządzeniu, sterowanie gestami przez WebSocket. FCM służy do odbioru komend.

SeedSnatcher (crypto stealer)

  • Dystrybucja: APK o nazwie „Coin”, promowany w kanałach Telegram; pakiet m.in. com.pureabuladon.auxes.
  • Evasja i C2: dynamic class loading (fake_dex → real payload), WebView content injection, integer-based C2 (kody 2000–2400), WebSocket keep-alive do hosta C2.
  • Kradzież portfeli: mapowanie template ID → konkretny portfel (np. Trust Wallet, MetaMask, OKX itd.), prezentacja fałszywych ekranów importu; walidacja słów wg BIP-39 by wymusić poprawną frazę; dodatkowo przechwyt SMS/OTP/2FA, exfiltracja kontaktów, plików, dzienników połączeń.

ClayRat (spyware — nowa wersja)

  • Nowe możliwości: pełne nadużycie Accessibility Services (m.in. keylogger PIN/hasła/wzoru i auto-unlock), MediaProjection do streamingu ekranu, nakładki (czarna, „aktualizacja systemu”, PIN overlay), fałszywe interaktywne powiadomienia i zbieranie treści powiadomień. Po uzyskaniu roli domyślnej aplikacji SMS malware dodatkowo przejmuje korespondencję.
  • Dystrybucja: setki unikalnych APK, >25 domen phishingowych (m.in. podszycia pod YouTube), obserwowane także pliki hostowane w Dropboxie.

Praktyczne konsekwencje / ryzyko

  • Bankowość mobilna w Polsce: FvncBot jest wyspecjalizowany w polskim języku/ekosystemie — wzrasta ryzyko fraudów w bankowości i BLIK.
  • Kryptoaktywa: SeedSnatcher celuje w frazy seed — pojedyncza pomyłka ofiary oznacza pełny takeover portfela.
  • Uprawnienia krytyczne: rola Accessibility i Default SMS oraz MediaProjection tworzą wektor na pełne przejęcie urządzenia i potajemną egfiltrację.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i działów IT (MDM/MTD):

  1. Zakaz sideloadingu i instalacji z linków SMS/IM; zezwalaj tylko na Google Play/zaufany MDM Store.
  2. Blokuj nadawanie ról Accessibility/Default SMS aplikacjom spoza allowlisty (polityki MDM, Managed Configs).
  3. Wykrywaj nadużycia MediaProjection/overlay (MTD/EDR mobilny) i monitoruj żądania uprawnień SYSTEM_ALERT_WINDOW, PACKAGE_USAGE_STATS, BIND_ACCESSIBILITY_SERVICE.
  4. Hardening bankowo-krypto: U2F/FIDO2 zamiast SMS OTP; hardware keys dla kont giełdowych; w portfelach — seed offline, brak importu przez telefon.
  5. Detekcja IOCs i zachowań: reguły dla komunikacji WebSocket do nietypowych domen, wzorce HVNC, wycieki eventów Accessibility.
  6. Reagowanie: jeżeli wykryto podejrzane uprawnienia/overlays — tryb samolotowy, kopia dowodowa, następnie factory reset + re-enrollment MDM; rotacja haseł/kluczy i przemapowanie portfeli z nową frazą seed (stare uznać za skompromitowane).

Dla banków i fintechów:

  • Attestation + anti-overlay w aplikacji, wykrywanie FLAG_SECURE bypass / screen-recordingu / Accessibility; dynamiczne risk-based auth i web-inject detection po stronie serwera. (Mechanizmy omijania FLAG_SECURE i MediaProjection wskazano w opisie FvncBota i ClayRat).

Różnice / porównania

  • FvncBot vs. klasyczne trojany bankowe (np. ERMAC): FvncBot jest pisany od zera i integruje HVNC + streaming ekranu oraz FCM jako kanał komend — to zbliża go do pełnej zdalnej obsługi urządzenia, a nie tylko overlay-phishingu.
  • SeedSnatcher vs. info-stealery: unikalne walidowanie BIP-39 i mapowanie UI portfeli zwiększają skuteczność kradzieży seedów.
  • ClayRat vs. stalkerware: nowy wariant łączy Default SMS + Accessibility + MediaProjection i notyfikacje interaktywne, co utrudnia wykrycie i odinstalowanie — „żyje” jak pełnoprawny RAT na Androidzie.

Podsumowanie / kluczowe wnioski

  • Polska jest celem co najmniej jednej z nowych kampanii (FvncBot), więc organizacje w PL powinny pilnie podnieść polityki MDM/MTD i świadomość użytkowników.
  • Techniki nadużycia uprawnień (Accessibility, MediaProjection, Default SMS, overlays) pozostają najskuteczniejsze na Androidzie — konieczne są zarówno kontrole użytkownika, jak i detekcja behawioralna.
  • Krypto-użytkownicy: nigdy nie wpisuj frazy seed w mobilnym „importerze” uruchomionym z linku; traktuj każdy import na telefonie jako potencjalny kompromis.

Źródła / bibliografia

  1. The Hacker News — „Android Malware FvncBot, SeedSnatcher, and ClayRat Gain Stronger Data Theft Features”, 8 grudnia 2025. (The Hacker News)
  2. Intel 471 — „New FvncBot Android banking trojan targets Poland”, 4 grudnia 2025. (Intel 471)
  3. CYFIRMA — „SEEDSNATCHER: Dissecting an Android Malware Targeting Multiple Crypto Wallet Mnemonic Phrases”, 3 grudnia 2025. (CYFIRMA)
  4. Zimperium zLabs — „Return of ClayRat: Expanded Features and Techniques”, 4 grudnia 2025. (Zimperium)

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)

Ponad 2 mld dol. okupu w 3 lata: co naprawdę pokazuje nowy raport FinCEN o ransomware (2022–2024)

Wprowadzenie do problemu / definicja luki

Amerykańska jednostka Financial Crimes Enforcement Network (FinCEN) opublikowała świeżą Financial Trend Analysis dotyczącą ransomware za lata 2022–2024. Z danych wynika, że w tym okresie odnotowano 7 395 raportów BSA dotyczących 4 194 incydentów, a łączna wartość opłaconych okupów przekroczyła 2,1 mld USD. Rok 2023 był rekordowy – ok. 1,1 mld USD płatności i 1 512 incydentów – po czym w 2024 r. nastąpił spadek zarówno liczby zgłoszeń (1 476), jak i wartości płatności (ok. 734 mln USD).

W skrócie

  • $2,1 mld w okupach w latach 2022–2024 (BSA/SAR). Rekord w 2023 r. (ok. $1,1 mld), spadek w 2024 r. do ok. $734 mln.
  • Bitcoin dominuje jako metoda płatności (~97% transakcji); Monero pojawia się marginalnie.
  • Najbardziej dotknięte branże (kwotowo i liczbowo): finanse, produkcja, ochrona zdrowia.
  • Najczęściej raportowane warianty: Akira, ALPHV/BlackCat, LockBit, Phobos, Black Basta; najwyższa skumulowana kwota po stronie ALPHV/BlackCat.
  • Spadek w 2024 r. FinCEN łączy z głośnymi operacjami organów ścigania przeciw ALPHV/BlackCat (XII 2023) i LockBit (II 2024).

Kontekst / historia / powiązania

FinCEN podkreśla, że trzy ostatnie lata niemal dorównały dziewięciu poprzednim (2013–2021) pod względem łącznej wartości okupów: $2,1 mld vs. ~$2,4 mld. To obrazuje skalę profesjonalizacji ekosystemu RaaS (ransomware-as-a-service). Jednocześnie w 2024 r. widoczny jest efekt presji organów ścigania – m.in. operacja DOJ/FBI przeciw ALPHV/BlackCat oraz międzynarodowa operacja „Cronos” przeciw LockBit.

Analiza techniczna / szczegóły raportu

Metodologia. FinCEN przeanalizował raporty BSA/SAR złożone między 1.01.2022 a 1.02.2025, obejmujące incydenty mające miejsce 1.01.2022–31.12.2024. Zestaw danych: 7 395 raportów, 4 194 incydenty. Statystyki dotyczą rzeczywistych lub próbnych transakcji związanych z ransomware.

Wartości i mediany. Mediana pojedynczej płatności: $124 097 (2022), $175 000 (2023), $155 257 (2024); najczęściej spotykany przedział < $250 000.

Łańcuch płatności. Bitcoin (BTC) odpowiada za ~97% zgłoszonych transakcji; Monero (XMR) w ~2%. Z perspektywy AML oznacza to, że monitoring przepływów BTC nadal daje szansę na identyfikację przepływów okupu i powiązanych typologii prania.

Komunikacja przestępców. W ~42% zgłoszeń opisano kanały kontaktu; z nich 67% to TOR, 28% – e-mail.

Branże najbardziej dotknięte. Liczbowo: produkcja (456), finanse (432), zdrowie (389), retail (337), usługi prawne (334). Kwotowo (łączna wartość): finanse (~$365,6 mln), ochrona zdrowia (~$305,4 mln), produkcja (~$284,6 mln), nauka i technologia (~$186,7 mln), retail (~$181,3 mln).

Warianty i wpływ. FinCEN identyfikuje 267 wariantów; ALPHV/BlackCat odpowiada za najwyższą łączną wartość (ok. $395,3 mln), za to Akira ma najwięcej incydentów (376). LockBit pojawia się równorzędnie z ALPHV pod względem liczby zgłoszeń (353).

Praktyczne konsekwencje / ryzyko

  • Ryzyko systemowe dla podmiotów regulowanych: sektor finansowy nie tylko jest ofiarą, ale i węzłem wykrywania przepływów (raportowanie BSA/SAR). Zmiany wzorców (np. wzrost mediany 2023) wymagają aktualizacji progów detekcji i scenariuszy AML.
  • Sektor zdrowotny i produkcyjny pozostają krytycznie narażone – wpływ na bezpieczeństwo pacjentów oraz łańcuchy dostaw.
  • Ekspozycja na BTC: dominacja jednego aktywa upraszcza analizę łańcucha, ale wymusza dojrzałą analizę blockchain (identyfikacja mixów, mostów, usług cash-out).
  • Efekt egzekwowania prawa działa, ale bywa krótkotrwały – po operacjach z XII 2023 i II 2024 część aktywności się odbudowuje (migracje afiliantów, renaming grup). Wnioski FinCEN wskazują na spadek 2024 r., jednak nie gwarantuje to trwałego trendu.

Rekomendacje operacyjne / co zrobić teraz

  1. Procedury płatności i „no-pay by default”. Ustanów politykę zarządu: brak płatności bez formalnej oceny prawnej, ryzyka sankcyjnego, ryzyka wtórnego i konsultacji z organami ścigania.
  2. Playbook IR z TOR/e-mail. Biorąc pod uwagę dominację TOR i e-mail, zaktualizuj runbooki: separacja sieciowa hostów negocjacyjnych, bezpieczne łączność, clean-room do obsługi kluczy.
  3. Telemetria kryptopłatności. Włącz on-chain analytics do detekcji adresów o wysokim ryzyku, typologii prania (peel chains, cross-chain bridges, CEX/KYC-weak off-ramps). Priorytet: BTC.
  4. Priorytety branżowe. Jeśli działasz w finansach, produkcji, zdrowiu – podnieś progi gotowości, testy odtwarzania kopii offline, segmentację i EDR z naciskiem na living-off-the-land oraz MFA-fatigue.
  5. Hunting po wariantach. Dodaj detekcje TTP dla Akira, ALPHV/BlackCat, LockBit, Black Basta (np. szyfrowanie masowe, exfil przy użyciu Rclone/MEGA, shadow copy deletion, ruch do C2 przez TOR).
  6. Ćwiczenia kryzysowe. Scenariusz 72 h: e-skrzynka kontaktowa atakujących, presja na „deadline”, równoległa publikacja na leak site.

Różnice / porównania z innymi przypadkami

  • Skala 3-letnia vs 9-letnia. 2022–2024 (3 lata) niemal dorównują wartością okupów 2013–2021 (9 lat) – to bezprecedensowe przyspieszenie monetyzacji.
  • Wpływ egzekucji prawa. FinCEN łączy spadek 2024 r. z działaniami przeciw ALPHV i LockBit – to rzadki przypadek, gdy operacje służb przekładają się na mierzalny spadek płatności rok-do-roku.

Podsumowanie / kluczowe wnioski

  • Trwała profesjonalizacja ekosystemu RaaS – pomimo uderzeń służb, wolumen i wartości w 2022–2024 są ogromne.
  • BTC pozostaje „krwiobiegiem” ransomware – to szansa dla analityki finansowej i AML.
  • Spadek 2024 r. to sygnał, nie gwarancja trendu – konieczny jest stały nacisk na TTP, detekcję on-chain i koordynację z organami ścigania.

Źródła / bibliografia

  1. FinCEN – Financial Trend Analysis: Ransomware Trends in BSA Data (2022–2024), 4 grudnia 2025 (PDF). (FinCEN.gov)
  2. FinCEN – komunikat prasowy dot. raportu FTA (4 grudnia 2025). (FinCEN.gov)
  3. The Record / Recorded Future News – artykuł podsumowujący wnioski FinCEN. (The Record from Recorded Future)
  4. U.S. DOJ – komunikat o disruption gangu ALPHV/BlackCat (19 grudnia 2023). (Department of Justice)
  5. U.S. DOJ – komunikat o disruption gangu LockBit / Operation Cronos (20 lutego 2024) oraz NCA. (Department of Justice)

React2Shell: krytyczna luka RCE w React Server Components (CVE-2025-55182) oraz duplikat w Next.js (CVE-2025-66478)

Wprowadzenie do problemu / definicja luki

3 grudnia 2025 r. zespół React ujawnił krytyczną podatność typu pre-auth RCE w protokole Flight dla React Server Components (RSC), śledzoną jako CVE-2025-55182 (CVSS 10.0). Dotyczy ona pakietu react-server i implementacji RSC w wersjach React 19.0–19.2.0 oraz bibliotekach react-server-dom-* (webpack/parcel/turbopack). Równolegle Next.js opublikował własne ogłoszenie (CVE-2025-66478), które następnie zostało odrzucone jako duplikat CVE-2025-55182.

W skrócie

  • Co to jest? Błąd nieserializowania bezpiecznego (unsafe deserialization) w obsłudze żądań Flight dla RSC prowadzący do zdalnego wykonania kodu bez uwierzytelnienia.
  • Kogo dotyczy? React 19 (pakiety react-server-dom-* w wersjach 19.0/19.1.0/19.1.1/19.2.0) oraz frameworki korzystające z RSC, m.in. Next.js 15.x/16.x (App Router).
  • Status Next.js: CVE-2025-66478 → duplikat CVE-2025-55182.
  • Wykryte nadużycia: CISA dodała CVE-2025-55182 do katalogu KEV (Known Exploited Vulnerabilities); Unit 42 opisuje realne działania poeksploatacyjne (skanowanie, web-shelle, kryptokoparki, próby Cobalt Strike).
  • Naprawa: aktualizacja do React 19.0.1 / 19.1.2 / 19.2.1 oraz do bieżących wersji Next.js z poprawkami.

Kontekst / historia / powiązania

Reakcja społeczności była natychmiastowa: oprócz oficjalnych biuletynów React i Next.js, w krótkim czasie pojawiły się alerty CISA oraz vendorów bezpieczeństwa. Vercel wydał podsumowanie i narzędzie ułatwiające podbicie projektów Next.js do wersji łatających błąd. 6 grudnia Vercel opublikował wpis z instrukcją i narzędziem npx fix-react2shell-next do automatycznej aktualizacji zależności w aplikacjach Next.js. 8 grudnia Unit 42 zaktualizowało swój raport, potwierdzając obserwacje działań atakujących.

Analiza techniczna / szczegóły luki

Rdzeń problemu: parser/warstwa deserializacji w RSC Flight akceptuje złośliwe, specjalnie spreparowane ładunki HTTP kierowane do Server Functions, co pozwala wpływać na logikę wykonania po stronie serwera i osiągnąć RCE. Co istotne, domyślna konfiguracja popularnych szablonów (np. świeżo utworzonego Next.js) była podatna bez modyfikacji kodu.

Zakres wersji:

  • React / RSC: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack w wersjach 19.0.0 / 19.1.0 / 19.1.1 / 19.2.0.
  • Next.js: głównie gałęzie 15.x i 16.x (App Router) oraz wybrane wydania canary od 14.3.0; projektowe domyślne wdrożenia były atakowalne.

Dlaczego to groźne dla „niewykorzystujących” Server Functions? Nawet jeśli aplikacja nie definiuje własnych endpointów Server Functions, obsługa RSC może być włączona „po drodze”, co utrzymuje powierzchnię ataku.

Praktyczne konsekwencje / ryzyko

  • Łatwość ataku: brak uwierzytelnienia, niski poziom złożoności, wysoka niezawodność exploita; podatność w konfiguracji domyślnej.
  • Skala: React/Next.js mają ogromny udział w rynku — CISA oznaczyła CVE jako znaną, wykorzystywaną; Unit 42 raportuje już poeksploatacyjne działania napastników (skrypty Bash, web-shelle, kryptokoparki, próby wdrożenia Cobalt Strike i aktywność IAB).
  • Potencjalny wpływ: przejęcie procesu serwerowego (Node.js), kradzież tajemnic (klucze, zmienne środowiskowe), pivot w sieci, trwale osadzone backdoory i dalsze kampanie (np. cryptojacking).

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja (patch now):
    • React: do 19.0.1 / 19.1.2 / 19.2.1 (lub nowszych).
    • Next.js: do najnowszych wersji z poprawką; w projektach Next.js skorzystaj z narzędzia npx fix-react2shell-next (Vercel).
  2. Przegląd zależności: wymuś podbicie react, react-dom, react-server, react-server-dom-*, a w Next.js — aktualny next oraz bundlery (Turbopack/Webpack) w zgodnych wersjach. (Weryfikuj lockfile.)
  3. Twarde ograniczenia sieciowe: izoluj serwery renderujące (SSR/RSC), kontroluj wychodzące połączenia z Node.js (blokuj „curl/wget do Internetu”, egres tylko do potrzebnych usług). Obserwuj anomalie DNS/HTTP. (Wnioski z TTP napastników).
  4. Detekcja IOC/TTP: szukaj poleceń Base64 z potokami | base64 -d | sh, skryptów typu sex.sh, podejrzanych web-shelli „React File Manager”, prób pobrania C2, śladów Cobalt Strike/Mirai/NOODLERAT.
  5. Higiena sekretów: rotuj klucze/tokenty środowiskowe (CI/CD, .env), sprawdź uprawnienia ról w chmurze — traktuj serwer jako potencjalnie skompromitowany, jeśli był podatny i publicznie dostępny w okresie 3–8 grudnia 2025 r. (po ujawnieniu).
  6. Twardnienie buildów: włącz ograniczenia --frozen-lockfile, SCA w CI, testy E2E po aktualizacji; rozważ WAF z regułami blokującymi sekwencje Flight/RSC nietypowe dla twojej aplikacji. (Dodatkowe wskazówki społeczności).

Różnice / porównania z innymi przypadkami

  • Wzorzec błędu: klasyczne unsafe deserialization znane z ekosystemów Java/.NET teraz uderza w RSC/Node.js — wektor to niestandardowy protokół (Flight) i domyślna obsługa w popularnych frameworkach.
  • CVE w Next.js: początkowo wydzielone jako CVE-2025-66478, lecz scalone do Reactowego CVE-2025-55182 — z punktu widzenia ryzyka operacyjnego to jedna podatność w warstwie RSC.

Podsumowanie / kluczowe wnioski

  • To najpoważniejsza luka w ekosystemie React/Next.js od lat: CVSS 10.0, pre-auth RCE, domyślne konfiguracje atakowalne. Aktualizacje są dostępne — wdrażaj natychmiast.
  • Dowody nadużyć już istnieją (CISA KEV, telemetryczne obserwacje Unit 42). Reaguj jak na incydent: patch + poszukiwanie TTP/IOC + rotacja sekretów.

Źródła / bibliografia

  • React — Critical Security Vulnerability in React Server Components (03.12.2025). (React)
  • Next.js — Security Advisory: CVE-2025-66478 (06.12.2025). (Next.js)
  • NVD — CVE-2025-55182 (ostatnia aktualizacja ~3 dni temu). (nvd.nist.gov)
  • CISA — dodanie CVE-2025-55182 do KEV (05.12.2025). (CISA)
  • Unit 42 (Palo Alto Networks) — Exploitation of Critical Vulnerability in React Server Components (akt. 08.12.2025) — obserwacje skanowania i działań poeksploatacyjnych. (Unit 42)

Portugalia tworzy „safe harbor” dla badaczy bezpieczeństwa. Nowe wyjątki w prawie o cyberprzestępczości

Wprowadzenie do problemu / definicja luki

Portugalia zaktualizowała ustawę o cyberprzestępczości (Lei n.º 109/2009), dodając nowy art. 8.º-A: „Akty niepodlegające karze ze względu na interes publiczny w cyberbezpieczeństwie”. Przepis wprowadza prawny „safe harbor” dla badań bezpieczeństwa w dobrej wierze, ograniczając ryzyko karne dla researcherów działających proporcjonalnie i w interesie publicznym. Zmiana została przyjęta w Dekrecie-Ustawie nr 125/2025, który jednocześnie transponuje dyrektywę NIS2 i wchodzi w życie po 120 dniach od publikacji.

W skrócie

  • Co się zmienia? Działania, które normalnie podpadałyby pod „nieuprawniony dostęp” lub „nielegalną intercepcję”, mogą być niekaralne, jeśli spełnione są surowe warunki „good-faith research”.
  • Warunki kluczowe: cel publiczny (ujawnienie i poprawa bezpieczeństwa), brak korzyści majątkowej, niezwłoczne zgłoszenie luki właścicielowi/administratorowi i autorytetowi ds. cyberbezpieczeństwa, działania ściśle proporcjonalne, zakaz DoS, socjotechniki, phishingu, instalacji malware itd.
  • Kiedy prawo zacznie obowiązywać? 120 dni po publikacji (tj. 3 kwietnia 2026 r.).

Kontekst / historia / powiązania

Zmiana jest częścią szerszej reformy wdrażającej NIS2: Dekret-Ustawa 125/2025 ustanawia nowy reżim cyberbezpieczeństwa, rozszerza zakres podmiotowy i kompetencje CNCS (narodowego centrum cyberbezpieczeństwa), a także modyfikuje m.in. prawo o łączności elektronicznej i bezpieczeństwie wewnętrznym. W tym pakiecie rząd po raz drugi nowelizuje ustawę o cyberprzestępczości (109/2009), dodając wspomniany art. 8.º-A. Informację o „safe harbor” nagłośniły media branżowe.

Analiza techniczna / szczegóły luki

Nowy art. 8.º-A precyzuje, kiedy badania bezpieczeństwa nie są karalne (streszczenie najważniejszych punktów):

  1. Cel i intencja – jedynym celem jest identyfikacja podatności w systemach/produktach/usługach IT w celu zwiększenia bezpieczeństwa (m.in. poprzez odpowiedzialne ujawnienie).
  2. Brak korzyści ekonomicznej – badacz nie działa w celu uzyskania zysku ani obietnicy zysku (poza wynagrodzeniem z tytułu zwykłej działalności zawodowej).
  3. Obowiązek niezwłocznego powiadomienia – po odkryciu luki należy natychmiast poinformować właściciela/administratora systemu lub usługodawcę oraz krajową władzę ds. cyberbezpieczeństwa; ta ostatnia kieruje sprawę do Polícia Judiciária (policji sądowej), jeśli zachodzi istotność karna. Należy też przestrzegać RODO/GDPR przy przetwarzaniu danych.
  4. Proporcjonalność i minimalizacja szkód – działania ogranicza się do tego, co niezbędne do identyfikacji luki; zakazane są w szczególności:
    • DoS/DDoS,
    • socjotechnika i wprowadzanie w błąd użytkowników/administratorów,
    • phishing,
    • kradzież haseł lub innych danych wrażliwych,
    • usuwanie/zmiana danych,
    • wyrządzanie szkód systemowi,
    • instalacja i dystrybucja złośliwego oprogramowania.
  5. Dane uzyskane podczas testów – podlegają zasadom ochrony danych; jeśli je pozyskano, należy je usunąć w ciągu 10 dni od usunięcia luki i utrzymać poufność do końca procedury.
  6. Zgoda właściciela – działania wykonane za zgodą właściciela/administratora systemu również są niekaralne, przy zachowaniu obowiązków notyfikacyjnych.

Wejście w życie: Dekret wchodzi w życie po 120 dniach od publikacji w Dzienniku Ustaw; lokalne media wyliczają datę na 3 kwietnia 2026.

Praktyczne konsekwencje / ryzyko

  • Dla researcherów: to realna, ustawowa „bezpieczna przystań”, ale z istotnymi ograniczeniami: zero DoS/socjotechniki, pełna proporcjonalność, brak zysku i twardy reżim zgłaszania. Przekroczenie tych ram może ponownie wprowadzić działania w sferę karną.
  • Dla organizacji: rośnie znaczenie procesu przyjmowania zgłoszeń podatności (VDP) i gotowości do współpracy z CNCS. Brak procedur może skutkować opóźnieniami, wyciekami oraz karami administracyjnymi z reżimu NIS2.
  • Dla rynku: formalizacja „good-faith research” powinna poprawić czas reakcji na luki i jakość komunikacji, o ile firmy ustanowią jasne kanały disclosure. Media branżowe przewidują pozytywny wpływ na ekosystem bezpieczeństwa.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji w Portugalii i podmiotów obsługujących portugalskich klientów:

  1. Ustanów VDP (Vulnerability Disclosure Policy) z jasnym kanałem kontaktu, SLA triage i polityką prywatności danych badawczych. Odnieś VDP do wymogów art. 8.º-A (powiadomienia, poufność, usuwanie danych).
  2. Wyznacz rolę „VDP ownera” po stronie bezpieczeństwa/IT i powiąż ją z zespołem prawnym oraz kontaktami do CNCS (krajowa władza ds. cyberbezpieczeństwa).
  3. Zaktualizuj wewnętrzne procedury NIS2: klasyfikacja incydentów, progi zgłoszeń i koordynacja z CSIRT – tak, by obsłużyć napływ zgłoszeń od researcherów po wejściu prawa w życie.
  4. Zabroń DoS/socjotechniki w regulaminach testów (np. programy bug bounty), aby nie zachęcać do działań wyłączonych z ochrony.
  5. Przygotuj klauzule prawne (NDA „limited”), które pozwolą na poufność do czasu naprawy i wykazanie usunięcia danych w 10 dni od załatania luki.

Dla researcherów:

  • Dokumentuj intencję i proporcjonalność, prowadź dziennik czynności.
  • Natychmiast zgłaszaj lukę właścicielowi/administratorowi i władzy ds. cyberbezpieczeństwa; zachowuj zgodność z RODO.
  • Unikaj wszystkich technik wyraźnie zakazanych (DoS, phishing, malware itd.).
  • Nie przyjmuj korzyści majątkowych za sam fakt nieautoryzowanego testu (bug bounty po zaproszeniu/uregulowane – tak; wymuszenia – nie).

Różnice / porównania z innymi przypadkami

Nowy portugalski przepis przypomina praktykę „safe harbor” znaną z programów bug bounty, ale ma rangę ustawową i precyzyjnie określone wyłączenia (DoS, socjotechnika, phishing). To bardziej formalne i restrykcyjne rozwiązanie niż ogólne, niepisane zasady „co jest OK” w branży – dzięki temu daje większą pewność prawną zarówno badaczom, jak i organizacjom. Jednocześnie ciężar dowodu dobrej wiary i proporcjonalności spoczywa na researcherze.

Podsumowanie / kluczowe wnioski

Portugalia wprowadza rzadko spotykany, ustawowy parasol ochronny dla badań bezpieczeństwa – ale ściśle skrojony i podporządkowany interesowi publicznemu. Jeśli firmy przygotują VDP i dostosują procesy NIS2, a researcherzy zachowają proporcjonalność, transparentność i zgodność z RODO, ekosystem zyska na szybszym i bezpieczniejszym ujawnianiu podatności.

Źródła / bibliografia

  1. Diário da República – Decreto-Lei n.º 125/2025 (oficjalny tekst; art. 7 dodaje art. 8.º-A do prawa o cyberprzestępczości; wejście w życie po 120 dniach).
  2. BleepingComputer – omówienie zmian i kontekstu dla researcherów. (BleepingComputer)
  3. ANACOM – nota o publikacji dekretu-ustawy i transpozycji NIS2. (Anacom)
  4. DataGuidance – informacja o transpozycji NIS2 w Portugalii. (DataGuidance)
  5. ECO SAPO – termin wejścia w życie: 3 kwietnia 2026 r. (ECO)