Archiwa: NIST - Strona 63 z 69 - Security Bez Tabu

ShadowRay 2.0: nowa fala ataków zmienia klastry Ray w koparki kryptowalut

Wprowadzenie do problemu / definicja luki

Trwa globalna kampania „ShadowRay 2.0”, w której napastnicy przejmują publicznie dostępne klastry Ray (open-source framework do skalowania aplikacji AI/Python) i zamieniają je w samopropagującą się infrastrukturę do kopania Monero. Wektor wejścia to nadal sporna, niewyłatania podatność CVE-2023-48022 w API zadań Ray, umożliwiająca zdalne wykonanie kodu bez uwierzytelnienia przy błędnej ekspozycji usług na Internet. Najnowsza fala kampanii rozszerza się poza cryptojacking – obserwowane są kradzieże danych/poświadczeń i funkcje DDoS.

W skrócie

  • Nowa kampania („ShadowRay 2.0”): ta sama luka, bardziej automatyczny łańcuch ataku; self-spread między węzłami/klastrami.
  • Ekspozycja ekosystemu: badacze szacują dziś >230 tys. serwerów Ray widocznych w Internecie (wcześniej „kilka tysięcy”).
  • CVE-2023-48022: zdalne RCE przez Jobs API; ocena CVSS 9.8 (CRITICAL), status „disputed” – twórcy Ray wskazują, że Ray ma działać w „ściśle kontrolowanym środowisku”.
  • Ładunki: generowane z pomocą LLM (charakterystyczne komentarze/docstringi), moduł XMRig ograniczający użycie CPU do ~60%, utrwalanie przez cron/systemd, reverse-shelle i moduł DDoS (Sockstress).
  • Brak łatki: zalecenia to „best practices” Anyscale – uruchomienie w zaufowanej sieci, filtrowanie portu 8265 (Dashboard), autoryzacja przez proxy, monitoring anomalii.

Kontekst / historia / powiązania

Pierwszą kampanię ShadowRay opisano w marcu 2024 r., wskazując aktywne nadużycia od września 2023 r. Wtedy już raportowano setki skompromitowanych klastrów oraz dominujące użycie koparek (XMRig/NBMiner/Zephyr) i reverse-shelli. Jednocześnie Anyscale podtrzymało, że brak wbudowanego uwierzytelniania to decyzja projektowa, a instancje powinny działać w środowiskach kontrolowanych; firma zapowiadała dodanie auth w przyszłych wersjach.

Analiza techniczna / szczegóły luki

CVE-2023-48022 dotyczy Jobs API w Ray i umożliwia zdalne przesłanie/uruchomienie zadań (Bash/Python) bez uwierzytelnienia, jeśli endpointy są wystawione na świat. NVD klasyfikuje lukę jako krytyczną (CVSS 9.8). Brak łatki wynika z modelu zaufania Ray – framework zakłada izolację sieciową i kontrolę dostępu po stronie operatora. W praktyce tysiące wdrożeń są błędnie wystawione (np. 0.0.0.0) lub pozbawione filtracji, co czyni je łatwym celem.

W ShadowRay 2.0 napastnicy (TRACK: IronErn440) korzystają z CVE-2023-48022 do uruchamiania wielostopniowych łańcuchów Bash/Python. Payloady, z oznakami generowania przez LLM, po zainfekowaniu rozsiewają się na wszystkie węzły klastra poprzez natywne mechanizmy orkiestracji Ray, a nawet klaster-do-klastra. Zaobserwowano dwie fale: starszą z dystrybucją przez GitLab (zakończona 5 listopada) i nową przez GitHub (aktywna od 17 listopada).

Moduły złośliwe obejmują:

  • Cryptojacker (XMRig) – wykrywa CPU/GPU, maskuje procesy (np. dns-filter), limity CPU (ok. 60%), zabija konkurencyjne koparki, blokuje pule w /etc/hosts i iptables, utrzymuje persistencję przez cron/systemd.
  • Dostęp interaktywny – wiele reverse-shelli do infrastruktury C2, z możliwością eksfiltracji danych środowisk ML (sekrety, hasła DB, klucze SSH, tokeny usług).
  • DDoS – komponent oparty o Sockstress do wyczerpywania zasobów TCP.

Praktyczne konsekwencje / ryzyko

  • Utrata mocy obliczeniowej (GPU/CPU) i wzrost kosztów chmurowych przez kopanie kryptowalut.
  • Wycieki sekretów produkcyjnych: hasła DB, klucze SSH, tokeny (OpenAI, HuggingFace, Slack, Stripe), dostęp do kube-API – ryzyko lateral movement i kompromitacji danych klientów.
  • Degradacja dostępności: możliwość użycia zasobów do DDoS oraz wpływ na trening/inferencję modeli.

Rekomendacje operacyjne / co zrobić teraz

  1. Nie wystawiaj Ray na Internet: uruchamiaj wyłącznie w zaufowanej, odseparowanej sieci/VPC/VPN; blokuj ruch przychodzący do komponentów Ray (w tym Dashboard :8265) regułami firewall/SG.
  2. Warstwa autoryzacji przed Dashboard/Jobs API: jeżeli dostęp zdalny jest konieczny, zastosuj reverse proxy z uwierzytelnianiem (mTLS/OIDC) i autoryzacją endpointów. Nie wiąż usług na 0.0.0.0.
  3. Higiena sekretów: rotuj poświadczenia (DB/SSH/API), unieważnij tokeny znalezione w logach/środowiskach i wymuś krótkie TTL. (Wnioski z incydentów ShadowRay.)
  4. Monitoring runtime: alertuj na tworzenie nietypowych zadań, reverse-shelle, połączenia do puli Monero, procesy podobne do xmrig, modyfikacje crontab/systemd. (IOC-e i TTP-y opisane przez Oligo.)
  5. Segmentacja i egress control: ogranicz ruch wychodzący z węzłów Ray do niezbędnych destynacji; blokuj znane pule, domeny pastebin/Git* używane w kampanii.
  6. Plan odzyskania: w razie kompromitacji – odseparuj klaster, zbuduj nowy z zaufanych artefaktów, przeprowadź triage sekretów i przegląd dostępu do chmury.
  7. Śledź komunikaty producenta: Anyscale wcześniej sygnalizowało przyszłe wsparcie auth – wdrażaj gdy dostępne; do tego czasu polegaj na izolacji sieci i kontrolach dostępu.

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

W porównaniu z typowymi kampaniami cryptojacking w klastrach kontenerowych, ShadowRay wyróżnia:

  • Wykorzystanie Jobs API Ray jako „legalnego” mechanizmu wykonania kodu (przy błędnej ekspozycji), co utrudnia detekcję przez skanery SAST/kompilacyjne.
  • Szybkie rozprzestrzenianie w obrębie klastra dzięki wbudowanej orkiestracji Ray oraz automatyczne „cluster-to-cluster spreading” w fali 2.0.
  • Ładunki generowane przez LLM (charakterystyczne artefakty w kodzie), co wskazuje na rosnącą automatyzację po stronie atakujących.

Podsumowanie / kluczowe wnioski

  • ShadowRay 2.0 pokazuje, że błędna ekspozycja usług AI to dziś jeden z najbardziej kosztownych błędów operacyjnych.
  • Brak wbudowanego auth w Ray nie jest „bugiem” w rozumieniu vendor-a, ale ryzyko operacyjne – które trzeba neutralizować segmentacją, filtracją i proxy z autoryzacją.
  • Zespoły ML/AI powinny mieć runbook na wypadek kompromitacji klastrów treningowych/inferencyjnych oraz telemetrykę ukierunkowaną na IOC/TTP ShadowRay.

Źródła / bibliografia

  1. BleepingComputer – „New ShadowRay attacks convert Ray clusters into crypto miners” (18 listopada 2025). (BleepingComputer)
  2. Oligo Security – „ShadowRay: First Known Attack Campaign Targeting AI Workloads…” (26 marca 2024). (oligo.security)
  3. NVD (NIST) – wpis CVE-2023-48022 (RCE w Ray Jobs API, CVSS 9.8, status „disputed”). (NVD)
  4. SecurityWeek – „Ray AI Framework Vulnerability Exploited to Hack Hundreds of Clusters” (27 marca 2024). (SecurityWeek)
  5. The Hacker News – „Critical Unpatched Ray AI Platform Vulnerability Exploited for Cryptocurrency Mining” (27 marca 2024). (The Hacker News)

Google łata nowy zero-day w Chrome (CVE-2025-13223) aktywnie wykorzystywany w atakach

Wprowadzenie do problemu / definicja luki

Google wydał awaryjną aktualizację przeglądarki Chrome, aby usunąć wysokiej wagi lukę CVE-2025-13223 w silniku JavaScript V8. Błąd ma charakter type confusion i jest już aktywnie wykorzystywany („exploit in the wild”). Łatka została udostępniona w wersjach 142.0.7444.175/.176 dla Windows, 142.0.7444.176 dla macOS oraz 142.0.7444.175 dla Linuksa.

W skrócie

  • Co: CVE-2025-13223 – błąd type confusion w V8 (możliwa korupcja sterty, potencjalne RCE).
  • Status: aktywnie wykorzystywany; Google ogranicza szczegóły do czasu zaktualizowania większości użytkowników.
  • Wersje z poprawką: 142.0.7444.175/.176 (Win), 142.0.7444.176 (macOS), 142.0.7444.175 (Linux).
  • Ocena wstępna: media branżowe raportują CVSS ~8.8 (wysoka).

Kontekst / historia / powiązania

To już siódmy zero-day w Chrome w 2025 r., jaki Google musiał łatać awaryjnie. Poprzednie przypadki obejmowały m.in. inne błędy w V8 oraz luki umożliwiające eskalację uprawnień lub ominięcie piaskownicy. Google tradycyjnie wstrzymuje publikację szczegółów technicznych do czasu rozpowszechnienia aktualizacji.

Analiza techniczna / szczegóły luki

CVE-2025-13223 to błąd klasy type confusion w V8 (JS/WebAssembly). Tego typu podatności wynikają z nieprawidłowych założeń co do typu obiektu w czasie wykonania, co może prowadzić do błędów pamięci (heap corruption). W praktyce możliwe jest wyzwolenie podatności poprzez spreparowaną stronę HTML i uzyskanie zdalnego odczytu/zapisu pamięci procesu przeglądarki — w określonych warunkach aż do zdalnego wykonania kodu (RCE) lub obejścia izolacji.

Zakres dotkniętych wersji: Chrome przed 142.0.7444.175/176 (desktop). Dystrybucje i advisories (NVD, Ubuntu, NHS) potwierdzają charakter podatności i progi wersji.

Praktyczne konsekwencje / ryzyko

  • Atak bezplikowy przez przeglądarkę: wystarczy wejście na złośliwą stronę lub wczytanie złośliwej reklamy/iframe, aby wyzwolić błąd.
  • Potencjalne RCE/eskalacja w łańcuchu exploitów: luki V8 są często łączone z innymi błędami (np. sandbox escape) w pełne łańcuchy ataków.
  • Profil celów: TAG często wiąże zero-daye z kampaniami APT/spyware wymierzonymi w osoby wysokiego ryzyka (dziennikarze, opozycja). Choć w tym przypadku brak jeszcze szczegółów atrybucji, Google potwierdza aktywną eksploatację.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja przeglądarki na stacjach roboczych i serwerach z GUI:
    • Chrome → MenuPomocInformacje o Google ChromeAktualizuj i Uruchom ponownie. Wersja docelowa: 142.0.7444.175/.176 (zależnie od OS).
  2. Zarządzanie flotą (Intune/Google Admin/Jamf): wymuś roll-out kanału Stable 142.0.7444.175/176; monitoruj wskaźnik zgodności. (Na podstawie wersji z ogłoszenia Stable Channel.)
  3. Chromium-based: sprawdź aktualizacje w przeglądarkach pochodnych (Edge, Brave, Opera), ponieważ podatność dotyczy V8. (Wniosek z charakteru luki; weryfikuj advisories vendorów).
  4. Hardening przeglądarki do czasu pełnej zgodności:
    • włącz Site Isolation, ogranicz uprawnienia JS dla niezaufanych domen (np. polityki ExtensionInstallBlacklist/URLBlacklist), rozważ uBO/NoScript w środowiskach wrażliwych;
    • egzekwuj automatyczne aktualizacje i restart przeglądarki (GPO/MDM).
  5. Detekcja i reagowanie:
    • monitoruj anomalia w procesach chrome.exe/chromium (spawn nieoczekiwanych child-processów, zrzuty pamięci, niepodpisane DLL);
    • telemetria przeglądania: nietypowe crashe V8, błędy Render Process gone po wejściu na daną domenę mogą wskazywać na testowanie exploitów.
  6. Zarządzanie ryzykiem:
    • zaktualizuj rejestr podatności i KPI patchowania;
    • jeśli organizacja stosuje allowlistę stron, tymczasowo ogranicz odwiedzanie nieznanych domen na stanowiskach o wysokiej wrażliwości.

Różnice / porównania z innymi przypadkami

Google w 2025 r. kilkukrotnie łatał zero-daye w V8. W odróżnieniu od wrześniowej luki CVE-2025-10585 (również type confusion), obecna podatność dotyczy gałęzi 142 i ma podobny wektor (spreparowany HTML/JS). W obu przypadkach Google ogranicza szczegóły do czasu powszechnego wdrożenia łatki.

Podsumowanie / kluczowe wnioski

  • Zaktualizuj Chrome do 142.0.7444.175/.176 jak najszybciej — exploit już krąży.
  • Luka dotyczy V8 (type confusion) i może prowadzić do RCE w odpowiednich warunkach.
  • Organizacje powinny wymusić restart przeglądarki po instalacji oraz audytować zgodność floty.

Źródła / bibliografia

  • Chrome Releases – Stable Channel Update for Desktop (17 listopada 2025): wersje i status exploitu. (Chrome Releases)
  • BleepingComputer – omówienie i kontekst siódmego zero-daya w 2025 r. (BleepingComputer)
  • NVD (NIST) – opis techniczny CVE-2025-13223 (V8, type confusion, heap corruption). (NVD)
  • SecurityWeek – wzmianka o CVSS 8.8 i implikacjach dla RCE. (SecurityWeek)
  • NHS Digital Cyber Alert – wersje zawierające poprawkę i status „exploited”. (NHS England Digital)

Chrome 142 łata aktywnie wykorzystywaną lukę w V8 (CVE-2025-13223). Aktualizuj natychmiast

Wprowadzenie do problemu / definicja luki

Google udostępnił 17 listopada 2025 r. aktualizację stabilnego kanału Chrome do 142.0.7444.175/.176 (Windows), 142.0.7444.176 (macOS) i 142.0.7444.175 (Linux). Łatka naprawia dwie luki wysokiej wagi w silniku V8, z czego CVE-2025-13223 jest aktywnie wykorzystywana („in the wild”). Druga luka to CVE-2025-13224, również „type confusion” w V8.

W skrócie

  • Zero-day: CVE-2025-13223 (V8, type confusion) – aktywnie wykorzystywana.
  • Druga luka: CVE-2025-13224 (V8, type confusion) – załatana w tym samym wydaniu.
  • Wpływ: zdalne naruszenie pamięci/heap corruption, potencjalnie wykonanie kodu po wizycie na spreparowanej stronie.
  • Działanie teraz: zaktualizować Chrome/Chromium-based przeglądarki i zrestartować, wymusić update w MDM/Intune/GPO, nadać wysoki priorytet zgodny z polityką „zero-day”. (Uzasadnienie niżej)

Kontekst / historia / powiązania

Rok 2025 przyniósł serię poważnych błędów w Chrome, wielokrotnie dotyczących V8. Nowe wydanie 142 dołącza do tegorocznych aktualizacji bezpieczeństwa, które regularnie łatały błędy pamięci w komponentach przeglądarki. Media branżowe odnotowują, że CVE-2025-13223 to kolejny aktywnie wykorzystywany błąd V8 w 2025 r.

Analiza techniczna / szczegóły luki

  • Klasa podatności: Type confusion w V8 – sytuacja, w której mechanizm JIT/optimizera traktuje obiekt jak inny typ, co prowadzi do błędów semantyki typu i ostatecznie do korupcji sterty.
  • CVE-2025-13223: zgłoszona 12.11.2025 przez Clémenta Lecigne (Google TAG). Google potwierdził aktywną eksploatację.
  • CVE-2025-13224: wykryta wcześniej (09.10.2025), również type confusion w V8; według NVD podatne wersje to Chrome przed 142.0.7444.175.
  • Skutki techniczne: „heap corruption” i potencjalne RCE po otwarciu złośliwej strony/HTML – wektor drive-by. (Opis ryzyka NVD dla 13224 i biuletyny CERT potwierdzają charakter błędu).

Praktyczne konsekwencje / ryzyko

  • Użytkownicy końcowi: pojedyncza wizyta na stronie może wystarczyć do kompromitacji przeglądarki/procesu renderera; łańcuch exploitów może dążyć do sandbox escape. (Typowe dla tej klasy błędów V8).
  • Organizacje: ryzyko malvertising/watering-hole, szczególnie dla profili wysokiego ryzyka, które śledzi zespół Google TAG.
  • Chromium-based: Edge, Brave, Opera zwykle dziedziczą te same łatki; do czasu wydania aktualizacji przez dostawców – podwyższony poziom ryzyka (praktyka potwierdzona w poprzednich falach łatek). Źródła branżowe i CERT potwierdzają pilność.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja:
    • Chrome do 142.0.7444.175/.176 (Win), 142.0.7444.176 (macOS), 142.0.7444.175 (Linux) + restart przeglądarki.
  2. Zarządzanie flotą:
    • W MDM/Intune/GPO wymuś TargetVersionPrefix=142, ustaw automatyczny restart po aktualizacji, monitoruj version drift. (Dostosuj do polityk firmy.)
  3. Monitoring/Detection:
    • Podnieś czułość na anomalie procesów chrome.exe/chrome (spawn nietypowych child-processów, zewnętrzne shell’e).
    • W proxy/IDS szukaj nietypowych kampanii drive-by i aktywności malvertising.
  4. Hardening tymczasowy (wysokie ryzyko/role wrażliwe):
    • Włączyć Site Isolation i ograniczyć JIT przez chrome://flags tylko jeśli akceptowalny spadek wydajności (środek tymczasowy do czasu pełnej propagacji).
  5. Chromium-based:
    • Śledź kanały aktualizacji Edge/Brave/Opera i wymuś update, gdy pojawią się buildy z gałęzi 142.
  6. Komunikacja:
    • Oznacz incydent jako „zero-day browser” w rejestrze ryzyka, powiadom użytkowników o koniecznym restarcie po aktualizacji.

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

W 2025 r. Google już kilkukrotnie łatal type confusion w V8; obecny przypadek powtarza schemat: szybka publikacja łatki, ograniczone szczegóły techniczne do czasu powszechnej aktualizacji. Doniesienia branżowe podkreślają, że to kolejny aktywnie nadużywany błąd V8 w tym roku, co wzmacnia tezę, że pamięcio-bezpieczeństwo w JIT pozostaje stałym wektorem ataków.

Podsumowanie / kluczowe wnioski

  • Aktualizacja do Chrome 142 jest pilna: CVE-2025-13223 już jest wykorzystywana.
  • Obie luki (13223, 13224) dotyczą V8 (type confusion) i mogą prowadzić do RCE poprzez stronę WWW.
  • Administratorzy powinni wymusić aktualizację i restart, monitorować propagację wersji oraz szykować reguły detekcyjne pod drive-by.

Źródła / bibliografia

  • Google Chrome Releases – „Stable Channel Update for Desktop”, 17.11.2025. (numery wersji, CVE, potwierdzenie „in the wild”) (Chrome Releases)
  • NVD (NIST) – CVE-2025-13224: opis klasy błędu, zakres wersji podatnych. (NVD)
  • HKCERT – „Google Chrome Multiple Vulnerabilities”: potwierdzenie aktywnej eksploatacji CVE-2025-13223 i ryzyka RCE. (HKCERT)
  • The Hacker News – omówienie kontekstu i trendu zero-day V8 w 2025 r. (The Hacker News)
  • Tenable – wpis CVE dla CVE-2025-13223/13224 (uzupełniający opis). (Tenable®)

#StopRansomware: Akira – aktualizacja 13.11.2025. Nowe TTP, wektory wejścia przez SonicWall i ataki na Nutanix AHV

Wprowadzenie do problemu / definicja luki

13 listopada 2025 r. opublikowano zaktualizowaną wspólną poradę (#StopRansomware) dot. grupy Akira. Dokument (AA24-109A) ostrzega o pilnym zagrożeniu dla infrastruktury krytycznej, nowych technikach oraz wskaźnikach kompromitacji (IOC). Najistotniejszy wątek: wejście przez urządzenia VPN (szczególnie SonicWall, CVE-2024-40766) i rozszerzenie szyfrowania na maszyny wirtualne Nutanix AHV, obok już znanych ataków na VMware ESXi/Hyper-V.


W skrócie

  • Wejście: nadużycie urządzeń VPN (m.in. SonicWall, CVE-2024-40766), podatnych usług/urządzeń brzegowych, nie-MFA, spearphishing, hasła wyciekłe/wypryskiwane (password spraying).
  • Rozszerzenie celu: pierwsze potwierdzone szyfrowanie dysków Nutanix AHV (czerwiec 2025).
  • TTP: nltest do odkrywania domen, Impacket/wmiexec, zdalne narzędzia (AnyDesk/LogMeIn), wyłączanie EDR, BYOVD/terminowanie AV.
  • Skala zysków: ~244,17 mln USD do IX 2025 r. (zgłoszenia śledcze FBI).

Kontekst / historia / powiązania

Akira działa co najmniej od marca 2023 r., początkowo Windows + rozszerzenie .akira, potem Megazord (Rust, rozszerzenie .powerranges) oraz Akira_v2; cele na wielu kontynentach i sektorach (produkcja, edukacja, IT, zdrowie, finanse, F&A). Autorzy łączą Akirę z aliasami Storm-1567/Howling Scorpius/Punk Spider/Gold Sahara i możliwymi koneksjami do upadłej Conti.

Od połowy 2025 r. obserwowano kampanię przeciw SonicWall SSL VPN – potwierdzoną też przez CERT-y/branżę (ACSC/ASD, vendor SonicWall, analizy Darktrace/Arctic Wolf).


Analiza techniczna / szczegóły luki

Wejście (Initial Access)

  • VPN bez MFA i znane CVE w produktach sieciowych, w tym Cisco (np. CVE-2020-3259, CVE-2023-20269), oraz SonicWall CVE-2024-40766. Dodatkowo Veeam (CVE-2023-27532, CVE-2024-40711). Często password spraying (np. SharpDomainSpray), RDP, kradzież poświadczeń, a także SSH przez router z publicznym IP.

Przykładowe zapisy do detekcji (Sigma, logon VPN SonicWall – event nieudany/udany z nietypowego ASN/geo):

title: SonicWall SSLVPN Suspicious Geo ASN Login
logsource:
  product: sonicwall
  service: sslvpn
detection:
  selection:
    outcome: success
  filter_geo:
    src_country|contains:
      - 'CN'
      - 'RU'
      - 'BR'
  condition: selection and filter_geo
level: medium
tags: [attack.t1110, initial-access]

Wykonanie (Execution)

  • Częste użycie VBScript do wykonywania poleceń i automatyzacji.

Trwałość / Ruch rozpoznawczy

  • Tworzenie nowych kont domenowych (spotykana nazwa itadm), Kerberoasting, zrzut LSASS (Mimikatz/LaZagne), skanowanie (SoftPerfect/Advanced IP Scanner/NetScan), polecenia net oraz nltest /dclist, nltest /DOMAIN_TRUSTS.

Szybki „hunt” w Windows (PowerShell):

# Nowo utworzeni członkowie Domain Admins w 7d
Get-ADGroupMember "Domain Admins" |
  ForEach-Object { Get-ADUser $_ -Properties whenCreated } |
  Where-Object { $_.whenCreated -gt (Get-Date).AddDays(-7) } |
  Select-Object Name, SamAccountName, whenCreated

# Artefakty net/nltest w PowerShell Operational (ID 4104/4103) i Security 4688
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 5000 |
  Where-Object {$_.Message -match 'nltest|net.exe'}

Unikanie obrony / Lateral Movement

  • PowerTool + podatny sterownik (BYOVD) do zabijania procesów AV/EDR (m.in. wyłączenie Defendera), nadużycie AnyDesk/LogMeIn, Impacket wmiexec.py, odinstalowanie EDR przed szyfrowaniem.

Szyfrowanie / Wpływ na wirtualizację

  • Po ESXi/Hyper-V, czerwiec 2025: szyfrowanie dysków VM Nutanix AHV – istotna zmiana dla środowisk HCI.

Praktyczne konsekwencje / ryzyko

  • Urządzenia brzegowe (SonicWall) stają się „jednym kliknięciem” do sieci wewnętrznej – nawet z MFA (doniesienia o przejętych seedach OTP/artefaktach pozwalających omijać MFA). Uderza to w model „MFA-i-po-sprawie”.
  • Wirtualizacja: przejście z ESXi/Hyper-V na Nutanix AHV rozszerza powierzchnię ataku i podnosi koszt RTO/RPO przy incydencie.
  • Utrudniona detekcja przez nadużycie legalnych narzędzi, wyłączanie EDR i użycie Impacket w ruchu bocznym.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast załataj i utwardź SonicWall (CVE-2024-40766), zresetuj poświadczenia SSL VPN, rozważ rotację/ponowną rejestrację sekretów OTP/MFA; zaktualizuj do najnowszego SonicOS 7.3.x, zastosuj zalecenia producenta.
  2. Wymuś phishing-resistant MFA (FIDO2/WebAuthn) oraz blokady po wielu nieudanych próbach; ogranicz wskazówki haseł, nie wymuszaj zbyt częstych zmian (zgodnie z NIST), ale wymuś rotację po incydencie VPN.
  3. Segmentacja i zasada najmniejszych uprawnień (kontrola przepływów, izolacja serwerów zarządzania hipernadzorcą/backupem).
  4. Kopie offline + testy odtwarzania (szczególnie VM AHV/ESXi/Hyper-V i repozytoria Veeam).
  5. Monitoring anomalii sieciowych i EDR: wykrywaj nltest/net, wmiexec/Impacket, instalacje AnyDesk/LogMeIn, próby deinstalacji EDR. (Patrz sekcja „hunt”.)
  6. Blokuj narzędzia BYOVD (wdrożenia HVCI/Blocklist sterowników Microsoft, AppControl), monitoruj ładowanie nietypowych sterowników (Sysmon ID 6).
  7. Dodatkowe źródła IOC i ATT&CK mapping – pobierz STIX z aktualizacji AA24-109A i wprowadź do SIEM/SOAR.

Przykładowe reguły (Sysmon/Sigma) – Impacket & nltest:

title: Impacket WMIExec Child Of Python
logsource: { product: windows, service: sysmon }
detection:
  sel1: { EventID: 1, ParentImage|endswith: '\python.exe', Image|endswith: '\wmic.exe' }
  sel2: { EventID: 3, DestinationPort: 135 }  # DCOM
  condition: sel1 or sel2
level: high
tags: [attack.t1047, lateral-movement]

---
title: Domain Discovery with nltest
logsource: { product: windows, service: security }
detection:
  sel: { EventID: 4688, NewProcessName|endswith: '\nltest.exe' }
  condition: sel
level: medium
tags: [attack.t1018,t1482]

Przykładowe zapory/SDN – ogranicz RDP/SMB/WMI do stref adminów:

# Linux nftables - blokuj SMB z podsieci użytkowników do serwerów
nft add rule inet filter forward ip saddr 10.20.0.0/16 ip daddr 10.30.10.0/24 tcp dport {445,139} drop

Różnice / porównania z innymi przypadkami

  • LockBit/ALPHV długo stawiały głównie na ESXi/Hyper-V; Akira jako jedna z pierwszych operacji potwierdzenie ataków na Nutanix AHV, co wymusza aktualizację playbooków IR/BCP dla HCI.
  • Akcent na SonicWall SSL VPN – rzadziej spotykany tak skoncentrowany wektor u konkurencyjnych grup w 2025 r.; zbieżne ostrzeżenia rządowe (ACSC) i vendor.

Podsumowanie / kluczowe wnioski

  1. Brzeg (VPN) to główna brama – łataj i rotuj sekrety. 2) AHV jest już na celowniku – ćwicz odtwarzanie VM poza hipernadzorcą. 3) Detekcja TTP (Impacket/nltest/AnyDesk) i ochrona przed BYOVD muszą być obowiązkowym elementem. 4) Wdróż MFA odporne na phishing i egzekwuj najmniejsze uprawnienia. 5) Pobierz i wprowadź IOC z AA24-109A (STIX).

Źródła / bibliografia

  1. FBI/CISA/DC3/HHS/EC3/NCSC-NL i in., #StopRansomware: Akira Ransomware – aktualizacja 13.11.2025 (AA24-109A). Zawiera TTP/IOC, MITRE ATT&CK i zalecenia.
  2. CISA – strona poradnika AA24-109A (mirror + opis aktualizacji). (CISA)
  3. ACSC/ASD – alert dot. aktywnej eksploatacji CVE-2024-40766 (SonicWall) i powiązania z Akirą. (Cyber.gov.au)
  4. SonicWall – komunikat producenta nt. zagrożeń dla Gen7 i SSLVPN oraz działań naprawczych. (SonicWall)
  5. BleepingComputer – wzmianka o szyfrowaniu Nutanix AHV przez Akirę (potwierdzenie trendu z AA24-109A). (BleepingComputer)

SOC Alert Triage

Od hałasu do sygnału – logika triage w SOC

Wyobraź sobie, że jako analityk SOC L1 patrzysz na ekran zalewu alertów: dziesiątki sygnalizacji typu „Email oznaczony jako phishing”, kilka „Podejrzana lokalizacja logowania VPN” i jedno groźnie brzmiące „Wykryto Mimikatz na hoście”. Co teraz? Którym alertem zajmiesz się najpierw i dlaczego? Taka scena to codzienność w Security Operations Center. Tutaj do gry wchodzi triage alertów – proces decydujący o tym, czy potencjalny atak zostanie szybko zauważony, czy zginie w tłumie false positive.

Czytaj dalej „SOC Alert Triage”

CVE-2025-12480 — Triofox Improper Access Control (auth bypass → RCE przez funkcję antywirusową)

TL;DR

Krytyczna luka w Gladinet Triofox pozwala nieautoryzowanemu napastnikowi ominąć logowanie, wejść w strony konfiguracji początkowej i utworzyć konto administratora aplikacji. W zaobserwowanych atakach przeciwnik użył konta do wykonania kodu z uprawnieniami SYSTEM przez nadużycie wbudowanej funkcji „antywirus” (dowolna ścieżka skanera), a następnie wdrażał Zoho UEMS/Assist, AnyDesk, Plink/PuTTY i tunelował RDP. Załataj do ≥ 16.7.10368.56560 (zalecane 16.10.10408.56683) i monitoruj IIS pod kątem odwołań „localhost” do /management/*. W artykule: gotowa Sigma, SPL, KQL, EQL, playbook IR i artefakty.


Krótka definicja techniczna

CVE‑2025‑12480 to błąd kontroli dostępu w Triofox, który po sfałszowaniu nagłówka/odwołania HTTP z wartością localhost odblokowuje strony inicjalizacji (AdminDatabase.aspxAdminAccount.aspxInitAccount.aspx) mimo zakończonego wdrożenia. Skutkiem jest założenie natywnego konta „Cluster Admin”, a w łańcuchu realnych ataków — RCE jako SYSTEM przez wskazanie własnej ścieżki skanera w funkcji AV. Wersje podatne: < 16.7.10368.56560; poprawki dostępne (zalecana najnowsza gałąź).


Gdzie występuje / przykłady platform

  • Windows Server + IIS/ASP.NET (host aplikacji Triofox).
  • Active Directory (opcjonalnie – integracja z LDAP/AD do autoryzacji użytkowników aplikacji).
  • IaaS (AWS/Azure/GCP) — często za ALB/WAF/NGFW; problem dotyczy warstwy aplikacji webowej na VM/serwerze.
  • Bazy danych (PostgreSQL/MySQL) sterowane z panelu inicjalizacji Triofox.
  • K8s/ESXi/M365 – brak natywnego wektora; występują wyłącznie jako kontekst infrastrukturalny [nie wymagane].

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

  • Wejście (T1190): błędna logika sprawdzania dostępu do krytycznych stron instalatora Triofox. Zmiana Host/Referer → localhost skutkuje dopuszczeniem do ścieżki instalacyjnej mimo ukończonej konfiguracji.
  • Utworzenie admina (T1136): atakujący przechodzi flow inicjalizacji i tworzy natywne konto administracyjne („Cluster Admin”) w samej aplikacji.
  • Wykonanie (T1059.001) + RCE: po zalogowaniu do panelu używa funkcji „Anti‑Virus Engine Path” – wskazuje własny plik/skrypt; Triofox uruchamia go w kontekście SYSTEM, co daje pełne RCE.
  • Post‑exploitation: pobranie legalnych narzędzi zdalnego dostępu (Zoho UEMS/Assist, AnyDesk), Plink/PuTTY do tunelowania RDP (T1219/T1572/T1105), enumeracja SMB i zmiany haseł/grup. Kampanie obserwowane co najmniej od 2025‑08‑24.
  • Dlaczego skuteczna: brak walidacji źródła localhost w kodzie, zależność od opcjonalnego TrustedHostIp w web.config, możliwość uruchomienia arbitralnej ścieżki AV z uprawnieniami usługi.

Artefakty i logi (SOC cheat‑sheet)

Warstwa / źródłoEID / poleWzorzec / przykład korelacjiUwagi
IIS (W3C)cs-uri-stem, cs(Referer)Żądania do /management/AdminDatabase.aspx, /AdminAccount.aspx, /InitAccount.aspx, /CommitPage.aspx z Referer zawierającym http://localhostMandiant pokazał wpis z 302 do CommitPage.aspx z refererem localhost. Śledzić zewnętrzne IP jako źródło.
IIS/WAF/ALBHost/RefererNagłówek/odwołanie Host/Referer=localhost z adresów publicznychMożliwe także X-Forwarded-Host=localhost za proxy.
Windows Security4688 (Process Create)Uruchomienia powershell.exe, cmd.exe przez procesy Triofox/IIS tuż po dostępie do paneluKoreluj z logami IIS (ten sam host, ten sam czas ±5 min).
Windows Security7045 (Service Installed)Nowe usługi: Zoho UEMS/Assist, AnyDesk, nietypowe ścieżki w binPathCzęste w opisywanej kampanii.
Sysmon1 (Process Create)Image: *\\plink.exe, *\\putty.exe, *\\AnyDesk*.exe, *\\Zoho*Tunelowanie i dostęp zdalny.
Sysmon3 (Network Connect)Połączenia do zidentyfikowanych IP C2/hosting (np. 85.239.63[.]37, 65.109.204[.]197, 84.200.80[.]252, 216.107.136[.]46)IoC z raportu; utrzymuj listę deny/monitor.
Sysmon11 (File Create)C:\Windows\Temp\*.exe, C:\triofox\*.bat (np. centre_report.bat)Nazwy z raportu Mandiant.
Aplikacja Triofoxlogi aplikacyjneZmiany konfiguracji AV engine path, publikacja udziałów (pokazanie ścieżki na dysku)Krytyczne do triage’u RCE.
CloudTrail (IaaS)AuthorizeSecurityGroupIngressDopuszczenie 0.0.0.0/0 → 443/80 na SG przypiętej do hosta TriofoxPomocnicze: wykrywa niepożądane ekspozycje.

Detekcja (praktyczne reguły)

Sigma (IIS – próba obejścia z localhost)

title: Triofox CVE-2025-12480 - Localhost Referrer to Management Pages (IIS)
id: 2f47d6b5-9e2e-4f0b-9b7e-97b1e0e2f480
status: experimental
description: Wykrywa odwołania z 'localhost' do stron /management/* w Triofox (możliwa eksploatacja CVE-2025-12480).
references:
  - https://cloud.google.com/blog/topics/threat-intelligence/triofox-vulnerability-cve-2025-12480
  - https://nvd.nist.gov/vuln/detail/CVE-2025-12480
author: Badacz CVE
date: 2025/11/12
logsource:
  category: webserver
  product: windows
  service: iis
detection:
  selection_pages:
    http.request.target|contains:
      - "/management/AdminDatabase.aspx"
      - "/management/AdminAccount.aspx"
      - "/management/InitAccount.aspx"
      - "/management/CommitPage.aspx"
  ref1:
    http.request.referrer|contains: "http://localhost"
  ref2:
    cs-referrer|contains: "http://localhost"
  condition: selection_pages and (ref1 or ref2)
fields:
  - client.ip
  - http.request.method
  - http.request.referrer
  - http.request.target
  - http.response.status_code
falsepositives:
  - Testy administratorskie wykonywane lokalnie (żądania z 127.0.0.1)
level: high
tags:
  - attack.T1190
  - cve.2025-12480

Splunk (IIS/WAF)

index=web (sourcetype=iis OR tag=web)
(cs_uri_stem="/management/AdminDatabase.aspx"
 OR cs_uri_stem="/management/AdminAccount.aspx"
 OR cs_uri_stem="/management/InitAccount.aspx"
 OR cs_uri_stem="/management/CommitPage.aspx")
( cs_Referer="http://localhost*" OR referer="http://localhost*" )
| stats count min(_time) as first_seen max(_time) as last_seen by c_ip cs_uri_stem cs_Referer sc_status
| where c_ip!="127.0.0.1"

KQL (Microsoft Sentinel – W3CIISLog)

W3CIISLog
| where csUriStem has "/management/"
| where csUriStem has_any ("AdminDatabase.aspx", "AdminAccount.aspx", "InitAccount.aspx", "CommitPage.aspx")
| where csReferer has "http://localhost"
| extend isPrivate = ipv4_is_private(cIP)
| where isPrivate == false

CloudTrail (CloudWatch Logs Insights – „szerokie” otwarcie 80/443)

fields @timestamp, eventName, requestParameters
| filter eventName = "AuthorizeSecurityGroupIngress"
| filter requestParameters.ipPermissions.items[*].ipRanges.items[*].cidrIp like /0\.0\.0\.0\/0/
| filter requestParameters.ipPermissions.items[*].fromPort in [80,443]
| sort @timestamp desc

Uzupełniające: aws ec2 describe-security-groups i kontrola SG przypiętych do instancji Triofox.

Elastic / EQL (procesy i tunelowanie)

process where process.name in ("plink.exe","putty.exe","AnyDesk.exe","Zoho*","ZohoAssist*")
  and process.parent.name in ("w3wp.exe","svchost.exe") /* web worker / usługa */
  and host.os.type == "windows"
network where process.name == "plink.exe" and
  (destination.port == 22 and
   (exists(destination.ip) and source.ip == "127.0.0.1" or destination.ip != "127.0.0.1"))

Heurystyki / korelacje

  • IIS „localhost” + /management/ AND w krótkim czasie 4688 z powershell.exe/cmd.exe na tym samym hoście.
  • Nowe usługi (7045) zawierające Zoho, AnyDesk AND wcześniejszy dostęp do panelu Triofox.
  • Plink/PuTTY uruchomione na serwerze Triofox AND wzrost połączeń na 3389/TCP (tunel RDP).
  • Publikacja nowego „share” w Triofox AND zaraz potem wykonanie pliku ze ścieżki udziału (abuse AV‑Path).

False positives / tuning

  • Prawdziwi administratorzy mogą testować system lokalnie; żądania z 127.0.0.1 (loopback) i/lub z sieci zarządzającej można whitelistować.
  • Legalne użycie Zoho/AnyDesk – filtruj po znanych kluczach/tenantach, podpisach cyfrowych i źródłach instalacji (MSI z firmowego repo).
  • Proxy/health‑checki rzadko ustawiają Referer=localhost; jeśli tak – ogranicz do znanych adresów/LB.

Playbook reagowania (IR)

  1. Identyfikacja i blokada
  • WAF/NGFW: reguła drop dla Host/Referer=localhost na ścieżkach /management/*.
  • Tymczasowe geo/IP‑deny wg IoC (np. 85.239.63[.]37, 65.109.204[.]197, 84.200.80[.]252, 216.107.136[.]46).
  1. Triage
  • Przeskanuj IIS za zdarzeniami z sekcji 6; skoreluj z 4688/7045/Sysmon‑1/3/11.
  • W Triofox sprawdź: lista kont admin, historia zmian AV Engine Path, ostatnie publikacje udziałów.
  1. Eradykacja
  • Usuń nieautoryzowane konto aplikacyjne („Cluster Admin” itp.).
  • Dezinstaluj Zoho UEMS/Assist/AnyDesk zainstalowane spoza Twojej dystrybucji; zamknij plink/putty.
  • Cofnij zmiany haseł/grup, wymuś rotację sekretów.
  1. Odtworzenie i twardnienie
  • Patch: co najmniej 16.7.10368.56560; zalecany 16.10.10408.56683 (2025‑10‑14).
  • Skonfiguruj TrustedHostIp/sieci zarządzające, ogranicz dostęp do panelu tylko z MFA/VPN; logowanie na szczegółowym poziomie.
  1. Lessons learned
  • Dodaj detekcje z rozdz. 7, testy regresyjne, „table‑top” z łańcuchem nadużyć AV‑Path.

Przykłady z kampanii / case studies

  • UNC6485 (Mandiant/Google): eksploatacja co najmniej od 2025‑08‑24 na wersji 16.4.10317.56372; obejście autoryzacji (Host/Referer localhost) → utworzenie „Cluster Admin” → RCE przez ścieżkę AV → wdrożenie Zoho UEMS/Assist i AnyDesk, Plink/PuTTY do tunelowania RDP:3389. Wskazane przykładowe IP i artefakty (hashy, ścieżki).
  • Relacje prasowe: BleepingComputer i SecurityWeek potwierdzają łańcuch i zalecają aktualizację do najnowszej gałęzi Triofox.

Lab (bezpieczne testy)

Wyłącznie w izolowanym labie z testową instancją Triofox; nie instruujemy eksploatacji — generujemy sygnał do detekcji.

  • Generacja wpisu IIS przypominającego anomalię Referer (na testowym serwerze www, do niekrytycznej strony):
$h = @{ "Referer" = "http://localhost/test" }
Invoke-WebRequest -UseBasicParsing -Headers $h `
  -Uri "https://triofox-lab.local/management/AccessDenied.aspx"
  • Wpis 7045 (test instalacji usługi):
sc.exe create TestCVE125 path= "C:\Windows\System32\notepad.exe" start= demand
sc.exe delete TestCVE125
  • E2E sprawdzenie korelacji w Splunk/KQL: odpal test powyżej, a następnie uruchom reguły z sekcji 7 i zweryfikuj alerty.

Mapowania (Mitigations, Powiązane techniki)

Mitigations (ATT&CK):

  • M1051 Update Software — aktualizuj Triofox do ≥ 16.7.10368.56560 (zal. 16.10.10408.56683).
  • M1031 Network Intrusion Prevention — sygnatury/WAF blokujące Host/Referer=localhost na ścieżkach admina i wykrywanie tuneli.
  • M1030 Network Segmentation — strefa DMZ dla serwera Triofox; dostęp administracyjny tylko z sieci zarządzającej/VPN.

Powiązane techniki:

  • T1190 — Exploit Public‑Facing Application – Atak przez błąd logiczny w kontroli dostępu do stron /management/* (bypass auth).
  • T1136 — Create Account – Utworzenie natywnego admina („Cluster Admin”) w aplikacji dla utrzymania przyczółka.
  • T1059.001 — Command and Scripting Interpreter: PowerShell – Skrypty/batche wywołujące PowerShell downloader w łańcuchu RCE.
  • T1219 — Remote Access Software – Wdrożenie Zoho Assist/AnyDesk jako kanału C2/remote‑ops.
  • T1572 — Protocol TunnelingPlink/PuTTY do tunelowania RDP przez SSH.
  • T1105 — Ingress Tool Transfer – Pobranie narzędzi (Zoho/AnyDesk/Plink) na host Triofox.

Źródła / dalsza lektura

  • Mandiant/Google Cloud: No Place Like Localhost — techniczne omówienie, IoC, łańcuch ataku. (Google Cloud)
  • NVD: karta CVE (wersje podatne, CVSS, CWE). (NVD)
  • BleepingComputer: Hackers abuse Triofox antivirus feature to deploy RATs (RCE=SYSTEM, zalecenia). (BleepingComputer)
  • SecurityWeek: Critical Triofox Vulnerability Exploited in the Wild. (SecurityWeek)
  • Tenable / OpenCVE: status, streszczenie, SSVC. (Tenable®)
  • Check Point IPS Advisory (CVE‑2025‑12480). (Check Point Software)
  • MITRE ATT&CK v18 — wersje i aktualizacje. (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC (operacyjnie):

  • Reguły z sekcji 7 wdrożone (IIS, EDR/Elastic, Sentinel, WAF).
  • Hunt: Referer/Host=localhost/management/* w IIS (30–90 dni wstecz).
  • Korelacja z 4688/7045/Sysmon‑1/3/11 i z procesami plink/putty/AnyDesk/Zoho*.
  • Przegląd kont admin w Triofox; inspekcja AV Engine Path.
  • Blokady IoC sieciowych i rotacja haseł/sekretów, jeśli wskazane.

CISO / właściciele usług:

  • Patch: ≥ 16.7.10368.56560 (preferuj 16.10.10408.56683).
  • WAF: deny Host/Referer=localhost dla /management/*.
  • Segmentacja: panel admin tylko z sieci zarządczej + MFA/VPN.
  • Polityka dopuszczalnych narzędzi zdalnych (Zoho/AnyDesk) i ich inwentaryzacja.
  • Przegląd ekspozycji w IaaS (SG/ALB) i CI/CD patch/release hygiene.

Uwaga o ryzyku: Luka była aktywnie eksploatowana i występuje prosta możliwość RCE jako SYSTEM przy wykorzystaniu funkcji AV w Triofox — traktuj priorytetowo.

Systemy Biometryczne: Architektura, Podatności i Zabezpieczenia

Czym są systemy biometryczne?

Systemy biometryczne wykorzystują cechy fizyczne lub behawioralne do identyfikacji i uwierzytelniania osób. Biometria obejmuje m.in. cechy fizjologiczne (twarz, tęczówka, odcisk palca, geometria dłoni, siatkówka oka) oraz behawioralne (głos, podpis odręczny, chód, sposób pisania na klawiaturze). W odróżnieniu od tradycyjnych metod (hasła, PIN-y, karty dostępu), cech biometrycznych nie da się zgubić ani zapomnieć, a próby oszukania systemu przez wykradzenie cech są trudniejsze – przynajmniej w teorii.

Czytaj dalej „Systemy Biometryczne: Architektura, Podatności i Zabezpieczenia”