Archiwa: SIEM - Strona 91 z 93 - Security Bez Tabu

Tag: SIEM

F5 obwinia „aktorów państwowych” o kradzież kodu źródłowego i danych o podatnościach BIG-IP

Wprowadzenie do problemu / definicja incydentu

15 października 2025 r. F5 ujawniło w raporcie Form 8-K oraz komunikacie do klientów, że wysoce zaawansowany, prawdopodobnie sponsorowany przez państwo napastnik utrzymywał długotrwały dostęp do wybranych systemów firmy, m.in. do środowiska rozwoju BIG-IP i platform wiedzy inżynierskiej. Z systemów tych wyeksfiltrowano pliki zawierające fragmenty kodu źródłowego BIG-IP oraz informacje o niewydanych jeszcze podatnościach (niepublicznych). F5 twierdzi, że nie ma dowodów na modyfikację łańcucha dostaw (pipeline’y build/release), ani na dostęp do środowisk NGINX, Distributed Cloud czy Silverline.

O sprawie jako pierwsze szeroko doniosły branżowe media, wskazując także, że profil ataku może wskazywać na Chiny.

W skrócie

  • Kiedy wykryto: 9 sierpnia 2025 r.; ujawnienie odroczono za zgodą DOJ (Item 1.05(c) 8-K).
  • Co ukradziono: pliki z częściami kodu BIG-IP i informacjami o niewydanych podatnościach; częściowo także konfiguracje/implementacje niewielkiego odsetka klientów.
  • Czego nie stwierdzono: brak dowodów na modyfikację supply chain, brak dostępu do CRM/finansów/iHealth/wsparcia; brak oznak aktywnego wykorzystywania „nieujawnionych krytycznych/ RCE” podatności F5.
  • Aktualizacje/łagodzenie: opublikowano zbiorcze biuletyny/aktualizacje październikowe dla BIG-IP, F5OS, BIG-IP Next, BIG-IQ i APM; F5 zaleca natychmiastowe wdrożenie.
  • Potwierdzenia zewnętrzne: media i niezależne serwisy powtórzyły główne tezy; NCSC wydało krótką notę z zaleceniem pilnych aktualizacji.

Kontekst / historia / powiązania

Urządzenia i oprogramowanie F5 BIG-IP od lat znajdują się w centrum uwagi APT i cyberprzestępców (m.in. fale exploitacji CVE-2020-5902, CVE-2022-1388 czy pary CVE-2023-46747/-46748). Trwałe utrzymanie się napastników w środowiskach wykorzystujących BIG-IP bywało wcześniej wiązane z chińsko-języcznymi grupami (np. kampania „Velvet Ant” z wykorzystaniem starszych urządzeń F5 dla utrzymania persystencji). Dzisiejszy incydent wpisuje się w ten trend polowania na źródła i wiedzę o 0-day u producentów.

Analiza techniczna / szczegóły luki

Z udostępnionego klientom oświadczenia (Exhibit 99.1 do 8-K) wynika, że:

  • Atakujący posiadali długoterminową persystencję w sieci F5, obejmującą repozytoria kodu i systemy KM.
  • Eksfiltracja objęła m.in. fragmenty kodu BIG-IP oraz opisy/artefakty podatności będących „w toku” (nieopublikowanych).
  • F5 nie zidentyfikowało dowodów na naruszenie łańcucha dostaw (źródła, build’y, pipeline’y), co potwierdziły niezależne audyty NCC Group i IOActive.
  • Brak dowodów na dostęp do NGINX oraz usług chmurowych F5, co ogranicza bezpośredni wektor supply-chain dla tych linii.

Choć firma podkreśla brak wiedzy o krytycznych/RCE nieujawnionych błędach, sama kradzież wiedzy o lukach zwiększa prawdopodobieństwo samodzielnego opracowania exploitów przez APT przed publikacją biuletynów („pre-disclosure weaponization”). To klasyczny wyścig z czasem: jeżeli opis podatności/patch różnicowy trafił do przeciwnika, okno narażenia dla klientów może się skrócić do tygodni lub dni.

Praktyczne konsekwencje / ryzyko

  • Ryzyko exploitów „day-(-1)” – użycie informacji o nieopublikowanych lukach F5 do cichych, ukierunkowanych wejść (szczególnie tam, gdzie konfiguracja BIG-IP bywa złożona i historycznie zaniedbana).
  • Rozpoznanie środowisk klientów – wyciek konfiguracji/implementacji części organizacji ułatwia lateral movement i selektywne omijanie WAF/ASM/AFM/APM.
  • Reputacyjne i regulacyjne – formalne ujawnienie w 8-K oznacza „material event” z potencjalnym wpływem na decyzje użytkowników i rynków; samo F5 ocenia na dziś brak istotnego wpływu operacyjnego.
  • Fala skanowania i prób dostępu – po medialnym nagłośnieniu zwykle rośnie aktywność botnetów i „copy-cats”.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowe aktualizacje: wdrożyć październikowe wydania dla BIG-IP/F5OS/BIG-IP Next/BIG-IQ/APM zgodnie z biuletynem F5. Zaplanuj rolling upgrade i weryfikację po-update’ową.
  2. Threat hunting pod kątem F5:
    • Przejrzeć logi TMOS/ASM/APM oraz syslog z event streaming do SIEM (zgodnie z KB F5 – wzorce: logowania admin, nieudane auth, zmiany uprawnień/konfiguracji).
    • Użyć zaleceń F5 dot. twardnienia (hardening checks w iHealth) i porównać z własnymi benchmarkami.
  3. Segmentacja i kontrola dostępu: odseparować interfejsy zarządcze BIG-IP (Mgmt/SSH/TMU) od sieci produkcyjnych, wymusić MFA i listy dozwolonych.
  4. Repozytoria i tajemnice: skontrolować własne integracje CI/CD z BIG-IP (np. AS3/DO/FAST). Zmienić poświadczenia, tokeny API, klucze iControl REST.
  5. Atesty konfiguracji klientów: jeśli korzystasz z partnerów/Integratorów, zażądaj potwierdzenia, że nie używali artefaktów/fragmentów konfigów podatnych na wyciek.
  6. Monitoring exploitów: śledzić biuletyny CISA KEV i krajowe CERT-y; NCSC rekomenduje pilne wdrożenie poprawek F5.
  7. Plan awaryjny: przygotować playbook „virtual patching” na F5 (np. tymczasowe iRules/policy WAF) w razie pojawienia się PoC przed pełnym patchem.

Różnice / porównania z innymi przypadkami

  • SolarWinds/3CX – głęboka manipulacja supply chain; tutaj F5 i niezależne audyty raportują brak modyfikacji pipeline’ów i artefaktów wydań, co zmniejsza ryzyko „zatrutych” aktualizacji.
  • Wycieki „knowledge-base” u dostawców (np. przypadki wiązane z MAPP/SharePoint) – wspólny motyw to pozyskanie wiedzy o 0-day przed publikacją, a niekoniecznie natychmiastowe uderzenie supply-chain. W doniesieniach prasowych o incydencie F5 przewija się hipoteza o aktorze z Chin, spójna z wcześniejszymi kampaniami przeciw producentom infrastruktury.

Podsumowanie / kluczowe wnioski

  • Incydent nie wygląda na kompromitację łańcucha dostaw, ale na wyciek kodu i „researchu” o lukach – co nadal jest poważnym zagrożeniem.
  • Czas działa na korzyść obrońców tylko wtedy, gdy szybko wdrożą aktualizacje i wymuszą twardnienie/monitoring zgodnie z zaleceniami F5.
  • Organizacje z krytycznymi wdrożeniami BIG-IP powinny traktować najbliższe tygodnie jako okres podwyższonego czuwania i aktywnie polować na anomalie.

Źródła / bibliografia

  1. F5 – Security Incident: Disclosure Statement (Exhibit 99.1 do 8-K, 15.10.2025) – szczegóły o eksfiltracji, produktach i zaleceniach. (SEC)
  2. SEC EDGAR – F5, Inc. Form 8-K (15.10.2025) – formalne zgłoszenie incydentu (Item 1.05). (SEC)
  3. SecurityWeek (15.10.2025) – przegląd incydentu i wskazanie na profil ataku sugerujący Chiny. (SecurityWeek)
  4. BleepingComputer (15.10.2025) – streszczenie zakresu eksfiltracji i harmonogramu wykrycia. (BleepingComputer)
  5. NCSC (UK) – nota potwierdzająca kompromitację i zalecająca wdrożenie aktualizacji. (NCSC)

CISA: nowy alert ICS – podatności w module Rockwell Automation 1715 EtherNet/IP Comms (ICSA-25-287-01)

Wprowadzenie do problemu / definicja luki

14 października 2025 r. CISA poinformowała o jednym nowym doradztwie ICS – ICSA-25-287-01 – dotyczącym Rockwell Automation 1715 EtherNet/IP Communications Module (seria 1715-AENTR). Jest to komponent stosowany w redundancji I/O w środowiskach OT/ICS. Doradztwo opisuje problem(y) bezpieczeństwa prowadzące do odmowy usługi (DoS) i utraty komunikacji CIP, co może wpływać na dostępność sterowania procesowego.

W skrócie

  • Kogo dotyczy: użytkownicy modułu Allen-Bradley 1715 EtherNet/IP (1715-AENTR) w systemach redundantnych I/O.
  • Co jest nie tak: podatności umożliwiające DoS – m.in. poprzez specyficzne komunikaty/pakiety CIP powodujące utratę komunikacji z modułem. (Szczegóły w doradztwie CISA).
  • Skutek: zatrzymanie lub degradacja wymiany danych I/O, możliwa utrata dostępności funkcji sterowania.
  • Co zrobić: zastosować aktualizacje/zalecenia producenta, segmentację i filtrowanie ruchu, twardą kontrolę dostępu do sieci OT.

Kontekst / historia / powiązania

CISA regularnie publikuje zbiory doradztw ICS – 14.10.2025 r. ogłoszono właśnie pojedyncze doradztwo skupione na linii 1715. W poprzednich tygodniach agencja publikowała większe paczki doradztw (np. 30.09 i 09.09), co podkreśla utrzymujące się ryzyka w ekosystemie Rockwell/ABB i innych dostawców OT. Najnowszy alert jest kontynuacją tej serii i wskazuje, że wektor DoS w komponentach komunikacyjnych EtherNet/IP pozostaje istotny.

Analiza techniczna / szczegóły luki

Doradztwo ICSA-25-287-01 opisuje problem(y) prowadzące do DoS w module 1715. Z informacji CISA wynika, że komunikacja CIP z przygotowanymi (crafted) ładunkami może doprowadzić do utraty komunikacji z modułem, co skutkuje niedostępnością usługi po stronie urządzenia. (Wskazane są scenariusze, w których specyficzne sekwencje/częstotliwość żądań wywołują błąd i reset/utratę łączności). Szczegółowe atrybuty – w tym zakres wersji i wektory – opisuje karta doradztwa CISA.

Uwaga redakcyjna: CISA niekiedy przypisuje też numery CVE w późniejszych aktualizacjach kart ICSA. Jeśli Twoje procesy GRC wymagają CVE, sprawdź kartę doradztwa producenta i indeksy advisory Rockwell (Trust Center), które są uzupełniane po walidacji.

Praktyczne konsekwencje / ryzyko

  • Dostępność procesu: DoS na łączności CIP może czasowo pozbawić sterownik aktualnych danych I/O z szafy 1715, wpływając na logikę sterowania, redundancję i reakcję na stany awaryjne.
  • Skutki operacyjne: możliwe przejście do stanów bezpiecznych przez moduły I/O, opóźnienia sterowania, a w skrajnych przypadkach przestoje instalacji (w zależności od konfiguracji SIS/HA i watchdogów).
  • Łańcuch dostaw: linia 1715 jest powszechnie wykorzystywana w przemyśle (proces, chemia, nafta-gaz, energetyka). Zakłócenia mogą mieć wpływ na KPI OT (OEE, dostępność, MTBF).

Rekomendacje operacyjne / co zrobić teraz

  1. Zweryfikuj ekspozycję
    • Zidentyfikuj wszystkie 1715-AENTR i sprawdź ich wersje firmware/konfigurację sieci. Zachowaj inwentarz w CMDB/asset inventory OT.
  2. Zastosuj poprawki i zalecenia producenta
    • Monitoruj Trust Center / Security Advisories Rockwell i wdrażaj publikowane aktualizacje/mitigacje (w tym firmware, jeśli dostępny). Testuj w środowisku QA/HIL przed produkcją.
  3. Ogranicz powierzchnię ataku w sieci OT
    • Segmentacja (ISA/IEC-62443 z poziomami/zonami), deny-by-default między IT-OT, filtrowanie CIP/EtherNet/IP tylko do zaufanych hostów, brak routingu do Internetu.
    • Zastosuj listy ACL na przełącznikach/industrial firewalls oraz rate-limiting ruchu do modułów 1715. (Dobrą praktyką jest również odseparowanie serwera WWW modułu, jeśli nie jest wymagany operacyjnie). [praktyki ogólne na podstawie zaleceń producenta/CISA]
  4. Monitoring i detekcja
    • Ustaw reguły w IDS/IPS OT na anomalie CIP, monitoruj reset/timeout połączeń, logi urządzeń i zliczanie błędów I/O. Koreluj w SIEM (runbooks SOC/IOC pod DoS CIP).
  5. Plany ciągłości działania
    • Przejrzyj procedury failover i stany bezpieczne. Zweryfikuj, czy zachowania w przypadku utraty I/O są zgodne z HAZOP i analizą ryzyka procesu. (W razie niezgodności – aktualizacja logiki i test FAT/SAT).

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

W przeszłości CISA i Rockwell publikowali liczne doradztwa dot. EtherNet/IP i komponentów komunikacyjnych (np. ControlLogix Ethernet Modules). Dzisiejsze doradztwo koncentruje się jednak na modułach redundancji I/O 1715, które pełnią inną rolę niż moduły sieciowe ControlLogix – ich degradacja wpływa przede wszystkim na dostępność ścieżki I/O w architekturach wysokiej dostępności, zamiast – lub oprócz – typowych implikacji dla ruchu routowalnego w całej szynie.

Podsumowanie / kluczowe wnioski

  • CISA (14.10.2025): Jeden nowy ICS Advisory ICSA-25-287-01 dla Rockwell 1715 EtherNet/IP Comms – głównie ryzyko DoS/utrata komunikacji CIP.
  • Priorytet: inwentaryzacja 1715-AENTR, aktualizacje/mitigacje producenta, segmentacja i kontrola ruchu CIP, monitoring anomalii.
  • Cel: utrzymanie dostępności sterowania i ograniczenie skutków potencjalnego DoS w środowiskach o wysokiej krytyczności.

Źródła / bibliografia

  • CISA – CISA Releases One Industrial Control Systems Advisory (14 października 2025). (CISA)
  • CISA – ICSA-25-287-01: Rockwell Automation 1715 EtherNet/IP Comms Module (karta doradztwa). (CISA)
  • Rockwell Automation – Security Advisories (Trust Center) – wytyczne producenta dot. podatności i aktualizacji. (Rockwell Automation)
  • Rockwell Automation – 1715-AENTR (EtherNet/IP Communications Adaptor Module) – dokumentacja produktu. (Rockwell Automation)
  • CISA – Zestawienia doradztw ICS (wrzesień 2025) – kontekst publikacji. (CISA)

Kompletny Przewodnik Po Promptach AI – Ponad 100 Gotowych Rozwiązań

Fundamenty efektywnego promptowania

Prompty AI to nic innego jak instrukcje lub pytania, które zadajemy modelom sztucznej inteligencji (np. ChatGPT), aby uzyskać od nich użyteczną odpowiedź. Odpowiednio sformułowane prompty potrafią znacznie usprawnić pracę specjalistów ds. bezpieczeństwa informacji – od analizy zagrożeń, przez automatyzację żmudnych zadań, po cele edukacyjne. Nic dziwnego, że w ostatnim czasie ChatGPT stał się gorącym tematem w IT – znajduje coraz szersze zastosowanie, także w cybersecurity.

Czytaj dalej „Kompletny Przewodnik Po Promptach AI – Ponad 100 Gotowych Rozwiązań”

GVM (Greenbone Vulnerability Management) – Kompletny Przewodnik

Czym jest GVM? Słyszałeś o OpenVas?

Greenbone Vulnerability Management (GVM) to otwartoźródłowy pakiet narzędzi do skanowania i zarządzania podatnościami w sieciach komputerowych. Projekt ten narodził się jako OpenVAS (Open Vulnerability Assessment System) – pierwotnie sam skaner podatności wywodzący się z otwartej wersji Nessusa. Z czasem firma Greenbone rozbudowała go o dodatkowe komponenty (zarządzanie wynikami, bazę danych, interfejs WWW) i przemianowała cały ekosystem na GVM, począwszy od wersji po OpenVAS 9.

Czytaj dalej „GVM (Greenbone Vulnerability Management) – Kompletny Przewodnik”

SIGMA –Uniwersalny Język Reguł Detekcji: Od Podstaw do Integracji z SIEM – Część 3

Studium przypadków i praktyczna integracja z systemami bezpieczeństwa

W części pierwszej oraz częsci drugiej omówiliśmy, czym jest Sigma, jak wygląda struktura jej reguł w formacie YAML oraz jak można konwertować je do języków zapytań konkretnych platform SIEM i EDR – takich jak Splunk, Elastic, Sentinel czy QRadar. Poznaliśmy też rolę Sigma w ustandaryzowaniu procesu detekcji i w budowie spójnych mechanizmów obronnych w środowiskach hybrydowych.

Czytaj dalej „SIGMA –Uniwersalny Język Reguł Detekcji: Od Podstaw do Integracji z SIEM – Część 3”

SIGMA – Uniwersalny Język Reguł Detekcji: Od Podstaw do Integracji z SIEM – Część 2

Dlaczego warto integrować reguły Sigma z platformami SIEM/EDR?

Sigma stała się „uniwersalnym językiem” opisu reguł detekcji zagrożeń w logach – czymś w rodzaju „SQL dla bezpieczeństwa” pozwalającym zdefiniować wykrywanie raz, a wykorzystywać na wielu platformach SIEM/EDR.

Czytaj dalej „SIGMA – Uniwersalny Język Reguł Detekcji: Od Podstaw do Integracji z SIEM – Część 2”

SIGMA – Uniwersalny Język Reguł Detekcji: Od Podstaw Do Integracji Z SIEM – Część 1

Wprowadzenie do detekcji opartej na logach i problemu braku standaryzacji

Detekcja zagrożeń oparta na logach jest fundamentem działania zespołów bezpieczeństwa (SOC) – to dzięki analizie dzienników zdarzeń systemów i aplikacji można wykrywać niepożądane aktywności. Historycznie jednak każde narzędzie SIEM (Security Information and Event Management) czy system analizy logów wprowadzało własny język zapytań lub reguł detekcji.

Czytaj dalej „SIGMA – Uniwersalny Język Reguł Detekcji: Od Podstaw Do Integracji Z SIEM – Część 1”