Archiwa: Cryptography - Security Bez Tabu

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)

Hakerzy wykorzystują błąd kryptograficzny w Gladinet CentreStack/Triofox do ataków RCE

Wprowadzenie do problemu / definicja luki

11 grudnia 2025 r. pojawiły się doniesienia o aktywnym wykorzystywaniu nowej, nieudokumentowanej wcześniej podatności kryptograficznej w produktach Gladinet CentreStack i Triofox. Błąd wynika z zastosowania stałych (hardcoded) kluczy AES w komponencie odpowiedzialnym za szyfrowanie tzw. „Access Ticketów”. Atakujący, posiadając te klucze, mogą odszyfrowywać lub fałszować bilety dostępu, pobierać plik web.config z serwera i następnie doprowadzać do zdalnego wykonania kodu (RCE) poprzez nadużycie ASP.NET ViewState. Vendor potwierdził aktualizacje i przekazał IOC oraz zalecenia, a badacze obserwują ataki na co najmniej 9 organizacji z różnych sektorów.

W skrócie

  • Co się dzieje: aktywne ataki na CentreStack/Triofox z wykorzystaniem stałych kluczy AES i mechanizmu „Access Ticket”.
  • Skutki: odczyt web.config → pozyskanie machineKeyViewState deserializationRCE.
  • Skala: potwierdzone co najmniej 9 ofiar (stan na 10 grudnia 2025 r.). Adres źródłowy widoczny w telemetrii: 147.124.216[.]205.
  • Wersje/patch: zalecana wersja 16.12.10420.56791 (wydana 8 grudnia 2025 r.). Bezwzględnie zrotować machineKey.
  • Łańcuch z wcześniejszą luką: aktywnie wykorzystywane CVE-2025-11371 (LFI) oraz wcześniejsze CVE-2025-30406 (RCE przez ViewState).

Kontekst / historia / powiązania

Jesienią 2025 r. CISA dodała do katalogu KEV podatność CVE-2025-11371 (LFI), umożliwiającą nieautoryzowany odczyt plików – w praktyce web.config. Wcześniej opisywano także CVE-2025-30406, gdzie błędna obsługa kluczy/machineKey umożliwia RCE przez ViewState. Obecnie obserwowany błąd kryptograficzny z hardcoded kluczami AES ułatwia ten sam łańcuch ataku i jest wykorzystywany „widzianie w boju” (in the wild).

Analiza techniczna / szczegóły luki

  • Miejsce problemu: niestandardowa implementacja AES w GladCtrl64.dll; podczas startu serwisu generowane są dwie stałe 100-bajtowe sekwencje znaków (chiński i japoński tekst marketingowy), z których obliczane są klucz (32 B) i IV (16 B).
  • Mechanizm błędu: handler filesvr.dn przyjmuje parametr t (Access Ticket), podmienia znaki, dekoduje Base64 i odszyfrowuje bilety stałym kluczem/IV. Ktokolwiek te wartości odczyta (np. z pamięci procesu), może tworzyć własne, ważne bilety – np. z timestampem ustawionym na rok 9999 (nigdy nie wygasną).
  • Co dalej robi atakujący: tworzy bilet wskazujący na ścieżkę C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config, pobiera plik i wyciąga z niego <machineKey>. Następnie przeprowadza ViewState deserialization i osiąga RCE w kontekście aplikacji IIS.
  • IOC o wysokiej wiarygodności: skrót szyfrowanego ciągu odpowiadający ścieżce web.config: vghpI7EToZUDIZDdprSubL3mTZ2 – to najlepszy wskaźnik w logach HTTP.

Praktyczne konsekwencje / ryzyko

  • Przejęcie serwera aplikacyjnego (RCE) i dostęp do plików udziałów/zasobów.
  • Ruch lateralny w domenie (kradzież poświadczeń, eskalacja uprawnień).
  • Eksfiltracja danych z udziałów plikowych udostępnionych przez CentreStack/Triofox.
  • Trwałość: bilety z timestampem „9999-…” można wielokrotnie odtwarzać.
  • Sektory: potwierdzone ofiary m.in. ochrona zdrowia i technologia.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja do 16.12.10420.56791 (build z 8 grudnia 2025 r.).
  2. Rotacja machineKey we wszystkich węzłach/instancjach (to warunek konieczny – same łatki nie unieważnią zdobytych kluczy).
  3. Przegląd logów (IIS, WAF, proxy) pod kątem:
    • żądań do /storage/filesvr.dn z parametrem t=,
    • wystąpień ciągu vghpI7EToZUDIZDdprSubL3mTZ2 (wysoka trafność),
    • nietypowych błędów ViewState/ObjectStateFormatter.
  4. Weryfikacja kompromitacji: jeśli machineKey mógł wyciec, zakładaj kompromitację → rotuj klucze, unieważnij sesje, przeprowadź IR (przegląd harmonogramów zadań, usług, modułów IIS, webshelli, skryptów w katalogach aplikacji).
  5. Twardnienie konfiguracji:
    • wyłącz/ogranicz dostęp do filesvr.dn,
    • zastosuj WAF-owe reguły dla podejrzanych t= (Base64 + znaki :, |),
    • zmień domyślny machineKey i egzekwuj jego rotację proceduralnie (runbook).
  6. Śledź KEV/CVE: monitoruj status CVE-2025-11371 (LFI) i wcześniejszej CVE-2025-30406 (RCE) – łańcuchy są ze sobą silnie powiązane operacyjnie.

Różnice / porównania z innymi przypadkami

  • CVE-2025-11371 (LFI): umożliwia odczyt plików bez uwierzytelnienia (np. web.config). Sama w sobie nie daje natychmiastowego RCE, ale otwiera drzwi do pozyskania machineKey.
  • Nowy błąd kryptograficzny (brak CVE na dziś): ułatwia fałszowanie Access Ticketów dzięki stałym kluczom AES — z pominięciem innych kontroli czasu/uwierzytelniania — co przyspiesza zdobycie web.config.
  • CVE-2025-30406 (RCE): deserializacja ViewState z użyciem poznanego machineKeypełne RCE w aplikacji.

Podsumowanie / kluczowe wnioski

  • Atakujący aktywnie łączą błąd kryptograficzny z wcześniejszymi słabościami CentreStack/Triofox, aby masowo uzyskiwać RCE.
  • Patch + rotacja kluczy to absolutne minimum; bez rotacji machineKey środowisko pozostaje narażone na ponowne wykorzystanie.
  • Najbardziej wiarygodny IOC do szybkiego huntingu w logach HTTP to: vghpI7EToZUDIZDdprSubL3mTZ2.
  • Wdrożenie kontroli prewencyjnych (WAF, ograniczenie handlerów, segmentacja) znacząco utrudni powtórny kompromis.

Źródła / bibliografia

  1. BleepingComputer: „Hackers exploit Gladinet CentreStack cryptographic flaw in RCE attacks” (11 grudnia 2025). (BleepingComputer)
  2. Huntress: „Active Exploitation of Gladinet CentreStack/Triofox Insecure Cryptography Vulnerability” (10 grudnia 2025). (Huntress)
  3. CISA KEV – wpis dot. CVE-2025-11371 (4 listopada 2025). (CISA)
  4. Huntress: „CVE-2025-30406 – Critical Gladinet CentreStack & Triofox vulnerability exploited in the wild” (14 kwietnia 2025). (Huntress)
  5. Gladinet Support: „Hardening the CentreStack Cluster” – sekcja o aktualizacji/rotacji machineKey. (support.centrestack.com)

Microsoft: Październikowe aktualizacje powodują problemy z uwierzytelnianiem kartami inteligentnymi w Windows

Wprowadzenie do problemu / definicja luki

Październikowy zestaw poprawek Microsoftu (opublikowany 14 października 2025 r.) wywołał u części organizacji problemy z uwierzytelnianiem opartym o karty inteligentne i certyfikaty na systemach Windows 10, Windows 11 oraz Windows Server. Microsoft powiązał incydent z wprowadzonym domyślnie utwardzeniem kryptografii w usługach Windows Cryptographic Services. Sprawa została oznaczona jako znany problem (known issue), otwarty 17 października i oznaczony jako „Resolved” (z rozwiązaniem/procedurą) 20 października 2025 r. w panelu Release Health.

W skrócie

  • Objawy: brak rozpoznania kart jako dostawcy CSP w aplikacjach 32-bitowych, błędy przy podpisywaniu, awarie logowania CBA; komunikaty typu „invalid provider type specified” i CryptAcquireCertificatePrivateKey error.
  • Przyczyna: wymuszenie użycia KSP (Key Storage Provider) zamiast CSP (Cryptographic Service Provider) dla certyfikatów RSA na kartach, w ramach zabezpieczenia luki CVE-2024-30098.
  • Status: Microsoft udokumentował wykrywanie i obejście (klucz rejestru DisableCapiOverrideForRSA). Strona Release Health wskazuje stan „Resolved” od 20.10.2025 (17:49 PT).

Kontekst / historia / powiązania

Zmiana kryptograficzna jest częścią dłuższej ścieżki utwardzania tożsamości i kryptografii w Windows (m.in. modyfikacje zachowania CAPI/KSP, wzmocnienia Kerberosa i CBA w 2025 r.). W tym miesiącu Microsoft równolegle korygował inny błąd z Październikowego Patch Tuesday (niedziałające USB we Windows Recovery Environment), który naprawiono 20 października aktualizacją awaryjną KB5070773—to inny problem, ale pokazuje, że październikowe poprawki były wyjątkowo „ruchome”.

Analiza techniczna / szczegóły luki

Październikowe aktualizacje (m.in. KB5066791 dla Windows 10 22H2 i KB5066793/ KB5066835 dla gałęzi Windows 11/Server) egzekwują użycie KSP zamiast CSP dla certyfikatów RSA na kartach inteligentnych. Celem jest utrudnienie nadużyć opisanych w CVE-2024-30098 (obejście funkcji zabezpieczeń w Windows Cryptographic Services). Jeśli środowisko lub aplikacje oczekiwały starszego modelu CSP, pojawiają się błędy podczas operacji kryptograficznych i uwierzytelniania CBA.

Microsoft udokumentował również sposób detekcji ryzyka: przed wdrożeniem aktualizacji warto sprawdzić, czy w dzienniku System dla usługi Smart Card Service występuje Event ID 624 („system używa CAPI do operacji RSA”). Obecność zdarzenia wskazuje na większe prawdopodobieństwo wystąpienia problemu po aktualizacji.

Praktyczne konsekwencje / ryzyko

  • Tożsamość i dostęp: potencjalna niemożność logowania z użyciem kart inteligentnych (CBA) do stacji roboczych/serwerów oraz usług zależnych od certyfikatów użytkownika.
  • Procesy biznesowe: podpisy elektroniczne i operacje kryptograficzne w aplikacjach 32-bitowych mogą przestać działać do czasu dostosowania środowiska.
  • Utrzymanie: eskalacje do servicedesków i rolling back mogą zwiększać ryzyko ekspozycji, bo cofnięcie poprawek znosi również łatki bezpieczeństwa. Lepszą ścieżką jest kontrolowane obejście i kompatybilność po stronie aplikacji. (Wniosek na podstawie dokumentacji KB/Release Health.)

Rekomendacje operacyjne / co zrobić teraz

  1. Zweryfikuj wpływ w logach przed wdrożeniem szerokim frontem. Szukaj Event ID 624 w dzienniku System/Smart Card Service na reprezentatywnych hostach.
  2. Jeśli już wystąpił problem – zastosuj obejście Microsoftu (per-host):
    • Otwórz Regedit → przejdź do HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais → utwórz/edytuj wartość DWORD DisableCapiOverrideForRSA i ustaw 0restart. (Klucz nie jest dodawany przez system/aktualizacje – trzeba go utworzyć ręcznie). Uwaga: edycję rejestru wykonuj po kopii zapasowej.
  3. Rozmawiaj z dostawcami aplikacji i PKI. Celem jest usunięcie zależności od CSP i pełna zgodność z KSP. Obejście rejestrowe traktuj jako tymczasowe. (Potwierdza to komunikacja MS w Release Health/KB).
  4. Zachowaj aktualność poprawek. Nie cofaj całych pakietów, aby nie tracić łatek bezpieczeństwa—monitoruj panel Release Health dla swojego wydania (Windows 10/11/Server) i stosuj poprawki uzupełniające.
  5. Change management: wstrzymaj globalne wdrożenia do czasu weryfikacji w pilotażu; przygotuj GPO/skrpty ustawiające DisableCapiOverrideForRSA=0 na hostach dotkniętych problemem (zgodnie z polityką organizacji). (Wniosek operacyjny na bazie dokumentacji MS.)

Różnice / porównania z innymi przypadkami (październik 2025)

  • Smart card/KSP vs. WinRE/USB: Problemy z kartami wynikają z twardego przełączenia CSP→KSP (kompatybilność aplikacji), natomiast błąd WinRE/USB był klasycznym regresem sterowników/środowiska odzyskiwania i został naprawiony aktualizacją awaryjną KB5070773.

Podsumowanie / kluczowe wnioski

  • Październikowe łatki wymuszają KSP dla certyfikatów RSA na kartach, co poprawia bezpieczeństwo (CVE-2024-30098), ale ujawniło zależności od starego CSP w części środowisk.
  • Microsoft podał procedurę obejścia (DisableCapiOverrideForRSA=0) i oznaczył problem jako „Resolved” w Release Health (20.10.2025), jednak długofalowo należy zmigrować aplikacje i łańcuchy kryptograficzne do modelu KSP.

Źródła / bibliografia

  • BleepingComputer: „Microsoft warns of Windows smart card auth issues after October updates”, 20 paź 2025. (BleepingComputer)
  • Microsoft Release Health – Resolved issues (Windows 11 25H2): status, objawy, rejestr, daty 17–20 paź 2025. (Microsoft Learn)
  • Microsoft Support (KB) – KB5066791 (Windows 10 22H2), sekcja [Cryptography]: wymuszenie KSP i odwołanie do CVE-2024-30098. (Microsoft Support)
  • Microsoft Support/Release Health – KB5070773 (hotfix WinRE USB), tło innych problemów październikowych. (Microsoft Learn)