Archiwa: Firewall - Strona 17 z 24 - Security Bez Tabu

Tag: Firewall

CVE-2015-3113 — Adobe Flash Player RCE

TL;DR

Krytyczna luka w Adobe Flash Player (CVE‑2015‑3113) umożliwiała zdalne wykonanie kodu poprzez przepełnienie bufora na stercie, m.in. po wejściu na złośliwą stronę lub kliknięciu odsyłacza w kampanii phishingowej. Zero‑day wykorzystywany był w operacji Clandestine Wolf (APT3), z łańcuchem: e‑mail → profilowanie JS → załadowanie pliku SWF/FLV → ROP/DEP/ASLR bypass → zrzut backdoora (SHOTPUT). Detekcja: obserwuj pobrania .swf, procesy/załadowane moduły Flash oraz nietypowe dzieci procesów Flash (cmd/powershell/wscript). Ponieważ Flash jest EOL (12.2020), każde użycie Flash w 2025 r. jest co najmniej podejrzane.

Krótka definicja techniczna

CVE‑2015‑3113 to luka typu heap‑based buffer overflow w Adobe Flash Player (przed 13.0.0.296; 14.x–18.x < 18.0.0.194 dla Windows/OS X; Linux < 11.2.202.468), pozwalająca zdalnie wykonać kod przy przetwarzaniu specjalnie spreparowanych treści Flash; w czerwcu 2015 była aktywnie wykorzystywana na wolności.

Gdzie występuje / przykłady platform

  • Endpointy: Windows (IE/Edge Legacy/Chrome/Firefox), macOS (Safari/Firefox/Chrome), Linux (Firefox/Chromium – PPAPI/NPAPI).
  • Scenariusze ataku: phishing z linkiem do serwisu z exploitem, drive‑by po wejściu na zainfekowaną stronę; znane cele zawierały m.in. Windows 7 (IE) i Firefox na XP.
  • Stan dzisiaj: Flash Player zakończył życie 31.12.2020 (blokada uruchomienia od 12.01.2021) — użycie w sieci produkcyjnej to incydent ryzyka.

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

Kampania Operation Clandestine Wolf przypisywana APT3 wykorzystywała e‑maile z odsyłaczami do przejętych witryn. Po kliknięciu ofiara była przekierowywana do skryptów profilujących (JS), które sprawdzały wersje przeglądarki/wtyczek. Następnie serwer dostarczał parę plików SWF + FLV wykorzystujących CVE‑2015‑3113. Exploit uzyskiwał arbitralny zapis/odczyt, wykonywał łańcuch ROP omijający DEP/ASLR, a finalnie odpalał shellcode i zrzucał backdoora SHOTPUT. Efekt: zdalne RCE i trwała kontrola hosta.

Dlaczego skuteczna?
(1) popularność Flash w 2015, (2) atak drive‑by nie wymagał pobierania plików przez użytkownika, (3) łańcuch exploitów obchodził mechanizmy łagodzące (DEP/ASLR), (4) szybka adopcja w ekosystemie exploit kitów (np. Magnitude).

Artefakty i logi

WarstwaArtefakt / źródłoWskaźniki / polaUwagi
Windows (Sysmon)EID 1 Process CreateImage/ParentImage: FlashPlayer.exe, FlashUtil*.exe, FlashPlayerPlugin*.exe; dzieci: cmd.exe, powershell.exe, wscript.exe, rundll32.exe, regsvr32.exeNietypowe dziecko procesu Flash = silny sygnał RCE. Nazwy procesów potwierdza Adobe Flash Player Admin Guide.
Windows (Sysmon)EID 7 Image LoadedImageLoaded = \pepflashplayer.dll (Chrome/Chromium)Obserwuj załadowanie w procesach przeglądarki.
Windows (Application)EID 1000 Application ErrorAwaria modułów Flash/pepflashNagłe crashe Flash niedługo przed nietypowym procesem‑dzieckiem.
Proxy/NGFW/DNSDostęp HTTP/S do *.swf, MIME application/x-shockwave-flashurl, mime, user_agent, referrerKoreluj z kliknięciami z e‑maila (M365).
M365 DefenderEmailUrlInfo, UrlClickEventsUrl, UrlDomain, kliknięcia Safe LinksŁącz URL .swf z hostami, które uruchomiły procesy Flash.
MITRE ATT&CK (kontekst)APT3 + SHOTPUTProfilowanie, dostarczenie backdooraDo korelacji z TTP grupy.
AWS (opcjonalnie)CloudTrail Lake (S3 Data Events)GetObject na kluczach %.swfWymaga włączonych data events.
CDNCloudFront Access Logs / Athenacs-uri-stem like '%.swf', sc-content-typePrzy hostowaniu/pośrednictwie treści.

Detekcja (praktyczne reguły)

Sigma (Windows / Sysmon – anomalie dzieci procesów Flash)

title: Flash Plugin Spawns Suspicious Child (CVE-2015-3113 Context)
id: 5a8b2f3b-8ce3-49d0-9f1f-6a2e1d1f3f31
status: experimental
description: Wykrywa nietypowe dzieci procesów Flash (cmd/powershell/skrpty), co bywa obserwowane przy RCE (np. CVE-2015-3113).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2015-3113
  - https://cloud.google.com/blog/topics/threat-intelligence/operation-clandestine-wolf-adobe-flash-zero-day/
tags:
  - attack.t1203
  - attack.t1189
  - attack.t1566.002
  - cve.2015-3113
logsource:
  category: process_creation
  product: windows
detection:
  sel_parent:
    ParentImage|contains:
      - '\FlashPlayer'
      - '\FlashUtil'
      - '\FlashPlayerPlugin'
  sel_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  condition: sel_parent and sel_child
fields:
  - ParentImage
  - ParentCommandLine
  - Image
  - CommandLine
falsepositives:
  - Rzadkie narzędzia korporacyjne wołane z aplikacji opartej na Flash (dziś skrajnie rzadkie)
level: high

Splunk (SPL)

1) Flash uruchomiony przez przeglądarkę

index=sysmon EventCode=1
(ParentImage="*\\iexplore.exe" OR ParentImage="*\\chrome.exe" OR ParentImage="*\\firefox.exe" OR ParentImage="*\\msedge.exe")
(Image="*\\FlashPlayer*.exe" OR Image="*\\FlashUtil*.exe" OR Image="*\\FlashPlayerPlugin*.exe")
| stats count min(_time) max(_time) by host, ParentImage, Image, CommandLine, ParentCommandLine

2) Dzieci procesów Flash

index=sysmon EventCode=1
(ParentImage="*\\FlashPlayer*.exe" OR ParentImage="*\\FlashUtil*.exe" OR ParentImage="*\\FlashPlayerPlugin*.exe")
(Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\wscript.exe" OR Image="*\\rundll32.exe" OR Image="*\\regsvr32.exe")
| table _time host ParentImage Image CommandLine

3) Proxy/HTTP — pobrania .swf

index=proxy (uri_path="*.swf" OR mime_type="application/x-shockwave-flash")
| stats count by src_ip, user, uri, http_status, user_agent, referrer

KQL (Microsoft Defender / M365)

Defender for Endpoint — dzieci procesów Flash

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("FlashPlayer.exe","FlashPlayerPlugin.exe","FlashUtil32.exe","FlashUtil64.exe")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine

MDO — kliknięcia linków .swf

UrlClickEvents
| where Url endswith ".swf" or Url has ".swf?"
| summarize Clicks=count() by UrlDomain, Url, AccountUpn, Timestamp

MDO — adresy URL w wiadomościach

EmailUrlInfo
| where Url endswith ".swf" or Url has ".swf?"
| join kind=leftouter EmailEvents on NetworkMessageId
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Url, UrlDomain, Subject, ThreatTypes

(Definicje tabel: EmailUrlInfo, UrlClickEvents — dokumentacja Microsoft).

CloudTrail / CloudWatch (AWS)

Założenie: włączone S3 Data Events lub logi CloudFront.

CloudTrail Lake SQL (AWS CLI): wyszukaj pobrania *.swf z bucketów

SELECT eventTime, sourceIPAddress, userIdentity.principalId, requestParameters.bucketName AS bucket,
       requestParameters.key AS objectKey
FROM event_data_store
WHERE eventSource = 's3.amazonaws.com'
  AND eventName   = 'GetObject'
  AND requestParameters.key LIKE '%.swf'
  AND eventTime > TIMESTAMP '2025-11-01 00:00:00';

(Wymaga włączonych data events).

CloudFront / Athena (przykład):

SELECT date, time, cs_host, cs_uri_stem, sc_status, sc_content_type, c_ip, cs_user_agent
FROM cloudfront_logs
WHERE cs_uri_stem LIKE '%.swf'
ORDER BY date, time DESC;

Elastic EQL

process where
  process.parent.name in ("FlashPlayer.exe","FlashPlayerPlugin.exe","FlashUtil32.exe","FlashUtil64.exe") and
  process.name in ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe")

Heurystyki / korelacje

  • Klik .swf ⇒ proces Flash ⇒ podejrzane dziecko ⇒ połączenie wychodzące (czasowo blisko) — korelacja M365 (UrlClickEvents / EmailUrlInfo) + EDR + egress DNS/HTTP.
  • Załadowanie pepflashplayer.dll przez przeglądarkę, następnie nietypowe zachowanie (np. nagłe powershell.exe).
  • Rzadko używane dziś MIME application/x-shockwave-flash w ruchu web — traktuj jako anomalię.
  • Artefakty APT3/SHOTPUT (nietypowe rozpoznanie hosta/użytkowników/sieci po kompromitacji) jako sygnały post‑exploitation do korelacji (np. lista kont, netstat).

False positives / tuning

  • Dziedzictwo wewnętrzne: pojedyncze kioski/offline‑aplikacje z zawartością SWF (dziś wyjątkowe). Użyj allowlist domen/aplikacji biznesowych i ogranicz reguły do organizacji/OU, gdzie jakiekolwiek Flash jest dopuszczone.
  • Narzędzia administracyjne mogą incydentalnie wywołać interpretery (np. skrypty logowania), ale rodzicem nie powinien być proces Flash.
  • Ustal okno czasowe (np. ±5 min od kliknięcia URL .swf) i filtruj znane testy w labie.

Playbook reagowania (SOC/IR)

  1. Zablokuj źródło: domenę/URL z .swf w proxy/DNS firewall; wypchnij blokadę przez EDR.
  2. Izoluj host z alertem (EDR quarantine).
  3. Triage artefaktów:
    • Procesy potomne Flash, dropy w %APPDATA%, połączenia C2.
    • Zrzut pamięci procesu przeglądarki/Flash (jeśli polityka na to pozwala).
  4. Hunting rozprzestrzenienie: użyj zapytań (SPL/KQL/EQL powyżej) w horyzoncie 7–30 dni.
  5. Patch & harden: potwierdź brak Flash w flocie (wycofanie EOL), wymuś aktualizacje przeglądarek.
  6. Eradykacja: usuń artefakty, przeinstaluj przeglądarkę, unieważnij poświadczenia pozyskane po kompromitacji.
  7. Lessons learned: blokada typów/MIME, EDR policy na podejrzane dzieci procesów, kampania edukacyjna „nie klikaj .swf”.

Przykłady z kampanii / case studies

  • Operation Clandestine Wolf (APT3/UPS) — phishing z odsyłaczami do przejętych witryn; profilowanie JS; exploit CVE‑2015‑3113; backdoor SHOTPUT (Backdoor.APT.CookieCutter). Branże: A&D, telco, high‑tech, transport, budownictwo.
  • Eksploatacja na szeroką skalę — szybka adopcja w exploit kitach (np. Magnitude) w 2015 r.

Lab (bezpieczne testy) — tylko w kontrolowanym środowisku

Nie instaluj Flash w produkcji. Nie testujemy exploitu — jedynie łańcuch detekcji.

  • Symulacja ruchu web
    • curl -I https://lab.example.org/test.swf (serwuj neutralny plik binarny z nagłówkiem Content-Type: application/x-shockwave-flash).
    • Zweryfikuj, że proxy/NGFW/Athena (CloudFront) odnotowały żądanie *.swf.
  • Symulacja korelacji M365
    • Wyślij na skrzynkę testową e‑mail z linkiem do https://lab.example.org/test.swf.
    • Sprawdź EmailUrlInfo / UrlClickEvents (KQL z sekcji 7).
  • Symulacja anomalii procesów
    • Zastępczo uruchom aplikację, która imituje wzorzec: proces „AplikacjaGUI.exe” → cmd.exe /c whoami. Reguły powinny złapać schemat „aplikacja multimedialna → interpreter”. (Bez użycia Flash).

Mapowania

Mitigations (ATT&CK):

  • M1050 Exploit Protection — ASR/Exploit Guard/EDR exploit prevention.
  • M1033 Limit Software Installation — blokada instalacji wtyczek/dodatków; usunięcie Flash.
  • M1040 Behavior Prevention on Endpoint — blokuj podejrzane łańcuchy (Flash → skrypty/LOLBins).
  • M1017 User Training — prewencja kliknięć w odsyłacze .swf.

Powiązane techniki (kaskada):

  • T1105 Ingress Tool Transfer — dociąganie backdoora po RCE.
  • T1027 Obfuscated/Compressed Files & Information — xor/steganografia/packery w payloadach.

Źródła / dalsza literatura

  • NVD: opis, wersje, „exploited in the wild” (VI 2015). (NVD)
  • Mandiant/FireEye: Operation Clandestine Wolf, łańcuch ataku, SHOTPUT (APT3). (Google Cloud)
  • SecurityWeek: zero‑day, cele (IE na Win7, Firefox na XP), powiązanie z APT3. (SecurityWeek)
  • Trend Micro: adopcja w exploit kitach (Magnitude). (www.trendmicro.com)
  • Adobe: EOL Flash (31.12.2020). (Adobe)
  • Adobe Flash Player 32 Admin Guide: procesy/plik DLL (FlashUtil*, pepflashplayer.dll). (open-flash.github.io)
  • MITRE ATT&CK: T1189, T1566.002, T1203; wersja v18.0. (MITRE ATT&CK)
  • Microsoft Defender: tabele EmailUrlInfo, UrlClickEvents. (Microsoft Learn)
  • AWS: CloudTrail Data Events, CloudFront/Athena zapytania. (AWS Documentation)

Checklisty dla SOC / CISO

SOC (operacyjne):

  • Włączone telemetry: Sysmon (EID 1/7), proxy/DNS, M365 Defender (EmailUrlInfo/UrlClickEvents).
  • Reguły: Sigma (Flash → cmd/powershell), SPL/KQL/EQL z sekcji 7.
  • Korelacja: klik .swf ↔ procesy Flash ↔ dziecko/egress DNS/HTTP.
  • Blokady: MIME application/x-shockwave-flash, rozszerzenie .swf w bramkach.
  • Hunting retro 30 dni: dzieci procesów Flash i ruch do domen z kampanii (wg TI).

CISO (strategiczne):

  • Potwierdzić brak Flash w organizacji (EOL).
  • Polityka „deny by default” dla wtyczek przeglądarek.
  • Wymuszony Exploit Protection/EDR (M1050/M1040).
  • Szkolenia użytkowników (M1017) z naciskiem na klikalność linków.
  • Gotowość IR: playbook powyżej, retencja logów ≥ 30–90 dni.

Pentest (Test Penetracyjny) — Co To Jest? Kompletny Przewodnik

Co to jest test penetracyjny (pentest)?

Test penetracyjny (ang. penetration test, potocznie pentest) to kontrolowany, celowy atak symulowany na system informatyczny, aplikację lub sieć, przeprowadzany w celu oceny bezpieczeństwa tego systemu. Innymi słowy, jest to zaplanowane “hakowanie” własnej infrastruktury – etyczny atak wykonywany za zgodą właściciela systemu.

Czytaj dalej „Pentest (Test Penetracyjny) — Co To Jest? Kompletny Przewodnik”

Jak Zamienić MITRE D3FEND W Wizualne Mapy Obrony

Dlaczego budujemy mapę obrony z MITRE D3FEND

W świecie cyberbezpieczeństwa Blue Team często korzysta z matrycy MITRE ATT&CK do mapowania taktyk i technik ataków przeciwnika. A co z naszą własną defensywą? Czy potrafimy równie przejrzyście zobrazować, jak broni się nasza organizacja? W tym artykule zobaczymy, jak framework MITRE D3FEND pomaga zbudować wizualną mapę obrony – swoisty dashboard defensywny zespołu SOC. Zamiast domyślać się, gdzie mamy luki, zwizualizujemy techniki obrony tak, by od razu wskazać mocne punkty i obszary wymagające uwagi.

Czytaj dalej „Jak Zamienić MITRE D3FEND W Wizualne Mapy Obrony”

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)

LG Energy Solution potwierdza incydent ransomware w zagranicznym zakładzie. Grupa Akira twierdzi, że ukradła 1,67 TB danych

Wprowadzenie do problemu / definicja luki

LG Energy Solution (LGES), jeden z największych na świecie producentów baterii litowo-jonowych dla pojazdów elektrycznych i magazynów energii, potwierdził atak ransomware na „konkretny zagraniczny zakład”. Spółka poinformowała, że pozostałe lokalizacje, w tym centrala, nie zostały dotknięte, a zaatakowany obiekt wrócił do normalnej pracy po działaniach naprawczych. Firma prowadzi nadal operacje bezpieczeństwa i dochodzenie zapobiegawcze.

Równolegle na serwisach śledzących wycieki pojawiło się przypisanie incydentu do grupy Akira, która utrzymuje, że wykradła około 1,67 TB dokumentów korporacyjnych i ~46 GB baz SQL i grozi publikacją danych. (Twierdzenia przestępców nie zostały niezależnie zweryfikowane przez redakcję w momencie publikacji).

W skrócie

  • Potwierdzenie incydentu: LGES – atak dotyczył jednego zagranicznego zakładu; produkcja przywrócona; trwają działania prewencyjne.
  • Roszczenia przestępców: Grupa Akira przypisuje sobie włamanie i grozi ujawnieniem 1,67 TB danych. (Deklaracje napastników).
  • Szersze tło: Akira jest aktywnie obserwowana przez CISA/FBI/DC3; najnowsza wspólna publikacja ostrzegawcza zawiera aktualne IOC/TTP i zalecenia.
  • Ryzyko sektorowe: potencjalny wpływ na łańcuchy dostaw EV/ESS, dane pracownicze oraz systemy OT/IT w zakładach produkcyjnych. (Wnioski na podstawie charakterystyki ofiar Akiry i praktyk podwójnego wymuszenia).

Kontekst / historia / powiązania

Akira działa od 2023 r., stosując model double-extortion (kradzież + szyfrowanie) i utrzymując serwis wyciekowy w sieci Tor. W 2024–2025 r. operatorzy rozwijali narzędzie szyfrujące (m.in. warianty dla Windows i Linux), a w kampaniach coraz częściej wykorzystują znane luki w VPN/backupach i narzędzia do zdalnego dostępu. Organy rządowe USA (CISA/FBI/DC3/HHS) 6–13 listopada 2025 r. ponownie wydały zaktualizowaną poradę #StopRansomware dedykowaną Akirze po fali ataków.

Analiza techniczna / szczegóły luki

Poniżej syntetyzujemy obecne TTP Akiry wg najnowszych materiałów CISA oraz badań branżowych:

  • Wejście (Initial Access): nadużycia znanych CVE w urządzeniach brzegowych (np. VPN, firewalle), systemach backupu oraz zdalnym zarządzaniu; kampanie phishingowe i nadużycie poświadczeń; obserwowano wykorzystanie luk pokroju CVE-2023-27532 (Veeam), CVE-2024-40766 (SonicWall) oraz podobnych wektorów.
  • Ruch boczny i eskalacja: użycie legalnych RMM (AnyDesk/LogMeIn), RDP, LSASS dump/credential theft; na hostach Linux/ESXi – ukierunkowane szyfrowanie zasobów produkcyjnych i plików VM.
  • Szyfrowanie/utrudnianie odzysku: w nowszych wariantach Windows wykorzystywany jest m.in. algorytm ChaCha8; usuwanie shadow copies i wyłączanie usług backupu skryptami PowerShell.
  • Eksfiltracja i wymuszenie: stały element operacji; publikacja nazw ofiar i porcji danych na stronie wyciekowej jako presja negocjacyjna.

Uwaga: LGES nie potwierdziło publicznie, że elementem ataku było szyfrowanie czy eksfiltracja określonego wolumenu danych – informacje te pochodzą od sprawców i agregatorów wycieków.

Praktyczne konsekwencje / ryzyko

  • Łańcuch dostaw motoryzacji i energii: nawet lokalny incydent w zakładzie ogniw/packów może powodować opóźnienia logistyczne, a w przypadku wycieku – ryzyko ekspozycji dokumentacji jakościowej, BOM-ów, planów testów czy danych partnerów. (Wniosek sektorowy na podstawie profilu LGES).
  • Ryzyko dla danych osobowych: potencjalna ekspozycja danych pracowniczych/kontrahentów zwiększa prawdopodobieństwo phishingu ukierunkowanego i nadużyć tożsamości. (Jeśli potwierdzi się narracja Akiry o bazach SQL).
  • Efekt domina IT/OT: Akira posiada zdolność atakowania środowisk wirtualizacyjnych i backupów, co może komplikować odtwarzanie i forensykę oraz wpływać na ciągłość produkcji.

Rekomendacje operacyjne / co zrobić teraz

Dla producentów i firm z łańcucha dostaw EV/ESS:

  1. Weryfikacja ekspozycji brzegowej: natychmiastowy audyt urządzeń VPN/UTM, firewall (ASA/FTD), SonicWall, bram RDP i serwerów backupu pod kątem znanych CVE wskazywanych w poradach CISA – z potwierdzeniem wersji i dat zastosowania łat.
  2. Segmentacja i „blast radius”: rozdzielenie IT/OT, kontrola ruchu do stref produkcyjnych (PLC/SCADA) i środowisk wirtualnych (ESXi/Hyper-V/AHV); zasada zero trust dla kont serwisowych.
  3. Twardo zaszyte kopie zapasowe: 3-2-1-1 (w tym izolowana, niezmienialna kopia poza domeną AD) + regularne testy odtwarzania; monitorowanie niepożądanych operacji na repozytoriach backupu.
  4. EDR + MDE/Defender for Server: detekcje TTP Akiry (np. wywołania PowerShell usuwające shadow copies, nietypowe RMM, LSASS dump); reguły blokujące narzędzia Living-off-the-Land.
  5. MFA wszędzie + hardening AD: zwłaszcza kont uprzywilejowanych i dostępów zdalnych; kontrola tokenów i polityki Kerberos/NTLM.
  6. IR playbook zgodny z #StopRansomware: gotowe procedury izolacji, triage artefaktów, kontakt z CERT/LE, polityka decyzyjna nt. okupu; mapowanie do IOCs z najnowszej publikacji CISA/FBI/DC3/HHS.

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

  • Akira vs. ALPHV/BlackCat: obie operacje stosują podwójne wymuszenie i szybkie unieruchamianie kopii zapasowych; Akira w 2024–2025 była aktywnie rozwijana (m.in. ChaCha8, Linux/VM/backup focus), a jej kampanie są obecnie przedmiotem świeżych ostrzeżeń wielu agencji. ALPHV była szeroko zakłócana przez organy ścigania pod koniec 2023 r., co jednak nie przełożyło się na trwały spadek aktywności całego ekosystemu RaaS.

Podsumowanie / kluczowe wnioski

  • LGES potwierdziło ograniczony geograficznie incydent ransomware i przywróciło pracę zakładu; pełna skala i charakter (szyfrowanie/wyciek) pozostają przedmiotem dochodzenia.
  • Grupa Akira przypisała sobie atak i grozi publikacją danych – to element presji negocjacyjnej, który wymaga weryfikacji.
  • Organizacje z sektora produkcji baterii/EV/ESS powinny pilnie przejrzeć ekspozycję na wektory wejścia wykorzystywane przez Akirę zgodnie z najnowszymi wskazówkami CISA/FBI/DC3/HHS i wdrożyć techniczne środki utrudniające destrukcję backupów i ruch boczny.

Źródła / bibliografia

  • The Record (Recorded Future News): „LG battery subsidiary says ransomware attack targeted overseas facility”, 18 listopada 2025. (The Record from Recorded Future)
  • Ransomware.live: wpis o ofierze „LG Energy Solution” przypisany do grupy Akira, 17 listopada 2025. (ransomware.live)
  • CISA/FBI/DC3/HHS: #StopRansomware: Akira Ransomware – zaktualizowana porada, 13 listopada 2025 (wersja PDF z IOC/TTP). (CISA)
  • Cisco Talos: „Akira ransomware continues to evolve”, 21 października 2024 – ewolucja wariantów, TTP. (Cisco Talos Blog)
  • IBM X-Force: „Spotlight on Akira ransomware” – podsumowanie taktyk i obserwacji IR. (IBM)

Finger.exe & ClickFix: jak stary protokół Finger (TCP/79) wraca w nowoczesnych atakach

Wprowadzenie do problemu / definicja luki

W najnowszym wpisie SANS ISC zwrócono uwagę, że w kampaniach ClickFix napastnicy znów nadużywają starego, zapomnianego protokołu Finger oraz wbudowanego w Windows klienta finger.exe do pobierania skryptów i komend z Internetu. Finger działa po TCP/79, a klient systemowy nie obsługuje proxy, co bywa kluczowe dla obejścia polityk egress w firmach polegających na explicit proxy. Rezultat: polecenia kopiowane ręką użytkownika (esencja ClickFix) mogą ściągać i uruchamiać payloady z pominięciem części kontroli sieciowych.

W skrócie

  • ClickFix = socjotechnika „zrób to sam”: strona-lurka prowadzi ofiarę do ręcznego uruchomienia polecenia (np. w cmd/PowerShell), które pobiera i uruchamia złośliwy kod. Microsoft opisał wzorzec ataku i jego obejścia zabezpieczeń.
  • W najnowszej odsłonie atakujący używają finger.exe (Windows) do pobrania skryptu przez Finger/TCP 79 – często z serwerów kontrolowanych przez napastnika lub z serwisów skompromitowanych. Temat nagłośnił również BleepingComputer.
  • Finger to stary protokół zdefiniowany w RFC 1288; port nie jest konfigurowalny (zawsze 79/TCP).
  • finger.exe to LOLBIN: narzędzie wbudowane, znane społeczności obronnej i opisane w projekcie LOLBAS – dostępne ścieżki, przypadki nadużyć i reguły Sigma.
  • Dla SOC: patrz sekcja „Rekomendacje” – gotowe KQL/Sigma/Splunk, przykładowe reguły Suricata (TCP/79), blokady AppLocker/WDAC, kontrola egress oraz TTPs do huntów.

Kontekst / historia / powiązania

Technika ClickFix była szeroko opisywana w 2024–2025 jako sposób „ominięcia” części automatów antymalware poprzez włączenie człowieka do łańcucha ataku: ofiara sama kopiuje komendę, która robi „resztę”. To redukuje sygnał detekcyjny (mniej klasycznego „drop & exec”). Microsoft szczegółowo rozebrał ten łańcuch, wskazując m.in. malvertising, fałszywe strony „naprawy błędu” i presję czasu na ofierze. W 2025 r. media branżowe odnotowały odświeżoną falę ataków, m.in. z użyciem Finger.

Analiza techniczna / szczegóły luki

Finger: właściwości protokołu

  • Transport: TCP
  • Port: stały 79/tcp (klient łączy się na 79)
  • Model zapytań: jedna linia zapytania → odpowiedź serwera (RUIP)
  • Brak TLS/uwierzytelniania, mechanizm archaiczny, projektowany do informacji o użytkownikach/hostach.
    Te cechy pochodzą z definicji protokołu w RFC 1288.

finger.exe w Windows jako LOLBIN

  • Lokalizacje: C:\Windows\System32\finger.exe, C:\Windows\SysWOW64\finger.exe.
  • Kluczowa obserwacja obrońców: nie powinien wykonywać się na typowych stacjach końcowych; jego aktywność sieciowa do Internetu to anomalia.
  • W projekcie LOLBAS znajdziesz reguły Sigma i znane nadużycia (np. pobieranie treści jako „komunikatu” finger i pipowanie do interpretera).

Łańcuch ClickFix z użyciem Finger (przykład)

  1. Wejście: phishing/malvertising → landing z instrukcjami „naprawy” (np. „skopiuj to polecenie i wklej do Run/PowerShell”).
  2. Pobranie: finger.exe łączy się do attacker[.]domain:79, pobiera „odpowiedź” zawierającą komendy/payload (np. Base64 PowerShell). SANS ISC zwraca uwagę, że finger.exe nie jest proxy-aware (łatwiej ominąć explicit proxy) i portu 79 nie da się zmienić.
  3. Wykonanie: odpowiedź Finger bywa przekierowana do shella/interpretera (np. | powershell -), co finalnie uruchamia loader/infostealer. O samej fali nadużyć Finger w kampaniach ClickFix informował BleepingComputer.

Uwaga: Finger widziano też jako kanał eksfiltracji/transferu (LOLBIN living-off-the-land) — warto to uwzględnić w hypothesach podczas huntów. (Dobry przegląd ryzyka dają materiały analityczne i praktyka DFIR).

Praktyczne konsekwencje / ryzyko

  • Omijanie egress przez proxy: jeśli organizacja bazuje na explicit proxy i blokuje „direct to Internet”, to brak proxy-awareness w finger.exe powoduje po prostu brak wyjścia — to akurat dobra wiadomość. Jednak w sieciach z transparent proxy lub źle egzekwowanym egress (np. brak deny-all + allow-list) ruch TCP/79 może przejść.
  • Niska widoczność: wiele IDS/NGFW nie obserwuje dziś intensywnie portu 79, bo usługa jest historyczna; to czyni z Finger atrakcyjny kanał niszowy.
  • Living-off-the-land: użycie narzędzia wbudowanego (finger.exe) utrudnia polityki „block-by-default” oparte wyłącznie na hashach/znanych loaderach; trzeba sięgnąć po AppLocker/WDAC, EDR i kontrole kontekstowe.

Rekomendacje operacyjne / co zrobić teraz

1) Szybkie twardnienie (hardening)

Sieć (egress):

  • Jeśli polityka organizacji nie wymaga Finger – zablokuj TCP/79 na brzegu i w segmentach użytkowników (deny-all → allow-list).
  • W transparent proxy/NGFW dodaj reguły blokujące tcp/79 outbound.
  • (Opcjonalnie) NLA: monitoruj jakiekolwiek połączenia do zewnętrznych IP:79 w NetFlow/Zeek.

Endpoint:

  • AppLocker (EXE Rule):
    • Deny dla %WINDIR%\System32\finger.exe i %WINDIR%\SysWOW64\finger.exe w „Unrestricted → Deny unless needed”.
  • WDAC: umieść finger.exe w polityce „Deny-List” (FileNameRule albo podpis/hashe).
  • SRP: „Disallowed” dla ścieżek finger w regułach Additional Rules.

Windows Firewall (host-based) – przykład (cmd jako admin):

netsh advfirewall firewall add rule name="Block Outbound TCP 79 (Finger)" dir=out action=block protocol=TCP localport=any remoteport=79

2) Detekcja — gotowe reguły i zapytania

Sigma (proc creation – finger.exe):

title: Suspicious Use of finger.exe
id: 3d2f2f5a-isc-clickfix-finger
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  sel:
    Image|endswith:
      - '\finger.exe'
  condition: sel
fields:
  - Image
  - CommandLine
  - ParentImage
  - User
  - ComputerName
level: high
tags:
  - attack.command_and_control
  - attack.t1105

(W projekcie LOLBAS znajdziesz też oficjalną regułę Sigma dla finger.exe — zaadaptuj do swojej telemetrii.)

Defender for Endpoint / KQL (wykrycie użycia + ruchu na 79/tcp):

// Procesy finger.exe
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName =~ "finger.exe"
| project Timestamp, DeviceName, InitiatingProcessAccountName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessParentFileName

// Połączenia sieciowe inicjowane przez finger.exe do publicznych IP (port 79)
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName =~ "finger.exe"
| where RemotePort == 79 and RemoteIPType == "Public"
| summarize dcount(RemoteIP) by DeviceName

Splunk (Sysmon EventID=1 + net connection EventID=3):

index=win* (EventCode=1 OR EventCode=3) 
| eval is_finger=if(like(Image,"%\\finger.exe"),1,0)
| search is_finger=1 OR (EventCode=3 dest_port=79 process_name="finger.exe")
| table _time host user Image CommandLine parent_process_name dest_ip dest_port

Suricata (prosty port-based; w praktyce lepiej TLS/JA3/treść, jeśli możliwe):

alert tcp $HOME_NET any -> $EXTERNAL_NET 79 (msg:"Egress Finger protocol (TCP/79)"; flow:to_server,established; classtype:policy-violation; sid:790001; rev:1;)

Zeek (conn.log szybki hunt):

# filter: outbound connections to port 79
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto service | awk '$3==79 && $4=="tcp"'

3) Reagowanie (IR)

  • Izoluj host i zbierz artefakty procesu rodzica finger.exe (kto zainicjował? cmd.exe, powershell.exe, przeglądarka?) oraz stronę/lurkę (artefakty przeglądarki, DNS Cache, Prefetch).
  • Artefakty łańcucha ClickFix: zrzuty schowka, historia RunMRU, TypedPaths, PowerShell Operational (Event ID 4104/4103), Shell-Core (ShellExecute).
  • Blokuj i burnuj: domeny/IP na 79/tcp, usuń reguły wyjątków w proksy/NGFW, zaktualizuj listy blokad w EDR.
  • User awareness: szybki komunikat do użytkowników o NIEKOPIOWANIU poleceń z pop-upów/stron „naprawczych”.

4) Testy kontrolne (Purple Team)

  • W bezpiecznym labie sprawdź, czy finger.exe w ogóle „wyjdzie” na Internet w Twojej sieci (explicit vs transparent proxy).
  • Wygeneruj kontrolowany ruch do hosta testowego na TCP/79 i upewnij się, że alertują: EDR (proc creation), NDR/IDS (port 79), SIEM (korelacja).
  • Przejrzyj atakowy playbook ClickFix z bloga Microsoft — od symulacji malvertising po ręczne wykonanie komendy — i dopasuj własne kontrolki.

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

  • Wcześniej ClickFix częściej polegał na powershell/bitsadmin/certutil czy „curl w PowerShell” — dziś widzimy „egzotyczne” kanały jak Finger. To obniża skuteczność sygnatur i allowlist tworzonych „pod modne TTP”.
  • W przeciwieństwie do bitsadmin lub curl, finger.exe jest rzadko używany w środowiskach korporacyjnych, więc jego anomalia jest bardziej oczywista, ale jednocześnie bywa nieprzefiltrowany w egress.
  • Jako LOLBIN finger.exe pozostaje w tym samym koszyku co inne narzędzia „żyjące na systemie”, ale ma sztywny port 79 i brak proxy-awareness, co daje zarówno wektor obejścia, jak i łatwy wskaźnik do blokady.

Podsumowanie / kluczowe wnioski

  • ClickFix nadal rośnie — powrót do Finger/TCP 79 to sprytne wykorzystanie niszy. Zablokuj 79/tcp, zabroń finger.exe, dołóż telemetrię i hunting na anomalie LOLBIN.
  • Wprowadź kontrolki procesowe (AppLocker/WDAC), korelację proces→sieć, oraz edukację użytkowników przeciwko „kopiuj–wklej”.
  • Od dziś: deny 79/tcp, alert na finger.exe, review egress i proxy, zapytania w SIEM — gotowce masz wyżej.

Źródła / bibliografia

  • SANS ISC Diary — Finger.exe & ClickFix (port 79, brak proxy-awareness, użycie w ClickFix). (SANS Internet Storm Center)
  • Microsoft Security Blog — ClickFix: łańcuch ataku, socjotechnika i obejście zabezpieczeń. (Microsoft)
  • BleepingComputer — nadużycie Finger w kampaniach ClickFix (2025-11). (BleepingComputer)
  • RFC 1288 — specyfikacja protokołu Finger (TCP/79). (IETF Datatracker)
  • LOLBAS — strona Finger.exe (LOLBIN, lokalizacje, detekcje). (lolbas-project.github.io)

Akira ransomware: ponad 250 zaatakowanych organizacji, nowe techniki (SonicWall CVE-2024-40766, Nutanix AHV) i wskazówki obrony [aktualizacja XI 2025]

Wprowadzenie do problemu / definicja luki

Akira to operacja ransomware-as-a-service aktywna od marca 2023 r., stosująca podwójną presję (exfiltracja danych + szyfrowanie). Najnowsza, zaktualizowana 13 listopada 2025 r. porada #StopRansomware (FBI/CISA/DC3/HHS i partnerzy UE) ostrzega, że aktorzy Akira nasilili ataki na infrastrukturę krytyczną oraz rozszerzyli cele szyfrowania na Nutanix AHV (wcześniej: VMware ESXi i Hyper-V), często po włamaniu przez urządzenia brzegowe SonicWall z wykorzystaniem CVE-2024-40766 oraz luk w Veeam Backup & Replication. Porada szacuje też, że do końca września 2025 r. Akira zgarnęła ~244 mln USD w okupach.

W skrócie

  • Skala: od początku działalności >250 celów (stan na I 2024 r.; dziś licznik jest wyższy), a łączne wpływy z okupów sięgnęły ~244 mln USD (IX 2025).
  • Wejście: nadużycia SSL VPN / SonicWall (CVE-2024-40766), słabe/MFA-less VPN, wycieki/kradzież haseł i OTP seedów, luki w Veeam; okazjonalnie spear-phishing i RDP/SSH.
  • Nowości 2025: szyfrowanie Nutanix AHV VMDK, obejście ochron VMDK i kradzież NTDS.dit, częstsze użycie AnyDesk/LogMeIn i tuneli Ngrok do C2, BYOVD do wyłączania EDR/AV.
  • Kryptografia/warianty: ewolucja do Akira_v2 (Linux/ESXi), epizodyczny „Megazord” (Rust, rozszerzenie .powerranges), u części wariantów ChaCha8 dla szybkości.

Kontekst / historia / powiązania

W 2023 r. Akira startowała na Windows (rozszerzenie .akira), a od kwietnia 2023 r. pojawiły się warianty Linux/ESXi. W sierpniu 2023 r. obserwowano użycie Megazord (Rust). Raporty incident-response z 2023/2024 opisywały też „exfil-only” – wymuszanie okupu wyłącznie kradzionymi danymi bez ryzyka detekcji typowej dla masowego szyfrowania. W 2024 r. Cisco Talos notował przejście do ChaCha8 (pragmatyka: szybsze szyfrowanie). Akira ma też powiązania nomenklaturowe z kontynuacją ekosystemu Conti (AIV).

Analiza techniczna / szczegóły luki

Wektory wejścia (Initial Access)

  • VPN bez odpornych na phishing MFA oraz słabe hasła; password spraying narzędziami pokroju SharpDomainSpray.
  • SonicWall SSLVPN – CVE-2024-40766 (Improper Access Control) – dodane do CISA KEV IX 2024; nadal wykorzystywane w 2025 r. (niekiedy z błędami w konfiguracji LDAP/MFA i publicznym dostępem do Virtual Office).
  • Veeam Backup & Replication – m.in. CVE-2023-27532 i CVE-2024-40711 (deserializacja), używane do eskalacji i dostępu do backupów.
  • SSH / routery brzegowe (pivot po tunelowaniu), IAB (Initial Access Brokers).

Eskalacja, ruch boczny, C2

  • Tworzenie kont itadm i dodawanie do Administrators, zrzut NTDS.dit poprzez „podmianę” VMDK DC i montaż w nowej VM (następnie kradzież krbtgt/DA).
  • AnyDesk / LogMeIn dla utrzymania i maskowania; Ngrok do C2; Impacket (wmiexec).
  • BYOVD (np. sterownik Zemana AntiMalware) + PowerTool do zabijania EDR/AV.

Szyfrowanie i platformy wirtualizacji

  • ESXi i Hyper-V były celem od 2023 r.; w VI 2025 odnotowano Nutanix AHV (VMDK/AHV-disk). Ważne: nie jest to podatność Nutanixa – wektor to SonicWall, po czym atakujący szyfrują dyski VM.

Kryptografia / warianty

  • Akira (C++) – rozszerzenie .akira;
  • Megazord (Rust) – rozszerzenie .powerranges;
  • Akira_v2 / Linux – nowe rozszerzenia, optymalizacja (m.in. ChaCha8).

Praktyczne konsekwencje / ryzyko

  • Szybkie tempo ataków – w skrajnych przypadkach exfiltracja danych w kilka godzin od wejścia; dla SOC oznacza to krótkie MTTD/MTTR okna i konieczność monitoringu 24/7.
  • SMB pod presją – priorytetowe cele wg FBI/CISA to małe i średnie firmy, ale ucierpiały też duże podmioty z produkcji, edukacji, IT, ochrony zdrowia i finansów.
  • Ryzyko błędnej atrybucji – „Nutanix AHV” w nagłówkach to skutek, nie przyczyna; błędna komunikacja grozi nieadekwatnymi działaniami naprawczymi.

Rekomendacje operacyjne / co zrobić teraz

1) Redukcja ekspozycji

  • SonicWall: zweryfikuj i wdroż natychmiast poprawki CVE-2024-40766; ogranicz dostęp SSLVPN/Virtual Office do zaufanych sieci; wymuś phishing-resistant MFA (FIDO2/WebAuthn), wyłącz TOTP tam, gdzie to możliwe.
  • Veeam: załataj CVE-2023-27532 / CVE-2024-40711, odseparuj serwer kopii i repozytoria (air-gapped/immutable).
  • VPN: wymuś MFA odporną na phishing, deny-all na portale samoobsługowe, rotacja haseł/OTP seedów po incydentach (podejrzenie kradzieży tajników MFA).

2) Twardnienie AD / wirtualizacji

  • Kontrolery domen: LSA Protection, izolacja DC, monitoring dostępu do plików VMDK DC i prób montażu poza VM.
  • Hypervisor: audyt uprawnień do datastore, „two-person rule” dla operacji na dyskach VM, backupy immutable.

3) Detekcja (przykładowe reguły/Sigma i zapytania)

Windows (Sysmon/EDR):

title: Akira - BYOVD Zemana/PowerTool
logsource: { category: driver_load, product: windows }
detection:
  sel:
    ImageLoaded|endswith: '\zamguard64.sys'
  condition: sel
level: high
tags: [attack.defense_evasion,T1562.001]

Anomalie C2/Tunnel (Ngrok):

title: Suspicious Ngrok Tunnel
logsource: { category: network_connection, product: windows }
detection:
  sel:
    DestinationHostname|contains: 'ngrok'
  condition: sel
level: medium
tags: [attack.command_and_control,T1572]

WMI/Impacket:

title: Impacket wmiexec-like Behavior
logsource: { category: process_creation, product: windows }
detection:
  sel:
    CommandLine|contains|all:
      - 'wmic'
      - 'process call create'
  condition: sel
level: medium
tags: [attack.lateral_movement,T1021.001]

Splunk – szybki hunt „AnyDesk/LogMeIn po VPN”:

index=firewall (app=sslvpn OR app=vpn) | stats count by src_ip user
| join user [ search index=edr (process=AnyDesk.exe OR process=LogMeIn.exe) 
| stats earliest(_time) as firstSeen by user ]
| where firstSeen - _time < 3600

4) Reakcja i odzyskiwanie

  • Procedura „isolate-then-triage”, snapshoty/backupy offline, test odtwarzania co sprint.
  • Komunikacja kryzysowa, w tym analiza ryzyka publikacji danych (DLS) i notyfikacje prawne.
  • Zgłaszaj incydenty do CERT/CSIRT oraz IC3/CISA; stosuj listę kontrolną CPG.

Różnice / porównania z innymi przypadkami

  • LockBit: większy ekosystem i „franczyza”, ale obecnie pod presją organów ścigania; Akira nadrabia zwinnością, w 2024 r. była jedną z najczęściej spotykanych w IR/MDR (wg Sophos).
  • Clop: dominowało exfil-only na aplikacje web (MOVEit), Akira łączy exfiltrację z klasycznym „węzłem noża” (szyfrowanie VM i backupów).

Podsumowanie / kluczowe wnioski

  1. Edge first: SonicWall/SSLVPN i Veeam to w 2025 r. praktyczne „drzwi wejściowe”.
  2. Wirtualizacja pod ostrzałem: poza ESXi i Hyper-V atakujący skutecznie szyfrują dyski Nutanix AHV, co wymusza twardnienie warstwy hypervisora i datastore.
  3. Czas reakcji liczy się w godzinach – wdroż MDR/24×7 lub równoważne pokrycie.
  4. MFA odporna na phishing + rotacja tajników to dziś must-have.
  5. Nie wierz nagłówkom: „problem Nutanixa” to w istocie błąd/konfiguracja na brzegu, a dopiero potem wpływ na VM.

Źródła / bibliografia

  1. FBI/CISA/DC3/HHS – #StopRansomware: Akira Ransomware (aktualizacja 13.11.2025) – pełne TTP/IOC, nowe techniki (Ngrok, AnyDesk/LogMeIn), szyfrowanie Nutanix AHV, kwota okupu ~244,17 mln USD. (Internet Crime Complaint Center)
  2. Cisco Talos – „Akira ransomware continues to evolve” (ChaCha8, nowe rozszerzenia Linux). (Cisco Talos Blog)
  3. Sophos – „Akira, again: The ransomware that keeps on taking” (trend exfil-only jako presja bez szyfrowania). (Sophos News)
  4. Rapid7 – CVE-2024-40766 (SonicWall SSLVPN Improper Access Control) i ostrzeżenia dot. kampanii Akira na urządzeniach SonicWall. (Rapid7)
  5. Nutanix – wyjaśnienie: brak błędu w AHV; problem zaczyna się na urządzeniach brzegowych (SonicWall), a efektem jest szyfrowanie dysków VM. (nutanix.com)

Uwaga kontekstowa: liczba „>250 organizacji” pochodzi z raportów z początku 2024 r. (Arctic Wolf i komunikaty dot. pierwszej wersji porady FBI/CISA). Dzisiejsza skala jest większa; najnowszy dokument rządowy koncentruje się na kwocie okupu (~244 mln USD) i nowych technikach, zamiast podawać bieżący licznik ofiar.