Archiwa: Phishing - Strona 81 z 98 - Security Bez Tabu

Tag: Phishing

Prokurator Generalny Pensylwanii potwierdza wyciek danych po ataku INC Ransom — co wiemy i co robić

Wprowadzenie do problemu / definicja luki

Biuro Prokuratora Generalnego stanu Pensylwania (Office of Attorney General, OAG) potwierdziło, że po sierpniowym ataku ransomware doszło do nieautoryzowanego dostępu do plików zawierających dane osobowe i medyczne. W komunikacie wskazano, że dla części osób ujawnione informacje mogą obejmować imię i nazwisko, numer Social Security (SSN) i/lub dane medyczne. OAG uruchomiło dedykowaną infolinię dla poszkodowanych (1-833-353-8060).

W skrócie

  • Incydent wykryto 9 sierpnia 2025 r.; początkowo sparaliżował stronę WWW, pocztę i telefony OAG.
  • OAG odmówiło zapłaty okupu; we wrześniu potwierdzono, że był to atak ransomware.
  • Grupa INC Ransom przypisała sobie atak i twierdzi, że wykradła 5,7 TB danych (roszczenie sprawców).
  • Niezależni badacze łączyli możliwy wektor wejścia z publicznie wystawionymi urządzeniami Citrix NetScaler podatnymi na CVE-2025-5777 („CitrixBleed 2”) — to hipoteza, nie potwierdzenie OAG.

Kontekst / historia / powiązania

BleepingComputer opisał 17 listopada 2025 r., że OAG potwierdziło naruszenie danych po sierpniowym ataku oraz wcześniejszą odmowę zapłaty okupu. We wrześniu urząd informował o trwającej niedostępności usług i o tym, że incydent nie powinien wpływać na prowadzone postępowania.

Równolegle, 20–23 września, INC Ransom dodało wpis o OAG na swojej stronie wyciekowej i opublikowało próbki rzekomo skradzionych dokumentów; media branżowe opisały roszczenie sprawców i wspomniały o 5,7 TB danych. OAG wówczas nie potwierdziło skali exfiltracji.

Analiza techniczna / szczegóły luki

  • Możliwy wektor: CitrixBleed 2 (CVE-2025-5777). Według doniesień prasowych i wpisów badaczy, w infrastrukturze OAG miały znajdować się publicznie dostępne urządzenia Citrix NetScaler podatne na CVE-2025-5777, nazwane „CitrixBleed 2” ze względu na podobieństwo do CitrixBleed z 2023 r. (CVE-2023-4966). Uwaga: OAG nie wskazało oficjalnie wektora ataku.
  • Charakterystyka CVE-2025-5777. To błąd prowadzący do odczytu pamięci i przechwycenia sesji w NetScalerach, aktywnie wykorzystywany w 2025 r.; podatność została szeroko opisana w materiałach producenta i firm bezpieczeństwa. (Kontekst i nazewnictwo wg Tenable).
  • TTP INC Ransom. Grupa działa w modelu RaaS od lipca 2023 r., stosuje podwójny wymus (szyfrowanie + exfiltracja/wyciek), wykorzystuje phishing oraz eksploatację znanych luk (w przeszłości m.in. w NetScaler).

Praktyczne konsekwencje / ryzyko

  • Ryzyko kradzieży tożsamości: wyciek SSN i danych medycznych zwiększa prawdopodobieństwo otwierania fałszywych kont, refund fraud w ochronie zdrowia oraz ukierunkowanych kampanii socjotechnicznych. (Zakres danych wg OAG).
  • Długotrwały wpływ operacyjny: nawet po przywróceniu usług, sprawcy mogą wykorzystywać wykradzione informacje do wtórnych ataków (impersonacja urzędników/prawników, spear-phishing). (Roszczenia o 5,7 TB to nadal twierdzenie przestępców).

Rekomendacje operacyjne / co zrobić teraz

Dla obywateli Pensylwanii potencjalnie dotkniętych incydentem:

  1. Skontaktuj się z infolinią OAG (1-833-353-8060) w godzinach 08:00–20:00 ET w dni robocze; sprawdź, czy Twoje dane dotyczące tożsamości/zdrowia mogły być w plikach.
  2. Zamrożenie kredytu (credit freeze) i alert fraudowy u biur kredytowych; monitorowanie raportów kredytowych przez minimum 12–24 mies.
  3. Ostrożność wobec phishingu: spodziewaj się prób podszywania się pod OAG, sądy, ubezpieczycieli.
  4. Monitoruj świadczenia zdrowotne (Explanation of Benefits) i żądaj korekt nadużyć.

Dla organizacji publicznych i przedsiębiorstw:

  1. Natychmiastowa walidacja ekspozycji NetScaler/Edge: jeżeli używasz Citrix NetScaler/ADC/Gateway — potwierdź wersję i zaaplikuj poprawki/mitigacje dla CVE-2025-5777; unieważnij sesje, rotuj ciasteczka/sekrety, wymuś ponowne logowanie.
  2. Hunting po wskaźnikach przejęcia sesji (nietypowe logowania, zmiany IP w aktywnych sesjach, brak MFA-promptów); sprawdź logi WAF/VPN.
  3. Segregacja i hardening systemów prawniczych/archiwów (dostęp wg zasady najniższych uprawnień, SSO z MFA odporne na phishing, DLP).
  4. Plan na wycieki danych: gotowe szablony notyfikacji, kontrakty na monitoring tożsamości dla poszkodowanych, playbook komunikacji kryzysowej.
  5. Testy odtwarzania i tabletop dla scenariusza „podwójnego wymuszenia” (negocjacje ≠ płatność; polityka „no-pay” + koordynacja z LE).

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

To kolejny poważny incydent ransomware wobec instytucji stanowych w Pensylwanii w ostatnich latach (2017, 2020). W odróżnieniu od minionych spraw, obecny atak wpisuje się w falę nadużyć CitrixBleed 2 przeciw urządzeniom brzegowym oraz trend masowej exfiltracji danych przed szyfrowaniem (double extortion).

Podsumowanie / kluczowe wnioski

  • Fakt: OAG potwierdziło wyciek danych i uruchomiło ścieżkę wsparcia dla obywateli.
  • Fakt: Atak miał charakter ransomware, a okup nie został zapłacony.
  • Roszczenie sprawców: INC Ransom przypisuje sobie kradzież 5,7 TB danych — tego OAG nie potwierdziło.
  • Hipoteza badaczy: możliwy wektor to CVE-2025-5777 / CitrixBleed 2 na NetScaler — wymaga traktowania jako priorytetowej poprawki i unieważnienia sesji.

Źródła / bibliografia

  1. BleepingComputer — „Pennsylvania AG confirms data breach after INC Ransom attack”, 17 listopada 2025. (BleepingComputer)
  2. PR Newswire / OAG — „Media Notice: Pennsylvania Office of Attorney General Provides Notice of Data Incident”, 14 listopada 2025. (PR Newswire)
  3. BleepingComputer — „Pennsylvania AG Office says ransomware attack behind recent outage”, 2 września 2025. (BleepingComputer)
  4. Tenable — „FAQ o CVE-2025-5777 (CitrixBleed 2)”, 27 czerwca 2025. (Tenable®)
  5. Comparitech — „Ransomware gang says it hacked Pennsylvania’s Attorney General”, 22 września 2025. (Comparitech)

Holenderska policja przejęła 250 serwerów „bulletproof hostingu”. Co to oznacza dla cyberprzestępców i obrońców?

Wprowadzenie do problemu / definicja luki

Policja w Niderlandach (Politie) poinformowała, że 12 listopada 2025 r. przejęła infrastrukturę złożoną z ok. 250 fizycznych serwerów należących do dostawcy tzw. bulletproof hostingu. Usługodawca reklamował pełną anonimowość i brak współpracy z organami ścigania; jego zasoby były wykorzystywane wyłącznie do działalności przestępczej (ransomware, botnety, phishing, a nawet dystrybucja materiałów CSAM). Serwery stały w Hadze i Zoetermeer, a ich zajęcie wyłączyło tysiące serwerów wirtualnych obsługiwanych na tej infrastrukturze.

W skrócie

  • Data operacji: 12 listopada 2025 r.; komunikat policji: 14 listopada 2025 r.
  • Skala: ~250 serwerów fizycznych; skutkowe wyłączenie tysięcy VM.
  • Miejsca: data centers w Hadze i Zoetermeer.
  • Historia sprawy: hoster przewijał się w >80 postępowaniach od 2022 r.
  • Aresztowania: na tym etapie brak informacji o zatrzymaniach.
  • Identyfikacja dostawcy: nazwa nieujawniona; media łączą sprawę z CrazyRDP (informacja niepotwierdzona przez Policję).
  • Powiązania z Operacją Endgame: równoległe działania w NL (przeszukania, 83 serwery i 20 domen) – sprawy są rozłączne według Policji cytowanej przez BleepingComputer.

Kontekst / historia / powiązania

„Bulletproof hosting” to segment usług, w którym operatorzy celowo ignorują abuse i wnioski o usunięcie treści, nie egzekwują KYC, dopuszczają płatności krypto i promują anonimowość klientów. Tego typu platformy są ekosystemowym „multiplikatorem” dla kampanii ransomware, phishingu, C2 botnetów i baz wykradzionych danych. Opisywany hoster działał co najmniej od 2022 r., a jego zasoby pojawiały się w wielu dochodzeniach zarówno w NL, jak i za granicą.

W tym samym tygodniu Europol ogłaszał kolejny etap Operation Endgame (ponad 1 025 serwerów zaburzeń/zdjętych globalnie, 20 domen, 11 przeszukań, w tym 9 w NL), jednak niderlandzka Policja – za pośrednictwem BleepingComputer – wskazała, że te dwa wątki nie są ze sobą połączone.

Analiza techniczna / szczegóły luki

  • Warstwa fizyczna i wirtualna: zajęto ~250 „metalowych” serwerów, co „kaskadowo” wyłączyło tysiące instancji wirtualnych (VPS/RDP), typowych dla tanich, łatwo skalowalnych hostów wybieranych przez przestępców.
  • Model usługowy: oferta bez-KYC, „no-logs”, akceptacja krypto – minimalizuje ślady transakcyjne, utrudniając atrybucję.
  • Profil użycia: C2 dla botnetów, infrastrukturę phishingową, staging malware i – w skrajnych przypadkach – CSAM. To mieszanka, którą Policja wprost przypisała temu hosterowi.
  • (Nie)ujawniona tożsamość: BleepingComputer wskazuje na CrazyRDP na podstawie źródeł i obserwacji (m.in. nagłe czyszczenie kanału Telegram, skargi klientów), lecz bez potwierdzenia organów – stąd należy traktować to jako hipotezę, nie fakt.

Praktyczne konsekwencje / ryzyko

  • Zakłócenie kampanii: odcięcie tysięcy VM to natychmiastowe przerwanie wielu łańcuchów ataku (hosting payloadów, panele C2, landing pages). Krótkoterminowo można oczekiwać spadku wolumenu z danego ekosystemu.
  • Efekt rozproszenia: operatorzy przestępczy zwykle migrują do alternatywnych hosterów lub budują nową infrastrukturę – jednak koszt, czas i ryzyko ekspozycji rosną. (Wątek ten potwierdza praktyka obserwowana przy równoległej Operacji Endgame).
  • Ryzyko wtórne dla legalnych klientów DC: doniesienia lokalnych mediów i społeczności NL sugerują, że akcja dotyczyła konkretnych klientów kolokacyjnych, a nie całych obiektów; mimo to incydenty tego typu mogą chwilowo dotknąć współlokatorów (np. zajęcie błędnie zidentyfikowanych maszyn).

Rekomendacje operacyjne / co zrobić teraz

  1. Hunting & telemetry:
    • Przejrzyjcie ostatnie DNS/HTTP egress i połączenia do instancji w NL (The Hague/Zoetermeer), które nagle „zamilkły” po 12.11 – to potencjalne wskaźniki wcześniejszego C2/hostingów.
    • Korelujcie alerty „orphaned beacons” w EDR/NDR po nagłym zniknięciu serwerów C2.
  2. Blokady sieciowe:
    • Tymczasowe sinkhole/blackhole dla znanych zakresów AS-ów i adresacji powiązanych z wyłączoną infrastrukturą (gdy tylko pojawią się IOCs z dochodzenia – śledźcie komunikaty Policji/Europolu).
  3. Phishing & web defense:
    • Zaostrzyć WAF/anty-phishing dla świeżych domen i tanich TLD; hosterzy bulletproof często rotują „jednodniowe” domeny i certyfikaty DV.
  4. Procesy wewnętrzne:
    • Aktualizujcie playbooki IR o scenariusz „masowe wyłączenie C2 u dostawcy”, aby szybciej identyfikować „martwe” kanały i zastępować je detekcjami host-based.
  5. Threat intel:
    • Monitorujcie komunikaty Policji NL oraz źródła branżowe (BleepingComputer, Tweakers, NL Times) pod kątem publikacji zakresów IP/AS, hashy i domen wynikłych z analizy powłamaniowej przejętej infrastruktury.

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

W lutym 2025 r. holenderska Policja wyłączyła 127 serwerów należących do innego bulletproof hostera (ZServers), co odbywało się pod parasolem sankcji–dochodzeń międzynarodowych. Obecna akcja jest większa na poziomie skutku (tysiące VM) i dotyczy innego podmiotu; dodatkowo – w odróżnieniu od wątków Endgame – Policja podkreśla brak powiązania między obiema historiami.

Podsumowanie / kluczowe wnioski

  • Trafione węzły infrastruktury przestępczej mają realny, natychmiastowy efekt na wolumen kampanii.
  • Tożsamość hostera nie została oficjalnie ujawniona; łączenie z konkretnymi markami (np. CrazyRDP) pozostaje niepotwierdzone.
  • Obrońcy powinni wykorzystać okno obserwowalności (nagłe wyciszenie C2/hostingów) do huntingu i aktualizacji detekcji.
  • Ekosystem przestępczy ma tendencję do odbudowy – kluczowa jest szybkość publikacji i konsumpcji IOC oraz współpraca z LE.

Źródła / bibliografia

  • Komunikat Policji NL (14.11.2025): szczegóły operacji, skala (250 fiz.), lokalizacje, >80 spraw od 2022 r. (Politie)
  • BleepingComputer (17.11.2025): podsumowanie akcji, rozróżnienie względem Endgame, wątek CrazyRDP (niepotwierdzony). (BleepingComputer)
  • Tweakers (14.11.2025): lokalne uzupełnienia nt. datacenter i przebiegu. (Tweakers)
  • NL Times (14.11.2025): potwierdzenia (brak aresztowań, >80 spraw), „thousands of virtual servers”. (NL Times)
  • Europol – Operation Endgame (listopad 2025): tło równoległej operacji (1 025 serwerów, 20 domen). (Europol)

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)

Microsoft Patch Tuesday — listopad 2025. Zero-day w jądrze Windows (CVE-2025-62215), krytyczne RCE (GDI+) i poprawki dla Office, SQL, WSL

Wprowadzenie do problemu / definicja luki

Microsoft opublikował listopadowy pakiet poprawek zabezpieczeń obejmujący 63 luki (CVE) w Windows i komponentach ekosystemu (Office, Edge (Chromium), Azure Monitor Agent, Dynamics 365, Hyper-V, SQL Server, WSLg itd.). Wśród nich znajduje się jeden zero-day aktywnie wykorzystywany – CVE-2025-62215 (eskalacja uprawnień w jądrze Windows), a także kilka krytycznych RCE (m.in. GDI+ CVE-2025-60724) oraz podatności dotykających workflow deweloperskich i rozszerzeń z obszaru Copilot/Agentic AI.

W skrócie

  • Skala: 63 CVE (wg ZDI/Tenable). 4–5 CVE ocenionych jako Critical, reszta Important.
  • Zero-day: CVE-2025-62215 – Windows Kernel EoP (wyścig zdarzeń/race condition). Wymaga lokalnego dostępu, ale często łączony z RCE w łańcuchu ataku. Priorytet 1 do patchowania.
  • Krytyczne RCE:
    • CVE-2025-60724 (GDI+) – CVSS 9.8, możliwa zdalna eksploatacja przez przetwarzanie specjalnie spreparowanych plików/metafili; ryzyko dla usług parsujących dokumenty bez interakcji użytkownika.
    • CVE-2025-62199 (Office) – RCE; „Preview Pane jako wektor” (ostrożnie: Microsoft wskazuje wymaganą interakcję użytkownika).
  • Inne istotne: Azure Monitor Agent RCE (CVE-2025-59504), WSLg RCE (CVE-2025-62220), DirectX/CLFS EoP, podatności CoPilot/Agentic AI (RCE/SFB, np. CVE-2025-62222).
  • Produkcyjne wskazówki: szybkie wdrożenie aktualizacji, czasowe wyłączenie Preview Pane w Outlook/Explorer, izolacja pracy z plikami Office, aktualizacja AMA/WSLg z linii poleceń, kontrola polityk makr i niepodpisanych rozszerzeń VS/VS Code. (Dowody w sekcjach niżej).

Kontekst / historia / powiązania

W październiku 2025 Microsoft łatał rekordowe 172 luki, w tym kilka aktywnie wykorzystywanych. Listopad przynosi wyraźne uspokojenie liczby CVE, ale charakter błędów (kernel EoP, GDI+ 9.8, Office/Preview Pane, elementy chmury/agentów) sprawia, że ich priorytet operacyjny pozostaje wysoki. Różne serwisy raportują rozbieżne liczby (63/66/68/80) – wynika to m.in. z uwzględniania/nie uwzględniania CVE chromium/Edge, komponentów zewnętrznych i aktualizacji dokumentacyjnych. Najbardziej spójne i techniczne podsumowania dla adminów publikują ZDI i Tenable – w tym materiale opieramy się głównie na nich oraz na przeglądzie Briana Krebsa.

Analiza techniczna / szczegóły luki

1) Zero-day: CVE-2025-62215 — Windows Kernel EoP (race condition)

  • Typ: Elevation of Privilege (lokalne, wymaga uwierzytelnienia).
  • Opis: warunek wyścigu w jądrze Windows, pozwalający atakującemu „wygrać” przełączenie stanu i uzyskać SYSTEM.
  • Zastosowanie w praktyce: łączone z RCE (phishing/dokument/serwis www) → post-exploitation: trwała eskalacja i obejście EDR przez uruchamianie implantów z uprawnieniami jądra/procesu krytycznego.
  • Status: aktywnie wykorzystywana w środowisku (zero-day). CVSS v3: 7.0, Important (niska zdalność, wysoka waga po połączeniu).

Wskazówka laboratoryjna (blue team): w telemetrii EDR szukaj anomalii w przełączaniu integrities (Low/Medium → SYSTEM), nietypowych uchwytów do urządzeń jądra i „daisy-chain” tuż po uruchomieniu niepodpisanego binarium z katalogów tymczasowych.

2) CVE-2025-60724 — GDI+ RCE (CVSS 9.8)

  • Wektor: przetwarzanie specjalnie spreparowanych metafili/obrazów (GDI+).
  • Ryzyko: potencjalna eksploatacja bez interakcji po stronie usług, które parsują dokumenty (np. previewer, usługi konwersji/ekstrakcji metadanych, serwerowe procesory plików).
  • Dlaczego istotne: GDI+ bywa bramką do RCE w aplikacjach serwerowych oraz pecetach skanujących pliki przychodzące (DLP, AV, indeksowanie).

Higiena: sandboxing parserów dokumentów i ograniczenie uprawnień kont usługowych wykonujących podgląd/konwersję.

3) CVE-2025-62199 — Microsoft Office RCE (Preview Pane)

  • Fakt kluczowy: Preview Pane wskazany jako wektor; jednocześnie Microsoft opisuje wymóg interakcji użytkownika (niespójność noty). Praktycznie: rozważ wyłączenie podglądu w Outlook/Explorer do czasu wdrożenia poprawek.

GPO (wyłączenie podglądu w Outlook):

Windows Registry Editor Version 5.00
; Outlook – wyłącz okienko podglądu
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences]
"ReadingPaneOptions"=dword:00000000

(W środowiskach korporacyjnych preferuj ADMX/Group Policy zamiast pojedynczych wpisów rejestru.)

4) Azure Monitor Agent (AMA) — RCE (CVE-2025-59504)

  • Charakter: nieuwierzytelnione RCE możliwe do wywołania z sieci przy podatnej konfiguracji.
  • Znaczenie: AMA jest szeroko stosowany w zbieraniu logów/telemetrii; kompromitacja może dać pivot do zasobów IaaS/serwerów hybrydowych.
  • Działanie: aktualizacja agenta i walidacja ekspozycji portów.

Aktualizacja AMA z linii poleceń (Windows):

# Aktualizacja rozszerzenia Azure Monitor Agent na VM z Azure (Az module)
$vm = Get-AzVM -Name "prod-app-01" -ResourceGroupName "RG-Prod"
Set-AzVMExtension -ResourceGroupName $vm.ResourceGroupName -VMName $vm.Name `
  -Name "AzureMonitorWindowsAgent" -Publisher "Microsoft.Azure.Monitor" `
  -Type "AzureMonitorWindowsAgent" -TypeHandlerVersion "1.29" -AutoUpgradeMinorVersion $true

5) WSLg — Windows Subsystem for Linux GUI RCE (CVE-2025-62220)

  • Opis: RCE w komponencie GUI WSL. Wymaga interakcji użytkownika (otwarcie przygotowanego pliku/akcji).
  • Patchowanie: aktualizacja WSL z poziomu wiersza poleceń (poza klasycznym Windows Update).

Aktualizacja WSL:

wsl.exe --update
wsl.exe --status

6) DirectX / CLFS — kolejne EoP

  • DirectX (EoP) i CLFS (EoP): historycznie CLFS bywało wielokrotnie wykorzystywane przez ransomware i APT do podniesienia uprawnień. Nie są oznaczone jako „exploited”, ale to wysoki priorytet twardnienia.

7) Copilot / Agentic AI / VS Code — RCE i SFB (np. CVE-2025-62222)

  • Trend: pierwsze wzmianki o lukach określanych jako dotyczące „Agentic AI” i integracji narzędzi deweloperskich.
  • Ryzyko: remote code execution na repozytoriach ofiary połączone ze spoofingiem/prompt-injection i niewystarczającą walidacją wygenerowanych artefaktów.
  • Reakcja: wymuś review i podpisywanie rozszerzeń/agentów, ogranicz automatyczne wykonywanie skryptów generowanych przez narzędzia asystujące.

Praktyczne konsekwencje / ryzyko

  • Łańcuchy ataku „phish → RCE → kernel EoP”: CVE-2025-62199 (Office/Preview Pane) lub CVE-2025-60724 (GDI+) daje inicjalny kod, CVE-2025-62215 zapewnia SYSTEM i trwałość.
  • Ryzyko serwerowe: serwisy przetwarzające pliki (skanery, konwertery, DLP, podglądy) narażone na GDI+ 9.8; hosty z AMA eksponowane na sieć — RCE bez auth.
  • DevSecOps: IDE/VS/VS Code i rozszerzenia Copilot/Agentic AI — nowy wektor: supply-chain w procesie developerskim.

Rekomendacje operacyjne / co zrobić teraz

1) Patch management (priorytet A — 24/48 h):

  • Windows/Office/SQL/WSLg/AMA na wszystkich hostach. Zacznij od systemów z ekspozycją internetową oraz stacjach z wysokim ryzykiem (helpdesk, finanse, GRC).

2) Twardnienie pod „Preview Pane”:

  • Tymczasowo wyłącz Preview Pane (Outlook/Explorer) polityką.
  • Zastosuj MOTW enforcement i politykę blokady makr z Internetu. (Microsoft od miesięcy promuje ten kierunek).
  • Włącz Protected View i otwieranie w trybie „Application Guard for Office”, jeśli licencje pozwalają.

3) Segmentacja parserów i usług plikowych:

  • Sandboxy dla serwisów podglądu/przetwarzania dokumentów; AppContainer/WDAC na hostach skanujących.
  • Uruchamiaj parsery na kontach niskoprzywilejowych z ograniczonym dostępem do sieci.

4) WSLg i AMA:

  • WSL: wsl.exe --update w zadaniu harmonogramu po patchach OS.
  • AMA: zaktualizuj rozszerzenie na VM w Azure i zweryfikuj reguły NSG — AMA nie powinien być bezpośrednio osiągalny z Internetu.

5) Dev tooling (VS/VS Code/Copilot):

  • Wymuś Allow-listę rozszerzeń, podpisy i minimalne wersje; odetnij uruchamianie skryptów z nieufnych źródeł (Set-ExecutionPolicy AllSigned).
  • Edukuj devów o prompt-injection i zasadzie „review przed run”.

6) Detections/telemetria (przykłady KQL/PowerShell):

  • Wzorzec EoP po RCE (pliki tymczasowe → SYSTEM) – Microsoft Defender for Endpoint (KQL):
DeviceProcessEvents
| where InitiatingProcessIntegrityLevel in ("Low","Medium")
| where ProcessIntegrityLevel == "System"
| where Timestamp > ago(3d)
| summarize count(), any(ProcessCommandLine) by DeviceName, InitiatingProcessFileName, ProcessName
  • Podejrzane preview/parsowanie plików Office:
DeviceFileEvents
| where Timestamp > ago(3d)
| where FileName matches regex @"\.(docx|xlsx|rtf|emf|wmf)$"
| where InitiatingProcessFileName in ("splwow64.exe","mspreview.exe","prevhost.exe","outlook.exe")
| summarize count() by DeviceName, InitiatingProcessFileName, FileName
  • Odnalezienie stacji z włączonym okienkiem podglądu (Outlook) – zapytanie PowerShell/Remoting, raport do CSV:
$computers = Get-ADComputer -Filter * | Select-Object -Expand Name
$results = foreach($c in $computers){
  Invoke-Command -ComputerName $c -ScriptBlock {
    Get-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Outlook\Preferences" `
      -Name ReadingPaneOptions -ErrorAction SilentlyContinue
  } | Select-Object PSComputerName, ReadingPaneOptions
}
$results | Export-Csv .\outlook_previewpane_status.csv -NoTypeInformation

Różnice / porównania z innymi przypadkami

  • Mniej CVE vs. październik 2025, ale większa „jakość” ryzyka: zero-day w kernelu, GDI+ 9.8, łańcuchy z Office/Preview i elementy agentów/AI.
  • Rozbieżności liczby CVE (63 vs. 66/68/80) wynikają z liczenia komponentów Chromium, Edge, czasem Adobe lub dokumentowanych wcześniej poprawek; dla operacji patchowania najwierniejsze bywają listy ZDI/Tenable zsynchronizowane z MSRC.

Podsumowanie / kluczowe wnioski

  1. Patchuj teraz – szczególnie systemy narażone i stacje użytkowników wysokiego ryzyka. CVE-2025-62215 (kernel EoP) jest aktywnie wykorzystywana i często domyka łańcuch po RCE.
  2. Zamknij Preview Pane i ogranicz otwieranie dokumentów zewnętrznych do czasu pełnego wdrożenia łatek. Office RCE (CVE-2025-62199) i GDI+ (CVE-2025-60724) to realne wektory.
  3. Zaktualizuj AMA i WSLg osobno, przejrzyj ekspozycję usług i uprawnienia kont serwisowych.
  4. Ucywilizuj narzędzia Dev (VS/VS Code/Copilot/Agentic AI): allow-listy, podpisy, zasada „review przed run”, egzekwuj AllSigned.

Źródła / bibliografia

  • Brian Krebs, „Microsoft Patch Tuesday, November 2025 Edition” — przegląd miesiąca i kontekst wdrożeniowy. (Krebs on Security)
  • Zero Day Initiative (Trend Micro), „The November 2025 Security Update Review” — lista CVE, omówienia GDI+/Office/AMA/WSLg/Agentic AI, wskazanie zero-day CVE-2025-62215. (Zero Day Initiative)
  • Tenable, „Microsoft’s November 2025 Patch Tuesday Addresses 63 CVEs (CVE-2025-62215)” — metryki i zestawienie dotkniętych komponentów. (Tenable®)
  • BleepingComputer, „Microsoft November 2025 Patch Tuesday fixes 1 zero-day, 63 flaws” — potwierdzenie skali i statusu 0-day. (BleepingComputer)
  • SANS Internet Storm Center, „Microsoft Patch Tuesday for November 2025” — ujęcie operacyjne i komentarz do krytycznych poprawek. (SANS Internet Storm Center)

CVE-2025-59299: luka w Delta Electronics DIAScreen (błąd walidacji plików wejściowych) – analiza, ryzyko i zalecenia

Wprowadzenie do problemu / definicja luki

CVE-2025-59299 to podatność w oprogramowaniu Delta Electronics DIAScreen (narzędzie HMI/SCADA z ekosystemu DIAStudio). Błąd wynika z braku prawidłowej walidacji danych z pliku dostarczonego przez użytkownika, co skutkuje zapisywaniem poza końcem bufora podczas parsowania projektu (CWE-787). Do wykorzystania konieczne jest otwarcie przez użytkownika specjalnie spreparowanego pliku – efekt to wykonanie kodu w kontekście bieżącego procesu. Wersje podatne to wszystkie przed 1.6.1; producent opublikował aktualizację podnoszącą DIAScreen do v1.6.1.

W skrócie

  • Produkt: Delta Electronics DIAScreen
  • CVE: CVE-2025-59299
  • Klasyfikacja: CWE-787 Out-of-Bounds Write (błąd parsowania plików projektu DPA)
  • Wymagania ataku: interakcja użytkownika (otwarcie złośliwego pliku)
  • Skutki: RCE w kontekście procesu DIAScreen (wysokie CIA)
  • Ocena ryzyka: CVSS v3.1 7.8 (High); v4.0 6.8 (Medium) wg CNA
  • Wersje podatne: < 1.6.1; remediacja: aktualizacja do v1.6.1
  • Zakres: środowiska OT/ICS, szczególnie stacje inżynierskie/HMI z DIAStudio

Kontekst / historia / powiązania

Luka została ujawniona w pakiecie czterech podobnych błędów DIAScreen: CVE-2025-59297, -59298, -59299, -59300, wszystkie o charakterze Out-of-Bounds Write w parserze plików projektu. Producent opublikował formalną notę bezpieczeństwa Delta-PCSA-2025-00018 z jednoznaczną rekomendacją aktualizacji do v1.6.1. Zero Day Initiative przypisuje odkrycie badaczowi Natnael Samson (@NattiSamson) i potwierdza wektor: złośliwy plik DPA → parsowanie → OOB write → RCE.

Analiza techniczna / szczegóły luki

Gdzie jest błąd?
W komponencie parsującym pliki projektu .DPA. Plik zawiera strukturę danych, która – przy braku rygorystycznej walidacji długości/pól – może spowodować zapis danych poza zaalokowaną strukturą. To klasyczny heap/stack OOB write (CWE-787), który umożliwia nadpisanie wskaźników/kontrolnych struktur pamięci i w konsekwencji przejęcie przepływu wykonania.

Warunki ataku:

  • Ofiara otwiera złośliwy plik w DIAScreen (wektor „file-based”).
  • Uprawnienia nie są wymagane ponad domyślne (PR:N), ale to atak lokalny z UI:R (użytkownik musi otworzyć plik).
  • Po udanym wywołaniu błędu możliwe jest RCE w kontekście użytkownika uruchamiającego DIAScreen.

Metadane CVSS (NVD):

  • CVSS v3.1: 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
  • CVSS v4.0 (CNA): 6.8 (UI:A, VA:H, itd.)
    W praktyce, na stacjach inżynierskich OT konsekwencje te często przekładają się na wysokie ryzyko operacyjne (kontekst HMI/SCADA).

Praktyczne konsekwencje / ryzyko

Scenariusze nadużyć w OT/ICS:

  1. Spear-phishing do inżynierów/techników – załącznik „aktualizacja projektu.dpa”; po otwarciu dochodzi do RCE i osadzenia implantu w środowisku HMI.
  2. Wymiana plików przez pamięci USB w strefach z ograniczoną łącznością – wektor popularny w fabrykach i na liniach produkcyjnych.
  3. Złośliwy projekt na serwerze wersji (np. share SMB) – podmiana pliku projektu, kompromitacja kolejnych stacji.

Skutek biznesowy: przejęcie stacji inżynierskiej/HMI może pozwolić na manipulację ekranami sterowania, zmianę receptur/parametrów, czy sabotaż procesu przy dalszym ruchu bocznym. Brak izolacji IT/OT i słaba segmentacja zwiększają prawdopodobieństwo eskalacji.

Źródła potwierdzają wektor i wpływ wprost (RCE po otwarciu pliku) oraz wskazują na pakiet czterech CVE w tej samej klasie błędów.

Rekomendacje operacyjne / co zrobić teraz

1) Patching i inwentarz

  • Zaktualizuj DIAScreen do v1.6.1 lub nowszej na wszystkich stacjach inżynierskich/HMI. To oficjalna i jednoznaczna rekomendacja producenta.
  • Zidentyfikuj instalacje (Windows) i sprawdź wersję aplikacji:
# Wykrywanie zainstalowanego DIAScreen i wersji w rejestrze (Apps & Features)
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
                 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' `
| Where-Object { $_.DisplayName -match 'DIAScreen' } `
| Select-Object DisplayName, DisplayVersion, Publisher, InstallLocation

Jeżeli skrypt nie zwróci wyniku, przeszukaj dysk pod kątem katalogów DIAStudio/DIAScreen i sprawdź wersję plików binarnych (Właściwości → Szczegóły).

2) „Virtual patching” i twardnienie do czasu aktualizacji

  • Zabroń/ogranicz otwieranie plików .DPA z lokacji ryzykownych (Downloads, %TEMP%, nośniki wymienne) – reguła SRP/AppLocker (Path/Hash).
  • Polityki pocztowe: blokada lub kwarantanna załączników .dpa, tagowanie detekcji w bramce pocztowej (DLP/ATP).
  • Kontrola nośników USB: whitelisting urządzeń, skan AV/EDR, auto-kwarantanna plików .dpa zewnętrznych.
  • Segmentacja sieci OT: stacje z DIAScreen za zaporą, brak dostępu z sieci biurowej; zdalny dostęp tylko VPN i tylko z listy dozwolonych.

3) Monitoring i detekcja (przykłady)

Sigma (Windows) – podejrzane otwarcia plików DPA z lokalizacji wysokiego ryzyka:

title: Suspicious DIAScreen Project Open From Risky Locations
id: 1b1a1e0c-6f6b-4d40-b1e5-7d1f4f5a9da9
status: experimental
logsource:
  category: file_event
  product: windows
detection:
  selection_ext:
    TargetFilename|endswith: '.dpa'
  selection_paths:
    TargetFilename|contains:
      - '\Downloads\'
      - '\Temp\'
      - '\$Recycle.Bin\'
      - '\RemovableDrive\'
  condition: selection_ext and selection_paths
level: medium
tags:
  - attack.initial_access
  - attack.t1204.002  # Malicious File

Sysmon – nietypowe wywołanie DIAScreen po otwarciu projektu:

<!-- Sysmon Event ID 1: Process Create -->
<RuleGroup name="DIAScreen Suspicious Launch" groupRelation="or">
  <ProcessCreate onmatch="include">
    <Image condition="end with">DIAScreen.exe</Image>
    <ParentImage condition="contains">\Temp\</ParentImage>
  </ProcessCreate>
  <ProcessCreate onmatch="include">
    <Image condition="end with">DIAScreen.exe</Image>
    <CommandLine condition="contains">.dpa</CommandLine>
  </ProcessCreate>
</RuleGroup>

EDR/AV: stwórz watchlist na proces DIAScreen.exe otwierający .dpa z „niezaufanych” ścieżek i na crash/exception w procesie (częsty artefakt prób OOB write).

4) Procedury użytkownika / szkolenia

  • Nie otwieraj plików projektu otrzymanych e-mailem/IM bez walidacji źródła.
  • W środowiskach air-gapped – skan nośników przed importem projektów.

Różnice / porównania z innymi przypadkami (pakiet CVE dla DIAScreen)

Zarówno CVE-2025-59297, -59298, -59299, jak i -59300 dotyczą tej samej klasy błędu (CWE-787) w parserze DIAScreen i są naprawione w v1.6.1. Różnią się one lokalizacją w kodzie/ścieżką parsowania i mogą być wyzwalane przez odmienne pola pliku. Z punktu widzenia obrony operacyjnej: te same kontrole (aktualizacja, polityki plików, segmentacja, monitoring) redukują ryzyko dla całego pakietu.

Podsumowanie / kluczowe wnioski

  • To błąd „file-open → RCE”: wystarczy otwarcie złośliwego projektu .DPA.
  • Ryzyko realne w OT/ICS, bo DIAScreen działa na stacjach inżynierskich/HMI.
  • Patch do v1.6.1 jest dostępny i zalecany natychmiast.
  • Do czasu aktualizacji: blokuj .DPA z nieznanych źródeł, egzekwuj segmentację i monitoruj użycie DIAScreen.
  • Wprowadź procedury operacyjne: kontrola nośników, polityki pocztowe, szkolenia użytkowników.

Źródła / bibliografia

  1. Vendor advisory (PDF): „Delta-PCSA-2025-00018 – DIAScreen File Parsing Out-Of-Bounds Write Vulnerabilities” – wersje podatne < 1.6.1, CVSS v3.1=7.8, rekomendacja aktualizacji do v1.6.1. (PDF)
  2. NVD – CVE-2025-59299: opis „lacks proper validation of the user-supplied file”, metryki CVSS v3.1=7.8, wskazanie na wersje do <1.6.1 i link do advisory producenta. (NVD)
  3. ZDI-25-970: „DPA File Parsing Out-Of-Bounds Write RCE”, UI:R, RCE w kontekście bieżącego procesu, timeline i odniesienie do CISA. (zerodayinitiative.com)
  4. Ameeba Exploit Tracker – wpis o CVE-2025-59299: streszczenie luki (wektor plikowy, RCE po otwarciu). (Użyte jako źródło drugorzędne/uzupełniające). (Ameeba)
  5. Strona przeglądowa Delta – Product Cybersecurity Advisory: potwierdza istnienie advisory i politykę publikacji po dostępności poprawek. (deltaww.com)

Uwaga operacyjna: NVD i advisory producenta wprost wskazują v1.6.1 jako próg naprawy; utrzymuj ten numer jako twardy warunek zgodności w CMDB/OT asset management i audytach patch compliance.

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.

79% firm w Indiach doświadczyło ataku ransomware. Co mówi nowe badanie Rubrik Zero Labs i co z tego wynika dla obrony?

Wprowadzenie do problemu / definicja luki

Według najnowszego badania Rubrik Zero Labs dotyczącego odporności tożsamości, 79% organizacji w Indiach doświadczyło w minionym roku ataku ransomware, a 91% z nich zapłaciło okup (często, by odzyskać dane lub zatrzymać intruzów). Artykuł „Deccan Herald” streszcza wnioski, podkreślając także, że 34% firm szacuje powrót do pełnej operacyjności dopiero po >2 dniach w przypadku ataku opartego o kompromitację tożsamości.

W skrócie

  • 79% badanych organizacji w Indiach miało incydent ransomware w ostatnich 12 miesiącach.
  • 91% ofiar zapłaciło okup.
  • Tylko 32% deklaruje zdolność do pełnego odtworzenia usług w ≤12h; ~34% potrzebuje >2 dni po ataku tożsamościowym.
  • Badanie wiąże wzrost ryzyka z eksplozją „tożsamości nie-ludzkich” (NHI) i agentów AI, czyli nowymi kontami/usługami działającymi automatycznie w środowiskach firm.

Kontekst / historia / powiązania

Dane Rubrika wpisują się w szerszy obraz: ransomware w 2024/2025 pozostaje dominującym wektorem szkód, a głośne incydenty w Indiach obejmowały także sektor bankowy (atak na dostawcę C-Edge, którego skutki odczuli klienci setek mniejszych banków; usługi przywrócono po izolacji i audycie). Z kolei zestawienia branżowe (Acronis/DSCI) wskazują, że Indie są jednym z najczęściej atakowanych rynków malware/ransomware globalnie.

Analiza techniczna / szczegóły luki

Nowy raport Rubrik Zero Labs („The Identity Crisis”) pokazuje, że tożsamość stała się główną powierzchnią ataku: napastnicy „żyją z zasobów” (Living-off-the-Land), nadużywając ważnych, ważnych i często uprawnień nadmiernych* kont – ludzkich i nieludzkich (usługi, boty, integracje, agenci AI). Kompromitacja poświadczeń pozwala ominąć klasyczne kontrole sieciowe i szybciej dotrzeć do kopii zapasowych, systemów MDM, chmur czy SaaS-ów. W tym modelu przywracalność (rapid recovery) staje się równie ważna, co prewencja.

Główne techniki napastników (z raportu i praktyki IR):

  • Kradzież/token hijacking (OAuth/OIDC), abuse refresh tokens.
  • „Password spraying” na Entra ID/Okta, następnie MFA bypass (MFA fatigue, token replay, fałszywe push-y).
  • Eskalacja uprzywilejowań w AD/Entra (misconfig, role assignment, stale app registrations).
  • Sabotaż kopii zapasowych: usuwanie snapshotów, wyłączanie retention/immutability.

Praktyczne konsekwencje / ryzyko

  • Wysoka skłonność do płacenia (91% w Indiach według Rubrika) utrzymuje rentowność grup ransomware i „double/triple extortion”.
  • Dłuższe RTO: tylko 32% firm jest gotowych na pełne odtworzenie ≤12h; duża część liczy >48h, co oznacza realne przerwy w przychodach i SLA.
  • Rozrost NHI i agentów AI zwiększa „blast radius”: każde konto/usługa wymaga cyklu kluczy, rotacji sekretów, kontroli skopów i krótkich TTL.

Rekomendacje operacyjne / co zrobić teraz

Poniżej checklista nastawiona na Identity Resilience + Rapid Recovery:

  1. Twarde RPO/RTO oraz izolowalne kopie
  • Kopie w trybie immutable/WORM, air-gap lub logical gap; odrębne poświadczenia backup.
  • Testy odtworzeniowe runbook→automaty (np. Terraform/Ansible) z mierzeniem RTO co sprint.
  1. Least privilege i segmentacja tożsamości
  • Oddziel break-glass od SSO, z posiadaniem fizycznym (FIDO2).
  • Rotacje i short-lived tokens dla aplikacji/NHI; deny by default dla grantów „offline_access”.
  1. Hardening AD/Entra/IdP – szybkie kontrole techniczne
# (AD) Wykryj konta z delegacją nieograniczoną
Get-ADUser -Filter * -Properties TrustedForDelegation | ? {$_.TrustedForDelegation -eq $true}

# (AD) Znajdź członków grup uprzywilejowanych
Get-ADGroupMember "Domain Admins" -Recursive

# (Windows) Wykryj wyłączenia AV/EDR ustawione przez atakującego
Get-MpPreference | fl ExclusionPath,ExclusionProcess

# (Entra ID) Aplikacje z uprawnieniami wysokiego ryzyka
Get-MgServicePrincipal | ? {$_.AppRoleAssignmentRequired -eq $false} | 
  % { Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $_.Id }
  1. MFA odporne na phishing + polityki ryzyka
  • FIDO2/Passkeys dla uprzywilejowanych; blokady „impossible travel”; step-up przy wrażliwych akcjach (np. kasowanie snapshotów).
  1. Ochrona kopii i platform SaaS/Cloud
  • Wymuszaj 4-eyes i „time-delay” na kasowanie kopii; alarmuj na DeleteSnapshot, PutBucketVersioning, kms:DisableKey.
  • Wprowadź SaaS-backup z retencją niezależną od IdP.
  1. Detekcje gotowe do użycia (SPL/Sigma)
-- Splunk: podejrzane wyłączenie EDR/AV w Windows
index=win* EventCode=7036 Message="*stopped*" (Service_Name="*Defender*" OR Service_Name="*EDR*")
| stats count by host, Service_Name, _time

-- Entra ID: nietypowe tworzenie aplikacji/sekretów
index=azure_audit OperationName IN ("Add app role assignment", "Add service principal")
| stats count dc(host) by actor, target, location
  1. Runbook IR dla ransomware opartego o tożsamość
  • Natychmiast: zablokuj refresh tokens, wymuś reauth, rotuj klucze aplikacji (IdP/API/KMS).
  • Odtwarzaj najpierw IdP/PKI/backup-controller, dopiero potem workloady.
  1. Ćwiczenia krzyżowe
  • Co kwartał: purple team proti wektorom token theft/MFA bypass; pomiar MTTD/MTTR, RTO.

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

Rubrik pokazuje bardzo wysokie wskaźniki ataków i płatności w Indiach (79%/91%). Dla porównania, Sophos „State of Ransomware 2025” raportował globalnie niższe odsetki płatności (w Indiach ~53% ofiar deklarowało zapłatę; median ransom spadł do ok. 481 tys. USD), co pokazuje, że metodologie/okresy i dobór próby mocno wpływają na wyniki – ale trend „tożsamość w centrum” pozostaje spójny. CERT-In 2024 również akcentuje wzrost aktywności grup ransomware i zróżnicowanie TTP.

Podsumowanie / kluczowe wnioski

  • Ransomware w Indiach ma charakter tożsamościowy: atakujący celują w konta, tokeny i uprawnienia.
  • Odporność na poziomie tożsamości + szybkie odtwarzanie stają się krytyczne KPI cyber-odporności (RTO/RPO).
  • Firmy powinny automatyzować odtwarzanie (runbooki jako kod), zamykać luki w IdP i utwardzać kopie – bo to właśnie te obszary decydują, czy płacisz okup, czy wracasz do pracy bez płacenia.

Źródła / bibliografia

  • Deccan Herald: streszczenie badania Rubrik Zero Labs dot. Indii (15.11.2025). (Deccan Herald)
  • Rubrik Zero Labs – komunikat prasowy o „Identity Resilience” (13.11.2025) i strona raportu „The Identity Crisis”. (rubrik.com)
  • PDF raportu „The Identity Crisis” (Rubrik Zero Labs, 2025). (Rubrik)
  • Uzupełniające relacje o danych dla Indii (The Mobile Indian, ETTelecom). (The Mobile Indian)
  • Kontekst rynkowy: incydent C-Edge (Reuters, 31.07–01.08.2024). (Reuters)
  • Porównawczo: Sophos „State of Ransomware 2025” (Indie – płatności/median ransom). (SOPHOS)
  • CERT-In: „Ransomware Report 2024”. (cert-in.org.in)