Archiwa: Security News - Strona 250 z 267 - Security Bez Tabu

Kategoria: Security News

TEE.Fail: nowy atak, który podważa „confidential computing” na CPU Intela, AMD i w ekosystemie GPU NVIDIA

Wprowadzenie do problemu / definicja luki

Zespół badaczy z Georgia Tech i Purdue przedstawił technikę TEE.Fail, która z użyciem taniego (≈< 1000 USD) interposera magistrali DDR5 pozwala odczytywać tajemnice z TEE (Trusted Execution Environment) nowej generacji – m.in. Intel TDX/SGX oraz AMD SEV-SNP (nawet z włączonym Ciphertext Hiding). Co więcej, wykradzione klucze atestacyjne umożliwiają podszywanie się pod zaufane środowiska i podważają modele zaufania także w GPU Confidential Computing NVIDII (np. H100).

W skrócie

  • Vektor ataku: pasywny podsłuch ruchu pamięci DDR5 z interposerem; brak potrzeby modyfikacji danych w locie.
  • Słaby punkt: deterministyczne szyfrowanie pamięci TEE (ta sama dana → ten sam szyfrogram), co umożliwia korelację wzorców i ekstrakcję kluczy.
  • Skutki: kradzież kluczy ECDH i kluczy atestacyjnych TDX/SGX, fałszowanie atestacji (także dla GPU-CC NVIDII), uruchamianie zadań poza TEE przy „zielonej” atestacji.
  • Koszt/próg wejścia: komponenty „z półki”, całość < 1000 USD.
  • Status vendorów: Intel potwierdził badania i utrzymuje, że ataki fizyczne pozostają poza modelem zagrożeń dla SGX/TDX; publikacja ogłoszenia bezpieczeństwa 28 października 2025 r.

Kontekst / historia / powiązania

TEE.Fail to następca ataków WireTap i Battering RAM, które dotyczyły DDR4 oraz starszych platform (gł. SGX/SEV bez DDR5). Kluczowa różnica: pierwsza demonstracja praktycznej skuteczności na DDR5 oraz CVM (Confidential VMs) opartych o Intel TDX i AMD SEV-SNP – czyli rozwiązania stanowiące fundament współczesnych wdrożeń „confidential computing”.

Analiza techniczna / szczegóły luki

Interposer DDR5. Badacze zbudowali interposer podpinany do jednego kanału DDR5 DIMM (DDR5 ma dwa kanały na moduł, co upraszcza konstrukcję) i pasywnie przechwytywali cały ruch DRAM między CPU a pamięcią. Zapis/odczyt są widoczne nawet przy szyfrowaniu pamięci przez TEE.

Szyfrowanie deterministyczne. SGX/TDX oraz SEV-SNP używają trybów szyfrowania pamięci, które w praktyce są deterministyczne (identyczny plaintext → identyczny ciphertext w tej samej lokalizacji). To umożliwia budowę słowników i korelację wzorców; na ilustracjach badaczy różnica między prawidłowym szyfrowaniem a deterministycznym jest wyraźna.

Ekstrakcja i fałszowanie atestacji (Intel). Z przechwyconych śladów udało się pozyskać Provisioning Certification Key – per-CPU klucz z łańcucha zaufania SGX/TDX. Mając go, atakujący fałszuje raporty atestacyjne i może uruchamiać obciążenia poza TEE, a jednak przekonać systemy, że działają w zaufanym CVM (nawet na innej architekturze CPU). Intel potwierdza i podkreśla, że fizyczne interposery są out-of-scope dla modelu zagrożeń TDX/SGX.

AMD SEV-SNP z Ciphertext Hiding. Badacze pokazali, że ataki działają nawet przy aktywnym Ciphertext Hiding (Zen 5/EPYC 5. gen), a więc mimo ograniczania widoczności szyfrogramów przez hypervisor. Dodatkowo zademonstrowano ekstrakcję kluczy podpisu OpenSSL wewnątrz VM chronionej przez SEV-SNP.

GPU Confidential Computing (NVIDIA). Ponieważ GPU-CC NVIDII opiera się na atestacji CVM CPU (TDX/SEV-SNP), przejęcie/wyłudzenie kluczy atestacyjnych CPU pozwala „pożyczać” atestacje GPU i prezentować zadania AI jako uruchomione w zabezpieczonym środowisku, choć faktycznie tak nie jest. To łamie model zaufania dla zadań AI (np. chaty LLM, inferencja modeli) na H100.

Praktyczne konsekwencje / ryzyko

  • Chmura/CVM: dostawca z dostępem fizycznym do serwera może podsłuchiwać i fałszować atestacje, wynosząc dane/klucze bez wykrycia z poziomu software’u.
  • Blockchain/MEV: demonstracja fałszowania atestacji TDX w sieci BuilderNet (Ethereum block builders), otwierająca drogę do niejawnego frontrunningu i dostępu do poufnych transakcji.
  • AI/LLM-as-a-Service: możliwość „udowodnienia” GPU-CC przy realnym uruchomieniu poza TEE → ryzyko wycieku danych treningowych/kluczy API i manipulacji wynikiem.
  • Szeroki ekosystem TEE: Intel oficjalnie klasyfikuje interposery jako poza modelem zagrożeń, co oznacza, że brak łatwych łatek firmware’owych – konieczne będą zmiany w założeniach architektonicznych i procesach operacyjnych.

Rekomendacje operacyjne / co zrobić teraz

  1. Modeluj zagrożenia z fizycznym dostępem – jeśli Twoje ryzyko obejmuje atakującego z dostępem do szafy serwerowej, nie zakładaj, że TDX/SEV-SNP w DDR5 zapewnią pełną poufność. Zaktualizuj oceny ryzyka i umowy z operatorami DC/colocation.
  2. Zarządzaj zaufaniem do atestacji – wiąż atestacje z tożsamością sprzętu i lokalizacją (asset-binding), wdrażaj policyjne listy dozwolonych hostów, łącz atestację z kontrolą łańcucha dostaw/IMD i monitoringiem fizycznym.
  3. Segmentuj dane wrażliwe – minimalizuj ekspozycję tajemnic w TEE (krótkotrwałe klucze, HSM/KMS poza hostem, dzielone sekrety). Dla AI rozważ prywatność po stronie klienta/lokalne szyfrowanie przed wysłaniem do chmury. (Wnioski operacyjne na bazie skutków TEE.Fail).
  4. Twarde kontrole fizyczne – plombowanie, CCTV, ewidencja serwisantów, detection-by-presence (wykrywanie rozpięcia DIMM/risera). (Wnioski operacyjne wynikające z wektora ataku).
  5. Śledź komunikaty vendorów – Intel opublikował ogłoszenie bezpieczeństwa (28.10.2025). Monitoruj zapowiedziane stanowiska AMD i NVIDII dot. dostosowań modelu zagrożeń/mitigacji.
  6. Architektura „defense-in-depth” – TEE traktuj jako warstwę, nie jedyne zabezpieczenie. Odnów procedury DLP, EDR w hipervisorze, izolację sieciową CVM i kontrole dostępu do danych w spoczynku. (Dobre praktyki ogólne poparte kontekstem NCSC).

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

  • WireTap/Battering RAM (DDR4): atak na starszą generację pamięci/CPU; TEE.Fail eskaluje do DDR5 i CVM (TDX/SEV-SNP), co uderza w aktualne wdrożenia chmurowe.
  • RMPocalypse (CVE-2025-0033, AMD SEV-SNP): błąd inicjalizacji RMP łamie integralność VMs; TEE.Fail to atak fizyczny/side-channel na poufność + atestację. Razem pokazują, że zarówno błędy implementacji, jak i założenia modelu zagrożeń osłabiają dzisiejsze TEE.

Podsumowanie / kluczowe wnioski

TEE.Fail nie jest „kolejną” podatnością z CVE, lecz uderzeniem w fundamenty zaufania do confidential computing w epoce DDR5. Przy fizycznym dostępie do serwera i deterministycznym szyfrowaniu pamięci, granice TEE znikają: można wyciągnąć klucze, fałszować atestacje i obchodzić GPU-CC. Organizacje muszą przewartościować model zagrożeń, twardo kontrolować fizyczny dostęp oraz wiązać atestację ze sprzętem i lokalizacją. Krótkoterminowo – operacyjne obejścia i polityki; długoterminowo – zmiany w projektach szyfrowania pamięci i łańcuchach atestacji.

Źródła / bibliografia

  • Strona badaczy: TEE.fail – Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (FAQ, scenariusze ataku, skutki, mitgacje). (tee.fail)
  • Intel Security Announcement 2025-10-28-001 (TEE.fail) – stanowisko Intela i zakres modeli zagrożeń. (Intel)
  • BleepingComputer: „TEE.Fail attack breaks confidential computing on Intel, AMD, NVIDIA CPUs” – przegląd skutków i demonstracji (BuilderNet, fałszywe atestacje, wyciek ECDH). (BleepingComputer)
  • The Hacker News: „New TEE.Fail Side-Channel Attack Extracts Secrets from Intel and AMD DDR5 Secure Enclaves” – kontekst kosztu sprzętu i nowości względem DDR4. (The Hacker News)
  • NCSC (Szwajcaria): „Technology brief: Confidential Computing” – tło i modele TEE/CVM dla zrozumienia wpływu TEE.Fail. (ncsc.admin.ch)

TurboMirai „Aisuru”: botnet IoT odpowiedzialny za ataki DDoS >20 Tb/s. Co to znaczy dla operatorów i firm?

Wprowadzenie do problemu / definicja luki

Najnowsze obserwacje firm badawczych wskazują na gwałtowny wzrost mocy wolumetrycznych ataków DDoS realizowanych przez klasę botnetów „TurboMirai”. Najgłośniejszy przedstawiciel — Aisuru — ma za sobą publicznie raportowane uderzenia przekraczające 20 Tb/s oraz 4 Gpps, w większości wymierzone w ekosystem gier online. Paradoksalnie, kod Aisuru nie generuje ruchu ze sfałszowanymi źródłami (no-spoofing), co ułatwia śledzenie i sanację zainfekowanych urządzeń po stronie operatorów sieci i dostawców internetu.

W skrócie

  • Moc ataków: >20 Tb/s i/lub >4 Gpps; notowane incydenty sięgały nawet ~29,6 Tb/s (krótkie „testy” mocy).
  • Pochodzenie: klasa TurboMirai — warianty Mirai z naciskiem na direct-path (bez refleksji/amplifikacji) i zwiększoną przepustowość per węzeł.
  • Brak spoofingu: ułatwia traceback i powiązanie ruchu z konkretnymi abonentami (SAV na brzegu dostępowym + brak uprawnień w urządzeniach).
  • Celowniki: głównie gaming/ISP, ale wpływ bywa systemowy (zatory międzyoperatorskie, awarie line-cardów).
  • Kompozycja botnetu: routery SOHO, rejestratory DVR, kamery IP i inne CPE ze wspólnymi OEM-ami/firmware.

Kontekst / historia / powiązania

Aisuru zadebiutował publicznie w 2024 r. w kontekście ataków na platformy gamingowe. W 2025 r. skala i częstotliwość rosły — od 6,3 Tb/s (incydent na KrebsOnSecurity w maju) przez przekroczenia 11 Tb/s, a następnie publiczne demonstracje mocy >22 Tb/s i ~29,6 Tb/s w październiku. Trend potwierdza szerszą narrację branżową: ostatnie lata to wysyp „hiper-wolumetrycznych” ataków oraz przejście od prostego DDoS do DDoD (Distributed Denial of Defense) — kampanii projektowanych do przeciążania samych systemów obrony.

Analiza techniczna / szczegóły luki

Wektory i charakterystyki ruchu

  • Direct-path UDP/TCP/GRE z przewagą średnich rozmiarów pakietów (ok. 540–750 B); widoczne także małe pakiety w atakach pps-owych. Zmienność flag TCP; obserwowano nawet 119 kombinacji w jednym ataku.
  • „Carpet bombing” oraz pseudo-losowa rotacja portów źródłowych/docelowych.
  • Wysokie Gpps uszkadzały/wybijały karty liniowe routerów szaszetowych (chassis line cards).
  • Większość kampanii z Aisuru to pojedynczy wektor direct-path; okazjonalnie łączony z innymi usługami booter/stresser w multivektor.

Dlaczego brak spoofingu?
Malware działa bez przywilejów w systemach CPE, a na brzegu wielu sieci dostępnych działa SAV/BCP38, co uniemożliwia fałszowanie źródeł. Efekt uboczny: możliwy traceback → korelacja z abonentem → kwarantanna/remediacja.

Skład i funkcje botnetu
Węzły to głównie routery domowe, CCTV, DVR i pokrewne CPE. Operatorzy aktywnie poszerzają pulę infekowalnych urządzeń, a Aisuru oferuje też usługę proxy rezydencyjnych do odbijania ataków L7/HTTPS z zewnętrznych harnessów.

Praktyczne konsekwencje / ryzyko

  • Operatorzy/ISP: z Aisuru znane są odpływy (outbound) >1 Tb/s z sieci dostępowych wskutek botów u abonentów; skutkiem bywa kongestia między AS-ami, degradacja QoS dla „postronnych” klientów, a w skrajnych przypadkach awarie kart liniowych.
  • Dostawcy gier / CDN / hosting: krótkotrwałe, ale ekstremalne piki mogą przewyższać lokalną/trasową pojemność, powodując łańcuchowe zakłócenia i re-routingi.
  • Przedsiębiorstwa: choć większość kampanii celuje w gaming/ISP, model direct-path i warstwa L3/L4 oznacza, że dowolny nieutwardzony zasób internetowy może zostać „przetestowany” lub wykorzystany do demonstracji mocy. Trend strategiczny DDoD pokazuje, że celem bywa sama obrona, nie tylko usługa.

Rekomendacje operacyjne / co zrobić teraz

Dla operatorów i dużych AS-ów

  1. Instrumentacja wszystkich krawędzi (w tym outbound/crossbound), by detekcja i tłumienie wychodzących ataków miały ten sam priorytet co inbound.
  2. IDMS + iACL/BCP-y: stosować inteligentne systemy łagodzenia (np. Arbor TMS/Sightline) oraz najlepsze praktyki iACL, Flowspec i S/RTBH, pamiętając o limitach sprzętowych na reguły.
  3. SAV/BCP38 konsekwentnie na brzegu dostępowym; automatyzacja traceback→powiadomienie→kwarantanna dla zainfekowanych CPE.
  4. Proaktywny rekonesans wewnętrzny w celu identyfikacji podatnych CPE u klientów (policyjne procedury remediacji/wymiany).

Dla firm (odbiorców usług)

  • Dwutorowa strategia DDoS: łączona obrona on-prem/edge + transit/cloud scrubbing, testy runbooków i procedur kryzysowych.
  • Segmentacja i separacja: rozdzielone łącza dla ruchu użytkowników wewnętrznych vs. usług publicznych; whitelisty protokołów/portów i limity rate.
  • Ćwiczenia: regularne testy „table-top” i techniczne (z udziałem dostawcy scrubbingu), w tym scenariusze krótkich hiper-pików Tb/s.

Dla zespołów SecOps/NetOps

  • Telemetria L3/L4 z wysoką rozdzielczością (pps/bps/rozmiary pakietów), alerting na outbound anomaliach i „carpet-bombing”.
  • Higiena CPE w politykach zakupowych i SLA z ISP (wymagania dot. aktualizacji, wyłączenia usług zbędnych, domyślne hasła).

Różnice / porównania z innymi przypadkami

  • Mirai (2016) vs. TurboMirai (2025): Mirai słynęło z refleksji/amplifikacji i rekordów setek Gb/s; TurboMirai/Aisuru dostarcza wieloterabitowe piki bez spoofingu, czystym direct-path z botów CPE, przy czym moc per węzeł jest większa, a wektory bardziej zróżnicowane (np. GRE).
  • Klasyczne DDoS vs. DDoD: dzisiejsze kampanie nie zawsze „idą w wolumen” — często atakują mechanizmy obrony i łańcuchy dostawcze (multidestination, poziomy horyzontalne), co wymaga odporności architekturalnej, nie tylko „większej rury”.

Podsumowanie / kluczowe wnioski

  • Aisuru to na dziś najgroźniejszy przykład klasy TurboMirai: ataki >20 Tb/s, rekordowe piki ~29,6 Tb/s, uderzenia głównie w gaming/ISP, ale z efektem ubocznym dla szerokiego internetu.
  • Brak spoofingu to zarówno słabość (łatwiejszy traceback), jak i ostrzeżenie: jeśli outbound suppression nie jest wdrożony, wasza sieć może stać się źródłem problemu.
  • Priorytet na krawędziach: równoważenie inbound/outbound, testy gotowości, modernizacja narzędzi IDMS oraz egzekwowanie BCP.

Źródła / bibliografia

  • SecurityWeek: TurboMirai-Class ‘Aisuru’ Botnet Blamed for 20+ Tbps DDoS Attacks (28 października 2025). (SecurityWeek)
  • NETSCOUT ASERT: Aisuru and Related TurboMirai Botnet DDoS Attack Mitigation and Suppression—October 2025—v1.0 (24 października 2025). (NETSCOUT)
  • KrebsOnSecurity: DDoS Botnet Aisuru Blankets US ISPs in Record DDoS (10 października 2025) oraz KrebsOnSecurity Hit With Near-Record 6.3 Tbps DDoS (20 maja 2025). (Krebs on Security)
  • Akamai: Move Over, DDoS: It’s the Era of Distributed Denial of Defense (DDoD) (16 września 2025) – szerszy kontekst trendów. (akamai.com)

Cyberprzestępcy handlują 183 mln skradzionych poświadczeń na Telegramie i podziemnych forach — co naprawdę się stało (i co z tym zrobić)

Wprowadzenie do problemu / definicja luki

Na przełomie października 2025 r. firma Synthient przekazała do Have I Been Pwned (HIBP) ogromny zbiór danych z ekosystemu infostealerów i podziemnych kanałów wymiany (m.in. Telegram, fora, social media). Po normalizacji i deduplikacji w HIBP pozostało 183 mln unikatowych adresów e-mail z odpowiadającymi im hasłami oraz domenami serwisów, w których były użyte. Co istotne, 16,4 mln adresów nie pojawiało się wcześniej w publicznych naruszeniach monitorowanych przez HIBP.

W skrócie

  • Skąd dane? Głównie logi infostealerów oraz listy do credential stuffing zbierane z Telegrama i forów.
  • Skala: 3,5 TB surowych plików, 23 mld wierszy; po deduplikacji 183 mln unikatowych adresów.
  • Nowość danych: ok. 9% (16,4 mln) adresów wcześniej nie widziano w HIBP.
  • Nie był to „wyciek Gmaila”: Google zdementowało doniesienia o rzekomym włamaniu do Gmaila; to agregat danych z wielu źródeł, głównie z infekcji malware.

Kontekst / historia / powiązania

Publikacje branżowe i wpisy twórcy HIBP, Troya Hunta, podkreślają, że ekosystem wycieków na Telegramie jest mocno recyklingowany: te same logi i combolisty są wielokrotnie przepakowywane i udostępniane. Dlatego każdy taki zbiór wymaga oczyszczenia i weryfikacji. Właśnie ten proces przeprowadził HIBP przed dodaniem rekordu „Synthient Stealer Log Threat Data”. Równolegle w mediach przetoczyła się fala błędnych nagłówków o „wielkim włamaniu do Gmaila”, czemu Google publicznie zaprzeczyło.

Analiza techniczna / szczegóły luki

Źródła danych. Zgodnie z opisem Synthient, ich system przez wiele miesięcy monitorował ~20 kontami Telegrama kanały powiązane z handlem logami, wykrywał linki-zaproszenia, pobierał archiwa, parsował różne, niespójne formaty i deduplikował z użyciem hashy plików oraz struktur w ClickHouse. Główne role w ekosystemie: primary sellers (sprzedawcy pierwotni), aggregators (wtórni kolekcjonerzy) i traffers (dystrybutorzy malware).

Weryfikacja i statystyki.

  • HIBP raportuje rekord „Synthient Stealer Log Threat Data” z opisem pól: adres e-mail, witryna (np. gmail.com, facebook.com) i użyte hasło. Po odrzuceniu duplikatów: 183 mln unikatowych adresów.
  • Hunt opisuje, że próbka pokazała ~91–92% adresów już znanych HIBP (recykling), a ~8–9% było nowych; po pełnym załadowaniu to 16,4 mln wcześniej nieobecnych w HIBP. Dodatkowo część zbioru stanowią listy do credential stuffing, nie tylko czyste logi infostealerów.

„To nie wyciek Gmaila”.
Google wyjaśniło, że mówimy o zebranej mieszance z wielu incydentów i infekcji, nie o świeżym ataku na jedną platformę. To nie podważa ryzyka dla użytkowników, ale zmienia interpretację: nie ma jednego „źródła włamania”, lecz wieloletni dryft poświadczeń po kanałach przestępczych.

Praktyczne konsekwencje / ryzyko

  • Przejęcia kont (ATO) przez credential stuffing i logowanie z przejętych sesji.
  • Spear-phishing i oszustwa oparte na znajomości serwisów, w których ofiara ma konta (domena z logu).
  • Lateral movement do środowisk firmowych, jeśli e-mail prywatny i służbowy współdzielą hasła.
  • Ujawnienie wzorców haseł, ułatwiające łamanie kolejnych skrótów.
  • Ryzyko reputacyjne i prawne (RODO) w razie wtórnego naruszenia w organizacji.

Warto założyć, że część haseł wciąż działa, zwłaszcza tam, gdzie MFA nie jest egzekwowane i użytkownicy recyklingują hasła.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i pracowników:

  1. Sprawdź adresy e-mail w HIBP (adres + „pwned sites” / „pastes”). W razie trafienia — natychmiastowa zmiana haseł i włączenie MFA (lub passkeys jako preferowany mechanizm).
  2. Unikalne hasło per serwis + menedżer haseł.
  3. Higiena urządzeń: aktualizacje, EDR/anty-malware, ostrożność wobec załączników i cracków — to infostealery są pierwotnym źródłem wycieku.

Dla zespołów bezpieczeństwa:

  1. Masowy reset haseł i/lub wymuszenie rotacji tam, gdzie brak MFA lub wykryto recykling.
  2. Egzekwuj MFA / passkeys dla poczty, VPN, SaaS i krytycznych aplikacji. Google i branża wskazują to jako najlepszą obronę przed kradzieżą poświadczeń.
  3. Blokada recyklingu haseł (zasady złożoności + sprawdzanie przeciw słownikom wycieków przy zmianie hasła).
  4. Detekcja ATO: reguły SIEM/UEBA na nietypowe logowania (nowe ASN, niestandardowe UA, nietypowa pora/geo), korelacja z listami adresów z HIBP.
  5. Unieważnij sesje po zmianie haseł; włącz powiadomienia o nowych logowaniach.
  6. Hunting na infostealery: IOC/IOA popularnych rodzin (Raccoon, RedLine, Vidar, Lumma itd.), kontrola egzekucji przeglądarek i kradzieży browser creds.
  7. Hardening przeglądarek (wyłączenie zapamiętywania haseł, izolacja profili), konteneryzacja przeglądania dla ról wysokiego ryzyka.
  8. Zarządzanie tożsamością: wdrożenie risk-based auth, FIDO2, ograniczenie dostępu uprzywilejowanego, just-in-time.

Różnice / porównania z innymi przypadkami

  • Combolisty vs. logi infostealerów: combolisty są zlepkiem starych wycieków (często bez kontekstu), podczas gdy logi infostealerów zawierają pary e-mail-hasło + domena, co podnosi skuteczność ATO. Zbiór Synthient zawiera obie kategorie, stąd duża objętość i konieczność deduplikacji.
  • „Jedno wielkie naruszenie” vs. „agregat wielu źródeł”: tutaj mamy agregat; brak pojedynczego punktu kompromitacji (np. „Gmail breach”).

Podsumowanie / kluczowe wnioski

  • Zbiór 183 mln unikatowych adresów z hasłami to realne ryzyko ATO na masową skalę, nawet jeśli większość wpisów to dane recyklingowane. 16,4 mln „nowych” adresów czyni ten przypadek wyjątkowo istotnym operacyjnie.
  • To nie jest wyciek jednego dostawcy poczty. To skutek lat infekcji infostealerami i wtórnego obiegu danych na Telegramie. Źródłem problemu są zainfekowane urządzenia i recykling haseł.
  • Priorytetem powinno być pełne egzekwowanie MFA/passkeys, polityka unikalnych haseł, monitoring ATO i hunting na infostealery w środowisku.

Źródła / bibliografia

  1. SecurityWeek — „Cybercriminals Trade 183 Million Stolen Credentials on Telegram, Dark Forums” (28 paź 2025). (SecurityWeek)
  2. Troy Hunt — „Inside the Synthient Threat Data” (22 paź 2025). (Troy Hunt)
  3. Have I Been Pwned — wpis „Synthient Stealer Log Threat Data”. (Have I Been Pwned)
  4. Synthient — „The Stealer Log Ecosystem: Processing Millions of Credentials a Day” (21 paź 2025). (Synthient)
  5. BleepingComputer — „Google disputes false claims of massive Gmail data breach” (27–28 paź 2025). (BleepingComputer)

CISA publikuje trzy nowe alerty dla systemów ICS (28 października 2025)

Wprowadzenie do problemu / definicja luki

Amerykańska CISA poinformowała o trzech doradcach bezpieczeństwa dla środowisk ICS/OT opublikowanych 28 października 2025 r.. Pakiet obejmuje jeden nowy doradca ICS dotyczący rozwiązań Schneider Electric EcoStruxure, jeden doradca ICS Medical dla Vertikal Systems (zaplecze systemu Hospital Manager) oraz aktualizację wcześniejszego doradcy dot. sterowników Schneider Electric Modicon. Doradcy CISA są krótkimi, technicznymi streszczeniami podatności i zaleceń łagodzących dla operatorów infrastruktury krytycznej.

W skrócie

  • Nowy doradca ICS: ICSA-25-301-01 — Schneider Electric EcoStruxure (szczegóły techniczne i środki zaradcze).
  • Doradca ICS Medical: ICSMA-25-301-01 — Vertikal Systems Hospital Manager Backend Services (podatności informacyjne w zapleczu systemu szpitalnego).
  • Aktualizacja wcześniejszego doradcy ICS: ICSA-24-352-04 — Schneider Electric Modicon (Update B) — przypomnienie o ryzykach i aktualnych zaleceniach dla linii Modicon.

Kontekst / historia / powiązania

Październik 2025 r. przyniósł wzmożoną liczbę publikacji CISA dla ICS — agencja już 21 i 23 października wydała odpowiednio 10 i 8 doradców. Trend ten odzwierciedla rosnącą powierzchnię ataku w OT oraz dużą aktywność producentów i badaczy zgłaszających luki.

Analiza techniczna / szczegóły luki

1) ICSA-25-301-01 — Schneider Electric EcoStruxure
Tytuł doradcy wskazuje na komponent(y) z rodziny EcoStruxure. Doradca zawiera standardowo: listę wspieranych wersji, oceny CVSS, wektor ataku (zwykle zdalny, niska złożoność), skutki (np. RCE/eskalacja uprawnień/DoS) oraz działania naprawcze producenta (aktualizacje, re-konfiguracje). Oficjalna karta doradcy (ICSA-25-301-01) jest potwierdzona przez CISA.

2) ICSMA-25-301-01 — Vertikal Systems Hospital Manager Backend Services (ICS Medical)
Doradca medyczny wskazuje na podatności ujawnienia informacji w zapleczu aplikacji (m.in. wycieki danych sesji, nagłówków autoryzacyjnych, stosów błędów, ścieżek wewnętrznych). Japońskie JVN (Japan Vulnerability Notes) publikuje zbieżny opis ryzyka dla tego produktu (CWE-497, CWE-209), co wzmacnia wagę ostrzeżenia CISA. Wersje sprzed 19 września 2025 r. są podatne.

3) ICSA-24-352-04 — Schneider Electric Modicon (Update B)
To aktualizacja doradcy z 2024 r., odświeżona w 2025 r. (ostatnia rewizja 18 marca 2025). Dotyczy sterowników Modicon (np. serie M241/M251/M258/LMC058), gdzie wcześniej raportowano m.in. błędy walidacji danych mogące prowadzić do RCE lub zakłóceń procesu. CISA utrzymuje stronę doradcy i aktualizuje zalecenia.

Uwaga: CISA ma obecnie ograniczony dostęp publiczny (część stron może zwracać błąd 403), jednak metadane doradców — numery, daty i tytuły — są widoczne w indeksie i wpisach przeglądowych.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla ciągłości procesu: luki w EcoStruxure/Modicon mogą dotyczyć sterowania liniami produkcyjnymi, energetyką czy gospodarką wodno-ściekową — skutkiem może być nieautoryzowana zmiana parametrów procesu, przestój lub manipulacja odczytami.
  • Ryzyko dla danych medycznych: ujawnienia informacji w Vertikal Systems mogą ułatwić pivoting w sieci szpitalnej i naruszenia poufności danych pacjentów, nawet jeśli luka nie jest od razu RCE.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast (0–24 h):

  1. Identyfikacja ekspozycji: skoreluj inwentarz OT/ICS z numerami doradców (ICSA-25-301-01, ICSMA-25-301-01, ICSA-24-352-04). Ustal, czy komponenty EcoStruxure/Modicon oraz Vertikal Systems są obecne w Twojej sieci.
  2. Segmentacja i minimalizacja dostępu: wymuś separację stref (ISA/IEC 62443), zablokuj nieużywane porty/protokoły, ogranicz management interfaces wyłącznie do sieci uprzywilejowanych/VPN. (CISA konsekwentnie rekomenduje segmentację i kontrolę dostępu w doradcach ICS).
  3. Twarde reguły w zaporach: domyślnie blokuj Modbus/TCP 502 oraz inne protokoły ICS na granicach stref; tylko allow-list. (Zalecenie spójne z praktykami CISA/producentów).

Krótki termin (1–2 tygodnie):
4. Patching / aktualizacje producenta: zastosuj łatki i hot-fixy publikowane przez Schneider Electric (EcoStruxure/Modicon) oraz poprawki/konfiguracje od Vertikal Systems; w razie braku łatek — zastosuj obejścia z doradców (defense-in-depth).
5. Hardening aplikacji webowych w sieci medycznej: wyłącz ujawnianie stack trace’ów i wersji frameworków (ASP.NET customErrors), wdroż WAF z regułami dla wycieków nagłówków/autoryzacji.
6. Monitoring & detekcja: wzbogacisz reguły IDS/IPS o sygnatury dla protokołów ICS oraz reguły anomalii (np. nieoczekiwane funkcje Modbus). Odnieś się do ATT&CK for ICS przy budowie scenariuszy detekcji.

Średni termin (≤ 30 dni):
7. Testy regresyjne na kopiach / OT lab: zanim wdrożysz łatki do produkcji, przetestuj wpływ na proces. (Najlepsza praktyka potwierdzana w materiałach producentów i społeczności ICS).
8. Przegląd architektury stref i kanałów zdalnych: ogranicz zdalne dostępy serwisowe dostawców (jump hosty, PAM, JIT).

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

  • ICS vs ICS Medical: doradca ICSMA (Vertikal Systems) dotyczy systemu klasy HIS/HMS. Tu skutki dominują w obszarze ujawnienia informacji i przyspieszenia rekonesansu, a nie bezpośredniego RCE — w przeciwieństwie do wielu doradców ICS (EcoStruxure/Modicon), gdzie częściej spotyka się RCE/eskalację i zakłócenia procesu.
  • Nowy doradca vs aktualizacja: ICSA-25-301-01 to nowa publikacja; ICSA-24-352-04 (Update B) rewiduje istniejące zalecenia, co bywa równie istotne dla długowiecznych instalacji OT, które nie mogły wdrożyć poprawek w 2024 r.

Podsumowanie / kluczowe wnioski

  • 28.10.2025 CISA wydała trzy istotne doradcy obejmujące EcoStruxure, Vertikal Systems (ICSMA) oraz Modicon (aktualizacja).
  • Operatorzy OT/ICS i placówki medyczne powinni natychmiast sprawdzić ekspozycję, wdrożyć segmentację i update’y oraz poprawić konfiguracje ujawniające informacje.
  • Nawet „tylko informacyjne” wycieki (jak w Vertikal Systems) realnie obniżają koszt ataku i mogą prowadzić do eskalacji w sieci OT/IT.

Źródła / bibliografia

  1. CISA — Alert: „CISA Releases Three Industrial Control Systems Advisories”, 28 października 2025. (potwierdza zestaw trzech doradców i datę) (CISA)
  2. CISA — ICS Advisory: ICSA-25-301-01 „Schneider Electric EcoStruxure”. (strona doradcy) (CISA)
  3. CISA — ICS Medical Advisory: ICSMA-25-301-01 „Vertikal Systems Hospital Manager Backend Services”. (strona doradcy) (CISA)
  4. JVN (Japan Vulnerability Notes): opis podatności Vertikal Systems (CWE-497, CWE-209, wersje sprzed 2025-09-19). (potwierdzenie technicznych szczegółów ICSMA) (jvn.jp)
  5. CISA — ICS Advisory (aktualizacja): ICSA-24-352-04 „Schneider Electric Modicon (Update B)”, ostatnia rewizja 18.03.2025. (tło i bieżące zalecenia) (CISA)
  6. WaterISAC — przegląd publikacji CISA (TLP:CLEAR) — trend październikowych doradców ICS. (kontekst operacyjny) (WaterISAC)

    Krytyczna luka w python-socketio pozwala przejąć serwery przez kolejkę komunikatów (CVE-2025-61765)

    Wprowadzenie do problemu / definicja luki

    W bibliotece python-socketio (implementacja Socket.IO dla Pythona) ujawniono podatność CVE-2025-61765, która w środowiskach wieloserwerowych umożliwia zdalne wykonanie kodu (RCE) poprzez złośliwą deserializację komunikatów przesyłanych przez wewnętrzną kolejkę wiadomości (np. Redis, RabbitMQ). Błąd dotyczy wersji < 5.14.0 i wynika z użycia modułu pickle do wymiany danych między procesami. Producent usunął pickle i przeszedł na JSON w wydaniu naprawczym.

    W skrócie

    • ID: CVE-2025-61765
    • Zakres wersji: od bardzo wczesnych wydań do < 5.14.0
    • Wektor ataku: atakujący, który uzyska dostęp do kolejki komunikatów używanej przez klaster python-socketio, może wstrzyknąć spreparowany „pickle”, który zostanie wykonany po stronie serwera.
    • Skutki: pełne wykonanie arbitralnego kodu w kontekście serwera aplikacyjnego; możliwe przejęcie systemu i danych.
    • Ocena ryzyka: średnio-wysokie — zależne od ekspozycji kolejki; nie jest to „pre-auth over the Internet”, ale często krytyczne w realnych, źle zabezpieczonych wdrożeniach. (Przykładowe klasyfikacje i analizy ryzyka publikują bazy NVD/Wiz/Miggo).
    • Naprawa: aktualizacja do >= 5.14.0 (zmiana serializacji na JSON) + utwardzenie kolejki.

    Kontekst / historia / powiązania

    Problem jest klasycznym przypadkiem insecure deserialization (CWE-502) w ekosystemie Pythona: pickle jest niebezpieczny dla niezaufanych danych i wielokrotnie był źródłem RCE w bibliotekach serwerowych. W tym incydencie błąd ogranicza się do komunikacji międzyserwerowej — ale w praktyce liczne wdrożenia mają kolejki MQ dostępne w tej samej sieci co aplikacje lub nawet (błędnie) wystawione na zewnątrz. Analizy bezpieczeństwa i doradcy branżowi zwracają uwagę, że łatanie pojedynczej biblioteki nie rozwiązuje systemowego nadużycia pickle.

    Analiza techniczna / szczegóły luki

    • Architektura klastrowa: python-socketio w trybach wieloprocesowych/wieloserwerowych wykorzystuje kolejkę MQ do przesyłania komunikatów sterujących (np. rozsyłanie zdarzeń do wszystkich węzłów).
    • Słaby punkt: starsze wersje serializowały komunikaty pickle, a po stronie odbiorcy wykonywały pickle.loads(). Złośliwy obiekt „pickle” może zdefiniować metody (__reduce__ itp.), które spowodują wykonanie dowolnego kodu w trakcie deserializacji.
    • Warunek wstępny ataku: napastnik musi przejąć dostęp do kolejki (np. błędna konfiguracja, brak uwierzytelnienia TLS/ACL, ekspozycja portu, wcześniejsza kompromitacja). Wtedy wysyła spreparowany komunikat, który zostaje automatycznie odczytany i uruchamia się w procesie serwera.
    • Zmiana w patchu: od 5.14.0 komunikacja międzyserwerowa zamiast pickle używa JSON, eliminując egzekucję kodu podczas deserializacji. Dystrybutorzy Linuksa publikują aktualizacje bezpieczeństwa potwierdzające tę zmianę.

    Praktyczne konsekwencje / ryzyko

    • Przejęcie serwera aplikacyjnego: RCE w procesie python-socketio = możliwość doinstalowania web-shella, kradzież sekretów (kluczy API, tokenów), eskalacja przywilejów w systemie.
    • Ruch lateralny: przejęty węzeł klastra może być trampoliną do innych usług w VPC/segmentach.
    • Wpływ na dostępność: sabotaż broadcastów zdarzeń, DoS przez toksyczne komunikaty w kolejce.
    • Ślad w logach: artefakty w logach MQ (nietypowe ładunki), anomalie w dziennikach workerów/uwsgi/gunicorna, nagłe spajki CPU podczas deserializacji.

    Rekomendacje operacyjne / co zrobić teraz

    1. Natychmiastowa aktualizacja
      • Produkcja i staging: podnieś python-socketio do >= 5.14.0.
      • Przykład: pip install --upgrade "python-socketio>=5.14.0" pip freeze | grep python-socketio
      • Zweryfikuj, że nowe obrazy/kontenery używają zaktualizowanej wersji. Dystrybucje (np. SUSE) wydały już advisory z poprawką JSON→zamiast pickle.
    2. Utwardź kolejkę MQ (Redis/RabbitMQ/Kafka):
      • Brak ekspozycji publicznej, sieciowe segregacje (VPC/NSG/SG), dostęp tylko z hostów aplikacyjnych.
      • Uwierzytelnianie, ACL, TLS, rotacja haseł/kluczy; monitoring kanałów i rozmiaru kolejek.
    3. Higiena aplikacyjna i IR:
      • Przegląd logów kolejek i workerów od co najmniej 30 dni wstecz pod kątem nietypowych ładunków/deserializacji.
      • Jeżeli masz ślady kompromitacji: rotacja sekretów, ponowna emisja tokenów sesyjnych, przegląd kont/kluczy usługi.
      • Testy bezpieczeństwa: skan zależności (SCA) i audyt innych bibliotek używających pickle.
    4. Polityka na przyszłość:
      • Zakaz pickle w komponentach komunikacyjnych; preferuj JSON/MessagePack/Protobuf.
      • Wymuś review architektury klastra i „assume breach” w komponentach MQ.

    Różnice / porównania z innymi przypadkami

    W odróżnieniu od typowych zdalnych RCE dostępnych „z internetu”, tu warunkiem jest dostęp do wewnętrznej kolejki MQ. To ogranicza powierzchnię ataku, ale w wielu środowiskach „wewnętrzne” nie znaczy „bezpieczne” (mis-konfiguracje, brak uwierzytelnienia, łańcuch ataków). To także odróżnia CVE-2025-61765 od podatności w endpointach HTTP Socket.IO — problem dotyczy warstwy międzyserwerowej i deserializacji pickle.

    Podsumowanie / kluczowe wnioski

    • Zaktualizuj natychmiast do ≥ 5.14.0 i sprawdź obrazy/kontenery.
    • Zabezpiecz kolejkę MQ (TLS/ACL/segregacja sieci), bo to wektor ataku.
    • Audytuj logi pod kątem anomalii w komunikacji międzyserwerowej i rotuj sekrety przy podejrzeniu incydentu.
    • Traktuj pickle jako niedozwolony do komunikacji z komponentami, które mogą przetwarzać dane z niezaufanego źródła.

    Źródła / bibliografia

    • SC Media: „Python-socket.io module flaw lets attackers access business servers”, 27 października 2025. (SC Media)
    • GitHub Security Advisory dla python-socketio (GHSA-g8c6-8fjj-2r4m). (GitHub)
    • NVD – wpis dla CVE-2025-61765. (NVD)
    • SUSE: ogłoszenie aktualizacji bezpieczeństwa (JSON zamiast pickle). (suse.com)
    • Wiz/Miggo/Snyk – analizy wpływu i opis wektora przez złośliwą deserializację w środowiskach multi-server. (wiz.io)

    QNAP ostrzega: NetBak PC Agent dla Windows podatny na krytyczną lukę w ASP.NET Core (CVE-2025-55315)

    Wprowadzenie do problemu / definicja luki

    QNAP ostrzegł, że jego NetBak PC Agent (narzędzie do kopii zapasowych danych z Windows na NAS QNAP) może być pośrednio podatny na CVE-2025-55315 – krytyczny błąd w ASP.NET Core (serwer Kestrel), który umożliwia ataki HTTP Request Smuggling i obejście mechanizmów kontroli dostępu. NetBak podczas instalacji dołącza komponenty ASP.NET Core, dlatego na stacjach roboczych mogą pozostać podatne wersje frameworka, jeśli systemy nie zostały zaktualizowane.

    W skrócie

    • CVE-2025-55315 (CVSS 9.9): błąd w ASP.NET Core/Kestrel prowadzący do Request Smuggling i Security Feature Bypass. W najgorszym scenariuszu możliwa kradzież poświadczeń, modyfikacja plików oraz DoS.
    • Wpływ na QNAP: komputery z NetBak PC Agent mogą zawierać podatne komponenty ASP.NET Core — konieczna aktualizacja .NET lub reinstalacja NetBak (która dociągnie najnowszy runtime).
    • Działania zalecane: zaktualizować ASP.NET Core (.NET 8/9/10 RC1) do najnowszej wersji lub przeinstalować NetBak; dla aplikacji self-contained — przebudowa i redeploy.

    Kontekst / historia / powiązania

    Microsoft załatał CVE-2025-55315 w aktualizacjach z 14 października 2025 r. i określił tę lukę jako mającą „najwyższy w historii” poziom ważności dla problemów ASP.NET Core. W kolejnych dniach pojawiły się komunikaty branżowe i vendorowe (w tym QNAP), które powiązały tę lukę z realnymi produktami zależnymi od środowiska .NET.

    Analiza techniczna / szczegóły luki

    Mechanizm ataku. CVE-2025-55315 dotyczy niespójnej interpretacji nagłówków/ciała HTTP pomiędzy komponentami brzegowymi (np. reverse proxy) a serwerem Kestrel. Napastnik może „przemycić” ukryte żądanie w innym żądaniu, co skutkuje zmianą zakresu uprawnień i ominięciem wybranych kontroli (np. autoryzacji, CSRF). Wektory skutków wskazują na C:H / I:H / A:L (wysoka poufność i integralność, mniejszy wpływ na dostępność).

    Zakres wersji i łatki. Microsoft dostarczył poprawki dla ASP.NET Core 2.3, 8.0, 9.0 i 10.0 RC1; zaktualizowano też pakiet Microsoft.AspNetCore.Server.Kestrel.Core dla gałęzi 2.x. Rekomendacje obejmują: instalację aktualizacji .NET, ewentualny update pakietów NuGet oraz — w aplikacjach self-contained/single-file — przebudowę i redeploy.

    Powiązanie z NetBak PC Agent. Instalator NetBak dołącza komponenty ASP.NET Core; niezałatane środowisko .NET na stacjach Windows, z których wykonywany jest backup na NAS QNAP, podnosi powierzchnię ataku. QNAP zaleca reinstalację NetBak lub ręczną instalację ASP.NET Core Runtime (Hosting Bundle) w najnowszej wersji (.NET 8.0.21 na październik 2025 r.).

    Praktyczne konsekwencje / ryzyko

    • Kradzież tożsamości i eskalacja uprawnień — przejęcie sesji/poświadczeń użytkowników korzystających z aplikacji działających na podatnym Kestrel.
    • Modyfikacja zawartości plików — potencjalna ingerencja w dane przetwarzane przez aplikacje webowe .NET (integralność kopii zapasowych, metadanych itp.).
    • SSRF / ominięcie CSRF — możliwość wykonywania wewnętrznych żądań (pivot w sieci) oraz ominięcia ochrony CSRF zależnie od implementacji aplikacji.
    • Ryzyko łańcuchowe — stacje backupowe Windows z NetBak mogą stać się wektorem do ataku na inne systemy, jeśli korzystają z lokalnych usług webowych opartych o podatne ASP.NET Core. (Wniosek na podstawie charakterystyki luki i zależności NetBak od .NET).

    Rekomendacje operacyjne / co zrobić teraz

    1. Zweryfikuj ekspozycję CVE-2025-55315
      • Sprawdź, czy na hostach z NetBak PC Agent (Windows) zainstalowane są komponenty ASP.NET Core i w jakiej wersji.
      • Zweryfikuj aplikacje .NET uruchamiane na tych hostach (w tym usługi self-hosted na Kestrel).
    2. Zaktualizuj platformę .NET
      • Zainstaluj najnowsze aktualizacje .NET 8/9/10 RC1 (Windows Update / instalatory .NET).
      • Dla gałęzi 2.3/2.x podnieś pakiet Kestrel.Core do wersji załatanej, przebuduj i wdroż aplikację.
    3. Zaktualizuj NetBak PC Agent
      • Metoda 1 (zalecana przez QNAP): Odinstaluj i zainstaluj ponownie NetBak — instalator dociągnie najnowszy runtime ASP.NET Core.
      • Metoda 2: Ręcznie zainstaluj ASP.NET Core Runtime (Hosting Bundle) z oficjalnej strony (.NET 8.0.21 na 10/2025), następnie restart aplikacji/systemu.
    4. Wymuś polityki hardeningu
      • Dopasuj konfiguracje reverse proxy / WAF (normalizacja nagłówków, spójność Content-Length/Transfer-Encoding).
      • Włącz dodatkowe logowanie anomalii w warstwie HTTP i monitoruj nietypowe wzorce żądań (dublowane/podwójne nagłówki, niezgodności CL/TE). (Dobre praktyki na bazie natury ataku).
    5. Testy regresyjne i skanowanie
      • Uruchom skanery SAST/DAST pod kątem HTTP Request Smuggling na aplikacjach .NET w ekosystemie backupu.
      • Zweryfikuj integralność i spójność procedur backupu po aktualizacjach.

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

    • W odróżnieniu od typowych RCE w serwerach web, CVE-2025-55315 to bypass funkcji bezpieczeństwa przez smuggling — skutki zależą silnie od implementacji aplikacji i łańcucha komponentów (proxy ↔ Kestrel). Stąd wysoka ocena (9.9) przy jednoczesnym zastrzeżeniu Microsoftu, że „najgorszy przypadek” nie zawsze będzie osiągalny w każdej aplikacji.
    • QNAP wcześniej notował problemy bezpieczeństwa w narzędziach backupowych (np. poprawki rsync w HBS 3 w styczniu 2025 r.), ale obecna sytuacja dotyczy komponentu platformowego (ASP.NET Core), a nie bezpośrednio podatności w samym NetBak.

    Podsumowanie / kluczowe wnioski

    • Jeśli używasz NetBak PC Agent na Windows, potraktuj hosty jako potencjalnie narażone, zaktualizuj .NET/ASP.NET Core lub przeinstaluj NetBak, aby mieć pewność, że środowisko uruchomieniowe nie jest podatne.
    • CVE-2025-55315 to błąd o wyjątkowo wysokiej ważności w ASP.NET Core/Kestrel, którego skutki zależą od logiki aplikacji — nie ignoruj aktualizacji nawet, jeśli nie widzisz bezpośredniej ekspozycji.
    • Włącz monitoring anomalii HTTP i przegląd konfiguracji proxy/WAF, bo smuggling często wykorzystuje rozbieżności interpretacji żądań.

    Źródła / bibliografia

    • BleepingComputer: „QNAP warns of critical ASP.NET flaw in its Windows backup software”, 27 października 2025. (BleepingComputer)
    • QNAP Security Advisory QSA-25-44: „Potential Security Impact of ASP.NET Vulnerability on NetBak PC Agent”, 24 października 2025 (rev. 1.0). (QNAP)
    • Microsoft / BleepingComputer: „Microsoft fixes highest-severity ASP.NET Core flaw ever”, 17 października 2025 (omówienie zaleceń Microsoftu). (BleepingComputer)
    • NVD: „CVE-2025-55315 – ASP.NET Core HTTP Request Smuggling”, 14 października 2025 (wektor CVSS, opis). (NVD)
    • SecurityWeek: „Highest Ever Severity Score Assigned by Microsoft to ASP.NET Core Vulnerability”, 17 października 2025. (SecurityWeek)

    Płatności okupu za ransomware spadły w III kw. 2025 roku. Skąd ten dołek — i co to znaczy dla firm?

    Wprowadzenie do problemu / definicja zjawiska

    W III kwartale 2025 r. branża odnotowała rekordowo niski odsetek płatności okupu — zaledwie 23% incydentów zakończyło się zapłatą. To wniosek z najnowszej analizy firmy reagowania na incydenty Coveware, która jednocześnie raportuje gwałtowny spadek średniej płatności do ~376,9 tys. USD (–66% kw./kw.) oraz medianę 140 tys. USD (–65% kw./kw.). Coveware wiąże to z coraz częstszą odmową płatności przez duże przedsiębiorstwa oraz mniejszymi żądaniami wobec firm ze średniego segmentu. Informacje podsumował również SecurityWeek.

    W skrócie

    • 23% – historycznie najniższy wskaźnik płatności (Q3 2025).
    • 376 941 USD / 140 000 USD – średnia / mediana zapłaconego okupu (–66% / –65% vs Q2).
    • Najaktywniejsze grupy: Akira, Qilin (oraz silna aktywność INC Ransom, Play, SafePay wg ZeroFox).
    • Sektory najczęściej na celowniku: usługi profesjonalne, wciąż wysoko produkcja i budownictwo.
    • Ekosystem wycieków: liczba aktywnych „data leak sites” osiągnęła 81 w Q3 (rekord wg ReliaQuest).
    • Wolumen incydentów: ZeroFox naliczył 1 429 przypadków R&DE w Q3 (≈+5% kw./kw., –27% vs rekordowego Q1).

    Kontekst / historia / powiązania

    Spadek płatności to kontynuacja trendu, który przyspieszył po licznych akcjach organów ścigania i upadkach znanych marek RaaS w latach 2024–2025. Według Coveware ekonomia cyberwymuszeń uległa erozji: koszty operacyjne rosną, a „double extortion” (same wycieki danych) coraz rzadziej skłaniają duże firmy do zapłaty. Równolegle rynek fragmentuje się — aktywność mniejszych kolektywów oraz rekordowa liczba witryn wyciekowych podtrzymują presję ataków, choć nie zawsze przekładają się na przychody grup.

    Analiza techniczna / szczegóły

    Wektory wejścia. Coveware wskazuje na kompromitację zdalnego dostępu (VPN, bramki chmurowe, RDP), socjotechnikę (w tym nadużycia helpdesku) oraz wykorzystanie luk jako trzy filary inicjalnego dostępu. Rosnąca „zbieżność” technik to m.in. uzyskiwanie dostępu poprzez wymuszone procesy wsparcia i OAuth. W TTPs przeważa eksfiltracja danych (filary TA0010/TA0008/TA0011).

    Nowe taktyki — łapówki dla insiderów. Opisany przez Coveware przypadek próby przekupstwa pracownika przez gang Medusa pokazuje, że grupy sięgają po insider threats jako środek do wdrożenia szyfratora u celów o wyższej dojrzałości.

    Aktywność grup i branż. ZeroFox ocenił, że w Q3 Qilin i Akira należały do najaktywniejszych, a usługi profesjonalne wyraźnie zyskały na zainteresowaniu napastników (do tej pory dominowały produkcja/budownictwo/ochrona zdrowia).

    Praktyczne konsekwencje / ryzyko

    • Negocjacje: Linie obrony „nie płacimy” są dziś skuteczniejsze — płacenie za „zduszenie” wycieku bywa bezwartościowe, a „nuisance payments” podtrzymują rynek wymuszeń.
    • Ryzyko operacyjne: Nasilenie ataków wolumenowych na mid-market oznacza krótszy czas do awarii usług i presję na zespoły IT/OT. Źle skonfigurowane dostępny zdalne, OAuth i „dług konfiguracyjny” to najsłabsze ogniwa.
    • Ryzyko reputacyjne/regulacyjne: Sektory usług profesjonalnych i produkcji narażają klientów/łańcuch dostaw; wycieki danych mogą inicjować dochodzenia regulatorów.

    Rekomendacje operacyjne / co zrobić teraz

    1. Uderz w wektory wejścia
      • Egzekwuj MFA wszędzie, szczególnie dla VPN, bram SaaS i uprzywilejowanych kont; wymuś FIDO2 jako standard.
      • Zamknij „dług konfiguracyjny”: rotacja starych kont/kluczy, blokada nieużywanych integracji OAuth, rejestrowanie i alertowanie nietypowych logowań międzytenantowych.
    2. Wykrywanie i segmentacja
      • EDR/XDR + analityka lateral movement (RDP/SSH/PSExec) z regułami anomalii.
      • Segmentacja sieci / mikrosegmentacja (zwł. IT/OT wg modelu Purdue w środowiskach krytycznych).
    3. Twarde procesy helpdesku
      • Twarde procedury weryfikacji przy resetach hasła/MFA; testy socjotechniczne typu red-team.
    4. Backup & odzyskiwanie
      • 3-2-1, izolacja kopii (immutable), regularne testy RTO/RPO i recovery „bez klucza napastnika”.
    5. Plan na wyciek (bez płatności)
      • Z góry opracuj playbook eksfiltracji: kontakt z prawnikami ds. prywatności, ocena materiału, komunikacja kryzysowa, działania wobec klientów/partnerów — bez „nuisance payments”.
    6. Program insiderski
      • Kanały zgłoszeń, szkolenia anty-korupcyjne, monitoring ryzyk personalnych; detekcja anomalii dostępu.
    7. Higiena podatności
      • Patchowanie systemów brzegowych i urządzeń sieciowych; priorytetyzacja luk historycznie wykorzystywanych przez RaaS.

    Różnice / porównania z innymi przypadkami

    • Q3 vs Q2 2025: średnia i mediana płatności spadły o ~2/3 kwartał do kwartału, co wskazuje na zmianę „unit economics” po stronie gangów i większą determinację dużych ofiar, by nie płacić.
    • „Big-game hunting” vs „mid-market at scale”: Chociaż wielkie ofiary coraz częściej odmawiają, kampanie wysokowolumenowe (np. Akira, Qilin) trzymają tempo, celując w firmy, które łatwiej zakłócić, ale które zapłacą mniejsze kwoty.
    • Ekosystem wycieków: Rekord 81 aktywnych DLS w Q3 nie przełożył się na wzrost płatności — presja reputacyjna działa, lecz coraz rzadziej konwertuje na przelewy.

    Podsumowanie / kluczowe wnioski

    Ransomware nie zwalnia, ale płacić się „nie opłaca”. Q3 2025 to przełom: mniej płatności, mniejsze wypłaty i rosnące koszty po stronie napastników. Organizacje, które inwestują w przygotowanie do wycieku i mają twarde procesy tożsamości/remote access, skuteczniej negocjują i częściej wychodzą bez zapłaty. Dalsze utrzymanie presji — technicznej, prawnej i operacyjnej — może dalej dławić ekonomię wymuszeń.

    Źródła / bibliografia

    • Coveware — „Insider Threats Loom while Ransom Payment Rates Plummet” (24 października 2025) — raport Q3 2025. (coveware.com)
    • SecurityWeek — „Ransomware Payments Dropped in Q3 2025: Analysis” (27 października 2025). (SecurityWeek)
    • ReliaQuest — „Ransomware and Cyber Extortion in Q3 2025” (8 października 2025). (ReliaQuest)
    • ZeroFox — „Q3 2025 Ransomware Wrap-Up” (3 października 2025). (ZeroFox)