Archiwa: Security News - Strona 428 z 445 - Security Bez Tabu

Herodotus: nowy trojan na Androida „udaje człowieka”, by omijać detekcję i okradać konta

Wprowadzenie do problemu / definicja luki

Badacze ThreatFabric ujawnili nową rodzinę mobilnego malware’u na Androida o nazwie Herodotus. To trojan bankowy typu Device Takeover (DTO), który podczas zdalnego sterowania telefonem symuluje ludzkie pisanie – wprowadza znaki pojedynczo z losowymi przerwami 0,3–3 s – aby zmylić mechanizmy antyfraudowe oparte na tempie interakcji i rytmie klawiatury. Kampanie potwierdzono m.in. we Włoszech i Brazylii, a zestawy fałszywych nakładek („overlays”) przygotowano także dla banków i serwisów krypto w USA, Wielkiej Brytanii, Turcji i Polsce.

W skrócie

  • Nowość: wprowadzanie tekstu z losowymi opóźnieniami imituje człowieka i utrudnia wykrycie automatyzacji.
  • Zdolności: przejęcie urządzenia (DTO) przez nadużycie Accessibility Service, nakładki na aplikacje bankowe, podgląd ekranu, kradzież kodów SMS/2FA.
  • Dystrybucja: smishingdropper (sideloading), podszywanie się m.in. pod „Banca Sicura” i „Modulo Seguranca Stone”.
  • Model: zapowiedziany jako Malware-as-a-Service (MaaS), autor „K1R0”.

Kontekst / historia / powiązania

ThreatFabric wskazuje, że Herodotus nie jest prostą ewolucją, ale ma fragmenty kodu i technik znanych z trojana Brokewell (np. ciągi znaków „BRKWL_JAVA”, podobna obfuskacja). To sugeruje „zszycie” komponentów z nowymi elementami, w tym modułem do bardziej „ludzkich” interakcji.

Analiza techniczna / szczegóły luki

  • Wejście tekstu: zamiast wklejać cały ciąg (co bywa wykrywane jako nieludzkie), malware dzieli tekst na znaki i wstawia je z losowym opóźnieniem 300–3000 ms. Celem jest ominięcie detekcji behawioralnej opartej na czasie wprowadzania danych.
  • Zdalne sterowanie: polecenia obejmują m.in. kliknięcia po elementach/koordynatach, gesty, akcje globalne (Back/Home/Recents), wpisywanie tekstu, a także VNC/screen-sharing.
  • Ukrywanie aktywności: „blocking overlay” – pełnoekranowa nakładka imitująca ekran ładowania, która maskuje działania oszusta podczas przelewów.
  • Kradzież danych: fałszywe strony logowania nad aplikacjami banków/krypto, przechwytywanie SMS (2FA), logowanie zawartości ekranu.
  • Dystrybucja i łańcuch infekcji: smishing prowadzący do droppera napisanego przez tego samego autora; dropper pomaga obejść ograniczenia Android 13+ dla Accessibility, uruchamia payload i prosi ofiarę o nadanie uprawnień.
  • Infrastruktura: komunikacja MQTT; domena google-firebase[.]digital z wieloma subdomenami przypisywanymi do różnych operatorów kampanii.

Praktyczne konsekwencje / ryzyko

  • Bankowość mobilna i fintech: Kontrole antyfraudowe polegające wyłącznie na tempie/rytmie interakcji mogą zostać zdegradowane – przerwy „jak u człowieka” obniżają ryzyko z punktu widzenia prostych silników behawioralnych. Potrzebne jest korelacyjne podejście (ryzyko urządzenia + sygnały sesyjne + behawioryka na poziomie indywidualnego wzorca).
  • Użytkownicy w Polsce: choć potwierdzone kampanie to Włochy i Brazylia, istnieją gotowe nakładki na aplikacje bankowe w Polsce, co wskazuje na realne ryzyko lokalnych kampanii.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów bezpieczeństwa w bankach/fintechach:

  1. Wzmacniajcie sygnalizację ryzyka urządzenia: wykrywanie aktywnych usług Accessibility, nakładek, wskaźników DTO (VNC/screen-sharing), nienaturalnych strumieni zdarzeń. Korelować z kontekstem sieciowym i reputacją aplikacji.
  2. Behawioralne modele per-użytkownik: zamiast prostych progów tempa wpisywania, modelować indywidualne wzorce; łączyć z detekcją anomalii na poziomie sekwencji UI (np. trajektorie kliknięć, wzorce nawigacji).
  3. Weryfikacja transakcji wysokiego ryzyka: step-up auth niezależny od SMS (np. FIDO2/push w zaufanej aplikacji), geokorelacja, challenge-response w obrębie aplikacji.
  4. Honeypoty anty-overlay: dynamiczne elementy UI i ukryte pola wykrywające „set text”/clipboard zamiast realnych zdarzeń klawiszy.
  5. Telemetria mobilna: alerty na „blocking overlay”, częste żądania uprawnień Accessibility, nietypowe użycie ACTION_SET_TEXT.

Dla użytkowników i działów IT:

  • Nie instaluj z SMS-ów/WWW – tylko Google Play i sprawdzony vendor MDM; wyłącz „instalację z nieznanych źródeł”.
  • Uważaj na prośby o Accessibility – legalne aplikacje rzadko tego potrzebują do bankowości.
  • 2FA bez SMS (aplikacyjna/push), aktualizacje Androida i Play Protect; w razie podejrzenia DTO – natychmiast rozłącz internet, zadzwoń do banku innym kanałem, zresetuj urządzenie i hasła.
  • Edukacja smishingowa (również dla helpdesku i contact center).
    Te zalecenia wynikają ze sposobu działania Herodotus (smishing→dropper→Accessibility→DTO).

Różnice / porównania z innymi przypadkami

  • Brokewell vs. Herodotus: Brokewell był wcześniejszą rodziną DTO; Herodotus wykorzystuje jego moduły i techniki, ale dodaje „humanizację” wejścia jako kluczową innowację anty-detekcyjną.
  • Na tle typowych trojanów bankowych: wklejanie danych/clipboard jest szybkie, ale „nieludzkie” – Herodotus celowo zwalnia i randomizuje. Media branżowe potwierdzają, że te przerwy potrafią wynosić do 3 sekund.

Podsumowanie / kluczowe wnioski

Herodotus to sygnał, że fraud na Androidzie wchodzi w erę „anty-behawioralną”: przestępcy modelują ludzkie zachowanie, żeby oszukać silniki antyfraudowe. Skuteczna obrona wymaga pełnej warstwowości: telemetryki urządzenia, detekcji DTO, modeli per-użytkownik, silnych metod weryfikacji transakcji i restrykcji instalacji aplikacji. Organizacje w Polsce powinny traktować temat priorytetowo, bo nakładki na krajowe aplikacje są już w arsenale operatorów.

Źródła / bibliografia

  • ThreatFabric: „New Android Malware Herodotus Mimics Human Behaviour to Evade Detection” (28.10.2025) – raport techniczny (kampanie, techniki, zakres opóźnień, DTO, overlay, MQTT). (threatfabric.com)
  • The Record (Recorded Future News): „New Android malware mimics human typing to evade detection, steal money” (28.10.2025) – streszczenie i regionalizacja (Włochy, Brazylia; nakładki m.in. Polska). (The Record from Recorded Future)
  • The Hacker News: „New Android Trojan ‘Herodotus’ Outsmarts Anti-Fraud Systems by Typing Like a Human” (28.10.2025) – potwierdzenie MaaS, Brokewell, zakres opóźnień. (The Hacker News)
  • BankInfoSecurity: „‘Herodotus’ Android Trojan Mimics Human Sluggishness” (28.10.2025) – opis anty-detekcji (opóźnienia do 3 s) i łańcucha infekcji. (BankInfoSecurity)
  • The Register: „Android malware types like your gran to steal banking creds” (28.10.2025) – omówienie kampanii i infrastruktury (domena google-firebase[.]digital). (The Register)

Schneider Electric i Emerson na liście ofiar ataków na Oracle E-Business Suite

Wprowadzenie do problemu / definicja luki

Cyberprzestępcy powiązani z marką wyciekową Cl0p zaczęli publikować listy rzekomych ofiar kampanii wymierzonej w Oracle E-Business Suite (EBS). Na stronie wyciekowej Cl0p pojawiły się m.in. Schneider Electric i Emerson, a przy tych nazwach udostępniono archiwa danych: ~2,7 TB (Emerson) oraz ~116 GB (Schneider Electric). Redakcje i badacze wskazują, że struktura plików i metadane sugerują pochodzenie informacji właśnie ze środowisk Oracle EBS.

W skrócie

  • Kampania trwa co najmniej od lipca–sierpnia 2025 r. i łączy kradzież danych ze szantażem e-mailowym wobec klientów Oracle EBS.
  • Oracle potwierdziło falę maili z żądaniami okupu kierowanych do klientów EBS i wezwało do pilnych aktualizacji.
  • Wektor wejścia wiązany jest z podatnościami CVE-2025-61882 (początkowo 0-day) oraz później CVE-2025-61884, dla których Oracle wydało poprawki awaryjne w październiku.
  • CISA potwierdziła, że CVE-2025-61884 jest aktywnie wykorzystywane (wpis do katalogu KEV).
  • Lista ofiar rośnie; niezależne relacje wymieniają obok Schneider/Emerson także inne organizacje (część już potwierdziła incydenty, jak Harvard czy Envoy Air).

Kontekst / historia / powiązania

9 października 2025 r. Google Threat Intelligence i Mandiant opisały szeroko zakrojoną kampanię wymuszeń wobec klientów Oracle EBS. Według ich analizy intruzi działający pod brandem Cl0p dostarczali do kadr kierowniczych masowe e-maile, przedstawiając listingi plików wykradzionych z EBS jako „dowód”. Reuters dzień później przytoczył komunikat Oracle o napływie zgłoszeń dot. e-maili z szantażem oraz rekomendacje aktualizacji. W kolejnych dniach zaczęły pojawiać się pierwsze publiczne potwierdzenia ofiar i wpisy w KEV CISA.

Analiza techniczna / szczegóły luki

Badacze opisują łańcuch ataku obejmujący:

  • Wykorzystanie podatności EBS (początkowo 0-day CVE-2025-61882, następnie poprawione również CVE-2025-61884) do zdalnego, nieautoryzowanego dostępu bez interakcji użytkownika. Oracle wydało awaryjne poprawki 4 października i kolejną aktualizację 11 października.
  • Cele HTTP obserwowane w kampanii (m.in. /OA_HTML/UiServlet, /OA_HTML/SyncServlet) oraz ścieżki wskazujące na nadużycia w komponentach EBS.
  • Implanty w Javie działające w pamięci (rodzina narzędzi opisywana przez Google/Mandiant m.in. jako GOLDVEIN, SAGEWAVE, SAGELEAF, SAGEGIFT), co utrudnia detekcję w oparciu o artefakty plikowe. Artykuł zawiera też wskaźniki kompromitacji (IP/C2, reguły YARA).

Ważne: CISA dodała CVE-2025-61884 do KEV, co wymusza na agencjach federalnych USA szybkie wdrożenie łatek i podkreśla realne nadużycia tej luki „w naturze”.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wycieku danych ERP (finanse, HR, łańcuch dostaw, logistyka) z instancji EBS, które w wielu firmach są krytycznym systemem back-office.
  • Szantaż i reputacja: Cl0p publikuje listingi i zrzuty, aby zwiększyć presję. Dla podmiotów przemysłowych (Schneider Electric, Emerson) ryzyko dotyczy w pierwszej kolejności poufności danych korporacyjnych, a nie bezpośrednio ICS/OT — ale kompromitacja ERP może pośrednio wpłynąć na operacje (łańcuch dostaw, zamówienia, serwis).
  • Efekt domina: rosnąca lista ofiar sugeruje skalę zbliżoną do wcześniejszych kampanii Cl0p (MOVEit, Cleo, Fortra) — masowy, ustandaryzowany model „data theft + extortion”.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast załataj EBS: zastosuj poprawki Oracle z 4 i 11 października 2025 r. dotyczące CVE-2025-61882/61884. Zweryfikuj, że środowiska są na bieżących poziomach CPU/PSU.
  2. Segmentacja i ekspozycja: odetnij EBS od Internetu (jeśli to możliwe), dopuszczaj dostęp przez VPN/ZTNA, listy kontroli dostępu, WAF z regułami na znane ścieżki i wzorce.
  3. Hunting w pamięci JVM: przeprowadź analizę pamięci procesów Java/WebLogic powiązanych z EBS pod kątem artefaktów GOLDVEIN/SAGEWAVE i użyj opublikowanych IOC/YARA.
  4. Przegląd logów HTTP i aplikacyjnych: szukaj nietypowych żądań do /OA_HTML/UiServlet, /OA_HTML/SyncServlet, /OA_HTML/OA.jsp?...TemplatePreviewPG... oraz anomalii w Concurrent Processing.
  5. IR i komunikacja: przygotuj „holding statement” i plan powiadomień (prawny/PR). Nie negocjuj pochopnie — weryfikuj próbki danych przesłane przez agresora. (Potwierdzone przypadki nierzadko zawierały elementy podkoloryzowania wartości danych).
  6. Twarde MFA i higiena kont: wymuś zmianę haseł, rotację kluczy, ogranicz dostępność kont serwisowych; monitoruj nietypowe logowania do kont uprzywilejowanych. (CISA ostrzegała wcześniej o ryzyku kradzieży poświadczeń w ekosystemie Oracle).
  7. Backupy i plan ciągłości: zapewnij odseparowane kopie krytycznych danych ERP; przetestuj odtwarzanie.

Różnice / porównania z innymi przypadkami

Model operacyjny przypomina fale Cl0p z lat 2020–2024 (Accellion FTA, MOVEit, Cleo, Fortra MFT): masowe wykorzystanie podatności 0-day/n-day w powszechnie używanym oprogramowaniu, krótko po czym następuje seria e-maili szantażowych i publikacje na DLS. Różnica: tym razem celem jest system ERP (Oracle EBS) — konsekwencje dla biznesu są bardziej „horyzontalne” (finanse/HR/łańcuch dostaw), podczas gdy w MFT chodziło głównie o repozytoria plików.

Podsumowanie / kluczowe wnioski

  • Schneider Electric i Emerson zostały publicznie wskazane przez napastników jako ofiary kampanii na EBS; przy ich nazwach opublikowano znaczne wolumeny danych. Organizacje nie skomentowały jeszcze sprawy mediom.
  • CVE-2025-61882/61884 stanowią realny wektor — z aktualnie dostępnymi łatami Oracle oraz potwierdzeniem aktywnej eksploatacji przez CISA. Patch now i wykonaj threat hunting.
  • Skalę zdarzenia potwierdzają liczne wpisy na DLS i raporty mediów branżowych; lista ofiar rośnie.

Źródła / bibliografia

  • SecurityWeek: Industrial Giants Schneider Electric and Emerson Named as Victims of Oracle Hack (28 października 2025). (SecurityWeek)
  • Google Threat Intelligence & Mandiant: Oracle E-Business Suite Zero-Day Exploited in Widespread Extortion Campaign (9 października 2025, aktual. 11 października 2025). (Google Cloud)
  • Reuters: Oracle says hackers are trying to extort its customers (3 października 2025). (Reuters)
  • SecurityWeek: CISA Confirms Exploitation of Latest Oracle EBS Vulnerability (21 października 2025). (SecurityWeek)
  • Dark Reading: Oracle EBS Attack Victims May Be More Numerous Than Expected (28 października 2025). (Dark Reading)

CISA ostrzega przed dwiema kolejnymi aktywnie wykorzystywanymi lukami w Dassault DELMIA Apriso (CVE-2025-6204, CVE-2025-6205)

Wprowadzenie do problemu / definicja luki

CISA dodała do katalogu KEV (Known Exploited Vulnerabilities) dwie luki w rozwiązaniu DELMIA Apriso firmy Dassault Systèmes, używanym do zarządzania i realizacji operacji produkcyjnych (MOM/MES). Chodzi o:

  • CVE-2025-6205Missing authorization (brak autoryzacji), umożliwiająca zdalne uzyskanie uprzywilejowanego dostępu przez nieautoryzowanego atakującego; ocena przez producenta CVSS 9.1 (Critical).
  • CVE-2025-6204Code injection (wstrzyknięcie kodu), pozwalająca uprawnionemu użytkownikowi o wysokich uprawnieniach wykonać dowolny kod; ocena CVSS 8.0 (High).

CISA informuje, że obie podatności są aktywnie wykorzystywane; agencje FCEB mają czas na wdrożenie środków do 18 listopada 2025 r.

W skrócie

  • Produkt: Dassault DELMIA Apriso (Release 2020–2025).
  • Luki: CVE-2025-6205 (brak autoryzacji), CVE-2025-6204 (wstrzyknięcie kodu).
  • Status: aktywne exploity, pozycje w CISA KEV. Termin dla FCEB: 18.11.2025.
  • Łatki: producent opublikował informacje i ścieżki remediacji w sierpniu 2025 r.
  • Sektory ryzyka: automotive, elektronika, lotnictwo, maszyny przemysłowe.

Kontekst / historia / powiązania

To kolejny raz, gdy DELMIA Apriso trafia do KEV w 2025 r. We wrześniu CISA dodała również CVE-2025-5086 (zdalne wykonanie kodu), po odnotowaniu pierwszych prób eksploatacji przez SANS ISC. Obecne wpisy (6204, 6205) potwierdzają utrzymujące się zainteresowanie atakujących tym ekosystemem.

Analiza techniczna / szczegóły luki

CVE-2025-6205 (Missing authorization)

  • Wektor: sieciowy (AV:N), niski poziom złożoności (AC:L), bez uwierzytelnienia (PR:N), brak interakcji użytkownika (UI:N), wpływ na poufność i integralność (C:H/I:H) – ocena CVSS 9.1 (CNA: Dassault).
  • Skutek: atakujący może zdalnie uzyskać uprzywilejowany dostęp do aplikacji.
  • CWE: CWE-862 (Missing Authorization).

CVE-2025-6204 (Code injection)

  • Wektor: sieciowy (AV:N), wysoka złożoność (AC:H), wymagane wysokie uprawnienia (PR:H); mimo to wpływ na C/I/A oceniony jako wysoki – CVSS 8.0 (CNA).
  • Skutek: wykonanie dowolnego kodu w systemie.
  • CWE: CWE-94 (Improper Control of Generation of Code).

Zakres wersji: Release 2020–2025. Dassault potwierdza dostępność remediacji i dokumentacji wsparcia (portal support.3ds.com).

Praktyczne konsekwencje / ryzyko

  • Ataki bez uwierzytelnienia (CVE-2025-6205): szczególnie niebezpieczne w środowiskach, gdzie interfejsy Apriso są dostępne z sieci korporacyjnej lub – co gorsza – z Internetu (np. błędna segmentacja). Umożliwia eskalację uprawnień i przejęcie orkiestracji procesów produkcyjnych.
  • Wstrzyknięcie kodu (CVE-2025-6204): choć wymaga wysokich uprawnień, zagrożenie jest realne w scenariuszach nadużycia kont serwisowych lub ruchu bocznego po wstępnym włamaniu.
  • Wpływ na OT/MES: zakłócenia produkcji, manipulacja danymi jakości, błędne zlecenia i traceability, ryzyko przestojów i strat finansowych w branżach o wysokich wymaganiach zgodności (automotive/lotnictwo).

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowe łatanie: zastosuj aktualizacje/remediacje dostarczone przez Dassault dla dotkniętych wydań (R2020–R2025).
  2. Weryfikacja ekspozycji:
    • Zidentyfikuj instancje Apriso oraz interfejsy web/API.
    • Upewnij się, że brak dostępu z Internetu; wymuś dostęp przez VPN i listy kontroli.
  3. Twarde ograniczenie uprawnień (szczególnie kont o wysokich rolach) oraz MFA dla interfejsów administracyjnych.
  4. Segmentacja IT/OT i kontrola ruchu (WAF/IPS) – reguły na wstrzyknięcie kodu oraz próby nadużyć autoryzacji.
  5. Hunting i detekcja:
    • Szukaj nietypowych logowań do Apriso, zmian konfiguracji, nagłych skoków uprawnień.
    • Koreluj z IOC/telemetrią z wrześniowych prób eksploatacji DELMIA Apriso (CVE-2025-5086) jako sygnałem zainteresowania środowiskiem.
  6. Zgodność z CISA KEV: jeśli podlegasz BOD 22-01, deadline 18.11.2025 na wdrożenie mitigacji; pozostałe organizacje powinny traktować priorytetowo.

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

  • CVE-2025-5086 (RCE) z września 2025 r. był wcześniej obserwowany w atakach; obecne luki uzupełniają powierzchnię ataku:
    • 6205bezautoryzacyjna eskalacja dostępu (krytyczna).
    • 6204remote code execution z poziomu uprzywilejowanego użytkownika (wysoka).
      Zestawienie sugeruje, że środowiska Apriso mogą być celem wielowektorowych kampanii, łączących początkowe wejście z dalszą eskalacją i wykonaniem kodu.

Podsumowanie / kluczowe wnioski

  • Dwie nowe luki w DELMIA Aprisoaktywnie eksploatowane i mają wysokie/ krytyczne znaczenie.
  • Łatki/remediacje dostępne od sierpnia 2025 r. – należy je wdrożyć niezwłocznie i ograniczyć ekspozycję interfejsów.
  • Organizacje przemysłowe (automotive, lotnictwo, elektronika, maszyny) powinny potraktować temat jako priorytet w obszarze MES/MOM i OT.

Źródła / bibliografia

  • BleepingComputer: “CISA warns of two more actively exploited Dassault vulnerabilities”, 28.10.2025. (BleepingComputer)
  • NVD (NIST): CVE-2025-6205 – opis, CVSS, wpis KEV/due date. (NVD)
  • NVD (NIST): CVE-2025-6204 – opis, CVSS, klasyfikacja CWE-94. (NVD)
  • Dassault Systèmes Trust Center: CVE-2025-6205 – advisory/remediacja. (Dassault Systèmes)
  • Dassault Systèmes Trust Center: CVE-2025-6204 – advisory/remediacja. (Dassault Systèmes)
  • SANS ISC: Exploit Attempts for Dassault DELMIA Apriso (CVE-2025-5086) – kontekst wcześniejszych ataków. (SANS Internet Storm Center)

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 atestacjiwiąż 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)