Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 439 z 465

Autor: Wojciech Ciemski

China-linked UNC6384 wykorzystuje zero-day w Windows (.LNK/CVE-2025-9491) do szpiegowania europejskich dyplomatów

Wprowadzenie do problemu / definicja luki

Arctic Wolf Labs ujawniło kampanię cyberszpiegowską przypisywaną grupie UNC6384 (łączonej w doniesieniach z Mustang Panda), która od września do października 2025 r. celowała w placówki dyplomatyczne w Belgii i na Węgrzech, a także w inne podmioty w Europie. Atakujący wykorzystują niezałataną podatność w skrótach Windows (.LNK) – CVE-2025-9491 – aby dostarczać i uruchamiać zdalnego trojana PlugX metodą DLL side-loading z użyciem podpisanych narzędzi Canona.

W skrócie

  • Co się dzieje? Kampania spear-phishingowa z przemyślanymi przynętami (agendy spotkań KE, warsztaty NATO) prowadzi do pobrania złośliwych .LNK, które eksploatują CVE-2025-9491 i finalnie ładują PlugX.
  • Dlaczego to działa? Luka maskuje złośliwe argumenty w strukturze COMMAND_LINE_ARGUMENTS pliku skrótu – użytkownik, przeglądając właściwości, nie widzi istotnych danych; Microsoft jak dotąd nie wydał łatki.
  • Kto na celowniku? Dyplomacja Belgii, Węgier, a także podmioty w Serbii, Włoszech i Niderlandach.

Kontekst / historia / powiązania

Trend Micro ZDI ujawniło podatność ZDI-CAN-25373 / CVE-2025-9491 18 marca 2025 r., wskazując na szerokie, realne wykorzystanie przez co najmniej 11 grup sponsorowanych przez państwa jeszcze przed publikacją. Microsoft uznał w marcu, że problem „nie spełnia progu” natychmiastowego serwisowania. W efekcie luka pozostaje bez oficjalnej poprawki, mimo że jest aktywnie nadużywana.

Dla szerszego tła: Google Threat Intelligence już w sierpniu 2025 r. przypisał UNC6384 złożoną kampanię wobec dyplomatów w Azji Południowo-Wschodniej (m.in. tematyka posiedzeń Rady UE), co spina się z obecnym „przeniesieniem” zainteresowań do Europy.

Analiza techniczna / szczegóły luki

CVE-2025-9491 (UI misrepresentation, CVSS 7.0) dotyczy sposobu, w jaki Windows prezentuje metadane plików .LNK. Specjalnie „spadkowane” białe znaki w polu COMMAND_LINE_ARGUMENTS powodują, że złośliwa komenda jest niewidoczna w interfejsie, choć wykonuje się po uruchomieniu skrótu. Wymagana jest interakcja użytkownika (otwarcie pliku / odwiedzenie przygotowanej strony), jednak trik utrudnia manualną inspekcję.

U UNC6384 łańcuch obejmuje:

  1. E-mail spear-phishing z osadzonym URL,
  2. pobranie i uruchomienie .LNK z tematem wydarzeń KE/NATO,
  3. wykonanie obfuskowanych poleceń PowerShell,
  4. zrzut podpisanego binarium Canon i DLL side-loading,
  5. wstrzyknięcie i utrwalenie PlugX (wariant SOGU.SEC). Arctic Wolf opisał również konkretne IOC (nazwy plików, hashe, domeny C2 – m.in. racineupci[.]org, dorareco[.]net).

Praktyczne konsekwencje / ryzyko

  • Trwały dostęp i exfiltracja: PlugX zapewnia zdalną kontrolę, keylogging, transfer plików, kradzież poświadczeń – idealne do ciągłej obserwacji procesów dyplomatycznych.
  • Skala i tempo adopcji: UNC6384 wdrożyło exploit w ~6 miesięcy po publicznym ujawnieniu, co potwierdza zdolność szybkiej industrializacji TTP.
  • Brak łatki wymusza kompensacje na poziomie polityk, kontroli uruchamiania i detekcji zachowań; atak korzysta z zaufania do podpisanych plików (Canon).

Rekomendacje operacyjne / co zrobić teraz

  1. Kontrola plików .LNK
    • Ogranicz użycie i wykonywanie .LNK z maili/WWW (zasady AppLocker/WDAC, blokady przez GPO na ścieżkach TEMP/Downloads).
    • Filtrowanie bramek pocztowych: blokuj załączniki/archiwa zawierające .LNK; oznaczaj „agendy/agenda/KE/NATO” jako lures wysokiego ryzyka.
  2. Telemetria i detekcja
    • Monitoruj procesy potomne explorer.exe/rundll32.exe/powershell.exe uruchamiane z kontekstu .LNK; sygnatury YARA/EDR na charakterystyczne CanonStager i artefakty PlugX; wzorce DLL sideloading. (IOC i TTP — patrz publikacja Arctic Wolf).
  3. Hardening PowerShell i ASR
    • Włącz Constrained Language Mode, Script Block Logging, AMSI; reguły Attack Surface Reduction (blokowanie uruchamiania wscript.exe/cscript.exe i podejrzanych makr/dzieci procesów Office/Explorer).
  4. Zaufane aplikacje/podpisane binaria
    • Egzekwuj listy WDAC i Applocker dla podpisanych narzędzi firm trzecich (np. drukarek), aby uniemożliwić sideloading.
  5. Segmentacja i zasada najmniejszych uprawnień
    • Oddziel stacje „dyplomatyczne”/VIP, MFA, ograniczenie dostępu do zasobów wrażliwych, Egress filtering do znanych C2. (Domeny/C2 — wg Arctic Wolf).
  6. Reakcja i hunting
    • Szukaj archiwów/skrótów o tematyce „European Commission”, „NATO”, „EPC/EU Council” z końcówki Q3–Q4 2025; koreluj z połączeniami do nowych domen C2; przejrzyj właściwości .LNK narzędziami niskopoziomowymi (nie GUI).
  7. Komunikacja użytkowników
    • Krótka kampania uświadamiająca: dlaczego .LNK jest ryzykowne, jak bezpiecznie weryfikować zaproszenia/agendy (oddzielny kanał potwierdzeń).

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

  • W przeciwieństwie do częstych kampanii z wykorzystaniem LNK+LNK loaderów w cyberprzestępczości, tutaj kluczowa jest luka UI misrepresentation (CVE-2025-9491), która utrudnia manualną inspekcję i podbija skuteczność spear-phishingu.
  • Kampania wpisuje się w dotychczasowy modus operandi UNC6384 (wcześniej ASEAN), ale tematyka przynęt została zaktualizowana na UE/NATO, a loader PlugX/CanonStager został odchudzony i rozwijany w ostatnich miesiącach.

Podsumowanie / kluczowe wnioski

  • UNC6384 aktywnie wykorzystuje CVE-2025-9491 (.LNK) przeciwko europejskim dyplomatom, dostarczając PlugX przez DLL side-loading.
  • Luka nie ma jeszcze łaty, co wymaga twardych polityk wykonania, EDR i kontroli .LNK.
  • Przynęty „KE/NATO” i podpisane binaria Canon zwiększają wiarygodność ataku — edukacja użytkowników + kontrole techniczne są krytyczne.

Źródła / bibliografia

  • Arctic Wolf Labs: szczegóły kampanii, TTP/IOC, łańcuch ataku i tematy przynęt. (Arctic Wolf)
  • ZDI (Trend Micro): advisory ZDI-25-148 / CVE-2025-9491, opis luki i oś czasu. (zerodayinitiative.com)
  • BleepingComputer: potwierdzenie CVE-2025-9491, status patcha i szersze tło wykorzystywania. (BleepingComputer)
  • SecurityWeek: podsumowanie ataków w Europie, CVSS oraz stanowisko Microsoftu nt. serwisowania. (SecurityWeek)
  • The Record: kontekst geopolityczny i rozszerzenie celów (Serbia, Włochy, Niderlandy). (The Record from Recorded Future)

Chińska grupa Tick (Bronze Butler) wykorzystywała lukę w Lanscope jako zero-day. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Badacze powiązali kampanię cyberszpiegowską chińskiej grupy Tick (Bronze Butler) z aktywnym wykorzystaniem krytycznej podatności CVE-2025-61932 w Motex Lanscope Endpoint Manager (on-premises). Luka polega na niewłaściwej weryfikacji źródła kanału komunikacyjnego i umożliwia zdalne wykonanie kodu bez uwierzytelnienia (RCE) poprzez wysłanie specjalnie przygotowanych pakietów do hostów z komponentami agenta Lanscope. Producent wydał poprawki 20 października 2025 r., a CISA dodała CVE do katalogu KEV, potwierdzając eksploatację „in the wild”.

W skrócie

  • Luka: CVE-2025-61932 (CWE-940), krytyczne RCE bez uwierzytelnienia.
  • Wpływ: zdalne wykonanie kodu z uprawnieniami SYSTEM na hostach z agentem Lanscope (MR/DA).
  • Zasięg: dotyczy instalacji on-prem; wersje z linii 9.4.7.x i starsze (JVN wskazuje ≤9.4.7.1; część publikacji podaje ≤9.4.7.2). Poprawki dostępne, SaaS/Cloud nie jest podatny.
  • Atakujący: Tick/Bronze Butler – kampania cyberszpiegowska, wdrożenie zaktualizowanego backdoora Gokcpdoor.

Kontekst / historia / powiązania

Tick działa co najmniej od 2010 r., celując głównie w organizacje w Japonii i Azji (przemysł, technologie). W połowie 2025 r. grupa wykorzystywała omawianą lukę jako zero-day do uzyskania wejścia, zanim producent załatał błąd, a agencje rządowe potwierdziły aktywną eksploatację.

Analiza techniczna / szczegóły luki

  • Mechanizm: niewłaściwa weryfikacja pochodzenia żądań w kliencie MR i agencie DA dla Lanscope (on-prem). Skutkuje możliwością wysłania pakietów wyzwalających RCE. CVSS v4: 9.3 / v3: 9.8.
  • Zakres komponentów: dotyczy agentów (MR/DA), a nie serwera zarządzającego; wariant chmurowy Lanscope Cloud jest niepodatny.
  • Wersje/łatki: JVN: podatne ≤9.4.7.1; BleepingComputer (na podstawie biuletynów): ≤9.4.7.2. Poprawki udostępniono 20.10.2025 r. (m.in. gałęzie 9.3.x oraz 9.4.x).
  • Łańcuch ataku obserwowany przez badaczy: po RCE wdrażano Gokcpdoor (nowsza wersja z rezygnacją z KCP i multipleksowaną komunikacją C2), czasem wykorzystywano Havoc C2; OAED Loader ładował payload przez DLL sideloading. Próbki serwera nasłuchiwały m.in. na portach 38000/38002.

Praktyczne konsekwencje / ryzyko

  • Zdalne przejęcie hostów z agentami Lanscope z uprawnieniami SYSTEM i możliwość ruchu bocznego w domenie.
  • Eksfiltracja danych z użyciem narzędzi AD dump, zdalnego pulpitu, archiwizacji, a także transferu do usług chmurowych (m.in. Piping Server).
  • Ryzyko sektorowe: wysokie w środowiskach z szeroką ekspozycją agentów na sieci publiczne i z rozproszoną flotą endpointów (typowe w Japonii/Azji – główny rynek Lanscope).

Rekomendacje operacyjne / co zrobić teraz

  1. Inwentaryzacja i zakres: zidentyfikuj wszystkie hosty z MR/DA (on-prem). Odróżnij od Lanscope Cloud (niepodatny).
  2. Patch now! Zastosuj wersje usuwające CVE-2025-61932 (gałęzie naprawcze 9.3.x/9.4.x – zgodnie z tabelą producenta/JVN). W przypadku ograniczeń – izoluj hosty i ogranicz ruch do agentów.
  3. Segmentacja i hardening: ogranicz dostęp do interfejsów agenta (ACL/VLAN/mikrosegmentacja), minimalizuj ekspozycję z Internetu.
  4. Monitoring & detekcja:
    • Wykrywanie prób RCE do agentów; korelacja nietypowych połączeń wychodzących z hostów klienckich.
    • IOCs/TTPs: poszukuj uruchomień OAED Loader, nietypowego DLL sideloading, aktywności Gokcpdoor/Havoc, nasłuchów na 38000/38002, narzędzi typu goddi, nieoczekiwanych archiwów 7-Zip i połączeń do usług chmurowych używanych do eksfiltracji.
  5. Response: w przypadku kompromitacji – izolacja hostów, rotacja poświadczeń (AD), przegląd kontrolerów domeny, triage artefaktów pamięci/dysków i pełna reinstalacja z zaufanych obrazów, jeśli potrzebne. (Wytyczne oparte na praktykach IR i opisanych TTP.)
  6. Zgodność z KEV: jeżeli podlegasz wymogom FCEB/zasadom inspirowanym KEV – uwzględnij termin remediacji po dodaniu do katalogu KEV (październik 2025 r.).

Różnice / porównania z innymi przypadkami

Tick/Bronze Butler wcześniej korzystał z błędów w oprogramowaniu popularnym w Japonii (ukierunkowanie geograficzne i łańcuch dostaw). W porównaniu z „klasycznymi” RMM/EMM-RCE, tutaj wektor znajduje się w agencie endpointowym, co zwiększa powierzchnię ataku – kompromitowany jest host użytkownika, nie wyłącznie serwer zarządzający.

Podsumowanie / kluczowe wnioski

  • CVE-2025-61932 to krytyczne RCE bez uwierzytelnienia w Lanscope (on-prem), wykorzystywane jako zero-day co najmniej od połowy 2025 r. przez Tick/Bronze Butler.
  • Priorytetem jest natychmiastowa aktualizacja agentów (MR/DA) i ograniczenie ich ekspozycji sieciowej.
  • Obserwowane TTPs (OAED Loader, DLL sideloading, Gokcpdoor/Havoc, porty 38000/38002) dają praktyczne wskazówki do detekcji i threat huntingu.

Źródła / bibliografia

  1. BleepingComputer – „China-linked hackers exploited Lanscope flaw as a zero-day in attacks” (01.11.2025). (BleepingComputer)
  2. Sophos – „BRONZE BUTLER exploits Japanese asset management software vulnerability” (30.10.2025). (news.sophos.com)
  3. JVN (JPCERT/CC & IPA) – „JVN#86318557: Lanscope Endpoint Manager (On-Premises) vulnerable to improper verification of source of a communication channel” (20–21.10.2025). (jvn.jp)
  4. NVD (NIST) – „CVE-2025-61932” – opis i metryki CVSS (20.10.2025). (NVD)
  5. Help Net Security – „Lanscope Endpoint Manager vulnerability exploited in zero-day attacks (CVE-2025-61932)” – szczegóły wersji i poprawek (23.10.2025). (Help Net Security)

Glosariusz Kluczowych Terminów Dyrektywy NIS2

Dlaczego warto znać te pojęcia?

Dyrektywa NIS2 stawia przed organizacjami szereg nowych wymogów z zakresu cyberbezpieczeństwa. Zrozumienie specjalistycznych terminów używanych w regulacjach i wytycznych NIS2 jest kluczowe dla menedżerów, specjalistów IT oraz ekspertów ds. cyberbezpieczeństwa odpowiedzialnych za zgodność z tymi przepisami.

Czytaj dalej „Glosariusz Kluczowych Terminów Dyrektywy NIS2”

Chińscy hakerzy skanują i eksploatują firewalle Cisco ASA w sieciach rządowych na całym świecie

Wprowadzenie do problemu / definicja luki

Badacze z Unit 42 (Palo Alto Networks) oraz amerykańskie media branżowe informują o trwającej fali skanowania i włamań do zapór Cisco Adaptive Security Appliance (ASA) – popularnych urządzeń brzegowych używanych w urzędach i instytucjach publicznych w USA, Europie i Azji (w tym m.in. w Polsce). Atak przypisywany jest grupie Storm-1849 / UAT4356, którą łączy się z wcześniejszą kampanią ArcaneDoor wymierzoną w urządzenia perymetryczne. Wykorzystywany jest łańcuch błędów w ASA, w tym CVE-2025-20333 oraz CVE-2025-20362.

W skrócie

  • Co się dzieje? Odnotowano wzmożone skanowanie i eksploatację firewalli Cisco ASA należących do instytucji rządowych i podmiotów z sektorów obronnego i finansowego.
  • Kto stoi za atakami? Storm-1849 / UAT4356 – aktor powiązany z kampanią ArcaneDoor; analizy infrastruktur wskazują na związki z podmiotami z Chin.
  • Jakie luki? Co najmniej CVE-2025-20333 (RCE, CVSS 9.9) i CVE-2025-20362 (eskalacja uprawnień), często łączone w łańcuch.
  • Skutki? Utrzymanie trwałej obecności na urządzeniu nawet po restarcie i aktualizacji, dostęp do ruchu i segmentów sieciowych za firewall’em.
  • Co robić? Natychmiastowe łatanie, inwentaryzacja ASA/FTD, triage pod kątem kompromitacji, rozważenie wymiany EoS/EoL, pełny “re-keying” po incydencie.

Kontekst / historia / powiązania

W kwietniu 2024 r. Cisco Talos opisało kampanię ArcaneDoor, w której szpiegowskie implanty na urządzeniach perymetrycznych (m.in. ASA/FTD) służyły do przechwytywania ruchu i pivotowania w głąb sieci. W wrześniu 2025 r. CISA wydała dyrektywę awaryjną nakazującą agencjom federalnym w 1 dzień załatać ASA i przeprowadzić forensykę, wskazując na aktywną eksploatację nowo ujawnionych luk. Wskazywano również na nakładanie się aktywności z kampaniami przypisywanymi państwu chińskiemu.

Analiza techniczna / szczegóły luki

Wektory i łańcuch ataku

  • CVE-2025-20333: zdalne wykonanie kodu (RCE) w ASA (wysoka krytyczność).
  • CVE-2025-20362: obejście/eskalacja uprawnień.
    Aktórzy łączą oba błędy, aby uzyskać uprzywilejowany dostęp i wdrożyć mechanizmy trwałości.

TTPs obserwowane przez Cisco i Unit 42

  • Utrwalanie dostępu: manipulacja pamięcią/konfiguracją i techniki pozwalające przetrwać restarty i upgrade’y; zalecany factory reset oraz pełna wymiana haseł/kluczy po podniesieniu wersji.
  • Ukrywanie śladów: wyłączanie logowania i celowe crashowanie urządzenia, aby utrudnić analizę.
  • Celowanie globalne: IP instytucji rządowych w USA, Europie (m.in. PL, FR, NO, NL, ES, UK), Azji i innych regionach.

Atrybucja
Unit 42 obserwowało ciągłość działań Storm-1849/UAT4356 w październiku 2025 r. (z przerwą w Golden Week), a wcześniejsze analizy Censys łączyły infrastrukturę ArcaneDoor z podmiotami w Chinach.

Praktyczne konsekwencje / ryzyko

  • Ryzyko strategiczne: uzyskanie pozycji na urządzeniach brzegowych rządu/krytycznej infrastruktury otwiera drogę do długotrwałej inwigilacji ruchu, pozyskiwania poświadczeń, modyfikacji polityk oraz lateral movement.
  • Trwałość i odporność na remediację: techniki utrzymania po aktualizacjach sprawiają, że samo patchowanie nie wystarcza — potrzebny jest pełny proces odtworzenia zaufania.
  • Zasięg geograficzny i sektorowy: poza USA celem są administracje w Europie i Azji, a także sektor finansowy i obronny.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowe łatanie ASA/FTD do wersji usuwających CVE-2025-20333 i CVE-2025-20362. Zastosuj zalecenia Cisco „Continued Attacks Against Cisco Firewalls”.
  2. Inwentaryzacja i triage: policz wszystkie ASA/FTD (także ukryte/niezarządzane), sprawdź wskaźniki włamania (IOCs), porównaj z artefaktami ArcaneDoor/Storm-1849.
  3. Re-keying po incydencie: factory reset urządzeń, następnie pełna wymiana haseł, certyfikatów, kluczy i konfiguracji z zaufanych źródeł.
  4. Wycofanie EoS/EoL: urządzenia 5500-X bez wsparcia lub z kończącym się wsparciem odłączyć/wymienić; brak patchy = stałe ryzyko.
  5. Twarde segmentowanie i monitoring: UBA/NDR na ruchu z/do strefy „edge”, reguły detekcyjne dla anomalii VPN/SSL i zmian konfiguracji.
  6. Zgodność z zaleceniami rządowymi: śledź komunikaty CISA/NSA/NCSC i stosuj ich checklisty reagowania na działania aktorów państwowych.

Różnice / porównania z innymi przypadkami

  • ArcaneDoor (2024) vs. kampania 2025: Ta pierwsza wykorzystywała dwie 0-day (m.in. „Line Dancer/Line Runner”); tegoroczna fala obejmuje nowe CVE-2025-20333/20362 i wykazuje większą dojrzałość w utrzymaniu dostępu po aktualizacjach.
  • Aktor: w 2024 r. atrybucja była ostrożna; dziś istnieje spójniejsza układanka łącząca infrastrukturę i TTPs z ekosystemem państwowych aktorów z Chin.

Podsumowanie / kluczowe wnioski

  • Urządzenia brzegowe ASA pozostają głównym celem operacji szpiegowskich.
  • Samo „załatanie” nie przywraca zaufania — konieczny jest reset, re-keying i forensyka.
  • Organizacje rządowe i krytyczna infrastruktura powinny traktować te zdarzenia jako kompromitację perymetru i wprowadzić twardsze kontrole dostępu oraz ciągłe monitorowanie.

Źródła / bibliografia

  1. The Record: Chinese hackers scanning, exploiting Cisco ASA firewalls used by governments worldwide (31 października 2025). (The Record from Recorded Future)
  2. Unit 42 (Palo Alto Networks): September 2025 Zero-Day Vulnerabilities Affecting Cisco Software (26 września 2025). (Unit 42)
  3. Cisco: Continued Attacks Against Cisco Firewalls (materiały techniczne i zalecenia). (sec.cloudapps.cisco.com)
  4. NSA: Guidance to counter China state-sponsored actors targeting global critical infrastructure (27 sierpnia 2025). (nsa.gov)
  5. Censys: Analysis of ArcaneDoor Threat Infrastructure Suggests Potential Ties to Chinese-Based Actor. (censys.com)

Australia ostrzega przed infekcjami „BadCandy” na niezałatanych urządzeniach Cisco

Wprowadzenie do problemu / definicja luki

Australijskie służby (ASD/ACSC) ostrzegają, że implant webshell BadCandy nadal aktywnie infekuje niezałatane urządzenia Cisco IOS XE wystawione do Internetu. Wg najnowszych danych, od lipca 2025 r. w Australii potencjalnie naruszono ponad 400 urządzeń, a ponad 150 nadal pozostaje zainfekowanych – mimo dostępnych od 2023 r. poprawek eliminujących pierwotny wektor ataku w interfejsie Web UI (CVE-2023-20198).

W skrócie

  • Vektor wejścia: historyczna luka w Cisco IOS XE Web UI (m.in. CVE-2023-20198), masowo wykorzystywana od października 2023 r. do wdrażania implantu BadCandy.
  • Czym jest BadCandy: lekki webshell w Lua rejestrowany jako niestandardowa ścieżka w wbudowanym serwerze www urządzenia; pozwala na zdalne wykonywanie poleceń na poziomie systemu/IOS.
  • Skala w AU (X–XI 2025): >400 potencjalnie naruszonych urządzeń; >150 nadal z implantem.
  • Dlaczego wciąż działa: wiele urządzeń pozostaje niezałatanych lub z utrzymaną trwałością (np. dodatkowe konta/hasła, inne formy persystencji) po pierwszym włamaniu.

Kontekst / historia / powiązania

Pierwsze szerokie wykorzystanie luki w IOS XE Web UI odnotowano w październiku 2023 r. – badacze Cisco Talos opisali wtedy kolejne wersje implantu BadCandy rozmieszczanego po uzyskaniu nieautoryzowanego dostępu. Od tego czasu operatorzy zagrożenia iteracyjnie modyfikują webshell, co ułatwia im przetrwanie i unikanie detekcji.

Analiza techniczna / szczegóły luki

Rejestracja webshella. BadCandy jest dostarczany jako plik konfiguracyjny (np. cisco_service.conf), który dodaje nowy endpoint URI w serwerze www urządzenia. Zapytania pod ten endpoint przyjmują parametry umożliwiające wykonywanie dowolnych komend na urządzeniu (system/IOS).

Ewolucja i protokół. Talos opisał co najmniej trzy wersje BadCandy; jedna z nich weryfikuje obecność nagłówka X-Csrf-Token w żądaniach – to mechanizm zaciemniania/zabezpieczenia kanału C2.

Artefakty/detekcja. Publicznie dostępne procedury detekcyjne (Fox-IT) wskazują, że implant może zdradzać obecność m.in. poprzez nietypowe odpowiedzi HTTP (np. różnice w odpowiedziach 404 przy specyficznym kodowaniu %25 w ścieżce) oraz obecność charakterystycznych wpisów konfiguracyjnych. Repo zawiera skrypty do skanowania i IOC.

Wektor wejścia. Historycznie ataki zaczynały się od nadużycia podatności CVE-2023-20198 (przywileje w Web UI), co pozwalało napastnikowi przejąć kontrolę, wgrać webshell i utrzymać się w systemie. Cisco opublikowało poprawki i szczegóły ograniczające ekspozycję Web UI.

Praktyczne konsekwencje / ryzyko

  • Pełne przejęcie urządzenia brzegowego: możliwość modyfikacji konfiguracji routingu/ACL, wstrzykiwania reguł, przechwytywania/zmiany ruchu (MITM), a nawet pivotu w głąb sieci.
  • Trwałość po łataniu: nawet po instalacji poprawek implant lub dodatkowa persystencja (np. konta, klucze, hasła, zaplanowane zadania) może utrzymywać dostęp atakującego. ACSC wyraźnie podkreśla konieczność usuwania implantu i twardej rekonfiguracji.
  • Ryzyko łańcuchowe: zainfekowane urządzenie na perymetrze to idealny punkt do kradzieży danych uwierzytelniających i ataków na systemy wewnętrzne.

Rekomendacje operacyjne / co zrobić teraz

Priorytet 0: reakcja na incydent

  1. Sprawdź ekspozycję i kompromitację: użyj procedur ACSC i narzędzi Fox-IT do wykrywania BadCandy; ręcznie sprawdź nietypowe endpointy, pliki *.conf rejestrujące usługi www oraz różnice odpowiedzi HTTP opisane przez Fox-IT.
  2. Jeśli kompromitacja potwierdzona: odłącz z Internetu, usuń implant zgodnie z wytycznymi ACSC, przeprowadź rebuild/reimage urządzenia, a następnie wgraj aktualny, wolny od backdoorów obraz. Obowiązkowo rotuj wszystkie poświadczenia (lokalne, TACACS+/RADIUS), klucze i sekretne wartości.

Priorytet 1: usunięcie wektora wejścia
3. Zainstaluj poprawki dla podatności Web UI (m.in. CVE-2023-20198) na wszystkich instancjach IOS XE; wyłącz lub ogranicz Web UI do zarządzania wyłącznie z zaufanych adresów (MGMNT/VPN), stosuj ACL i AAA.

Priorytet 2: hardening i monitorowanie
4. Minimalizacja powierzchni ataku: wyłącz zbędne usługi HTTP/HTTPS, telemetry, legacy protokoły; wymuś MFA i RBAC dla administratorów.
5. Monitoruj wskaźniki naruszenia (IOC) i anomalie ruchu do/ze zdefiniowanego endpointu webshella; ustaw alerty na niestandardowe ścieżki URI i nagłówki żądań (np. X-Csrf-Token).
6. Logowanie i forensyka: eksportuj logi poza urządzenie (syslog/SIEM); pamiętaj, że sprawcy często modyfikują/wyłączają logowanie, dlatego artefaktów możesz szukać również w konfiguracji i ruchu.

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

Na tle innych kampanii przeciwko infrastrukturze sieciowej BadCandy wyróżnia lekki, „konfiguracyjny” sposób wpięcia webshella w serwer www IOS XE, bez ciężkiego binarnego implantu. W praktyce utrudnia to detekcję (artefakty przypominają „normalną” konfigurację usług), a napastnik może szybko zmieniać endpointy i parametry bez ingerencji w obraz systemu.

Podsumowanie / kluczowe wnioski

  • BadCandy to wciąż realne i aktywne zagrożenie dla niezałatanych urządzeń Cisco IOS XE – również w IV kw. 2025 r. (Australia: >150 aktywnych infekcji pod koniec października).
  • Samo łatane po incydencie nie wystarczy – trzeba usunąć implant, rotować poświadczenia i przeprowadzić pełny hardening oraz monitoring pod kątem persystencji.
  • Organizacje powinny traktować ekspozycję Web UI jako ryzyko krytyczne i ograniczać ją do minimum, a detekcję oprzeć o artefakty HTTP oraz niestandardowe endpointy.

Źródła / bibliografia

  • ACSC: „How your devices could be implanted and what to do about it (BADCANDY)” – wytyczne reagowania i usuwania. (cyber.gov.au)
  • ACSC (PDF): „Don’t take BADCANDY from strangers” – skala i procedury (X–XI 2025). (cyber.gov.au)
  • Cisco Talos: bieżąca analiza aktywnej eksploatacji IOS XE Web UI i wariantów BadCandy (2023–2024). (Cisco Talos Blog)
  • Cisco: Advisory dot. eksploatacji Web UI w IOS XE (CVE-2023-20198) i zalecenia ograniczenia ekspozycji. (sec.cloudapps.cisco.com)
  • BleepingComputer: artykuł podsumowujący ostrzeżenie Australii (31 października 2025). (BleepingComputer)

CISA dodaje luki XWiki (RCE) i VMware (LPE) do katalogu KEV: co to oznacza dla Twojej infrastruktury

Wprowadzenie do problemu / definicja luki

Amerykańska CISA dodała do katalogu Known Exploited Vulnerabilities (KEV) dwie luki aktywnie wykorzystywane w atakach: krytyczną RCE w XWiki (CVE-2025-24893) oraz wysokiej wagi lokalne podniesienie uprawnień w VMware Aria Operations/VMware Tools (CVE-2025-41244). Dodanie do KEV oznacza, że istnieją potwierdzone dowody eksploatacji w środowiskach produkcyjnych i organizacje powinny potraktować aktualizacje priorytetowo.

W skrócie

  • XWiki – CVE-2025-24893 (CVSS 9.8, RCE): niezalogowany atakujący może wykonać dowolny kod przez podatny mechanizm wyszukiwania SolrSearch.
  • VMware – CVE-2025-41244 (LPE): błąd umożliwia lokalne podniesienie uprawnień na VM-ach z VMware Tools/Aria Operations; producent potwierdził i wydał poprawki.
  • Status KEV: obie pozycje dodane 30 października 2025 r. – sygnał, że obserwuje się realne nadużycia.

Kontekst / historia / powiązania

Informacja o dodaniu do KEV pojawiła się po wcześniejszych raportach społeczności bezpieczeństwa: w przypadku XWiki badacze od miesięcy notowali aktywne nadużycia, m.in. łańcuch ataku kończący się uruchomieniem koparki kryptowalut. W VMware Broadcom/VMware udostępnił zestaw łatek i zaktualizował komunikat bezpieczeństwa.

Analiza techniczna / szczegóły luki

CVE-2025-24893 (XWiki, RCE):

  • Wejście użytkownika w komponencie SolrSearch nie jest właściwie sanityzowane, co pozwala na server-side template injection i wykonanie złośliwego kodu po stronie serwera.
  • Atak możliwy bez uwierzytelnienia – „gość” może wywołać RCE przygotowanym żądaniem HTTP.

CVE-2025-41244 (VMware Tools / Aria Operations, LPE):

  • Luka klasy local privilege escalation dotyczy środowisk z narzędziami VMware Tools i/lub zarządzanych przez Aria Operations; poprawki są dostępne w ramach advisory Broadcoma.

Praktyczne konsekwencje / ryzyko

  • XWiki (RCE): pełna kompromitacja instancji (CIA: H/H/H), instalacja backdoorów, kryptominerów, pivot do sieci wewnętrznej. Atak możliwy z Internetu.
  • VMware (LPE): eskalacja uprawnień na VM-ach może umożliwić wyjście poza ograniczenia kontenerów/usług i ułatwić lateral movement w środowiskach wirtualizacyjnych. (Charakter wniosku – na podstawie klasy podatności i oficjalnego advisory).

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytetowe łatanie (48–72h):
    • Zaktualizuj XWiki do wersji zawierającej poprawkę RCE oraz wszystkie zależności wtyczek wyszukiwania. (Sprawdź noty wydawnicze własnej dystrybucji/instancji).
    • Zastosuj łatki Broadcom/VMware dla Aria Operations/VMware Tools zgodnie z advisory (VMSA/komunikat Broadcom).
  2. Krótkoterminowe twardnienie:
    • Ogranicz dostęp z Internetu do interfejsów administracyjnych XWiki i Aria/Tools (WAF, IP allowlist).
    • Monitoruj nietypowe żądania do endpointów wyszukiwania XWiki (np. parametry text= w SolrSearch) i blokuj wzorce SSTI. (Na podstawie opisów CVE i obserwacji badaczy).
  3. Threat hunting / IR:
    • W XWiki szukaj artefaktów z kampanii coinminer (np. podejrzane pliki w /tmp, podejrzane żądania do Main/SolrSearch).
    • Na hostach VMware: przejrzyj logi pod kątem nietypowej aktywności lokalnych użytkowników na VM-ach z Tools oraz zgodności wersji z advisory.
  4. Zarządzanie ryzykiem ciągłe:
    • Włącz automatyczną korelację z CISA KEV – traktuj wpisy z KEV jako priorytet w SLA patchowania.

Różnice / porównania z innymi przypadkami

  • Klasa ataku: XWiki to zdalne RCE bez uwierzytelnienia (ekspozycja internetowa = najwyższe ryzyko). VMware to lokalne podniesienie uprawnień (wymaga wcześniejszego footholdu, ale w środowiskach VDI/serwerowych skutki mogą być krytyczne).
  • Ścieżka ataku: XWiki – wektor aplikacyjny HTTP; VMware – wektor lokalny na VM zarządzanej przez narzędzia VMware.

Podsumowanie / kluczowe wnioski

  • KEV = „alarm patchowania”: dodanie obu CVE do KEV potwierdza aktywne nadużycia i wymaga natychmiastowych działań.
  • XWiki (CVE-2025-24893) to łatwy, zdalny RCE – priorytet 1 w systemach publicznie dostępnych.
  • VMware (CVE-2025-41244) wzmacnia łańcuch ataku po początkowym włamaniu – niezwłocznie aktualizuj narzędzia i komponenty zarządzające.
  • Dowody z terenu (XWiki) pokazują faktyczne infekcje i kryptomining – włącz detekcje behawioralne i IoC.

Źródła / bibliografia

  • SecurityWeek: „CISA Adds Exploited XWiki, VMware Flaws to KEV Catalog”. (SecurityWeek)
  • CISA: alert o dodaniu dwóch pozycji do KEV (30.10.2025) oraz strona katalogu KEV. (CISA)
  • Broadcom (VMware): advisory dot. CVE-2025-41244 (Aria Operations / VMware Tools). (Support Portal)
  • NVD: wpis dla CVE-2025-24893 (XWiki, RCE). (NVD)
  • VulnCheck: obserwacje aktywnej eksploatacji CVE-2025-24893. (VulnCheck)

Open VSX: „GlassWorm” nie był robakiem? Eclipse gasi pożar i zaostrza zasady bezpieczeństwa

Wprowadzenie do problemu / definicja luki

Pod koniec października 2025 r. społeczność deweloperów VS Code i kompatybilnych edytorów odnotowała kampanię „GlassWorm”, w której do rejestru Open VSX trafiły złośliwe rozszerzenia kradnące poświadczenia i przejmujące stacje programistów. Zespół Open VSX (Eclipse Foundation) poinformował, że incydent został opanowany, a narracja o „samorozprzestrzeniającym się robaku” jest przesadzona — to raczej ukierunkowana kampania wykorzystująca wycieki tokenów do publikacji trojanizowanych paczek.

W skrócie

  • Zasięg: pierwsza fala objęła co najmniej 7 rozszerzeń w Open VSX; łączna liczba kompromitowanych instalacji była szacowana na ~35,8 tys. (różne źródła).
  • Wejście na platformę: atakujący wykorzystali wycieknięte tokeny wydawców, by publikować złośliwe wersje.
  • Stan obecny: znane złośliwe rozszerzenia usunięto, tokeny unieważniono, a Open VSX wdraża krótsze TTL tokenów i automatyczne skanowanie przy publikacji.
  • Spór o „robaka”: badacze mówili o „self-propagating worm”, ale Eclipse twierdzi, że to nie był klasyczny robak samoreplikujący, tylko malware dystrybuowane poprzez zaufany kanał.

Kontekst / historia / powiązania

Pierwsze publiczne raporty (20–21 października) opisywały „GlassWorm” jako nową formę ataku na łańcuch dostaw rozszerzeń VS Code i Open VSX; wskazywano m.in. na masowe kradzieże poświadczeń oraz mechanizmy C2 utrudniające wyłączenie infrastruktury. 27–31 października Eclipse opublikowało aktualizacje: unieważnienie tokenów, brak oznak aktywnych złośliwych paczek i planowane wzmocnienia procesu publikacji. 31 października SecurityWeek odnotował, że Open VSX tonuje przekaz o „robaku” i podkreśla ograniczony wpływ incydentu po działaniach zaradczych.

Analiza techniczna / szczegóły luki

Wektor wejścia: Zgodnie z Eclipse Foundation, atakujący uzyskali dostęp do tokenów wydawniczych (część wyciekła poza ekosystemem), co pozwoliło im publikować lub podmieniać rozszerzenia w Open VSX. Nie ma dowodów na kompromitację samej infrastruktury Open VSX.

Łańcuch ataku w rozszerzeniach:

  • ukryte fragmenty kodu (m.in. niewidoczne znaki Unicode) oraz wieloetapowe skrypty instalacyjne;
  • exfiltracja poświadczeń (NPM, GitHub, Git), tokenów i haseł;
  • komponenty do zdalnej kontroli stacji roboczej (np. ukryty VNC / proxy SOCKS), potencjalne celowanie w portfele krypto;
  • szybka dystrybucja dzięki automatycznym aktualizacjom rozszerzeń po stronie użytkowników.

Czy to „robak”? Wczesne raporty badaczy podkreślały cechy samo-rozprzestrzeniania przez aktualizacje rozszerzeń i infekowanie środowisk developerskich. Eclipse odpowiada, że brakowało klasycznego mechanizmu autonomicznej replikacji w sieci — propagacja następowała przez zaufany kanał publikacji i aktualizacji, a nie poprzez bezpośrednią „kopiarkę” malware’u. W praktyce oznacza to spór semantyczny, ale ryzyko operacyjne pozostaje wysokie.

Praktyczne konsekwencje / ryzyko

  • Utrata sekretów: przechwycone tokeny i klucze mogą umożliwić dalsze ataki na CI/CD, rejestry pakietów, repozytoria kodu i konta developerskie.
  • Pivot na infrastrukturę firmową: zainfekowana stacja developera to wygodny punkt startu do ruchu bocznego — proxy, VNC/RAT i kradzież sesji.
  • Reputacja i łańcuch dostaw: publikacja trojanizowanych rozszerzeń z legalnych kont uderza w zaufanie do marketplace’ów i narzędzi Dev.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów bezpieczeństwa i platform engineering:

  1. Inwentaryzacja rozszerzeń w środowiskach developerskich i CI — porównanie z listami kompromitacji z końca października; odinstalowanie, reinstalacja ze zweryfikowanych źródeł.
  2. Rotacja sekretów: natychmiastowa wymiana tokenów NPM/GitHub/Git, kluczy API, PAT; wdrożenie krótkiego TTL i automatycznego odwoływania. (Zgodnie z kierunkiem zmian ogłoszonym przez Eclipse).
  3. Higiena publikacji: wymuś 2FA dla kont wydawców, segregację ról, minimalny zakres uprawnień dla tokenów wydawniczych oraz monitorowanie prób publikacji.
  4. Monitoring endpointów Dev: reguły EDR pod kątem nieoczywistych procesów VS Code, tworzenia serwisów VNC, tuneli SOCKS, anomalii w ruchu do usług blockchain/kalendarzy (jeśli były wykorzystywane w C2 w innych wariantach).
  5. Skanowanie rozszerzeń przed dopuszczeniem do złotych obrazów deweloperskich; preferuj źródła z automatycznym skanem przy publikacji (Eclipse zapowiedziało wzmocnienia).

Dla indywidualnych developerów:

  • Aktualizuj VS Code/edytor i usuń podejrzane rozszerzenia; przejrzyj historię instalacji i uprawnienia.
  • Wyczyść menedżer haseł/kluczy (npm, git-credentials), zresetuj tokeny i włącz 2FA.
  • Obserwuj aktywność kont i repozytoriów pod kątem nietypowych commitów/publikacji.

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

Wcześniejsze kampanie przeciwko marketplace’om (np. wrześniowe fale złośliwych wtyczek „WhiteCobra”) bazowały na typowych infostealerach i szybkim odtwarzaniu pakietów po usunięciu. „GlassWorm” wyróżnia się intensywniejszym wykorzystaniem ukrytego kodu i atakiem na łańcuch publikacji (wykorzystanie tokenów), lecz — według Eclipse — bez cechy klasycznego, sieciowego self-wormingu. Wniosek: problemem nie jest tylko sama wtyczka, ale proces publikacji i zaufanie do kont wydawców.

Podsumowanie / kluczowe wnioski

  • Incydent opanowano: złośliwe rozszerzenia usunięto, wycieknięte tokeny cofnięto, a kontrolę publikacji w Open VSX zaostrzono.
  • Spór o definicję „robaka” nie zmienia faktu, że środowiska Dev są atrakcyjnym celem i wymagają takiej samej dyscypliny bezpieczeństwa jak produkcja.
  • Organizacje powinny traktować rozszerzenia jak kod produkcyjny: wersjonować, skanować, dopuszczać kontrolowanie, a publikacyjne tokeny chronić jak klucze do release pipeline’u.

Źródła / bibliografia

  • SecurityWeek: „Open VSX Downplays Impact From GlassWorm Campaign” (31 października 2025). (SecurityWeek)
  • Eclipse Foundation — „Open VSX security update, October 2025”. (Eclipse Foundation Staff Blogs)
  • Truesec: „GlassWorm — Self-Propagating VSCode Extension Worm” (21 października 2025). (Truesec)
  • BleepingComputer: „Self-spreading GlassWorm malware hits OpenVSX, VS Code registries” (20 października 2025). (BleepingComputer)
  • heise online (EN): „Open VSX: Eclipse Foundation draws consequences from GlassWorm attack” (31 października 2025). (heise online)