Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 446 z 464

Autor: Wojciech Ciemski

Pwn2Own: badacz wycofał pokaz exploita na WhatsApp. Twierdzi, że „prywatnie” ujawnił go Meta

Wprowadzenie do problemu / definicja luki

Pwn2Own Ireland 2025 — edycja słynnego konkursu ZDI — miała przynieść głośny pokaz exploita na WhatsApp, wycenionego na 1 mln USD w kategorii „zero-click RCE”. Tuż przed prezentacją badacz wycofał się jednak z demonstracji, deklarując, że szczegóły luki zostały prywatnie przekazane firmie Meta (właścicielowi WhatsAppa). Organizatorzy i Meta nie potwierdzili dotąd szczegółów ani ew. wypłaty nagrody, co wywołało spekulacje wokół realnej wykonalności łańcucha ataku.

W skrócie

  • Badacz zapowiedzianego exploita na WhatsApp odwołał publiczny pokaz na Pwn2Own Ireland 2025 i twierdzi, że zgłosił go bezpośrednio do Meta. Brak potwierdzenia po stronie ZDI/Meta.
  • Sama kategoria WhatsApp w tegorocznym Pwn2Own miała bezprecedensową nagrodę do 1 mln USD za zademonstrowanie zero-click RCE.
  • W ostatnich tygodniach WhatsApp ujawnił i załatał poważną podatność (CVE-2025-55177), która w łańcuchu z błędem Apple była wykorzystywana w atakach ukierunkowanych — co podnosi kontekst zagrożeń dla komunikatora.

Kontekst / historia / powiązania

Pwn2Own od lat wynosi na światło dzienne luki klasy RCE/logic w popularnych produktach. W 2025 r. ZDI ustanowiło rekordowe stawki w kategorii komunikatorów mobilnych, z naciskiem na zero-click (brak interakcji ofiary). Dla WhatsAppa ogłoszono pulę sięgającą 1 mln USD — poziom mający przyciągnąć topowe zespoły exploitacyjne.

Równolegle, we wrześniu 2025 r., Meta opublikowała advisory opisujące błąd synchronizacji urządzeń powiązanych (CVE-2025-55177), który — w połączeniu z luką systemową Apple (CVE-2025-43300) — mógł być wykorzystywany w atakach szpiegowskich. Media branżowe potwierdzały te doniesienia, wskazując na realne kampanie ukierunkowane.

Analiza techniczna / szczegóły luki

W sprawie odwołanego pokazu brakuje publicznych detali technicznych: nie ujawniono komponentu (np. parserów multimediów, mechanizmów link preview, WebRTC, E2EE transportu) ani stopnia interakcji (zero-click vs. one-click). Według relacji SecurityWeek, badacz zadeklarował tylko prywatne zgłoszenie do Meta i zrezygnował z demonstracji na scenie, co spowodowało wątpliwości w branży co do statusu exploita. Do chwili publikacji nie ma potwierdzonych informacji o akceptacji zgłoszenia czy wypłacie nagrody.

Dla porównania, CVE-2025-55177 (wrzesień 2025) dotyczyło niepełnej autoryzacji w obsłudze wiadomości synchronizacji urządzeń powiązanych, co mogło prowadzić do przetwarzania treści z arbitralnego URL na urządzeniu ofiary — lukę tę łączono z błędem na poziomie systemu Apple w celu osiągnięcia skutków zero-click.

Praktyczne konsekwencje / ryzyko

  • Niepewność ryzyka resztkowego: brak publicznej weryfikacji łańcucha exploita z Pwn2Own utrudnia ocenę ekspozycji. Jeśli istnieje, mógłby być wykorzystywany wysoce selektywnie (APT/spyware).
  • Historia realnych nadużyć: świeżo załatane CVE-2025-55177 pokazuje, że zaawansowane ataki na WhatsApp są możliwe i mają precedens w 2025 r.
  • Łańcuchy wieloetapowe: praktyka łączenia błędów aplikacyjnych z systemowymi (iOS/macOS) pozostaje najgroźniejszym wektorem dla „zero-clicków”.

Rekomendacje operacyjne / co zrobić teraz

  1. Aktualizacje natychmiastowe:
    • Utrzymuj WhatsApp/WhatsApp Business oraz klienta macOS w najnowszych wersjach (po wrześniowych łatkach adresujących CVE-2025-55177).
    • Wymuszaj szybki cykl aktualizacji iOS/macOS (łaty na poziomie obrazu/Media/ImageIO).
  2. Hardening środowiska mobilnego: MDM z politykami ograniczeń (blokowanie instalacji z nieznanych źródeł, kontrola profili, minimalizacja powierzchni udostępnień). (Wniosek operacyjny na bazie powszechnych praktyk; brak specyficznego CVE.)
  3. Detekcja i monitoring:
    • Telemetria aplikacyjna (Mobile Threat Defense), wykrywanie anomalii w ruchu (m.in. wzorce C2), alerting na nietypowe procesy multimedialne. (Praktyki branżowe.)
  4. Zarządzanie ryzykiem „zero-click”:
    • Traktuj komunikatory jako ryzyko wysokie w profilach VIP/stanowisk wrażliwych; rozważ separację urządzeń i minimalny zestaw aplikacji. (Praktyki branżowe.)
  5. Bug bounty / responsywne zgłaszanie:
    • Śledź aktualizacje ZDI i zasady Pwn2Own, które determinują okna publikacji PoC oraz model wynagradzania.

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

  • Odwołany pokaz vs. potwierdzona luka: w przypadku CVE-2025-55177 mieliśmy jasne advisory i łaty; w sprawie exploita z Pwn2Own — brak potwierdzonej dokumentacji i brak publicznego PoC.
  • Nagroda konkursowa vs. program bug bounty: oferta 1 mln USD w Pwn2Own dotyczy publicznej demonstracji w regulaminie konkursu; prywatne ujawnienie Meta wchodzi już w tryb programu zgłaszania podatności, z innymi kryteriami i poziomami nagród.

Podsumowanie / kluczowe wnioski

  • Głośny pokaz exploita WhatsApp na Pwn2Own nie doszedł do skutku; badacz twierdzi o prywatnym disclosure do Meta, lecz brak niezależnej weryfikacji.
  • Kontekst 2025 r. (CVE-2025-55177 + Apple zero-day) dowodzi, że zaawansowane łańcuchy zero-click przeciw WhatsApp są realne — aktualizacje i twarde polityki mobilne to must-have.
  • Organizacje powinny traktować komunikatory jako powierzchnię krytyczną, wdrażając MDM/MTD, segmentację użytkowników wysokiego ryzyka i szybki patching.

Źródła / bibliografia

  • SecurityWeek — „Pwn2Own WhatsApp Hacker Says Exploit Privately Reported to Meta” (24 października 2025). (SecurityWeek)
  • SecurityWeek — „WhatsApp Zero-Day Exploited in Attacks Targeting Apple Users” (2 września 2025). (SecurityWeek)
  • WhatsApp Security Advisories 2025 — opis CVE-2025-55177. (whatsapp.com)
  • BleepingComputer — o ofercie 1 mln USD na Pwn2Own Ireland 2025. (BleepingComputer)
  • ZDI / Trend Micro — regulamin Pwn2Own Ireland 2025. (Zero Day Initiative)

Atak DDoS na Rosselkhoznadzor sparaliżował cyfrowe certyfikaty weterynaryjne „Mercury”. Skutki dla łańcuchów dostaw żywności w Rosji

Wprowadzenie do problemu / definicja luki

22 października 2025 r. rosyjska państwowa służba nadzoru weterynaryjnego i fitosanitarnego (Rosselkhoznadzor) ogłosiła, że jej systemy informatyczne zostały objęte zakrojonym na szeroką skalę atakiem DDoS. Uderzenie dotknęło m.in. kluczowe platformy VetIS i Saturn, w tym komponent Mercury odpowiedzialny za elektroniczne wystawianie weterynaryjnych dokumentów towarzyszących (E-VSD), bez których legalny obrót mięsem, nabiałem, jajami i inną żywnością pochodzenia zwierzęcego jest w Rosji niemożliwy. Według doniesień branżowych skutkiem były opóźnienia i przestoje w wysyłkach produktów spożywczych.

W skrócie

  • Kiedy? Środa, 22 października 2025 r. (komunikaty i relacje z 22–24 października).
  • Co się stało? Skorelowane wolumetryczne ataki DDoS zakłóciły dostęp do VetIS/Saturn, w tym do Mercury.
  • Skutek biznesowy: Część producentów (m.in. mleczarskich i żywności dla dzieci) zgłaszała wstrzymanie/zwłoki w odczytach i wystawianiu E-VSD, co spowodowało czasowe zablokowanie wysyłek.
  • Stan oficjalny: Rosselkhoznadzor utrzymywał, że nie ma zagrożenia integralności/confidentiality danych, a Mercury „działa w trybie normalnym”, mimo możliwej okresowej niedostępności per region/łączność.
  • Powtarzalność: To co najmniej czwarty incydent wpływający na Mercury w 2025 r.; w czerwcu firmy przechodziły na tryb „papierowy”, co wywołało chaos logistyczny.

Kontekst / historia / powiązania

Mercury (część VetIS) jest centralnym rejestrem śledzenia łańcucha „od pola do półki” dla produktów pochodzenia zwierzęcego. Od 2018 r. wystawianie E-VSD w Mercury jest obowiązkowe dla podmiotów obracających m.in. mięsem, rybami, jajami, miodem, mlekiem i szeroką gamą przetworów — bez tych dokumentów detaliści i przetwórcy nie mogą prawnie przyjmować towaru.

W 2025 r. system był już kilkukrotnie zakłócany: w czerwcu odnotowano przerwę skutkującą przejściem części branży na obieg papierowy i specjalne procedury awaryjne. Obecny incydent z 22 października ponownie unaocznił krytyczność Mercury jako punktu pojedynczej awarii (SPOF) dla dostaw żywności.

Analiza techniczna / szczegóły incydentu

Z dostępnych komunikatów wynika, że:

  • Atak miał charakter wolumetrycznych DDoS (duży wolumen szkodliwego ruchu), z objawami niestabilności łączy i urządzeń brzegowych zapewniających dostęp do Internetu. Operatorzy (m.in. Megafon, Rostelecom, Intelsk) mieli filtrować ruch, co powodowało miejscowe/okresowe niedostępności.
  • Wpływ obejmował VetIS/Saturn i dostęp do usług Mercury. Z perspektywy części producentów oznaczało to praktyczną blokadę wystawiania E-VSD i brak możliwości legalnej wysyłki/odbioru towaru.
  • Rosselkhoznadzor podkreślał brak kompromitacji danych oraz deklarował działanie Mercury „w zwykłym trybie”, co stoi w napięciu z relacjami rynkowymi o przestojach trwających kilka godzin (m.in. u dwóch dużych mleczarni i producenta żywności dla dzieci).

Hipotezy techniczne (w oparciu o znane TTP dla DDoS):

  • Scenariusz ataku rozproszonym ruchem z botnetu (warstwa 3/4) z okresowymi falami, wymuszający filtrowanie/Blackholing przez operatorów i powodujący „efekt uboczny” w postaci utraty dostępności częściowo geograficznie.
  • Możliwe komponenty L7 (HTTP/S) na frontach aplikacyjnych Mercury/VetIS, zwiększające czas odpowiedzi, time-outy i błędy przy autoryzacji dokumentów.
  • Brak skutecznej, automatycznej procedury „graceful degradation” (np. przełączenia na podpisy wsadowe/offline albo tryb cache’owania tokenów dokumentów) — co tłumaczy różnicę między deklarowaną „pracą systemu” a realną dostępnością funkcji krytycznych po stronie użytkowników.

Praktyczne konsekwencje / ryzyko

  • Zakłócenia łańcucha dostaw żywności w skali kraju: brak E-VSD = brak możliwości przyjmowania towaru przez sieci handlowe i przetwórców; odnotowano wstrzymania wysyłek „przez pół dnia” u części producentów.
  • Ryzyko finansowe: przestój linii produkcyjnych, utrata świeżości produktów krótkoterminowych (nabiał), kary umowne za opóźnienia.
  • Ryzyko regulacyjne i reputacyjne: rozbieżność komunikatów urzędowych i obserwacji rynkowych; presja na formalizację trybów awaryjnych (wysyłka bez E-VSD z późniejszym uzupełnieniem).
  • Trend: wzrost częstotliwości ataków na systemy logistyczno-certyfikacyjne; analogiczne ostrzeżenia dla sektora logistyki publikowały instytucje rządowe na Zachodzie (choć dot. innych celów).

Rekomendacje operacyjne / co zrobić teraz

Dla właścicieli systemów krytycznych (gov/branża):

  1. Anycast + wielowarstwowe scrubbing centers (L3/4 i L7) z automatycznym failoverem między dostawcami; testy grywalizowane TTX co kwartał.
  2. Segmentacja usług Mercury-like: separacja krytycznych ścieżek wystawiania E-VSD od interfejsów publicznych; dynamiczne limitowanie żądań (rate-limiting, token-bucket) per AS/region/UA.
  3. Procedury „degraded mode”: tryb awaryjny dopuszczający czasową legalną wysyłkę bez pełnego E-VSD z obowiązkowym dosłaniem w oknie 24–48 h; formalne, z góry uzgodnione z regulatorami i sieciami handlowymi. (Takie rozwiązania były już stosowane podczas wcześniejszych zakłóceń w 2025 r.).
  4. Redundancja geograficzna i DNS: active-active z izolacją blast radius, niezależne łącza i dostawcy.
  5. Telemetria anty-DDoS: BGP Flowspec/RTBH, automatyczna orkiestracja z SIEM/SOAR, reguły na podstawie profili ruchu.

Dla producentów i detalistów (odbiorców systemu):

  1. Plany ciągłości działania (BCP) na wypadek niedostępności E-VSD: listy kontrolne wysyłki „warunkowej”, escrow dokumentów, uzgodnione z regulatorami SLA na dosłanie certyfikatów.
  2. Bufory logistyczne dla produktów szybko psujących się; priorytetyzacja tras o mniejszym ryzyku opóźnień.
  3. Monitoring statusu systemów centralnych i kanałów urzędowych (np. oficjalny kanał Telegram) oraz szybkie kanały kontaktu z sieciami handlowymi.
  4. Wewnętrzne proxy/kolejki: w razie L7-DDoS — lokalne buforowanie żądań do czasu przywrócenia przepustowości.

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

  • Czerwiec 2025 (Rosja/ Mercury): brak dostępności skutkował przejściem na dokumenty papierowe; formalnie ogłoszono tryb awaryjny. Październikowy incydent miał profil DDoS i spór o realny poziom dostępności (rynek zgłaszał przestoje, urząd deklarował „pracę w normie”).
  • Logistyka na Zachodzie (ostrzeżenia 2025): akcent na kampanie APT przeciw łańcuchom dostaw i firmom TSL; choć inny kontekst, wnioski o konieczności redundancji i procedur „degraded mode” pozostają spójne.

Podsumowanie / kluczowe wnioski

Atak z 22 października potwierdza, że systemy certyfikacji i śledzenia pochodzenia żywności są celami o wysokiej wartości zakłóceniowej: nawet bez naruszenia danych sam brak dostępności generuje dotkliwe koszty biznesowe i ryzyka regulacyjne. Organizacje utrzymujące podobne rejestry powinny pilnie wdrażać wielowarstwową ochronę DDoS, tryby „graceful degradation” oraz uzgodnione prawnie procedury awaryjne umożliwiające kontynuację obrotu z późniejszym uzupełnieniem dokumentów.

Źródła / bibliografia

  1. The Record (Recorded Future News): raport o ataku i wpływie na wysyłki, 24 października 2025. (The Record from Recorded Future)
  2. Shopper’s (rosyjskie medium branżowe): relacje producentów o wstrzymaniu odgórkek i szczegóły dot. braku trybu awaryjnego, 22 października 2025. (shoppers.media)
  3. RIA Nowosti / komunikaty Rosselkhoznadzoru: informacja o DDoS i braku zagrożeń dla danych; deklaracja „pracy w trybie zwykłym”. (РИА Новости)
  4. ROSNG: zaprzeczenie problemom z Mercury po ataku, 23 października 2025. (rosng.ru)
  5. The Record (czerwiec 2025): wcześniejsze zakłócenia Mercury i skutki dla branży mleczarskiej. (The Record from Recorded Future)

Masowe ataki na WordPress: przestępcy wykorzystują stare luki w GutenKit i Hunk Companion

Wprowadzenie do problemu / definicja luki

Od 8–9 października 2025 r. obserwowana jest kampania masowych ataków na strony WordPress, której celem są stare, ale wciąż powszechnie używane wersje wtyczek GutenKit oraz Hunk Companion. Według danych cytowanych przez BleepingComputer, dostawca zabezpieczeń Wordfence zablokował 8,7 mln prób w ciągu dwóch dni. Atakujący łączą podatności pozwalające bez uwierzytelnienia instalować dowolne wtyczki lub wgrywać pliki podszyte pod wtyczki, co eskaluje do zdalnego wykonania kodu (RCE).

W skrócie

  • Na celowniku: GutenKit (≤ 2.1.0 — CVE-2024-9234) i Hunk Companion (≤ 1.8.4 — CVE-2024-9707; ≤ 1.8.5 — CVE-2024-11972). Łatki: GutenKit 2.1.1 (X 2024), Hunk Companion 1.9.0 (XII 2024).
  • Wektor: nieautoryzowane endpointy REST umożliwiające instalację/aktywację wtyczek lub wgrywanie „fałszywych” paczek.
  • Łańcuch ataku: po uzyskaniu dostępu napastnicy doinstalowują złośliwą paczkę „up” albo podatną wtyczkę WP Query Console (brak poprawek, RCE), aby utrzymać trwałą kontrolę.
  • Ślady (IoC): żądania do /wp-json/gutenkit/v1/install-active-plugin, /wp-json/hc/v1/themehunk-import; katalogi: /up, /background-image-cropper, /ultra-seo-processor-wp, /oke, /wp-query-console.

Kontekst / historia / powiązania

Luki w Hunk Companion były już nagłaśniane pod koniec 2024 r. — CVE-2024-11972 jest poprawką/bypassem wcześniejszej CVE-2024-9707; obie ocenione jako CVSS 9.8 (krit.). W praktyce błędy umożliwiają atakującemu instalowanie i aktywowanie dowolnych wtyczek z repozytorium WordPress (także tych wycofanych), co stanowi wygodny „most” do RCE. Równolegle CVE-2024-9234 w GutenKit pozwala uploadować pliki podszyte pod wtyczki i aktywować je bez uprawnień.

Analiza techniczna / szczegóły luki

GutenKit (CVE-2024-9234). Brak właściwej autoryzacji/capability check w funkcji obsługującej install-active-plugin (REST) umożliwia nieautoryzowaną instalację/aktywację wtyczek lub wgranie arbitralnego pliku udającego wtyczkę (do 2.1.0 włącznie).

Hunk Companion (CVE-2024-9707, CVE-2024-11972). Błędy w endpointach themehunk-import (REST) pozwalają na nieautoryzowane POST-y skutkujące instalacją/aktywacją wtyczek. CVE-2024-11972 domyka wcześniejszą łatę i również oceniona jest na CVSS 9.8; wersja naprawcza to 1.9.0.

Eskalacja do RCE. Po pierwszym kroku atakujący:

  • instalują paczkę „up” (ZIP hostowany m.in. na zewnętrznych repozytoriach), zawierającą zaciemnione skrypty do uploadu, pobierania, usuwania plików i zmiany uprawnień; jeden z komponentów maskuje się jako element All in One SEO i automatycznie loguje napastnika jako admina,
  • albo doinstalowują podatną wtyczkę WP Query Console ≤ 1.0 (CVE-2024-50498, brak poprawek) i uzyskują RCE bez uwierzytelnienia.

IoC i TTP. W logach ruchu widoczne są żądania do:
/wp-json/gutenkit/v1/install-active-plugin oraz /wp-json/hc/v1/themehunk-import (sygnatura exploitów). W systemie plików sprawdź katalogi: /up, /background-image-cropper, /ultra-seo-processor-wp, /oke, /wp-query-console.

Praktyczne konsekwencje / ryzyko

  • Przejęcie strony i trwała persystencja (backdoory, automatyczny login na admina).
  • Eksfiltracja danych (pliki, konfiguracje, dane klientów), modyfikacje treści, wstrzykiwanie SEO-spam/malvertising.
  • Pivot na serwer — RCE pozwala wykorzystywać host do dalszych ataków (phishing, botnet, cryptomining).
  • Ryzyka prawne i reputacyjne (RODO, utrata pozycji SEO).
    Źródła branżowe raportują o łączeniu kilku luk w jeden łańcuch, co zwiększa automatyzację i skalę kampanii.

Rekomendacje operacyjne / co zrobić teraz

1) Patching i audyt wersji

  • Natychmiast zaktualizuj:
    • GutenKit → ≥ 2.1.1,
    • Hunk Companion → ≥ 1.9.0.
  • Jeśli wtyczki są zbędne — usuń je całkowicie (dezaktywacja to za mało).

2) Detekcja nadużyć (logi i pliki)

  • Przeskanuj logi HTTP pod kątem:
    • "/wp-json/gutenkit/v1/install-active-plugin"
    • "/wp-json/hc/v1/themehunk-import"
  • Przeszukaj system plików:
    • katalogi: /up, /background-image-cropper, /ultra-seo-processor-wp, /oke, /wp-query-console.

Przykładowe polecenia (Linux):

# Szukaj podejrzanych żądań w access.log (Nginx/Apache)
grep -E 'wp-json/(gutenkit|hc)/v1/(install-active-plugin|themehunk-import)' /var/log/*/access.log*

# Wykryj "podejrzane" katalogi w instalacji WP
cd /var/www/html
find . -maxdepth 3 -type d -regex ".*/\(up\|background-image-cropper\|ultra-seo-processor-wp\|oke\|wp-query-console\)"

3) Ograniczenia i WAF

  • Tymczasowo blokuj/limituj dostęp do ww. endpointów REST (np. reguła WAF/ModSecurity) do czasu aktualizacji.
  • Stosuj Rate Limiting i blokowanie IP/ASN powiązanych z falą skanów (dane z bieżących raportów bezpieczeństwa).

4) Hardening WordPress

  • Włącz auto-update dla wtyczek i rdzenia.
  • Ogranicz liczbę adminów, wymuś MFA i klucze aplikacji dla integracji.
  • Utrzymuj kopie zapasowe offline i testuj odtwarzanie.

5) Incydent response (jeśli są ślady kompromitacji)

  1. Odizoluj witrynę (maintenance/firewall).
  2. Zrzut i analiza artefaktów: nowe konta admin, cron, wp-content/uploads, mu-plugins, wp-config.php.
  3. Usuń backdoory, zaktualizuj do bezpiecznych wersji, zresetuj hasła i klucze salts.
  4. Rozważ przywrócenie z kopii sprzed incydentu i pełny przegląd wtyczek (usuń porzucone).

Różnice / porównania z innymi przypadkami

  • Klasyczne RCE w wtyczce (np. WP Query Console) zwykle wymaga pojedynczej luki; tutaj napastnicy najpierw wymuszają instalację podatnej wtyczki przez inny błąd (REST), co zwiększa skuteczność automatycznych kampanii.
  • Specyfika WordPress.org: możliwość sięgnięcia po stare, wycofane paczki w repozytorium, co ułatwia „dowiezienie” RCE po uzyskaniu dostępu do endpointu instalacji.

Podsumowanie / kluczowe wnioski

  • Trwają zautomatyzowane, masowe ataki na WordPress z użyciem starych błędów w GutenKit i Hunk Companion, z potwierdzonymi milionami prób w krótkim czasie. Priorytetem jest aktualizacja lub deinstalacja podatnych wtyczek, przegląd logów pod kątem specyficznych endpointów REST oraz poszukiwanie charakterystycznych katalogów/pliki IoC. Dla zespołów SecOps to sygnał do tworzenia reguł WAF/IDS oraz blokad na poziomie infrastruktury.

Źródła / bibliografia

  1. BleepingComputer — „Hackers launch mass attacks exploiting outdated WordPress plugins”, 24 października 2025. (BleepingComputer)
  2. NVD — CVE-2024-9234 (GutenKit): opis błędu i wektor ataku. (NVD)
  3. NVD — CVE-2024-11972 (Hunk Companion): brak autoryzacji endpointów, wersja naprawcza. (NVD)
  4. WPScan — WP Query Console ≤ 1.0 — Unauthenticated RCE (CVE-2024-50498) — brak poprawek. (WPScan)
  5. SecurityWeek — łączenie luk Hunk Companion + WP Query Console do przejęcia stron (grudzień 2024). (SecurityWeek)

3 000 filmów na YouTube jako pułapki malware. „YouTube Ghost Network” rozbite — co to było i jak się bronić

Wprowadzenie do problemu / definicja luki

Check Point Research ujawnił skoordynowaną operację dystrybucji złośliwego oprogramowania na YouTube, nazwaną YouTube Ghost Network. Sieć wykorzystywała przejęte lub fałszywe konta, by publikować filmy-tutoriale (cracki, „haki” do gier), które prowadziły do pobrania stealerów informacji. Zidentyfikowano ponad 3 000 złośliwych filmów, z których wiele miało setki tysięcy wyświetleń. Po zgłoszeniach badaczy Google usunął większość treści. Źródło przypisuje aktywność co najmniej od 2021 r., a w 2025 r. liczba filmów potroiła się.

W skrócie

  • Skala: >3 000 filmów na przejętych kanałach; rekordowe pojedyncze wideo ~293 tys. wyświetleń (Photoshop), inne ~147 tys. (FL Studio).
  • Wektor socjotechniczny: „darmowe” cracki i cheaty (m.in. Roblox, Adobe, FL Studio), komentarze i lajki budujące fałszywą wiarygodność.
  • Rodziny malware: głównie infostealery – Lumma (przed jej wiosennym rozbiciem), później Rhadamanthys, a także RedLine, StealC, Phemedrone/0debug; bywał łańcuch z HijackLoaderem.
  • Łańcuch infekcji: linki w opisie, przypiętych komentarzach lub „instrukcji wideo” → skracacze URL → Google Sites/Blogger/Telegra.ph lub dyski Dropbox/Google Drive/MediaFire → archiwum z hasłem + prośba o wyłączenie Defendera → payload.
  • Reakcja branży: Check Point + Google usunęli większość treści; media branżowe potwierdziły skalę i modus operandi.

Kontekst / historia / powiązania

  • Lumma Stealer był „hitem” w sieci do czasu międzynarodowej akcji Microsoftu i Europolu (16 marca–16 maja 2025 r.), po której operatorzy kampanii częściej przechodzili na Rhadamanthys.
  • Zjawisko „Ghost Network” wcześniej opisywano na GitHubie (kampania Stargazers Ghost Network), gdzie masowo podszywano się pod wiarygodne repozytoria do dystrybucji złośliwych plików. YouTube to kolejna odsłona tej samej taktyki „platform-as-distribution”.

Analiza techniczna / szczegóły luki

Architektura ról (operacja na YouTube):

  1. Video-accounts – publikują filmy-wabiki i udostępniają linki (w opisie, przypiętym komentarzu lub jako „hasło+link” w samym wideo).
  2. Post-accounts – publikują posty społeczności z linkami i hasłami do archiwów; aktualizują wpisy, by omijać zgłoszenia; możliwe użycie AI do interakcji.
  3. Interact-accounts – dodają „lajki” i entuzjastyczne komentarze („works!”, „no virus”), podbijając sygnały zaufania.

Łańcuch dystrybucji i unikanie detekcji:

  • Skracacze URL maskujące destynację.
  • Hosty plików i usługi Google (Sites/Blogspot/Drive) – wysoka reputacja domen utrudnia filtrowanie reputacyjne.
  • Archiwa chronione hasłem (często „1337”) – brak możliwości skanowania zawartości bez hasła.
  • Instrukcje „wyłącz Defendera na chwilę” – celowe osłabienie ochrony podczas instalacji.
  • Pliki o dużych rozmiarach lub MSI instalujące HijackLoadera, który dociąga właściwy stealer (np. Rhadamanthys).

Cele i treści przynęt:

  • Cracki do Adobe Photoshop/Premiere/Lightroom, FL Studio, CorelDRAW, cheaty do gier (np. Roblox).
  • Kierowanie do grup docelowych (twórcy wideo/muzyki, gracze), gdzie popyt na „darmowe” narzędzia jest wysoki.

Praktyczne konsekwencje / ryzyko

  • Utrata danych uwierzytelniających (przeglądarki, menedżery haseł, cookie session tokens), portfele kryptowalut, poczta i konta społecznościowe — typowe dla stealerów.
  • Przejęcia kont korporacyjnych przez wykradzione sesje (SSO, M365, Slack, Git).
  • Wektory wtórne: zainfekowane endpointy stają się punktem wyjścia do BEC, ransomware lub dalszych kradzieży danych. (Wynika z typowych zdolności Lumma/Rhadamanthys i obserwacji Check Point dot. infostealerów w kampanii).

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/IT (organizacje)

  1. Zablokuj ryzykowne kategorie transferów: egzekwuj polityki dla popularnych skracaczy URL i hostingów plików (Dropbox/Drive/MediaFire) w ruchu korporacyjnym — co najmniej kontrola i logowanie + izolacja przeglądarkowa dla niezweryfikowanych pobrań.
  2. Reguły detekcji:
    • Alerty na pobrania archiwów z hasłem z przeglądarki i nietypowe uruchomienia msiexec/exe po pobraniu.
    • Telemetria EDR dla wskaźników typowych dla Rhadamanthys/Lumma (procesy z nietypową komunikacją C2, kradzież danych z przeglądarek). (Uzasadnienie: kampania dostarczała właśnie te stealer-y).
  3. Zasady anty-tampering: wymuś niemożność wyłączenia Defendera/AV przez użytkownika bez uprawnień admina; monitoruj zdarzenia prób wyłączenia ochrony w czasie instalacji.
  4. Twarde uwierzytelnianie: MFA odporne na phishing (FIDO2/Passkeys), krótkie TTL sesji, automatyczne unieważnianie tokenów po incydencie ze stealerem. (Kontekst: masowe kradzieże cookies przez stealery).
  5. Kontrola aplikacji i uprawnień: blokada uruchamiania niepodpisanych MSI/EXE spoza zaufanych katalogów; WDAC/AppLocker; zasada least privilege na endpointach.
  6. DTR/IR playbook dla stealerów: natychmiastowa rotacja haseł/kluczy/API, reset sesji, przegląd logowania z nowych lokacji, przegląd skrzynek i reguł przekierowań.

Dla użytkowników (awareness)

  • Nie instaluj cracków i „hacków do gier” — to w 2025 r. najczęstsza przynęta w tej kampanii.
  • Weryfikuj kanały i linki: jeśli link prowadzi przez skracacz lub na Google Sites/Telegra.ph i wymaga hasła do archiwum – traktuj to jako czerwone flagi.
  • Nie wyłączaj antywirusa „na chwilę” z powodu filmu w sieci.
  • Używaj menedżera haseł + MFA i aktualizuj system.

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

  • GitHub „Stargazers Ghost Network” (2024–2025) i YouTube Ghost Network (2025) to ta sama logika „Ghost accounts as a service” na różnych platformach: manipulacja sygnałami zaufania (gwiazdki/forciowanie repo vs. wyświetlenia/komentarze), treści przynęt (narzędzia/dev-tool vs. cracki/cheaty), lecz cel identyczny — masowa dystrybucja infostealerów przy użyciu „dobrych” domen i funkcji społecznościowych.

Podsumowanie / kluczowe wnioski

  • Kampania YouTube Ghost Network pokazała, jak łatwo zbrodnicze grupy weaponizują platformy społecznościowe — od SEO i komentarzy po posty społeczności — by sprzedawać wiarygodność i dostarczać malware na masową skalę.
  • Cracki i cheaty pozostają najbardziej ryzykownym typem treści dla użytkowników; to na nich żerują operatorzy stealerów.
  • Higiena tożsamości, polityki pobrań i kontrola aplikacji są dziś równie ważne, co sygnaturowe AV.
  • Po rozbiciu Lumma napastnicy przechodzą na alternatywy (Rhadamanthys), co wymaga ciągłej adaptacji detekcji.

Źródła / bibliografia

  • Check Point Research: Dissecting YouTube’s Malware Distribution Network (23 października 2025). (Check Point Research)
  • The Hacker News: 3,000 YouTube Videos Exposed as Malware Traps… (24 października 2025). (The Hacker News)
  • The Register: Google and Check Point nuke massive YouTube malware… (23 października 2025). (The Register)
  • Help Net Security: Researchers expose large-scale YouTube malware distribution network (23 października 2025). (Help Net Security)
  • Europol: Europol and Microsoft disrupt world’s largest infostealer Lumma (21 maja 2025). (Europol)

Hakerzy polują na użytkowników przeglądarki Perplexity Comet: fałszywe domeny, aplikacje i reklamy

Wprowadzenie do problemu / definicja luki

Krótko po premierze przeglądarki Perplexity Comet cyberprzestępcy uruchomili skoordynowaną kampanię podszywania się pod markę: rejestrowali domeny podobne do oficjalnych adresów, publikowali fałszywe aplikacje mobilne i promowali fikcyjne instalatory poprzez reklamy w wyszukiwarkach i mediach społecznościowych. Celem jest skłonienie użytkowników do pobrania nieautoryzowanego oprogramowania lub przeklikania się do stron phishingowych podszywających się pod „pobieranie Comet”. Takie wnioski opublikował zespół BforeAI, a temat opisał SecurityWeek.

W skrócie

  • Czas: Comet wystartował 9 lipca 2025 r.; 2 października 2025 r. został udostępniony bezpłatnie dla wszystkich. Kampania fałszywych domen i aplikacji nasiliła się między sierpniem a październikiem 2025 r.
  • Skala: BforeAI przeanalizowało >40 podejrzanych domen; część z nich to bezpośrednie imitacje marki (np. perplexitycomet-ai.com, cometaibrowser.com).
  • Aplikacje mobilne: wykryto krytyczne fałszywe pozycje w Google Play oraz nieautoryzowaną aplikację w App Store, przed którą publicznie ostrzegł CEO Perplexity.
  • Powiązane ryzyka: wcześniejsze badania wykazały, że AI-przeglądarki (w tym Comet) są podatne na prompt-injection, phishing i scenariusze „agentic”.

Kontekst / historia / powiązania

Perplexity uruchomiło Comet jako AI-native przeglądarkę z asystentem zintegrowanym w przepływ pracy (poczta, kalendarz, research). Początkowo dostęp był ograniczony, później – od 2 października – produkt stał się darmowy dla wszystkich użytkowników, co znacząco zwiększyło rozpoznawalność marki i… atrakcyjność dla oszustów.

Równolegle pojawiły się niezależne badania bezpieczeństwa: Guardio Labs pokazało scenariusz „Scamlexity”, w którym AI-przeglądarka potrafi zautomatyzować błędne działania (np. pomagać dokonać zakupu na fałszywym sklepie), a LayerX opisał technikę CometJacking, gdzie pojedynczy złośliwy URL „przejmuje” agenta i wykrada dane (e-maile, kalendarz, „pamięć” użytkownika).

Analiza techniczna / szczegóły kampanii podszywania się

Wektory ataku zidentyfikowane przez BforeAI:

  1. Typosquatting i brand impersonation — rejestracje po starcie Comet, z użyciem słów kluczowych „comet”, „ai”, „browser”, „perplexity”, „download”. Przykłady: cometai.site, cometaibrowser.com, perplexitycomet-ai.com, cometbrowser.net, aicometbrowser.com. Część domen parkowana (np. cometai.net oferowana za 9 999 $).
  2. SEO-poisoning / malvertising — reklamy w wyszukiwarkach i social media kierujące do „pobierania Comet” z nieoficjalnych stron trzecich; serwowane pseudo-instalatory EXE.
  3. Fałszywe aplikacje mobilne — m.in. „Comet AI Atlas App Info” w Google Play; dodatkowo nieautoryzowana pozycja w iOS App Store, przed którą ostrzegł publicznie CEO Perplexity 14 października 2025 r.

Cechy operacyjne kampanii: wykorzystanie prywatności WHOIS, rejestratorów w różnych jurysdykcjach (w tym REG.RU, Name SRS AB, NameCheap) i szybkich, niedrogich rejestracji TLD (.com, .net, .ai, .site, .app), co utrudnia egzekwowanie i sprzyja rotacji infrastruktur.

Praktyczne konsekwencje / ryzyko

  • Zainfekowanie endpointu przez pobranie nieoficjalnego instalatora (infostealery, adware, RAT) podszywającego się pod „Comet Setup”. (Wniosek na podstawie znanych TTP kampanii malvertising / fake installers).
  • Kradzież danych i sesji: w scenariuszu CometJacking samo odwiedzenie spreparowanego linku może wywołać działania agenta i eksfiltrację treści (e-maile, kalendarz, „memory”).
  • Utrata środków / phishing transakcyjny: „Scamlexity” pokazuje, że agent może „pomóc” dokończyć oszustwo, jeśli UX atakującego zostanie zaprojektowany pod AI.
  • Ryzyko reputacyjne i zgodności dla organizacji dopuszczających niezweryfikowane pobrania i korzystanie z nieoficjalnych aplikacji.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów IT

  1. Pobieraj Comet wyłącznie z oficjalnych kanałów Perplexity (witryna i wpisy na blogu produktu). Zweryfikuj domenę perplexity.ai i podpisy binariów.
  2. Ignoruj reklamy „Download Comet” w Google/Bing oraz „skróty” w social media — zamiast tego wpisz adres ręcznie. (Wniosek na podstawie analizy malvertisingu BforeAI).
  3. Na mobile: do czasu oficjalnej premiery iOS nie instaluj żadnej „Comet” z App Store; zgłaszaj podejrzane pozycje.
  4. Przeglądarka/agent – higiena bezpieczeństwa: wyłącz autowykonywanie wtyczek/akcji, ogranicz uprawnienia do skrzynek pocztowych i kalendarzy, używaj profili tymczasowych do zadań „agentic”. (Wniosek na podstawie CometJacking/Scamlexity).

Dla SOC/Blue Team

  1. Blokady DNS/URL: dodaj wykazane przez BforeAI wskaźniki (domeny typosquatting) do list blokad i monitoringu; śledź rejestracje z ciągami comet|perplexity|browser|ai.
  2. Polityka instalacji: wymuś allow-listę źródeł oprogramowania; blokuj instalatory z unknown publisher.
  3. Detekcje: reguły na ruch do nowych, świeżo zarejestrowanych domen + detekcja nietypowych zapytań HTTP/JS wskazujących na exfiltrację przez agenta (np. base64 w parametrach URL opisana przez LayerX).
  4. Awareness: przeszkol użytkowników nt. prompt-injection i ryzyk „agentic browsing”; pokaż realne dema (Scamlexity).

Różnice / porównania z innymi przypadkami

  • AI-native vs. klasyczne przeglądarki: kluczowa różnica to agent wykonujący akcje. W tradycyjnej przeglądarce ofiara musi kliknąć/ulegać socjotechnice; w AI-przeglądarce agent może zautomatyzować niepożądane decyzje. (Wniosek na podstawie Guardio/LayerX).
  • Powierzchnia ataku: poza phishingiem dochodzi manipulacja kontekstem (prompt-injection, data exfiltration z „pamięci” agenta), co zwiększa skutki błędu użytkownika.

Podsumowanie / kluczowe wnioski

  • Popularność Comet po udostępnieniu „dla wszystkich” zbiegła się z falą nadużyć marki (domeny, reklamy, aplikacje).
  • Zagrożenia „agentic” sprawiają, że koszt błędu użytkownika jest wyższy niż w klasycznych przeglądarkach. Zasada 0-zaufania do reklam i nieoficjalnych źródeł jest tu krytyczna.
  • Organizacje powinny wyprzedzić atakujących: blokady DNS, polityki instalacji, profile ograniczone dla AI-agentów, oraz bieżące śledzenie wskaźników BforeAI.

Źródła / bibliografia

  • SecurityWeek: Hackers Target Perplexity Comet Browser Users (24 paź 2025). (SecurityWeek)
  • BforeAI: Threat Research Report: Malicious Activity Surrounding Perplexity’s Comet Browser Launch (paź 2025). (BforeAI)
  • Perplexity Blog: Introducing Comet (9 lip 2025) i Comet is now available to everyone worldwide (2 paź 2025). (Perplexity AI)
  • Guardio Labs: “Scamlexity”: We Put Agentic AI Browsers to the Test (20 sie 2025). (Guard.io)
  • LayerX: CometJacking: How One Click Can Turn Perplexity’s Comet AI Browser Against You (paź 2025). (LayerX)

GlassWorm: samorozprzestrzeniający się robak infekuje rozszerzenia VS Code i uderza w łańcuch dostaw

Wprowadzenie do problemu / definicja luki

Badacze bezpieczeństwa opisali nową kampanię malware nazwaną GlassWorm, która samodzielnie rozprzestrzenia się poprzez zainfekowane rozszerzenia Visual Studio Code publikowane w rejestrach Open VSX i Microsoft VS Code Marketplace. Atak celuje w łańcuch dostaw oprogramowania – wprost w narzędzia deweloperskie – kradnie poświadczenia (npm, GitHub), przejmuje środowiska i wykorzystuje maszyny programistów jako infrastrukturę przestępczą.

W skrócie

  • Skala: ok. 35,8 tys. instalacji złośliwych rozszerzeń; co najmniej kilka–kilkanaście paczek w obiegu w OpenVSX i na rynku Microsoftu.
  • Techniki ukrywania: „niewidzialny kod” z użyciem niewidocznych znaków Unicode w źródłach rozszerzeń, utrudniający przegląd i detekcję.
  • Zdolności: kradzież tokenów npm/GitHub, celowanie w 49 wtyczek portfeli krypto, uruchamianie SOCKS proxy i ukrytego VNC/RAT dla pełnego zdalnego dostępu.
  • Propagacja: użycie wykradzionych poświadczeń do publikowania zainfekowanych aktualizacji i przejmowania kolejnych kont/paczek.

Kontekst / historia / powiązania

Pierwsze publiczne raporty pojawiły się 20–24 października 2025 r.. Media branżowe i dostawcy bezpieczeństwa (m.in. BleepingComputer, Dark Reading) potwierdzają, że to jedna z najpoważniejszych jak dotąd kampanii wymierzonych w ekosystem VS Code. Część źródeł wiąże odkrycie z pracą badaczy Koi Security, a rozszerzenia w OpenVSX miały zostać podmienione 17 października; 2 dni później część z nich nadal rozprowadzała malware.

Analiza techniczna / szczegóły luki

Vektor wejścia. GlassWorm trafia do środowisk poprzez instalację (lub aktualizację) zainfekowanych rozszerzeń VS Code z OpenVSX oraz Microsoft Marketplace. Atakujący przejmują konta wydawców lub łańcuch CI/CD i publikują skażone wersje.

„Niewidzialny” kod. Krytycznym elementem jest ukrywanie złośliwej logiki z użyciem znaków sterujących Unicode (np. kierunków zapisu/bidirectional control), które sprawiają, że fragmenty kodu nie są widoczne przy zwykłym przeglądzie i mogą mylić zarówno recenzentów, jak i niektóre narzędzia SAST. Efekt: czysty diff, pozornie prawidłowa składnia, złośliwe ścieżki wykonania zaszyte między literami.

Zdolności po infekcji. Po zainstalowaniu, GlassWorm:

  • eksfiltruje poświadczenia npm i GitHub oraz inne sekrety deweloperskie,
  • skanuje przeglądarkę/środowisko pod kątem 49 rozszerzeń portfeli krypto i próbuje drenować środki,
  • wdraża SOCKS proxy, aby wykorzystywać hosta jako przekaźnik,
  • instaluje ukryte VNC/RAT dla pełnego zdalnego dostępu, utrzymując się w systemie,
  • używa skradzionych tokenów do przejęcia kolejnych pakietów/rozszerzeń i samoreplikacji.

Skala i telemetry. Według niezależnych relacji prasowych i firm badawczych mówimy o ~35,8 tys. instalacji/udanych pobrań skażonych rozszerzeń; atak dotknął co najmniej kilka–kilkanaście pakietów w popularnych rejestrach rozszerzeń.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja łańcucha dostaw: przejęte tokeny npm/GitHub = ryzyko publikacji trojanów w repozytoriach firmy/OSS.
  • Ryzyko finansowe: celowanie w portfele krypto i możliwa utrata środków.
  • Infrastruktura przestępcza: hosty dev stają się proxy i zdalnymi stacjami sterowanymi przez atakujących (VNC/RAT) – ekspozycja sieci wewnętrznej.
  • „Blind spot” w code review: użycie niewidzialnych znaków obchodzi kontrolę peer review i statyczną analizę, co utrudnia tradycyjne procesy SDLC.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast (IR – Incident Response):

  1. Inwentaryzacja rozszerzeń VS Code w organizacji (OpenVSX/Microsoft Marketplace). Wytypować i odinstalować podejrzane/ostatnio aktualizowane.
  2. Rotacja i unieważnienie wszystkich tokenów npm/GitHub/PAT, kluczy CI/CD, cookies sesyjnych przeglądarki; włączyć 2FA i ograniczyć zakres uprawnień (fine-grained PAT).
  3. Izolacja stacji roboczych dev: odłączenie od sieci, skan EDR/AV, detekcja SOCKS proxy i ukrytych usług VNC/RAT; przegląd autostartów i harmonogramów zadań.
  4. Przegląd repozytoriów i rejestrów: niezwłoczne sprawdzenie ostatnich publikacji/commitów/wersji paczek pod kątem nietypowych zmian i „niewidzialnego” Unicode.

W kolejnych dniach (hardening):

  • Wymuś weryfikację wydawcy i pinning zaufanych rozszerzeń; ogranicz instalację do listy dozwolonych (allow-list). (Praktyka zalecana przez branżę w kontekście tego incydentu).
  • W pipeline’ach dodaj kontrole Unicode (detekcja znaków sterujących Bidi, zero-width, itd.) i policy skanów dla rozszerzeń/artefaktów przed dopuszczeniem do stacji dev.
  • Egzekwuj zasadę najmniejszych uprawnień dla tokenów (scopes, TTL, rotacja), ochronę sekretów i monitoring publikacji (alerty przy zmianie maintainerów lub kluczy publikacyjnych).
  • Użyj EDR z regułami na nietypowe połączenia proxy/VNC i anomalie narzędzi deweloperskich; przegląd ruchu wychodzącego pod kątem tuneli SOCKS.

Artefakty/detekcja (przykłady do playbooka IR):

  • Skan plików źródłowych pod kątem znaków: \u202E, \u2066–\u2069, \u200B itd. (Bidi/zero-width).
  • Audyt folderów rozszerzeń ~/.vscode/extensions / %USERPROFILE%\.vscode\extensions pod kątem niepodpisanych/nieznanych vendorów i recent-modified. (Dobre praktyki zgodne z doniesieniami o wektorze).

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

W porównaniu z wcześniejszymi incydentami „tylko” trojanizującymi pojedyncze rozszerzenie, GlassWorm łączy samopropagację (wykorzystanie świeżo wykradzionych tokenów do publikacji kolejnych zainfekowanych aktualizacji) z niewidzialnym kodem Unicode, co utrudnia review i automatyczną analizę. To jakościowy skok względem znanych kampanii typosquattingu i przejęć paczek NPM/VS Code.

Podsumowanie / kluczowe wnioski

  • GlassWorm uderza w samo serce SDLC – narzędzia deweloperskie – i omija klasyczne bramki kontrolne dzięki „niewidzialnym” trikom Unicode.
  • Organizacje powinny traktować sprawę jak incydent bezpieczeństwa łańcucha dostaw: natychmiastowa rotacja sekretów, czyszczenie stacji dev, whitelisting rozszerzeń i kontrole Unicode w pipeline’ach.
  • Nawet po usunięciu skażonych wtyczek, skradzione tokeny mogą umożliwiać dalsze nadużycia – higiena kluczy i monitoring publikacji są krytyczne.

Źródła / bibliografia

  • The Hacker News – „Self-Spreading ‘GlassWorm’ Infects VS Code Extensions…” (24 października 2025). (The Hacker News)
  • BleepingComputer – „Self-spreading GlassWorm malware hits OpenVSX, VS Code registries” (20 października 2025). (BleepingComputer)
  • Dark Reading – „Self-Propagating GlassWorm Attacks VS Code Supply Chain” (20 października 2025). (Dark Reading)
  • Truesec – „GlassWorm – Self-Propagating VSCode Extension Worm” (analiza techniczna, październik 2025). (Truesec)
  • Koi Security (blog) – przegląd zdolności GlassWorm i TTP (październik 2025). (koi.ai)

Raportowanie Incydentów W Zgodzie Z NIS2 – Jak Działa Zasada 24h/72h

Dlaczego raportowanie incydentów stało się kluczowe w dyrektywie NIS2

Dyrektywa NIS2 (Network and Information Systems Directive 2) wprowadza jednolite wymogi w całej UE dotyczące cyberbezpieczeństwa, w tym obowiązek szybkiego zgłaszania poważnych incydentów bezpieczeństwa. Organizacje uznane za podmioty kluczowe lub istotne (ang. essential and important entities) muszą raportować incydenty o znaczącym wpływie na usługi zgodnie z zasadą 24h/72h.

Czytaj dalej „Raportowanie Incydentów W Zgodzie Z NIS2 – Jak Działa Zasada 24h/72h”