Archiwa: Admin - Strona 16 z 33 - Security Bez Tabu

Nefilim ransomware: ukraiński operator przyznaje się do winy — jak działał model „affiliate” i co to mówi o dzisiejszych kampaniach RaaS

Wprowadzenie do problemu / definicja luki

Sprawa Nefilim to dobry przykład, jak „klasyczny ransomware” ewoluował w dojrzały model usługowy: jedni dostarczają platformę i malware, inni (affiliate) włamują się do sieci ofiary, kradną dane, a potem szyfrują i szantażują publikacją. To nie „jedna luka”, tylko cały łańcuch: dostęp początkowy → rozpoznanie → eskalacja → eksfiltracja → szyfrowanie i presja negocjacyjna.


W skrócie

  • Artem Aleksandrovych Stryzhak (35 lat) przyznał się w USA do udziału w międzynarodowych atakach ransomware z użyciem Nefilim; grozi mu do 10 lat więzienia.
  • Z materiałów sprawy wynika, że otrzymał dostęp do kodu i „panelu” Nefilim w zamian za 20% udziału w okupach.
  • Operatorzy Nefilim mieli preferować firmy z USA/Kanady/Australii z przychodami > 100 mln USD (a później zachęcać do > 200 mln USD) i stosować double extortion („szyfrujemy + publikujemy wykradzione dane”).
  • Wątek ścigania współsprawcy (Volodymyr Tymoshchuk) jest wspierany nagrodą do 11 mln USD za informacje prowadzące do zatrzymania/lokalizacji.

Kontekst / historia / powiązania

Nefilim był szerzej obserwowany od 2020 r. jako „nowoczesny ransomware” celujący w duże organizacje, powiązywany z ekosystemem RaaS oraz ewolucją/continuum rodzin typu Nemty. Trend Micro opisuje go jako operację RaaS z podziałem zysków i długim „czasem przebywania” w sieci ofiary (często tygodnie) w celu maksymalizacji presji i strat.

W tle tej sprawy pojawiają się też powiązania personalne/operacyjne z innymi głośnymi rodzinami ransomware. The Record opisywał oskarżenia wobec Tymoshchuka jako administratora m.in. LockerGoga, MegaCortex i Nefilim, co pasuje do wzorca „rebrandów” i rotacji narzędzi, gdy ekosystem zostaje spalony lub pojawiają się publiczne deszyfratory.


Analiza techniczna / szczegóły luki

1) Model operacyjny: panel + per-ofiara artefakty

Z opisu postępowania wynika, że afilianci korzystali z platformy („panelu”), a dla każdej ofiary przygotowywano unikalny plik wykonywalny, klucz deszyfrujący i dedykowaną notatkę okupu. To utrudnia proste IOC-based hunting i sprzyja skalowaniu operacji.

2) Dobór ofiar i „profilowanie” pod kwotę okupu

W materiałach przytoczonych przez DataBreaches wskazano, że po uzyskaniu dostępu sprawcy badali firmę (rozmiar, przychody, dane kontaktowe), aby dobrać strategię negocjacji i cenę — to cecha kampanii „big game hunting”.

3) Double extortion i infrastruktura „leak site”

Nefilim działał w schemacie podwójnego wymuszenia: szyfrowanie było tylko jednym z elementów, a realną dźwignią stała się groźba publikacji danych na publicznie dostępnych stronach wyciekowych („Corporate Leaks”).

4) Typowy łańcuch ataku wg MITRE ATT&CK (przykładowy scenariusz)

Trend Micro mapuje typową narrację ataku Nefilim na taktyki/techniki MITRE: rozpoznanie hostów wystawionych do internetu, wejście przez podatny komponent brzegowy (w ich scenariuszu: Citrix ADC CVE-2019-19781), a następnie poruszanie się lateralne i użycie legalnych narzędzi administracyjnych, zanim dojdzie do fazy destrukcyjnej.

W praktyce: Nefilim to nie „klik w załącznik”, tylko kampanie o charakterze ukierunkowanym, gdzie bezpieczeństwo usług zdalnego dostępu, podatności edge i higiena uprawnień są krytyczne.


Praktyczne konsekwencje / ryzyko

  1. Ryzyko operacyjne: przestoje, utrata ciągłości działania i koszty odtwarzania (nawet bez płatności okupu). Organy ścigania wskazują na milionowe straty wynikające zarówno z wymuszeń, jak i szkód w sieciach ofiar.
  2. Ryzyko prawne i regulacyjne: double extortion oznacza, że incydent szybko staje się naruszeniem poufności (potencjalne obowiązki notyfikacyjne, spory, kary).
  3. Ryzyko reputacyjne i strategiczne: długotrwałe utrzymywanie danych na leak site i „przykładowe” publikacje podbijają presję na kolejne ofiary i wzmacniają efekt kuli śniegowej.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie „przecinają” łańcuch ataku obserwowany w nowoczesnych kampaniach RaaS (takich jak Nefilim):

  1. Zabezpiecz dostęp zdalny i usługi brzegowe
  • MFA wszędzie, gdzie to możliwe (VPN, VDI, portale, panele administracyjne).
  • Zero-trust dla dostępu uprzywilejowanego: PAM, JIT/JEA, segmentacja.
  • Ogranicz ekspozycję RDP/administracji (allowlist IP, bastion host, brak bezpośredniego wystawienia).
  1. Patch management pod edge
  • Priorytet dla podatności na urządzeniach brzegowych (VPN, ADC, urządzenia publikujące aplikacje). Trend Micro wprost pokazuje, że to częsty punkt startu.
  1. Wykrywanie działań „przed szyfrowaniem”
  • Polowanie na techniki z ATT&CK: skanowanie usług, nietypowe logowania adminów, tworzenie nowych kont uprzywilejowanych, masowe zrzuty poświadczeń, wyłączanie zabezpieczeń.
  • Alerty na nietypowe narzędzia administracyjne używane „po godzinach” i z nietypowych hostów.
  1. Backupy odporne na ransomware
  • Kopie niemodyfikowalne (immutable), offline/air-gapped, testy odtwarzania (RTO/RPO).
  • Oddzielne poświadczenia do systemów backupu i monitoring zmian polityk backupowych.
  1. Gotowość na wariant „data theft”
  • DLP/egress monitoring, limity i detekcje na duże transfery, kontrola narzędzi do archiwizacji i szyfrowania po stronie atakującego.
  • Plan komunikacji i IR: playbook na „wyciek + szyfrowanie”.

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

  • Nefilim vs LockerGoga/MegaCortex: z perspektywy praktycznej dla obrońców różnica polega nie tylko na rodzinie malware, ale na ekosystemie (rebrand, zmiana narzędzi, migracja operatorów). Wątek Tymoshchuka w The Record sugeruje, że ci sami aktorzy mogli rotować narzędziami i infrastrukturą, gdy poprzednie operacje traciły „przydatność” (np. przez publikację deszyfratorów lub presję organów ścigania).
  • Nefilim jako „RaaS z dojrzałym profilingiem”: Trend Micro podkreśla długi dwell time, victim profiling i presję double extortion jako elementy charakterystyczne dla nowoczesnych, targetowanych kampanii.

Podsumowanie / kluczowe wnioski

Sprawa Stryzhaka nie jest tylko historią o jednym „operatorze ransomware”. To migawka z rynku RaaS, w którym:

  • afilianci kupują/uzyskują dostęp do narzędzi i infrastruktury,
  • ataki są targetowane na organizacje o wysokich przychodach,
  • presja negocjacyjna opiera się na kradzieży danych i groźbie publikacji,
  • a techniczny punkt ciężkości obrony przesuwa się na edge security, tożsamość, telemetrię i odporne kopie.

Źródła / bibliografia

  1. DataBreaches.net — opis sprawy, informacje z dokumentów sądowych, szczegóły dot. panelu i profilu ofiar. (DataBreaches.Net)
  2. U.S. Department of Justice (EDNY) — komunikat o przyznaniu się do winy, ekstradycji i nagrodzie dla współsprawcy. (Department of Justice)
  3. CyberScoop — kontekst medialny, podsumowanie zakresu czasowego aktywności i skutków. (CyberScoop)
  4. The Record (Recorded Future News) — kontekst dot. Tymoshchuka i powiązań z LockerGoga/MegaCortex/Nefilim. (The Record from Recorded Future)
  5. Trend Micro — techniczny opis typowego łańcucha ataku Nefilim i mapowanie na MITRE ATT&CK. (www.trendmicro.com)

Polskie Konferencje Security 2026

Lista konferencji cybersecurity i IT 2026: założenia zestawienia

W cybersecurity łatwo wpaść w tryb „muszę być wszędzie”, bo każda konferencja obiecuje świeże trendy, nowe zagrożenia i wiedzę, której rzekomo nie da się zdobyć inaczej. Prawda jest prostsza: większość wartości bierze się z kilku dobrze dobranych wydarzeń, resztę można ogarnąć selektywnie.

Czytaj dalej „Polskie Konferencje Security 2026”

Ponad 25 tys. urządzeń Fortinet z włączonym FortiCloud SSO wystawionych na zdalne ataki – co oznaczają CVE-2025-59718 i CVE-2025-59719

Wprowadzenie do problemu / definicja luki

W grudniu 2025 r. zwrócono uwagę na bardzo niebezpieczny scenariusz: tysiące urządzeń Fortinet (m.in. FortiOS/FortiGate, FortiProxy, FortiSwitchManager oraz FortiWeb) ma włączoną funkcję “Allow administrative login using FortiCloud SSO” i jednocześnie wystawiony na Internet panel administracyjny. Internetowe skany wskazały ponad 25 000 takich adresów IP, co przy aktywnych próbach nadużyć przekłada się na realne ryzyko przejęcia kont administracyjnych i wycieku konfiguracji.

Rdzeniem problemu są dwie podatności:

  • CVE-2025-59718 – dotyczy wielu produktów (w praktyce: FortiOS/FortiProxy/FortiSwitchManager) i pozwala ominąć uwierzytelnianie FortiCloud SSO,
  • CVE-2025-59719 – analogiczny wektor dla FortiWeb.

W obu przypadkach chodzi o błędną weryfikację podpisu kryptograficznego w przepływie SAML (klasa błędu CWE-347), co umożliwia atakującemu obejście logowania SSO bez posiadania prawidłowych poświadczeń.


W skrócie

  • Skala ekspozycji: Shadowserver raportował >25 tys. IP z “odciskiem” FortiCloud SSO; w samych USA ~5,4 tys., w Indiach ~2 tys.
  • Aktywne nadużycia: Arctic Wolf obserwował intruzje z użyciem “malicious SSO logins” od 12 grudnia 2025.
  • Typowy ciąg ataku: udane logowanie admin przez SSO → eksport/ściągnięcie pliku konfiguracji przez GUI.
  • Priorytet naprawy: CISA dodała CVE-2025-59718 do KEV 16 grudnia 2025, a w NVD widać termin działań do 23 grudnia 2025 (kontekst KEV).

Kontekst / historia / powiązania

Warto podkreślić jedną rzecz, która ułatwia przeoczenie ryzyka w organizacjach: FortiCloud SSO nie musi być włączone “od zawsze”.

CERT Polska zwraca uwagę, że funkcja jest domyślnie wyłączona, ale w praktyce bywa automatycznie włączana podczas rejestracji urządzenia w FortiCare z poziomu GUI, jeśli administrator nie odznaczy odpowiedniej opcji.

W tym samym czasie (grudzień 2025) obserwujemy typowy “pattern” dla urządzeń brzegowych (edge): szybkie przejście od publikacji poprawek do masowych skanów i prób nadużyć, szczególnie gdy panel administracyjny jest dostępny z Internetu. W omawianym incydencie potwierdzono także, że liczba instancji z włączonym SSO i widocznym GUI jest zaskakująco duża.


Analiza techniczna / szczegóły luki

Na czym polega podatność?

Z technicznego punktu widzenia obie podatności sprowadzają się do tego, że urządzenie akceptuje spreparowaną odpowiedź SAML w procesie FortiCloud SSO, ponieważ weryfikacja podpisu kryptograficznego jest niewłaściwa (CWE-347). Skutkiem jest obejście uwierzytelniania – atakujący może uzyskać sesję administracyjną bez prawidłowego logowania.

Co robią atakujący w praktyce?

BleepingComputer oraz Arctic Wolf opisują spójny schemat:

  1. logowanie do panelu jako admin metodą SSO z nietypowego adresu źródłowego,
  2. następnie akcja przez GUI typu download/export system configuration,
  3. a dalej – analiza konfiguracji (interfejsy, polityki, usługi wystawione na Internet, hashe haseł).

Arctic Wolf opublikował też przykładowe adresy źródłowe (IOC) powiązane z obserwowanymi, złośliwymi logowaniami SSO oraz wskazał, że ruch pochodził z wybranych dostawców hostingu.

Jakie wersje są podatne i jakie są “fixed”?

Kanadyjskie Cyber Centre podaje jednoznacznie, do jakich wersji należy zaktualizować systemy (przykłady):

  • FortiOS: 7.6.4+, 7.4.9+, 7.2.12+, 7.0.18+
  • FortiProxy: 7.6.4+, 7.4.11+, 7.2.15+, 7.0.22+
  • FortiSwitchManager: 7.2.7+, 7.0.6+
  • FortiWeb: 8.0.1+, 7.6.5+, 7.4.10+

Praktyczne konsekwencje / ryzyko

Najbardziej “toksyczny” element tego typu incydentów to pobranie konfiguracji. Taki plik potrafi ujawnić:

  • topologię i podsieci (network layout),
  • reguły firewall / polityki,
  • listę usług wystawionych na Internet,
  • konta administracyjne i artefakty uwierzytelniania (w tym hashe, które w sprzyjających warunkach da się łamać offline).

W praktyce oznacza to, że nawet jeśli atakujący “tylko” zaloguje się i ściągnie konfigurację, konsekwencje mogą być długofalowe: dalsza eskalacja, pivot do sieci wewnętrznej, przygotowanie kampanii ransomware albo trwałe utrzymanie dostępu.


Rekomendacje operacyjne / co zrobić teraz

Poniżej playbook w kolejności, która zwykle działa najlepiej operacyjnie:

  1. Zidentyfikuj ekspozycję GUI
    • Czy panel administracyjny (HTTPS/GUI) jest dostępny z Internetu?
    • Jeśli tak: ogranicz dostęp (VPN / allowlista / segmentacja), zanim przejdziesz dalej.
  2. Natychmiast aktualizuj do wersji naprawionych
    • Kieruj się listą “Solution/Upgrade to …” podaną przez Cyber Centre (sekcja powyżej).
  3. Tymczasowo wyłącz logowanie FortiCloud SSO (jeśli nie możesz od razu zaktualizować)
    • CERT Polska oraz Arctic Wolf wskazują możliwość wyłączenia FortiCloud SSO także z CLI:config system global set admin-forticloud-sso-login disable end
  4. Sprawdź logi pod kątem wzorca nadużycia
    • Szukaj zdarzeń typu “admin login successful” z metodą sso oraz krótkiej sekwencji działań administracyjnych po logowaniu (np. pobranie konfiguracji przez GUI).
    • Porównaj adresy źródłowe z IOC publikowanymi przez Arctic Wolf.
  5. Higiena poincydentowa (jeśli widzisz oznaki kompromitacji)
    • rotacja haseł admin, przegląd kont i uprawnień,
    • weryfikacja zmian w konfiguracji i regułach,
    • jeśli plik konfiguracyjny mógł wyciec: traktuj to jako wyciek informacji wrażliwych i dostosuj model zagrożeń (np. zmiana kluczy/sekretów, przegląd ekspozycji usług).

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

W tym przypadku szczególnie istotne są dwie różnice względem “klasycznych” luk w GUI/SSL-VPN:

  • Warunek aktywacji wektora: atak dotyczy sytuacji, gdy jest włączona funkcja FortiCloud SSO dla logowania administracyjnego (co może się stać “przy okazji” rejestracji w FortiCare).
  • Wektor SAML/SSO: zamiast błędu w endpointach webowych, problem siedzi w obsłudze i weryfikacji SAML, co ułatwia tworzenie “logic exploitów” (obejścia), a niekoniecznie typowych exploitów pamięciowych.

Podsumowanie / kluczowe wnioski

  • Jeśli masz produkty Fortinet i kiedykolwiek rejestrowałeś je w FortiCare, sprawdź, czy nie jest włączone FortiCloud SSO dla logowania admina.
  • Traktuj tę sprawę jako pilną: potwierdzono aktywne nadużycia (od 12 grudnia 2025), a CVE-2025-59718 trafiło do kontekstu KEV (16 grudnia 2025; termin działań do 23 grudnia 2025 w NVD).
  • “Must-have” to: patch + ograniczenie dostępu do GUI + weryfikacja logów pod kątem logowań SSO i eksportów konfiguracji.

Źródła / bibliografia

  1. BleepingComputer – skala ekspozycji i kontekst Shadowserver/SSO fingerprinting (BleepingComputer)
  2. Arctic Wolf – obserwacje nadużyć, IOCs, przykładowe logi oraz wersje naprawione (Arctic Wolf)
  3. CERT Polska (moje.cert.pl) – opis warunku włączenia SSO i rekomendacje + CLI (moje.cert.pl)
  4. NVD (NIST) – opis CVE-2025-59718 oraz adnotacja dot. KEV/due date (nvd.nist.gov)
  5. Canadian Centre for Cyber Security – alert AL25-019 z listą wersji i zaleceń (Canadian Centre for Cyber Security)

Nowa grupa hakerska powiązana z Chinami szpiegowała rządy w Azji Południowo-Wschodniej i Japonii

Wprowadzenie do problemu / definicja luki

Badacze ESET ujawnili nową, wcześniej nieudokumentowaną grupę APT powiązaną z Chinami, którą nazwali LongNosedGoblin. Zespół ten ma prowadzić ukierunkowane operacje cyberszpiegowskie wobec instytucji rządowych w krajach Azji Południowo-Wschodniej oraz w Japonii. Charakterystyczną techniką napastników jest nadużywanie Zasad grupy (Windows Group Policy) do rozsyłania i utrzymywania narzędzi szpiegowskich w zainfekowanych domenach. Informację potwierdziły branżowe media, w tym Recorded Future News (The Record).

W skrócie

  • Ofiary: instytucje rządowe w regionie ASEAN oraz w Japonii.
  • Atrybucja: grupa APT LongNosedGoblin, powiązana z ekosystemem cyberoperacji ChRL.
  • Kluczowa technika: dystrybucja złośliwych komponentów przez Group Policy (GPO) w domenie Windows.
  • Aktywność: co najmniej od 2023 r.; aktywna kampania potwierdzona w grudniu 2025 r.

Kontekst / historia / powiązania

Cyberszpiegostwo sponsorowane przez państwo chińskie od lat koncentruje się na administracji publicznej i sektorach strategicznych w Azji. W 2025 r. odnotowano szereg operacji PRC-nexus wymierzonych w administrację i dyplomację regionu, co potwierdzają m.in. bieżące raporty i przeglądy trendów (Mandiant/Google Cloud oraz publikacje branżowe). Na tym tle pojawienie się LongNosedGoblin wpisuje się w szerszy wzorzec stałej presji wywiadowczej.

Analiza techniczna / szczegóły kampanii

Wejście i rozprzestrzenianie: według ESET, po uzyskaniu wstępnego dostępu napastnicy wykorzystują mechanizmy Group Policy do zautomatyzowanego wdrażania ładunków w całej domenie. Taki model umożliwia trwałą i „cichą” dystrybucję komponentów, zgodną z legalnym przepływem administracyjnym w środowiskach Windows.

Komunikacja i utrzymanie dostępu: doniesienia branżowe wskazują, że w niektórych przypadkach wykorzystywana jest infrastruktura chmurowa i techniki utrzymywania C2 typowe dla operacji APT z regionu Chin, co utrudnia blokowanie i atrybucję. (Wniosek syntetyzowany na podstawie materiałów o kampanii i szerszych przeglądów PRC-nexus w 2025 r.).

Celowanie: priorytetowo traktowane są resorty rządowe (ministerstwa, urzędy centralne) w wybranych państwach Azji Południowo-Wschodniej oraz w Japonii, co sugeruje cele czysto wywiadowcze (kradzież dokumentów, planów, notatek dyplomatycznych).

Mapowanie do MITRE ATT&CK (wybrane techniki):

  • T1484.001 – Domain Policy Modification (GPO) – modyfikacja/wykorzystanie zasad domenowych do egzekucji payloadów.
  • T1059 / T1053 – Command & Scripting Interpreter / Scheduled Task – egzekucja i utrzymanie harmonogramu na hostach (typowy wzorzec przy GPO). (Wniosek na bazie opisu nadużycia GPO).

Praktyczne konsekwencje / ryzyko

  • Szybka, domenowa propagacja: nadużycie GPO pozwala w krótkim czasie objąć zasięgiem całą organizację – bez wzbudzania podejrzeń użytkowników.
  • Trudna detekcja: działania są wykonywane w ramach „normalnych” mechanizmów AD, co utrudnia wykrywanie sygnaturowe i sprzyja długotrwałej obecności napastnika.
  • Ryzyko wycieku wrażliwych danych (korespondencja dyplomatyczna, dokumenty rządowe), co może mieć skutki geopolityczne i negocjacyjne.

Rekomendacje operacyjne / co zrobić teraz

  1. Włącz i egzekwuj auditing GPO/AD: szczegółowy monitoring zmian w Group Policy Objects (kto/ kiedy/ co) + alertowanie na tworzenie/edycję skryptów logon/logoff, startup/shutdown.
  2. Zasada najmniejszych uprawnień dla GPO: ogranicz administracyjne uprawnienia do tworzenia/edycji GPO, segmentuj role, stosuj „just-in-time” i „just-enough admin”.
  3. Telemetria hostowa i Sysmon: rejestrowanie procesów wyzwalanych przez GPO (np. powershell.exe, cmd.exe, mshta.exe), korelacja z czasem aktualizacji zasad. (Good practice wynikająca z opisanego TTP).
  4. Kontrola wykonywania skryptów: AppLocker / WDAC dla skryptów i binariów LoLBin, polityki ASR blokujące uruchamianie podejrzanych interpreterów przez GPO. (Wniosek operacyjny na bazie techniki).
  5. Hunting w AD: przegląd niedawno zmienionych GPO i powiązanych sysvol (szczególnie skrypty, pliki MSI/EXE/DLL), analiza nietypowych uprawnień na obiektach.
  6. Zewnętrzny traffic & C2: inspekcja ruchu do usług chmurowych i nietypowych domen jako potencjalnego C2, z uwzględnieniem wzorców PRC-nexus opisywanych w 2025 r.
  7. Playbook IR pod GPO-abuse: przygotuj procedury szybkiego „roll-backu” złośliwych zasad, izolacji kontrolerów domeny oraz rotacji poświadczeń.

Różnice / porównania z innymi przypadkami

Nadużywanie Group Policy było dotąd rzadziej opisywanym wektorem masowej dystrybucji w ramach operacji APT – częściej widzieliśmy techniki takie jak side-loading czy złośliwe aktualizacje oprogramowania. LongNosedGoblin wyróżnia się systemowym wykorzystaniem GPO jako kanału wdrożeniowego, co upodabnia atak do wewnętrznej operacji administracyjnej i znacząco utrudnia detekcję oraz triage.

Podsumowanie / kluczowe wnioski

  • LongNosedGoblin to świeżo udokumentowana, China-aligned APT, która celuje w rządy regionu ASEAN i Japonię.
  • Jej znakiem rozpoznawczym jest nadużywanie Windows Group Policy do dystrybucji narzędzi szpiegowskich w domenie.
  • Obrona wymaga precyzyjnego monitoringu i kontroli zmian GPO, łączenia telemetrii AD/host/C2 oraz gotowych playbooków IR.

Źródła / bibliografia

  • ESET WeLiveSecurity: „LongNosedGoblin tries to sniff out governmental affairs in Southeast Asia and Japan” (19 grudnia 2025). (welivesecurity.com)
  • Help Net Security: „Group Policy abuse reveals China-aligned espionage group targeting governments” (18–19 grudnia 2025). (Help Net Security)
  • The Record (Recorded Future News): „New China-linked hacker group spies on governments in Southeast Asia, Japan” (18–19 grudnia 2025). (The Record from Recorded Future)
  • The Hacker News: „China-Aligned Threat Group Uses Windows Group Policy to Deploy Espionage Malware” (19 grudnia 2025). (The Hacker News)
  • Google Cloud Threat Intelligence (kontekst PRC-nexus 2025): „PRC-Nexus Espionage Campaign … targets diplomats” (25 sierpnia 2025). (Google Cloud)

Cisco ostrzega przed aktywnie wykorzystywanym 0-dayem w AsyncOS (CVE-2025-20393) — ataki na Secure Email Gateway/SEWM

Wprowadzenie do problemu / definicja luki

Cisco poinformowało o krytycznej luce dnia zerowego w AsyncOS dla urządzeń Cisco Secure Email Gateway (SEG) oraz Cisco Secure Email and Web Manager (SEWM). Błąd oznaczony jako CVE-2025-20393 ma CVSS 10.0 i umożliwia zdalne wykonanie komend z uprawnieniami roota na podatnym urządzeniu. Wykorzystanie jest obserwowane „na żywo” w ograniczonej puli urządzeń o nietypowej (niestandardowej) ekspozycji do Internetu.

W skrócie

  • Co: zdalne RCE przez niewłaściwą walidację danych wejściowych w AsyncOS (CWE-20).
  • Kogo dotyczy: urządzeń SEG/SEWM z włączonym i do Internetu wystawionym modułem Spam Quarantine (nie jest domyślnie aktywny).
  • Kto atakuje: grupa o powiązaniach z Chinami śledzona jako UAT-9686.
  • Status łatek: brak patcha w momencie publikacji; CISA dodała CVE do KEV z terminem działań do 24 grudnia 2025 dla agencji federalnych USA.

Kontekst / historia / powiązania

Kampania została zauważona przez Cisco 10 grudnia 2025 r., a aktywność atakujących sięga końca listopada. Równolegle GreyNoise zarejestrował zautomatyzowane kampanie logowań (password spraying/credential stuffing) wymierzone w VPN-y (Palo Alto GlobalProtect i Cisco SSL VPN) — to inny, niezależny wątek niż 0-day w AsyncOS, ale pokazuje presję na urządzenia brzegowe.

Analiza techniczna / szczegóły luki

  • Identyfikator: CVE-2025-20393
  • Wektor: zdalny, bez uwierzytelnienia, niski nakład pracy; wpływ na C/I/A: High (CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).
  • Warunki eksploatacji:
    • Funkcja Spam Quarantine jest włączona.
    • Interfejs Spam Quarantine jest osiągalny z Internetu (ekspozycja).
    • Dotyczy zarówno wydań fizycznych, jak i wirtualnych SEG/SEWM.
  • Łańcuch po włamaniu (observed TTPs):
    • Wgranie lekkiego backdoora „AquaShell” (Python) podsłuchującego pasywnie na żądania HTTP POST i wykonującego zakodowane polecenia w powłoce systemu.
    • Użycie narzędzi tunelujących AquaTunnel/ReverseSSH oraz Chisel w celu trwałego dostępu i pivotu, a także AquaPurge do „czyszczenia” logów.
    • W Talosie odnotowano osadzenie AquaShell m.in. w pliku /data/web/euq_webui/htdocs/index.py.

Praktyczne konsekwencje / ryzyko

  • Przejęcie pełnej kontroli nad urządzeniem SEG/SEWM (root), a więc ryzyko podmiany polityk, manipulacji pocztą, eksfiltracji danych, pivotu do sieci wewnętrznej oraz ukrywania śladów (AquaPurge).
  • Urządzenia SEG/SEWM często pełnią centralne funkcje zarządcze i kwarantanny — ich kompromitacja ma ponadprzeciętny wpływ na łańcuch dostarczania poczty i bezpieczeństwo całej organizacji.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast:

  1. Oceń ekspozycję: sprawdź, czy Spam Quarantine jest włączony oraz czy interfejs jest osiągalny z Internetu; jeśli tak — odetnij go od Internetu (ACL/WAF/VPN), najlepiej umieść za firewallem i ogranicz ruch do zaufanych hostów.
  2. Oddziel interfejsy: rozdziel interfejsy mail i management; wyłącz HTTP dla portalu administratora (pozostaw wyłącznie HTTPS z mTLS/VPN).
  3. Twarde uwierzytelnianie: wymuś silne metody SSO/MFA (np. SAML/LDAP), wyłącz konta domyślne, zmień hasła adminów.
  4. Higiena usług: wyłącz nieużywane usługi, przeglądnij konfigurację AsyncOS pod kątem niestandardowych ustawień i ekspozycji.
  5. Monitoring i IR: przeanalizuj logi WWW/SSH pod kątem nieoczekiwanych żądań POST oraz tuneli; skorzystaj z IOC-ów Talosa (hashe, IP) i gotowych reguł/telemetrii w EDR/NDR. W razie potwierdzenia kompromitacji przeinstaluj/odbuduj urządzenie (jedyna pewna metoda usunięcia trwałości).

W najbliższych dniach:

  • Śledź aktualizacje Cisco PSIRT i wdrożenie ewentualnych łat natychmiast po publikacji; agencje federalne w USA mają termin działań do 24 grudnia 2025 r. (KEV).
  • Jeśli Twoja organizacja widzi korelację z aktywnością brute-force na VPN-ach, zastosuj ochronę kont (MFA, blokady, geo, prędkości), ale pamiętaj, że to oddzielna kampania od 0-daya w AsyncOS.

Jak sprawdzić ustawienie Spam Quarantine (skrót): w GUI przejdź do Network → IP Interfaces → [interfejs] i sprawdź, czy Spam Quarantine jest zaznaczony (SEG); analogicznie dla SEWM. Jeśli zaznaczony, nie powinien być dostępny z Internetu.

Różnice / porównania z innymi przypadkami

  • AsyncOS 0-day (CVE-2025-20393) wymaga specyficznej konfiguracji (włączony i wystawiony Spam Quarantine). To odróżnia go od wielu „remote-by-default” błędów w brzegowych urządzeniach.
  • Kampania GreyNoise na VPN-y to automatyczne próby logowania (credential-based), a nie exploit luki — inna technika, inny cel, choć ofiary mogą się pokrywać (organizacje z dużą ekspozycją usług).

Podsumowanie / kluczowe wnioski

  • Mamy do czynienia z aktywnie wykorzystywanym 0-dayem o maksymalnej krytyczności, wykorzystywanym przez UAT-9686.
  • Brak łat oznacza, że architektura i ekspozycja decydują dziś o bezpieczeństwie: odetnij Spam Quarantine od Internetu, wzmocnij dostęp administracyjny, monitoruj pod kątem AquaShell/AquaTunnel/Chisel.
  • Potwierdzona kompromitacja ⇒ rebuild urządzenia.
  • Śledź komunikaty Cisco/Talos i wpis w KEV; działaj przed terminem compliance.

Źródła / bibliografia

  • Cisco Talos: „UAT-9686 actively targets Cisco Secure Email Gateway and Secure Email and Web Manager” (szczegóły AquaShell/AquaTunnel/Chisel, IOC). (Cisco Talos Blog)
  • NVD (CVE-2025-20393): opis CVE, wektor CVSS, odnośnik do KEV i advisory Cisco. (NVD)
  • Cisco PSIRT Advisory (AsyncOS / SEG / SEWM; warunki eksploatacji, zalecenia). (sec.cloudapps.cisco.com)
  • The Hacker News: podsumowanie, warunki „Spam Quarantine + ekspozycja”, zalecenia tymczasowe. (The Hacker News)
  • GreyNoise: „Coordinated Credential-Based Campaign Targets Cisco and Palo Alto Networks VPN Gateways” (kampania loginów, niezależna od 0-daya). (greynoise.io)

CISA dodaje trzy luki do katalogu KEV: Cisco AsyncOS (Secure Email), SonicWall SMA1000 i ASUS Live Update (supply chain)

Wprowadzenie do problemu / definicja luki

17 grudnia 2025 r. amerykańska CISA dopisała do Known Exploited Vulnerabilities (KEV) trzy nowe pozycje potwierdzone jako aktywnie wykorzystywane:

  • CVE-2025-20393Cisco Secure Email Gateway oraz Secure Email and Web Manager (AsyncOS): krytyczne RCE wskutek niewłaściwej walidacji danych.
  • CVE-2025-40602SonicWall SMA1000: luka „missing authorization” w Appliance Management Console prowadząca do eskalacji uprawnień; wykorzystywana w łańcuchu z wcześniejszą deserializacją CVE-2025-23006.
  • CVE-2025-59374ASUS Live Update: historyczny incydent supply-chain (osadzenie złośliwego kodu), dotyczy przestarzałych wersji klienta.

W skrócie

  • Cisco (CVE-2025-20393): aktywnie eksploatowane, RCE bez uwierzytelniania na urządzeniach Secure Email/SEWM; brak obejść; vendor publikuje wskazówki i śledzi kampanię. Priorytet „natychmiast”.
  • SonicWall (CVE-2025-40602): lokalna eskalacja w SMA1000 AMC; w praktyce łączona z CVE-2025-23006 dla pełnego przejęcia. Aktualizacje/hotfixy dostępne.
  • ASUS Live Update (CVE-2025-59374): wpis do KEV za incydent supply-chain; dotyczy EoS/starych wersji klienta Live Update—zalecane zaprzestanie użycia oraz aktualizacja/odinstalowanie.

Kontekst / historia / powiązania

KEV to lista podatności potwierdzonych jako wykorzystywane „in the wild”, która wyznacza obowiązkowe terminy remediacji dla agencji federalnych USA i stanowi czytelny sygnał priorytetyzacji dla sektora prywatnego.

Dodatkowo producent Cisco opisuje aktywne ataki na AsyncOS z możliwością wykonania poleceń z uprawnieniami root; brak obejść, zalecane pilne działania ograniczające ekspozycję oraz aktualizacje, gdy będą dostępne.

Analiza techniczna / szczegóły luki

1) Cisco Secure Email / Secure Email & Web Manager – CVE-2025-20393 (RCE)

  • Wektor: niewłaściwa walidacja danych wejściowych (input validation) w AsyncOS, umożliwiająca zdalne wykonanie poleceń z uprawnieniami root.
  • Zasięg: dotyczy urządzeń Secure Email Gateway i Secure Email & Web Manager; obserwowane ataki ukierunkowane.
  • Status: aktywnie wykorzystywana 0-day, opisana w doradztwie Cisco; brak trwałych obejść, konieczne ograniczenie dostępu i ścisły monitoring.

2) SonicWall SMA1000 – CVE-2025-40602 (LPE, missing authorization)

  • Wektor: brak/insufficient authorization w Appliance Management Console (AMC)lokalna eskalacja uprawnień.
  • Praktyczny łańcuch ataku: połączona z CVE-2025-23006 (deserializacja) daje atakującym RCE + root.
  • Status: aktywnie wykorzystywana w kampanii łańcuchowej; dostępne poprawki/hotfixy i wtyczki detekcyjne (Tenable).

3) ASUS Live Update – CVE-2025-59374 (embedded malicious code, supply chain)

  • Charakter:Embedded malicious code” (CWE-506) — dystrybucja zmodyfikowanych, zainfekowanych buildów klienta ASUS Live Update w historycznym incydencie łańcucha dostaw; dotyczy legacy/EoS wersji.
  • Ryzyko dziś: systemy, które nadal mają stare klienty lub obrazy bazowe zawierające podatne wydania. Zalecenie: aktualizacja do ≥ 3.6.8 lub całkowite usunięcie klienta.

Praktyczne konsekwencje / ryzyko

  • Perimeter compromise: luki w bramach pocztowych (Cisco) oraz portalach dostępowych/VPN (SMA1000) mają wysoki wpływ na tożsamość, pocztę i lateral movement.
  • Persistence przez supply chain: starsze obrazy systemów z ASUS Live Update mogą wprowadzać trwałe ryzyko w procesach golden image / VDI / lab.

Rekomendacje operacyjne / co zrobić teraz

Dla wszystkich organizacji:

  1. Inwentaryzacja i skan: natychmiast znajdź urządzenia Cisco Secure Email/SEWM (AsyncOS), SonicWall SMA1000 oraz systemy z ASUS Live Update.
  2. Segmentacja i dostęp:
    • Ogranicz HTTP/HTTPS/AMC/administrację do zaufanych adresów (allow-list, VPN z MFA).
    • Zablokuj ekspozycję interfejsów admin do Internetu.
  3. Aktualizacje / hotfixy:
    • Śledź doradztwa Cisco (AsyncOS) i zastosuj wymagane wersje/tymczasowe kroki ograniczające.
    • Zainstaluj hotfixy SonicWall SMA1000; jeśli używasz SMA100 (starsza linia), sprawdź odrębne biuletyny producenta.
    • Usuń/aktualizuj ASUS Live Update do wersji ≥ 3.6.8 lub odinstaluj na obrazach bazowych.
  4. Monitoring i IR:
    • Szukaj nietypowych logowań do paneli admin, eksportów konfiguracji, tworzenia nowych kont admin oraz komend systemowych uruchamianych przez procesy appliance. (Cisco/AsyncOS).
    • Dla SMA1000: alerty na dostęp do AMC, artefakty LPE i ślady eksploatacji deserializacji (CVE-2025-23006).
  5. Zarządzanie ryzykiem KEV: wprowadź politykę, by KEV = najwyższy priorytet remediacji z krótkim SLA (zgodnie z praktyką CISA).

Różnice / porównania z innymi przypadkami

  • Cisco vs. SonicWall: w Cisco mówimy o pre-auth RCE na appliance pocztowym (skrajnie niebezpieczne); w SonicWall bazowa luka to LPE, ale realne ryzyko rośnie przez łańcuch z pre-auth deserializacją.
  • ASUS Live Update: to przykład podatności supply-chain (embedded malicious code) — inny profil ryzyka: legacy footprint i ryzyko residuala w obrazach/systemach, które nie zostały zmodernizowane.

Podsumowanie / kluczowe wnioski

  • Trzy wpisy KEV z 17.12.2025 r. obejmują krytyczne wektory perymetru (email/VPN) oraz historyczny, ale wciąż groźny ślad supply-chain.
  • Priorytet: Cisco AsyncOS (odcięcie ekspozycji + działania zgodne z doradztwem), SonicWall SMA1000 (natychmiastowy hotfix i twarde kontrolki dostępu), ASUS Live Update (likwidacja starych klientów/obrazów).

Źródła / bibliografia

  • CISA – alert o dodaniu 3 pozycji do KEV (17 grudnia 2025). (CISA)
  • Cisco Security Advisory – CVE-2025-20393 (AsyncOS: Secure Email Gateway / Secure Email & Web Manager). (Cisco)
  • CVE Details – CVE-2025-20393 (opis, wpływ, KEV). (CVE Details)
  • Tenable Research – CVE-2025-40602 (SMA1000 LPE, łańcuch z CVE-2025-23006). (Tenable®)
  • NVD – CVE-2025-59374 (ASUS Live Update, embedded malicious code, supply-chain). (NVD)

Amazon ostrzega przed trwającą kampanią cryptominingu wykorzystującą przejęte konta AWS

Wprowadzenie do problemu / definicja luki

Amazon (AWS) poinformował o trwającej kampanii cryptominingu wymierzonej w klientów korzystających z Amazon EC2 i Amazon ECS. Atakujący nie wykorzystują luki w usługach AWS, lecz legalne, skompromitowane poświadczenia IAM (tożsamości i uprawnienia), co pozwala im szybko wdrażać koparki i utrzymywać się w środowisku dzięki nowym technikom utrwalania (persistence). AWS wykrył kampanię 2 listopada 2025 r. i opisał jej przebieg oraz wskaźniki kompromitacji (IoC).

W skrócie

  • Wejście uzyskiwane jest przez przejęte klucze/hasła IAM o uprawnieniach zbliżonych do admina. Koparki startują w ~10 minut od pierwszego logowania.
  • Wykorzystywane są EC2 (w tym instancje GPU/ML) oraz ECS/Fargate z agresywnym autoscalingiem (do 999 instancji w grupie).
  • Nowa technika persistence: masowe ustawianie ModifyInstanceAttributedisableApiTermination: true utrudnia automatyczną reakcję/terminację.
  • W kampanii użyto złośliwego obrazu Docker Hub yenik65958/secret (usunięty) z SBRMiner-MULTI i pulami *.rplant.xyz:17155.
  • Media branżowe potwierdzają szczegóły (m.in. DryRun do sprawdzania uprawnień, publiczne Lambda URL i tworzenie użytkownika z SES Full Access).

Kontekst / historia / powiązania

Cryptojacking w chmurze nie jest nowy – wcześniejsze kampanie uderzały m.in. w AWS Lambda czy klastry kontenerowe, często opierając się na wykradzionych kluczach bądź błędach konfiguracji. Przykładowo w 2022 r. opisano pierwszy znany malware ukierunkowany na AWS Lambda. Dzisiejsza kampania wyróżnia się jednak tempem i dojrzałym łańcuchem działań w wielu usługach jednocześnie.

Analiza techniczna / szczegóły kampanii

Wejście i rozpoznanie

  • Logowanie z anomalii sieciowej przy użyciu skompromitowanego użytkownika IAM z uprawnieniami admin-like.
  • Szybkie sondowanie limitów EC2 (GetServiceQuota) oraz walidacja uprawnień przez wielokrotne wywołania RunInstances z flagą DryRun (tani „test” bez tworzenia instancji). To charakterystyczny, wczesny sygnał ostrzegawczy w logach CloudTrail.

ECS / Fargate – wpływ

  • Tworzenie dziesiątków klastrów ECS (czasem >50 w jednej ofierze).
  • Rejestracja task definition z obrazem yenik65958/secret:user, uruchamianie usług na Fargate z CPU=16384, RAM=32 GiB, desiredCount=10. Skrypt run.sh uruchamia RandomVIREL z pulami asia|eu|na.rplant.xyz:17155.

EC2 – wpływ

  • Tworzenie szablonów uruchamiania i 14 grup autoskalujących z parametrami do 999 instancji, celowanie w GPU/ML (g4dn/g5/p3/p4d/inf1) oraz instancje ogólnego przeznaczenia (c6i/m5/r5).

Persistence / utrudnianie IR

  • Masowe ustawienie disableApiTermination: true dla każdej instancji (via ModifyInstanceAttribute). To przerywa automatyczną remediację i zmusza zespoły do ręcznego cofnięcia ochrony przed terminacją.
  • Utworzenie publicznego URL w AWS Lambda (CreateFunctionUrlConfig z AuthType: NONE) oraz nadanie AddPermission z principal: "*".
  • Dodanie użytkownika user-x1x2x3x4 z polityką AmazonSESFullAccess – wskazuje to na potencjalne kampanie phishingowe przez Amazon SES.

IoC / Telemetria

  • Obraz: yenik65958/secret (Docker Hub – usunięty).
  • Domeny mining pool: asia|eu|na.rplant.xyz.
  • UA / narzędzia: ślady Boto3 (AWS SDK for Python).
  • Wzorce nazewnictwa ASG: SPOT-us-east-1-G*-* oraz OD-us-east-1-G*-*.

Wykrycie

  • Kampanię skorelowały mechanizmy Amazon GuardDuty Extended Threat Detection (m.in. AttackSequence:EC2/CompromisedInstanceGroup), łącząc TI, anomalie sieciowe i runtime. Niezależne serwisy (BleepingComputer, Dark Reading, THN) potwierdzają opis AWS.

Praktyczne konsekwencje / ryzyko

  • Koszty: gwałtowny wzrost wykorzystania zasobów (GPU/ML, Fargate) może przełożyć się na pięcio-/sześciocyfrowe kwoty na fakturze, zanim monitoring zareaguje. (Wprost wynika z opisu skalowania do setek instancji.)
  • Degradacja usług: wyczerpanie limitów i zasobów wpływa na aplikacje produkcyjne.
  • Bezpieczeństwo komunikacji: nadużycie SES do phishingu zwiększa ryzyko wtórnych incydentów (brand abuse, BEC).

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowa higiena tożsamości

  • Rotacja wszystkich długoterminowych kluczy IAM; wymuś MFA dla użytkowników i ról, w tym break-glass.
  • Zasada najmniejszych uprawnień i tymczasowe poświadczenia (IAM Roles, SSO) zamiast długowiecznych access keys.

2) Szybkie kontrole detekcji

  • Sprawdź w CloudTrail nietypowe wywołania: RunInstances z DryRun, CreateServiceLinkedRole, CreateRole, RegisterTaskDefinition, CreateService, CreateLaunchTemplate, CreateAutoScalingGroup, ModifyInstanceAttribute (disableApiTermination=true), CreateFunctionUrlConfig (AuthType=NONE), AddPermission (principal="*"), tworzenie użytkowników i polityk SES.
  • W GuardDuty upewnij się, że masz Runtime Monitoring i Extended Threat Detection dla EC2/ECS.

3) Blokady prewencyjne (SCP/Config/CIEM)

  • Wdróż SCP zakazujące publicznych Lambda URL (FunctionUrlAuthType="NONE").
  • Wymuś image scanning i deny-listę podejrzanych rejestrów/obrazów dla ECS/Fargate.
  • Zablokuj możliwość ustawiania disableApiTermination poza procesem IR (np. przez SCP/Config Rules, reguły automatyczne). (Wniosek z analizy AWS).

4) Playbook reakcji (skrót)

  • Izoluj podejrzane instancje/klastry, cofnij disableApiTermination, terminuj workloady miningowe.
  • Rotuj wszystkie klucze i unieważnij sesje.
  • Przejrzyj SES (nadane uprawnienia, wysyłki), usuń publiczne Lambda URL/permissions.
  • Oceń koszty i wdróż budżety/limity + alerty kosztowe na poziomie kont i OU. (Zalecenia wprost/pośrednio z wpisu AWS).

Różnice / porównania z innymi przypadkami

W porównaniu z wcześniejszymi falami cryptojackingu w AWS, obecna kampania:

  • łączy wiele usług (ECS/Fargate + EC2) z agresywnym autoscalingiem,
  • wykorzystuje DryRun do cichej walidacji uprawnień,
  • utrudnia IR przez hurtowe disableApiTermination,
  • dobudowuje wektor phishingu (SES) i publiczne Lambda URL dla utrzymania obecności.
    Te elementy razem składają się na bardziej dojrzałą metodykę nadużycia skradzionych poświadczeń w chmurze.

Podsumowanie / kluczowe wnioski

  • To nie jest „bug w AWS” – to nadużycie zaufanych poświadczeń i błędów procesowych.
  • Sekundy i minuty mają znaczenie: atak osiąga pełną moc kopania w ~10 min; bez automatyki koszt eskaluje wykładniczo.
  • Detekcja wzorca (DryRun, disableApiTermination, publiczne Lambda URL, SES Full Access, obrazy spoza zaufanych rejestrów) powinna być stałą regułą w SIEM/SOAR.
  • GuardDuty (ETD + Runtime) + MFA, SCP, least privilege to dziś must-have dla każdego konta/OU.

Źródła / bibliografia

  1. AWS Security Blog – „Cryptomining campaign targeting Amazon EC2 and Amazon ECS” (16 grudnia 2025) – opis techniczny, IoC, rekomendacje. (Amazon Web Services, Inc.)
  2. BleepingComputer – „Amazon: Ongoing cryptomining campaign uses hacked AWS accounts” (17 grudnia 2025) – podsumowanie i kontekst rynkowy. (BleepingComputer)
  3. The Hacker News – „Compromised IAM Credentials Power a Large AWS Crypto Mining Campaign” (16 grudnia 2025) – dodatkowe szczegóły o DryRun, Lambda URL, SES. (The Hacker News)
  4. Dark Reading – „Attackers Use Stolen AWS Credentials in Cryptomining Campaign” (17 grudnia 2025) – potwierdzenie ETD/GuardDuty i IoC. (Dark Reading)
  5. The Record – „Cryptomining malware targeting AWS Lambda” (5 kwietnia 2022) – kontekst historyczny dot. wcześniejszych kampanii na AWS Lambda. (The Record from Recorded Future)