Archiwa: SIEM - Strona 52 z 56 - Security Bez Tabu

Tag: SIEM

Alarm w branży: włamanie do F5 odsłania systemowe ryzyka dla tysięcy organizacji

Wprowadzenie do problemu / definicja luki

20 października 2025 r. Reuters opisał długotrwałe naruszenie bezpieczeństwa w F5 — dostawcy kluczowej infrastruktury aplikacyjnej (m.in. BIG-IP, F5OS, BIG-IP Next), którego rozwiązania znajdują się w wielu organizacjach z listy Fortune 500 oraz sieciach federalnych USA. Atak, przypisywany aktorowi powiązanemu z państwem (doniesienia medialne wskazują na Chiny), miał trwać co najmniej kilkanaście miesięcy i zakończył się kradzieżą fragmentów kodu źródłowego BIG-IP oraz informacji o nieujawnionych jeszcze podatnościach. Rząd USA zareagował 15 października wydaniem Emergency Directive 26-01 dla agencji federalnych.

W skrócie

  • Co się stało: długotrwała kompromitacja środowisk deweloperskich i wiedzy inżynierskiej F5; kradzież kodu i materiałów dot. luk.
  • Dlaczego to ważne: kod i wiedza o lukach mogą przyspieszyć tworzenie exploitów przeciwko urządzeniom F5 w skali globalnej.
  • Reakcja rządu: CISA nakazała natychmiastowy przegląd, aktualizacje i dodatkowe środki ochronne dla środowisk FCEB (ED 26-01).
  • Co (na razie) wiemy, że NIE zaszło: F5 i partnerzy nie znaleźli dowodów na modyfikację łańcucha dostaw ani „wypchnięcie” złośliwych buildów do klientów.

Kontekst / historia / powiązania

Incydent porównuje się do SolarWinds z 2020 r., lecz na dziś brak dowodów manipulacji procesem buildów F5. Równocześnie skala ekspozycji jest wysoka, bo urządzenia F5 często stoją „na styku” sieci (LB/WAF/SSL offload, Access). W przeciwieństwie do SolarWinds, tu kradzież wiedzy i kodu może przynieść atakującym „przewagę wyprzedzenia” w znajdowaniu i weaponizacji luk — nawet zanim pojawią się poprawki.

Analiza techniczna / szczegóły luki

Zakres kompromitacji

  • Środowiska dotknięte: systemy rozwoju oprogramowania BIG-IP oraz repozytoria wiedzy inżynierskiej.
  • Dane wyprowadzone: fragmenty kodu BIG-IP oraz materiały nt. nieopublikowanych podatności (undisclosed vulns).
  • Linia czasu: F5 wykrył nieautoryzowaną aktywność 9 sierpnia 2025 r.; upublicznienie nastąpiło 15 października 2025 r. (SEC 8-K).

Co to oznacza technicznie

Dostęp do kodu źródłowego oraz wewnętrznych analiz luk skraca czas potrzebny na:

  • Diff-ing i code auditing w poszukiwaniu błędów logicznych i RCE/priv-esc;
  • Tworzenie łańcuchów exploitów specyficznych dla wersji i modułów (TMOS/F5OS, TMM, ASM/AFM/APM);
  • Ominięcia funkcji bezpieczeństwa (np. reguł WAF, mechanizmów access).

CISA ostrzega, że takie dane dają aktorowi „technologiczną przewagę” nad obroną.

Praktyczne konsekwencje / ryzyko

  • Przyspieszone 0-day/1-day: realne ryzyko szybkich exploitów zanim poprawki zostaną wdrożone szeroko w terenie.
  • Nadużycia kluczy/API/secrets z repozytoriów inżynierskich (jeśli występowały w materiałach).
  • Ryzyko sektorowe: instytucje rządowe, telekomy, finansowy, zdrowie — wszędzie tam, gdzie BIG-IP pełni rolę bramy/krytycznego LB/WAF.

Rekomendacje operacyjne / co zrobić teraz

1) Inwentaryzacja i ekspozycja

  • Sporządź pełną listę aktywów F5: BIG-IP (iSeries/rSeries/TMOS), F5OS, BIG-IP Next, BIG-IQ. Zmapuj wersje, moduły i lokalizacje.
  • Sprawdź, czy interfejsy zarządcze są odseparowane i niewystawione do Internetu; jeśli są — natychmiast odetnij i wdroż ACL/VPN/JIT. (Dobre praktyki wynikające z alertów CISA).

2) Aktualizacje i twardnienie

  • Zastosuj wydane przez F5 poprawki/aktualizacje zgodnie z ED 26-01; priorytet dla urządzeń EoL/EoS do wymiany.
  • Włącz TLS inspection hardening, weryfikuj polityki i sygnatury WAF/AFM; rozważ tryb „blocking” dla krytycznych aplikacji o znanym profilu. (Wnioski z analiz branżowych).

3) Detekcja i reagowanie

  • Przeprowadź hunting pod kątem anomalii na płaszczyźnie zarządczej i dataplane (TMM): nietypowe logowania, zmiany konfiguracji, modyfikacje iRules, polityk ASM/APM. (Zalecenia oparte o research).
  • Zastosuj telemetrię L7 (np. pełne logowanie HTTP), korelację z SIEM oraz EDR na hostach za F5 (pod kątem lateral movement). (Wnioski operacyjne).

4) Zarządzanie wersjami i gotowość na 1-day

  • Ustal okna szybkiej dystrybucji poprawek dla F5 (48–72h) i proces wymuszonej aktualizacji dla systemów krytycznych. (ED 26-01 wymaga pilnych działań dla FCEB).
  • Przygotuj wzorce wczesnego wykrywania (IOC/behawior) z Unit 42/Rapid7 oraz monitoruj KEV CISA pod kątem nowych wpisów F5.

5) Higiena tajemnic i buildów

  • Rotacja kluczy/API/secrets powiązanych z integracjami F5; przegląd tokenów automatyzacji (Ansible/Terraform). (Wnioski z 8-K i analiz).
  • Weryfikacja integralności backupów i konfiguracji (ucs/qkview), kontrola dostępu do repozytoriów i pipeline’ów NetOps/SecOps. (Praktyki branżowe).

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

  • SolarWinds (2020): kompromitacja łańcucha dostaw i dystrybucja zainfekowanej aktualizacji.
  • F5 (2025): na dziś brak dowodów na modyfikację buildów; kluczowe jest wycieknięcie know-how i kodu, co zwiększa ryzyko szybkich exploitów bez pośrednictwa złośliwych aktualizacji.

Podsumowanie / kluczowe wnioski

  • Wyciek kodu i wewnętrznych analiz luk to „akcelerator” dla przeciwnika.
  • Obrońcy muszą traktować ED 26-01 jak projekt kryzysowy: pełna inwentaryzacja, odseparowanie zarządzania, szybkie patche/wymiany, hunting i telemetria L7.
  • Utrzymuj stały monitoring Unit 42/Rapid7/CISA KEV — to źródła, które najszybciej wskażą nowe TTP/IOC i potencjalne 1-daye po stronie F5.

Źródła / bibliografia

  1. Reuters — omówienie skali i ryzyk (20.10.2025). (Reuters)
  2. CISA — Emergency Directive 26-01 oraz komunikaty dot. F5 (15.10.2025). (CISA)
  3. SEC 8-K F5 (15.10.2025) — szczegóły ujawnienia i zakres danych. (SEC)
  4. Unit 42 (Palo Alto Networks) — analiza techniczna i implikacje. (Unit 42)
  5. Rapid7 — podsumowanie „co wiemy” i zalecenia operacyjne. (Rapid7)

NIS2 – Nowa Dyrektywa UE W Sprawie Cyberbezpieczeństwa: Cele, Zakres I Znaczenie Dla Organizacji

NIS2 w skrócie – po co powstała i co zmienia dla organizacji

Dyrektywa NIS2 (Network and Information Systems 2) to unijne prawo dotyczące cyberbezpieczeństwa, będące następcą pierwszej dyrektywy NIS z 2016 roku (tzw. NIS1). Stanowi ona znaczący krok naprzód w wysiłkach UE na rzecz wzmocnienia cyberbezpieczeństwa w kluczowych sektorach gospodarki.

Czytaj dalej „NIS2 – Nowa Dyrektywa UE W Sprawie Cyberbezpieczeństwa: Cele, Zakres I Znaczenie Dla Organizacji”

Google Ads podszywają się pod Homebrew i LogMeIn. Kampania malvertising atakuje deweloperów macOS infostealerami (AMOS, Odyssey)

Wprowadzenie do problemu / definicja luki

Badacze odnotowali nową falę malvertisingu w Google Ads, w której przestępcy podszywają się pod Homebrew, LogMeIn i TradingView, aby infekować użytkowników macOS – głównie deweloperów – kradnącym dane malware: Atomic macOS Stealer (AMOS) oraz Odyssey Stealer. Reklamy prowadzą do witryn-klonów z instrukcjami uruchomienia komend w Terminalu (“ClickFix”), które pobierają i uruchamiają złośliwe skrypty, omijając mechanizmy ochronne (Gatekeeper).

W skrócie

  • Wektor wejścia: sponsorowane wyniki Google kierujące do fałszywych serwisów (np. homebrewonline[.]org, homebrewupdate[.]org, fałszywe domeny LogMeIn/TradingView).
  • TTP: socjotechnika ClickFix – ofiara kopiuje do schowka i uruchamia w Terminalu polecenie curl | bash ukryte pod pozornie nieszkodliwym przyciskiem “Copy/Verify”.
  • Ładunki: AMOS (MaaS, ~1000 USD/mies.) i Odyssey (fork Poseidon/AMOS) – kradzież haseł, cookies, Keychain, portfeli krypto, plików; exfiltracja do C2.
  • Skala: zidentyfikowano >85 powiązanych domen i współdzieloną infrastrukturę (m.in. IP 93.152.230[.]79, 195.82.147[.]38, certyfikaty SSL reuse).
  • Google: wcześniejsze fale malvertisingu Homebrew potwierdzano już na początku 2025 r.; Google deklarowało zawieszanie kont reklamodawców i usuwanie reklam naruszających zasady.

Kontekst / historia / powiązania

Fałszywe reklamy prowadzące do klonów Homebrew obserwowano już w styczniu 2025 r. – ad prezentował prawidłowy URL brew.sh, ale przekierowywał na niemal identyczne brewe.sh, skąd serwowano AMOS. Google usuwało reklamy i zawieszało powiązane konta, lecz technika powraca w nowych wariantach.
Latem 2025 r. rozwinęła się technika ClickFix (fałszywe “naprawy” i poradniki), którą BleepingComputer i CrowdStrike wiązali m.in. z rodziną Shamos (wariant AMOS). Obecna kampania recyklinguje tę samą logikę nakłaniania do uruchamiania komend.

Analiza techniczna / szczegóły luki

Socjotechnika i interfejsy stron:

  • Strony-klony wyświetlają instrukcję instalacji (Homebrew/LogMeIn/TradingView) oraz przycisk “Copy”. Kliknięcie wrzuca do schowka zaszyfrowaną Base64 komendę, która po wklejeniu do Terminala pobiera install.sh i uruchamia binarkę; stronę utrudniającą zaznaczanie tekstu i podgląd zawartości schowka opisano w raportach threat-intel.

Łańcuch infekcji:

  1. Wejście przez reklamę Google → domena phishingowa (np. homebrewfaq[.]org, tradingviewen[.]com, sites-phantom[.]com).
  2. “Copy” → Base64-curl → pobranie install.sh → pobranie ładunku (AMOS/Odyssey).
  3. Skrypt usuwa atrybut com.apple.quarantine (xattr) i nadaje prawa (chmod), co ominie Gatekeeper.
  4. Malware uruchamia kontrole anti-VM/sandbox, podnosi uprawnienia (sudo), zabija wybrane usługi (np. OneDrive updater), korzysta z XPC, zbiera artefakty systemowe i przeglądarkowe, a następnie exfiltruje dane do C2.

Infrastruktura i IOCs (wybór):

  • Domeny: homebrewonline[.]org, homebrewupdate[.]org, homebrewclubs[.]org, homebrewfaq[.]org, tradingviewen[.]com, tradingvieweu[.]com, sites-phantom[.]com, filmoraus[.]com; warianty LogMeIn: m.in. logmeln[.]com, logmeeine[.]com.
  • IP: 93.152.230[.]79, 195.82.147[.]38; korelacja po re-use certyfikatów SSL (np. CN związany z trading.example.com).

Rodziny malware:

  • AMOS – MaaS udostępniany na abonament (~1000 USD/mies.), eksfiltruje hasła, cookies, Keychain, portfele, karty; niedawno otrzymał komponent backdoora (persistent remote access).
  • Odyssey – nowa rodzina powiązana rodowodem z Poseidon/AMOS, kradnie dane z Safari/Chrome/Firefox, ponad setki rozszerzeń portfeli i Keychain, pakuje do ZIP i wysyła do C2.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja tożsamości deweloperskiej (tokeny, SSH keys, cookies sesyjne) → ryzyko supply-chain (publikacja złośliwych buildów, backdoor w repo).
  • Utrata środków z kryptowalut/portfeli przeglądarkowych.
  • Persistent access (komponenty backdoor) i lateral movement w urządzeniach BYOD/MDM, także w kontekstach firmowych korzystających z LogMeIn/TradingView.

Rekomendacje operacyjne / co zrobić teraz

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

  1. Nie uruchamiaj w Terminalu poleceń znalezionych na stronach innych niż oficjalne – prawidłowe domeny to m.in. brew.sh (Homebrew), nie ich warianty typograficzne. Dodaj reguły DNS/URL Filtering blokujące znane typosquaty (lista wyżej).
  2. Instalacja Homebrew: korzystaj z oficjalnej instrukcji na brew.sh (weryfikuj URL i certyfikat). Zawsze czytaj skrypty instalacyjne przed pipowaniem do shella.
  3. EDR/AV na macOS z detekcją stealerów (AMOS/Odyssey) i monitorowaniem uruchomień curl → bash oraz modyfikacji xattr. (Por. wcześniejsze raporty o kampaniach Homebrew/AMOS).
  4. Twarde polityki przeglądarki: wyłącz automatyczne uruchamianie skryptów z niezaufanych źródeł, izoluj profile przeglądarki, wymuś passkey/2FA dla krytycznych usług.
  5. Higiena kluczy i tokenów: rotacja Keychain, haseł, tokenów CI/CD i logowań do chmur po incydencie; unieważnienie sesji (cookies).
  6. Monitoruj IOC: dodaj do blokad i SIEM/EDR (domeny/IP powyżej), filtruj ruch do nowo-zarejestrowanych domen i TLD spoza profilu.

Dla zespołów marketingu/reklam:
7. Zgłaszaj podejrzane reklamy i nadużycia brandu w Google Ads; praktyka z pocz. 2025 r. pokazuje, że zawieszenia kont i usuwanie reklam są wdrażane, ale atakujący szybko rotują infrastrukturą – konieczny jest brand monitoring i taksonomie słów kluczowych (wykluczenia, “exact match”).

Dla SOC/DFIR – wskazówki detekcyjne (starter):

  • Sygnatury zachowania: łańcuch browser → clipboard → Terminal; procesy: Terminal.app/iTerm2 uruchamiają bash/zsh z parametrem -c oraz curl -fsSL ... | base64 -d | bash. Wzorce xattr -d com.apple.quarantine, chmod +x tuż przed uruchomieniem binarki.
  • Telemetria sieciowa: żądania do domen typosquattingowych (Homebrew/LogMeIn/TradingView), korelacja z IP 93.152.230[.]79 i 195.82.147[.]38 oraz reuse certyfikatów.

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

  • GitHub-malspam (AMOS): wcześniej dystrybucja przez fałszywe repozytoria; obecnie wraca malvertising + ClickFix. Wspólny mianownik: socjotechnika i kradzież tożsamości dewelopera.
  • “Fake fixes” na macOS (Shamos/AMOS): ta sama technika ClickFix, ale pretekst inny (rzekome naprawy systemu). Obecna kampania udaje instalatory znanych narzędzi (Homebrew/LogMeIn/TradingView).

Podsumowanie / kluczowe wnioski

  • Atak łączy SEO+Ads z socjotechniką Terminalową – skuteczny wobec deweloperów przyzwyczajonych do skryptowych instalatorów.
  • AMOS/Odyssey pozostają jednymi z najbardziej aktywnych stealerów na macOS; ich operatorzy recyklingują infrastrukturę i domeny, przez co kampanie są długowieczne.
  • Higiena instalacji (weryfikacja domen, brak “curl | bash” z niezweryfikowanych źródeł), telemetria EDR i blokady DNS to najszybsze środki obniżające ryzyko.

Źródła / bibliografia

  1. BleepingComputer – Google ads for fake Homebrew, LogMeIn sites push infostealers (18 października 2025). (BleepingComputer)
  2. Hunt.io – Odyssey Stealer & AMOS Hit macOS Developers with Fake Homebrew Sites (16 października 2025). (hunt.io)
  3. SecurityWeek – Homebrew macOS Users Targeted With Information Stealer Malware (23 stycznia 2025). (SecurityWeek)
  4. Bitdefender – Criminals Use Fake Mac Homebrew Google Ads in New Malicious Campaign (22 stycznia 2025). (Bitdefender)
  5. BleepingComputer – Fake Mac fixes trick users into installing new Shamos infostealer (22 sierpnia 2025). (BleepingComputer)

Europol rozbija sieć „SIM farm”: 7 zatrzymanych, 1 200 urządzeń SIM-box i 49 mln fałszywych kont

Wprowadzenie do problemu / definicja luki

Europol (przy wsparciu Eurojustu i służb z Austrii, Estonii, Finlandii oraz Łotwy) rozbił międzynarodową infrastrukturę cybercrime-as-a-service o kryptonimie SIMCARTEL, która wynajmowała przestępcom numery telefoniczne z ponad 80 krajów do rejestracji i weryfikacji kont oraz prowadzenia oszustw. Zatrzymano 7 osób, przeprowadzono 26 przeszukań, zajęto 1 200 urządzeń SIM-box i 40 000 aktywnych kart SIM, a także pięć serwerów i dwie domeny wykorzystywane do świadczenia usługi. Według organów ścigania infrastruktura pomogła utworzyć blisko 50 mln fałszywych kont.

W skrócie

  • Skala: 3 200+ udokumentowanych przypadków oszustw, straty min. ~5 mln € (gł. Austria i Łotwa).
  • Modus operandi: hurtowy wynajem numerów (SIM-farmy/SIM-boxy) do obejścia weryfikacji SMS i ukrywania tożsamości.
  • Seizury: 1 200 SIM-box, 40 000 aktywnych SIM, setki tys. dodatkowych kart, 5 serwerów, mrożenie środków i konfiskata luksusowych aut.
  • Zastosowania przestępcze: phishing/smishing, fałszywe inwestycje, „na córkę/syna” w WhatsApp, podszywanie się pod policję, sklepy-widmo, a także przestępstwa pozatelekomunikacyjne.

Kontekst / historia / powiązania

Eurojust podaje, że platforma udostępniała numery z >80 krajów i była oferowana innym grupom w modelu CaaS (Crime-as-a-Service). Działania operacyjne przeprowadzono 10 października 2025 r., a komunikaty opublikowano 17 października.
Niezależne redakcje (BleepingComputer, CyberScoop, The Record) potwierdzają aresztowania i skalę zabezpieczeń, podając zbliżone szacunki strat: ok. 4,5 mln € w Austrii i ~420 tys. € na Łotwie.

Analiza techniczna / szczegóły luki

SIM-box/SIM-farmy to zestawy bramek GSM z dziesiątkami/setkami gniazd SIM, które automatycznie rotują karty i numery. Dzięki sterowaniu API można masowo:

  • odbierać kody SMS (OTP) do rejestracji kont i resetów haseł,
  • prowadzić smishing na dużą skalę,
  • omijać mechanizmy anty-fraudowe platform (np. limity na numer/urządzenie),
  • maskować geolokalizację i tożsamość operatora.

W sprawie SIMCARTEL infrastruktura działała jak profesjonalna usługa: panel online, automatyzacja, pozyskiwanie kart z wielu rynków, a nawet „oferta” na wynajem numerów i monetyzację cudzych kart. Organy przejęły m.in. serwisy ułatwiające pozyskanie numerów jednorazowych do kodów weryfikacyjnych.

Dlaczego to działa?
Ekosystem SMS-OTP i weryfikacji numeru telefonu jest podatny na nadużycia, bo:

  • SMS nie zapewnia silnego uwierzytelnienia i jest podatny na przekierowania/SS7/małe opóźnienia dostaw,
  • wiele serwisów ufnie traktuje numer jako tożsamość (KBA/„posiadanie”),
  • reputacja numeru jest słabo współdzielona między usługami.

Praktyczne konsekwencje / ryzyko

  • Platformy online: zalew botów i kont-widm (do 49 mln), spadek skuteczności AML/KYC light, nadużycia programów promocyjnych, większe koszty moderacji i ryzyka.
  • Instytucje finansowe: phishing inwestycyjny, podszywanie się, nadużycia „SCA via SMS”.
  • Użytkownicy: ataki „na córkę/syna” w komunikatorach, wyłudzenia danych i środków.
  • Telco: wykorzystanie ich sieci do generowania ruchu A2P, ryzyko reputacyjne i regulacyjne.

Rekomendacje operacyjne / co zrobić teraz

Dla platform i fintechów

  1. Ogranicz zaufanie do SMS-OTP: przejdź na passkeys/FIDO2 jako główny MFA; SMS zostaw jako fallback z dodatkowymi kontrolami ryzyka.
  2. Weryfikacja numeru ≠ weryfikacja tożsamości: zawsze łącz z innymi sygnałami (dokument/biometria, proof-of-personhood).
  3. Inteligencja numerów: HLR/MNP lookups, kontrola klasy usługi (pre-/post-paid), sprawdzanie nowości numeru, scoring reputacji (czy numer był widziany przy wielu rejestracjach).
  4. Anti-abuse na rejestrację: device fingerprinting, velocity rules (na IP/ASN/IMEI-like), limity per metoda płatności, weryfikacje „liveness” w KYC, dynamiczne CAPTCHy.
  5. Monitoring: reguły SIEM/FRM wychwytujące anomalię OTP (dużo SMS na ten sam numer/zakres), alerty na skoki rejestracji z jednego kraju/ASN.

Dla banków i e-commerce

  • Transaction-level MFA (push z bindingiem urządzenia, podpis kryptograficzny), detekcja „social engineering session”.
  • Predefiniowane ostrzeżenia UX i bloki słów kluczowych w komunikacji (np. wzorce „nowy numer dziecka”, „pilny przelew”).

Dla operatorów telekomunikacyjnych

  • Detekcja SIM-box: korelacja IMSI/IMEI, anomalia w TADIG/CellID (duża liczba MSISDN z jednego modemu), nietypowe profile SMS-MT/MO, hurtowa rotacja kart.
  • Współpraca z LEA/CSIRT oraz sinkhole numerów/domen powiązanych z farmami.

Dla użytkowników

  • Nie traktuj SMS jako dowodu tożsamości rozmówcy. Weryfikuj „nowe numery” bliskich innym kanałem. Blokuj linki z SMS/komunikatorów kierujące do płatności/logowania.

Różnice / porównania z innymi przypadkami

W USA we wrześniu 2025 r. tajne służby rozbiły dużą SIM farmę (ponad 300 serwerów i 100 000 kart SIM) wskazując na rosnące ryzyko dla infrastruktury krytycznej. Europa i USA notują więc zbliżoną taktykę, ale inne wektory nadużyć (w UE – silny nacisk na oszustwa konsumenckie i masowe rejestracje kont).

Podsumowanie / kluczowe wnioski

  • SIM-farmy komodytyzują nadużycia oparte na SMS-OTP i deprecjonują numer telefonu jako sygnał zaufania.
  • Organizacje powinny odejść od SMS-OTP jako głównego MFA i wzmocnić kontrole anty-abuse na etapie rejestracji/kontaktu.
  • Współpraca LEA (Europol/Eurojust) z podmiotami prywatnymi i operatorami pozostaje kluczowa do demontażu infrastruktury CaaS.

Źródła / bibliografia

  1. Eurojust: „Decisive action against various online scams in Austria and Latvia: seven arrests”, 17.10.2025. (szczegóły operacji, liczby: 1 200 SIM-box, 40 000 SIM, ~50 mln kont, 26 przeszukań). (Eurojust)
  2. Europol: „Cybercrime-as-a-service takedown: 7 arrested – Operation SIMCARTEL” (komunikat prasowy: aresztowania, przejęte serwisy). (Europol)
  3. BleepingComputer: „Europol dismantles SIM box operation renting numbers for cybercrime”, 17.10.2025 (szacunki strat, przejęte domeny). (BleepingComputer)
  4. CyberScoop: „Europol dismantles cybercrime network linked to $5.8M in financial losses”, 17.10.2025 (dodatkowe liczby, kontekst USA). (CyberScoop)
  5. The Record: „European police bust network selling thousands of phone numbers to scammers”, 17.10.2025 (tło śledztwa, cytaty, materiał wideo policji). (The Record from Recorded Future)

Luki w Fuji Electric V-SFT (HMI Configurator): analiza techniczna, skutki dla OT i jak się zabezpieczyć

Wprowadzenie do problemu / definicja luki

W oprogramowaniu V-SFT (konfigurator HMI dla paneli MONITOUCH firmy Fuji Electric) ujawniono nowy pakiet podatności, które mogą prowadzić do wykonania dowolnego kodu na stacji inżynierskiej po otwarciu specjalnie spreparowanego pliku projektu. Luki dotyczą wersji 6.2.7.0 i starszych i zostały ujęte przez JPCERT/CC pod numerem JVNVU#90008453 (zestaw CVE-2025-61856 … 61864). Producent udostępnił aktualizację do V-SFT 6.2.9.0.

W skrócie

  • Wpływ: wykonanie kodu, ujawnienie informacji, awaria aplikacji (ABEND) po otwarciu złośliwego pliku V-SFT.
  • Wektor: atak wymaga interakcji użytkownika (socjotechnika / dostarczenie projektu V-SFT).
  • Zakres: dotyczy stacji inżynierskich Windows w zespołach OT (inżynierowie HMI/SCADA).
  • Łatki: aktualizacja do 6.2.9.0 (strona producenta nie nazywa wprost “security fix”, ale to wersja wskazana przez JPCERT).

Kontekst / historia / powiązania

To kolejny w tym roku pakiet luk w V-SFT. W maju 2025 JPCERT publikował JVNVU#97228144 (CVE-2025-47749 … 47760) dotyczący wersji 6.2.5.0 i starszych – również z ryzykiem RCE po otwarciu plików V7/V8. Zatem obserwujemy ciągłość problemów w parserach formatów projektu V-SFT.

Badacz Michael Heinzl opublikował własne advisories i wskazuje, że w ostatnich miesiącach załatano ponad 20 błędów w tym ekosystemie narzędziowym.

Analiza techniczna / szczegóły luki

Pakiet październikowy (JVNVU#90008453) obejmuje m.in.:

  • CVE-2025-61856 – stack-based buffer overflow w VS6ComFile!CV7BaseMap::WriteV7DataToRom.
  • CVE-2025-61857 … 61859 – out-of-bounds write w różnych ścieżkach przetwarzania obiektów/animacji.
  • CVE-2025-61860 … 61863 – out-of-bounds read w modułach pamięci/serializacji.
  • CVE-2025-61864 – use-after-free w load_link_inf.

Wszystkie ocenione na CVSS v4.0: 8.4 (High) oraz CVSS v3.1: 7.8 (High). Warunkiem skuteczności jest otwarcie spreparowanego pliku przez operatora/inżyniera; wykonanie następuje z uprawnieniami zalogowanego użytkownika.

Zakres wersji: „V-SFT v6.2.7.0 i starsze” – oficjalna nota JPCERT. Producent publikuje „Improvement information” dla 6.2.9.0, która jest wskazywana jako docelowa przez JPCERT, mimo że release notes nie nazywają zmian „security”.

Praktyczne konsekwencje / ryzyko

  • Przejęcie stacji inżynierskiej: wykonanie kodu pozwala na instalację narzędzi zdalnego dostępu, kradzież poświadczeń i pivot do sieci OT/IT.
  • Łańcuch dostaw projektów HMI: atakujący mogą podszywać się pod integratorów/partnerów i dostarczać „aktualizację” projektu.
  • Ataki bezpośrednio na środowisko produkcyjne: choć luki nie „dotykają” bezpośrednio paneli HMI, kompromitacja stacji inżynierskiej zwiększa ryzyko nieautoryzowanej zmiany logiki/ekranu HMI, a w konsekwencji wpływu na proces.
  • Niski próg socjotechniczny: wystarczy nakłonić inżyniera do otwarcia pliku.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj V-SFT do 6.2.9.0 na wszystkich stacjach inżynierskich (zgodnie ze wskazaniem JPCERT). Zweryfikuj hash/pochodzenie instalatora.
  2. Zablokuj uruchamianie projektów z nieznanych źródeł. Wprowadź whitelisting dostawców/projektów HMI.
  3. Segmentacja OT: stacje inżynierskie w osobnej strefie, dostęp z IT tylko przez jump hosty i MFA.
  4. Polityka poczty i wymiany plików: sandboxing załączników, skanowanie na bramkach, blokada makr/nietypowych rozszerzeń projektów V-SFT.
  5. Uprawnienia minimalne: użytkownicy V-SFT bez praw administratora; włącz Application Control/SRP/WDAC.
  6. Monitoring: reguły EDR/SIEM pod kątem nieoczekiwanego uruchamiania procesów potomnych przez V-SFT, kompilatorów, PowerShell/WSH.
  7. Testy IR: scenariusz „złośliwy projekt HMI” w planach ćwiczeń blue teamu.
  8. Przegląd poprzednich ostrzeżeń: jeśli wciąż działają wersje ≤6.2.5.0, zastosuj zalecenia z wcześniejszego JVNVU#97228144.

Różnice / porównania z innymi przypadkami

  • Ten sam wektor, nowe prymitywy: zarówno pakiet majowy (CVE-2025-47749…60), jak i październikowy (CVE-2025-61856…64) opierają się na błędach parsowania plików (OOB R/W, UAF, stack overflow), ale uderzają w inne komponenty DLL i ścieżki (np. CV7BaseMap, CItemDraw, WinFont*).
  • Ścieżka łatania: w październiku wskazana wersja docelowa to 6.2.9.0; w maju – aktualizacja wyższa niż 6.2.5.0. Ciągła potrzeba aktualizacji podkreśla wagę zarządzania wersjami narzędzi inżynierskich w OT.
  • Widoczność po stronie vendorów/CSIRT: SecurityWeek nagłaśnia, JPCERT formalnie koordynuje; CISA wcześniej publikowała advisories dla linii V-SFT/TELLUS, co pokazuje stałe zainteresowanie regulatorów ICS tym ekosystemem.

Podsumowanie / kluczowe wnioski

  • Najnowszy pakiet CVE dla V-SFT ≤6.2.7.0 umożliwia RCE po otwarciu pliku; ryzyko wysokie (CVSS v4.0: 8.4).
  • Aktualizacja do 6.2.9.0 jest w tej chwili kluczowym środkiem zaradczym, mimo niejednoznacznych not w „Improvement information”.
  • Organizacje powinny traktować stacje inżynierskie jak systemy o podwyższonym ryzyku: twarda segmentacja, kontrola źródeł projektów, EDR i polityki wymiany plików.

Źródła / bibliografia

  • SecurityWeek: „Fuji Electric HMI Configurator Flaws Expose Industrial Organizations to Hacking”, 16 października 2025. (SecurityWeek)
  • JPCERT/CC (JVN): JVNVU#90008453 – Multiple vulnerabilities in FUJI Electric V-SFT, 8 października 2025. (Japan Vulnerability Notes)
  • JPCERT/CC (JVN): JVNVU#97228144 – Multiple vulnerabilities in V-SFT, 14 maja 2025. (Japan Vulnerability Notes)
  • Fuji Electric / Hakko: Improvement information (V-SFT-6) – lista wersji, w tym 6.2.9.0. (Monitouch)
  • aweSEC (Michael Heinzl): lista advisories 2025 z pozycjami dotyczącymi Fuji Electric V-SFT. (awesec.com)

Microsoft unieważnia ponad 200 certyfikatów, by zablokować kampanię Rhysida — co to oznacza dla firm?

Wprowadzenie do problemu / definicja luki

Microsoft poinformował, że w początku października 2025 r. zakłócił kampanię prowadzącą do wdrożeń ransomware Rhysida, unieważniając ponad 200 certyfikatów używanych do podpisywania złośliwych plików. Kampanię przypisano grupie Vanilla Tempest (znanej także jako Vice Spider / Vice Society). Złośliwe binaria podpisywano m.in. przy użyciu Trusted Signing oraz usług podpisywania kodu dostawców SSL.com, DigiCert i GlobalSign.

W skrócie

  • Vektor wejścia: fałszywe strony podszywające się pod witrynę pobierania Microsoft Teams (np. teams-download[.]buzz, teams-install[.]run, teams-install[.]top).
  • Payload: podpisany backdoor Oyster (znany też jako Broomstick/CleanUpLoader), wykorzystywany następnie do wdrożenia Rhysida.
  • Działanie obronne: Microsoft unieważnił >200 certyfikatów, aktualizując detekcje dla fałszywych podpisów oraz narzędzi kampanii.
  • Aktor: Vanilla Tempest — finansowo motywowany, znany z ataków na edukację i ochronę zdrowia, wcześniej wykorzystywał różne rodzinny ransomware (m.in. BlackCat, Quantum Locker, Zeppelin).

Kontekst / historia / powiązania

Vanilla Tempest to nowa nazwa taksonomiczna Microsoftu dla wcześniej trackowanego DEV-0832/Vice Society, znanego z ataków oportunistycznych i eklektycznego doboru ładunków szyfrujących.
Rhysida funkcjonuje w modelu RaaS i jest regularnym celem ostrzeżeń rządowych — najnowsza, zaktualizowana w 2025 r. notyfikacja CISA opisuje TTPs i IOC tej rodziny.
Backdoor Oyster był już wcześniej dystrybuowany przez malvertising/SEO-poisoning jako trojanizowane instalatory popularnych narzędzi (PuTTY, WinSCP, a ostatnio — Teams).

Analiza techniczna / szczegóły luki

Łańcuch ataku:

  1. Pozycjonowanie i reklamy kierowały ofiary na domeny łudząco podobne do legitymnych stron Teams.
  2. Pobierany plik MSTeamsSetup.exe był loaderem, który uruchamiał podpisaną wersję backdoora Oyster.
  3. Oyster zapewnia trwały, zdalny dostęp (kradzież plików, wykonywanie poleceń, dogrywanie ładunków), ułatwiając lateral movement i wdrożenie Rhysida.

Nadużycie zaufania:
Aktor wykorzystywał Trusted Signing (krótkoterminowe certyfikaty) oraz usługi podpisywania kodu SSL.com, DigiCert, GlobalSign, aby nadać artefaktom pozory wiarygodności (SmartScreen, AV/EDR trust). Microsoft przerwał kampanię przez hurtową revokację >200 certyfikatów powiązanych z fałszywymi instalatorami i narzędziami post-exploitation.

Praktyczne konsekwencje / ryzyko

  • Podpis ≠ bezpieczeństwo: Sam fakt podpisania binarium nie gwarantuje braku złośliwości. SOC-e powinny korelować podpisy z telemetrią uruchomień, siecią i zachowaniem.
  • Ryzyko supply-chain w userlandzie: Użytkownicy częściej „googlują” instalatory niż pobierają je z portali producenta — atak świetnie skaluje się na helpdeskach i w SMB.
  • Utrzymujące się TTPs: Nawet po revokacji certyfikatów aktor może się przegrupować z nowymi certyfikatami/infrastrukturą.

Rekomendacje operacyjne / co zrobić teraz

  1. Blokady domen/URL: natychmiast dodać do denylist znane domeny kampanii (teams-download[.]buzz, teams-install[.]run, teams-install[.]top, itp.) i monitorować pokrewne typosquaty.
  2. Źródła instalatorów: enforce’ować politykę pobierania oprogramowania wyłącznie z domen producenta; rozważyć blokadę pobrań EXE/MSI z wyszukiwarek.
  3. Kontrole podpisów: w EDR/SIEM budować reguły na anomalia podpisów (wydawca ≠ oczekiwany; chain do niedawno odwołanego certyfikatu; short-lived certs).
  4. Detekcje Oyster/Rhysida: wdrożyć najnowsze IOC/TTP z biuletynów branżowych i CISA; szukać nietypowych połączeń C2 oraz artefaktów loadera.
  5. Hardening przeglądarek/DNS: izolacja przeglądarek dla pobrań, DNS sinkhole dla domen malvertisingowych, blokada reklam na poziomie sieci.
  6. Edukacja użytkowników: krótkie runbooki „Jak bezpiecznie pobierać Teams” + banery w intranecie. (Źródła kampanii dowodzą skuteczności SEO-poisoningu).
  7. IR gotowość: playbook Ryusida/Oyster: containment hostów z podejrzanym MSTeamsSetup.exe, natychmiastowa rotacja poświadczeń, review logonów interaktywnych, hunting po sygnaturach podpisu.

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

W przeszłości widzieliśmy kradzione lub wyłudzone certyfikaty używane do podpisywania malware. Nowością jest systemowe nadużycie usług podpisywania (w tym Trusted Signing z krótką ważnością certyfikatów), co znacząco zwiększa tempo rotacji certyfikatów po stronie aktora i utrudnia proste bloki „na wydawcę”. Dzisiejsze zdarzenie pokazuje, że hurtowa revokacja i telemetria behawioralna są skuteczniejsze niż poleganie na samym zaufaniu do łańcucha certyfikacji.

Podsumowanie / kluczowe wnioski

  • >200 odwołanych certyfikatów to zdecydowany ruch, który obniża skuteczność kampanii, ale nie eliminuje ryzyka rearmowania się przeciwnika.
  • Fałszywe instalatory Teams + Oyster → Rhysida: łańcuch ataku był wiarygodny dzięki podpisom i SEO-poisoning.
  • Organizacje powinny wzmocnić kontrolę źródeł oprogramowania, reguły detekcji podpisów i higienę przeglądarkową.

Źródła / bibliografia

  1. SecurityWeek — „Microsoft Revokes Over 200 Certificates to Disrupt Ransomware Campaign”, 16 października 2025 r. (SecurityWeek)
  2. BleepingComputer — „Microsoft disrupts ransomware attacks targeting Teams users”, 16 października 2025 r. (BleepingComputer)
  3. CISA — „#StopRansomware: Rhysida Ransomware” (zaktualizowane 30 kwietnia 2025 r.). (CISA)
  4. Microsoft Security Blog — „DEV-0832 (Vice Society)…” (mapowanie do Vanilla Tempest), 25 października 2022 r. (Microsoft)
  5. Broadcom / Symantec — „Oyster backdoor spread via malicious Teams setup”, 29 września 2025 r. (Broadcom)

F5: atak powiązany z Chinami, wycieki kodu BIG-IP i szybkie łatki. Rządy wydają alerty

Wprowadzenie do problemu / definicja luki

F5 potwierdziło poważny incydent bezpieczeństwa: zaawansowany aktor państwowy uzyskał długotrwały dostęp do środowisk deweloperskich i platformy wiedzy inżynierskiej, skąd wykradziono m.in. fragmenty kodu źródłowego BIG-IP oraz informacje o nieujawnionych jeszcze podatnościach. W reakcji F5 opublikowało pakiet poprawek bezpieczeństwa i przeprowadziło rotację kluczy/certyfikatów podpisywania oprogramowania. Agencje rządowe USA i Wielkiej Brytanii wydały pilne ostrzeżenia i wytyczne.

W skrócie

  • Atrybucja: doniesienia medialne i analiza profilu ataku wskazują na grupę powiązaną z Chinami (m.in. wątki łączone z kampanią BRICKSTORM/UNC5221).
  • Ryzyko systemowe: CISA wydała Emergency Directive 26-01, nazywając zagrożenie „imminent threat” i nakazując federalnym agencjom inwentaryzację, twardnienie i szybkie łatanie BIG-IP (m.in. do 22 października 2025 r. dla części działań).
  • Stan łańcucha dostaw: na ten moment brak dowodów na modyfikację procesu build/release czy backdoor w produktach, ale wyciek kodu i wiedzy o podatnościach może przyspieszyć rozwój ukierunkowanych exploitów.

Kontekst / historia / powiązania

F5 BIG-IP jest powszechnie wykorzystywany jako load balancer/WAF na brzegu sieci — stąd każdy incydent w ekosystemie F5 ma potencjał „efektu domina”. W ostatnich tygodniach Google Threat Intelligence i Mandiant opisały kampanię BRICKSTORM: bardzo długie utrzymywanie się w sieciach ofiar (średnio setki dni), celowanie w firmy technologiczne i SaaS oraz kradzież kodu w celu wyszukiwania 0-dayów. Wątki te są spójne z tym, co F5 przekazuje klientom po incydencie.

Analiza techniczna / szczegóły luki

  • Vuln intel: F5 w „Quarterly Security Notification (October 2025)” wydało duży pakiet łatek na dziesiątki podatności w BIG-IP i innych produktach. Znaczna część luk to DoS (często zdalne i bez uwierzytelnienia), ale są też obejścia mechanizmów bezpieczeństwa i eskalacje uprawnień wymagające logowania.
  • Artefakty ataku: napastnicy uzyskali dostęp do repozytoriów/zasobów inżynierskich, skąd pozyskali fragmenty kodu i informacje o nieopublikowanych jeszcze podatnościach. To szczególnie groźne, bo umożliwia analizę statyczną/dynamiczną pod kątem błędów logicznych i tworzenie precyzyjnych exploitów.
  • Łańcuch dostaw: F5 (we współpracy z Mandiant i CrowdStrike) nie znalazło dowodów na manipulację pipeline’em build/release ani tampering kodu NGINX czy usług chmurowych F5; CISA i NCSC jednak ostrzegają, że warstwa ryzyka pozostaje podwyższona.

Praktyczne konsekwencje / ryzyko

  • Przyspieszone exploit dev: wyciek kodu i wiedzy o lukach zwiększa prawdopodobieństwo pojawienia się ukierunkowanych RCE/priv-esc bypassów na BIG-IP.
  • Dostęp do kluczy/sekretów: według CISA potencjalne wykorzystanie dotkniętych produktów może dać atakującym dostęp do wbudowanych poświadczeń i kluczy API, lateral movement, eksfiltrację danych i trwałą persystencję.
  • Sektor publiczny i krytyczna infrastruktura: stąd pilne dyrektywy/zalecenia USA i UK.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowe łatanie: zastosuj najnowsze aktualizacje F5 (BIG-IP i inne dotknięte produkty). W organizacjach objętych reżimem federalnym USA odnieś się do ED 26-01 (deadline’y operacyjne, m.in. 22.10.2025).
  2. Inwentaryzacja i segmentacja: sporządź pełną listę fizycznych/virtual BIG-IP, zwłaszcza z interfejsem do Internetu; egzekwuj zasadę najmniejszych uprawnień na kontach administracyjnych.
  3. Hardening i ekspozycja: ogranicz dostęp do TMUI/zarządzania (VPN/jump hosts), włącz SSH key-only, wyłącz nieużywane moduły, zweryfikuj SNAT/irule/ASM policy pod kątem misconfigów. (Dobre praktyki wynikają z wytycznych CISA/NCSC i doświadczeń z incydentami na urządzeniach brzegowych.)
  4. Rotacja sekretów: po aktualizacji zmień hasła, klucze i certyfikaty powiązane z BIG-IP (w tym MGT/API), zweryfikuj zaufanie do łańcuchów certyfikatów — F5 przeprowadziło rotację własnych kluczy podpisywania.
  5. Threat hunting pod BRICKSTORM/UNC5221: skanuj pod kątem technik długotrwałej persystencji, nietypowych jobów/cronów, artefaktów tunelowania i anomalii ruchu wychodzącego; porównaj baseline’y konfiguracji i logów z ostatnich 12+ miesięcy. (Mapowanie do kontekstu BRICKSTORM i TTPs).
  6. Monitoring i telemetria: włącz/dotwardź logowanie LTM/TMM, ASM/Adv WAF, APM; wysyłaj do SIEM, wprowadź reguły korelacyjne na anomalie cookie/session oraz błędy TMUI.

Różnice / porównania z innymi przypadkami

W odróżnieniu od klasycznych kampanii na urządzenia brzegowe (np. wyłącznie exploit znanej luki TMUI), tu wektor ryzyka wynika z kompromitacji producenta, wycieku kodu i wiedzy o nieopublikowanych lukach. To przybliża scenariusz do głośnych incydentów supply-chain (SolarWinds, 3CX), choć dotychczas nie ma dowodów na zainfekowane buildy/aktualizacje F5.

Podsumowanie / kluczowe wnioski

  • Incydent F5 ma wysoki ciężar systemowy: BIG-IP stoi na styku sieci, a wyciek kodu i informacji o lukach zwiększa presję czasową na zespoły.
  • Łataj, utwardzaj, rotuj sekrety i poluj na persystencję — wprost według ED 26-01 i wskazówek NCSC.
  • Wątek BRICKSTORM/UNC5221 wzmacnia hipotezę o długotrwałej, cichej infiltracji nakierowanej na pozyskiwanie kodu i wiedzy, co może owocować exploitami „szytymi na miarę” w najbliższych tygodniach.

Źródła / bibliografia

  1. SecurityWeek: „F5 Hack: Attack Linked to China, BIG-IP Flaws Patched, Governments Issue Alerts” (16 października 2025). (SecurityWeek)
  2. CISA – Emergency Directive 26-01: Mitigate Vulnerabilities in F5 Devices (15 października 2025). (CISA)
  3. NCSC UK – „Confirmed compromise of F5 network” (15 października 2025). (NCSC)
  4. Google Threat Intelligence – „BRICKSTORM espionage campaign” (24 września 2025). (Google Cloud)
  5. Reuters – „Breach at F5 blamed on China, Bloomberg reports” (16 października 2025). (Reuters)